Anthropic用Claude造Claude：大脑与双手分离的工程哲学

Anthropic 如何用 Claude 来构建 Claude？在近期一场技术分享中，Katelyn Lesse 与 Angela Jiang 围绕 Opus 5.5、Claude Platform 以及 AI Agent 背后的工程实践展开讨论。其中一个核心命题是：把「大脑」和「双手」分开。这不是一句修辞，而是当前构建可靠 AI Agent 系统时一条越来越清晰的工程原则。

为什么要把「大脑」和「双手」拆开

所谓「大脑」，指的是模型本身的推理与决策能力；「双手」则是模型与外部世界交互的工具层——读写文件、调用 API、执行代码、检索信息。当两者耦合过紧时，任何一个环节的变动都会牵动整个系统，调试和迭代都变得困难。

Anthropic 的做法是把模型能力与工具调用抽象成两层：模型专注于理解意图、规划步骤、判断结果；工具层负责稳定执行并回传结构化反馈。这样，模型升级不会破坏工具契约，工具替换也不影响推理逻辑。对于需要长时间运行、多步骤协作的 Agent 而言，这种解耦是保持系统可维护性的前提。

从工程角度看，这一原则还带来一个隐性收益：可观测性。当每一类交互都有明确的接口和边界，团队就能分别度量「决策是否正确」和「执行是否成功」，而不是面对一个黑盒输出无从下手。

工具调用（Tool Use / Function Calling）机制是理解「双手」层的技术前提。现代大模型并不直接操作系统，而是由模型输出结构化的调用意图（通常是 JSON，包含工具名与参数），由外部运行时负责解析、执行并把结果作为新的上下文回传给模型，形成「推理—调用—观察」的循环。因此工具契约的稳定性取决于两点：一是 schema 定义的严格程度，二是运行时对错误、超时、非法参数的处理策略。当工具数量增多时，如何让模型在数十个工具中做出正确选择，还涉及工具描述的质量与检索式工具路由等设计问题，这也是平台层需要封装的复杂度。

Claude Platform：把 Agent 的基础设施做厚

如果说「大脑与双手分离」是设计哲学，Claude Platform 就是承载它的落地形态。Lesse 和 Jiang 在讨论中提到，平台层的职责不是替开发者做决策，而是提供稳定的运行时、工具接入方式和上下文管理能力，让开发者能把注意力放在业务逻辑上。

这与当前 Agent 开发的一个普遍痛点直接相关：早期的 Agent 演示往往止步于「能跑通一次」，真正要上线时才发现上下文会膨胀、工具调用会失败、长任务会中断。平台化的思路是把这些「脏活」收进基础设施，让模型侧保持轻量。

对开发者而言，这意味着选型时应关注平台是否提供了清晰的工具抽象、是否支持多轮长任务的上下文管理、以及失败后的恢复机制，而不只是比较单次推理的质量。

**上下文管理（Context Management）**是长任务 Agent 的核心工程难题。模型拥有有限的上下文窗口，而多步骤任务会不断累积工具返回结果、对话历史和中间产物，很容易触达上限或稀释关键信息。常见做法包括：对历史进行摘要压缩、只保留与当前目标相关的片段、把大体积中间结果外置到文件或存储中仅保留引用、以及在多轮之间维护显式的任务状态。这些策略直接决定 Agent 能否稳定跑完数十步的任务，也解释了为何文章强调平台应把上下文管理收进基础设施，而非交由每个业务方各自实现。

Opus 5.5 的定位：更强的「大脑」意味着什么

讨论中提到的 Opus 5.5 代表了模型这一侧的持续演进。更强的模型能力对 Agent 系统的影响并不是线性的——它会把瓶颈从「模型想不出来」转移到「系统接不住」。

换句话说，当模型的规划和推理能力提升后，工具层的稳定性、上下文的组织方式、以及结果校验的严谨程度，反而成为决定整体表现的关键。这也解释了为什么 Anthropic 会把「用 Claude 构建 Claude」作为一条实践路径：模型参与自身工具链和开发流程的改进，本身就是对 Agent 能力的一次真实压力测试。

需要说明的是，上述关于 Opus 5.5 的讨论来自 Lesse 与 Jiang 的分享，具体能力边界仍需结合官方文档和实际测试判断，本文不对其性能做量化断言。

**自举（Bootstrapping）**在软件工程中原本指用一门语言的编译器编译它自身，或用现有工具链构建下一代工具链。应用到 AI 开发场景，自举意味着模型成为自身研发流程的一部分，参与生成、审查和改进构建 Agent 所需的代码与工具，从而形成「模型改进工具—工具提升模型应用效果—效果反馈暴露短板」的循环。这一思路的价值在于反馈信号来自真实任务而非合成基准，但也存在风险：当模型同时充当产出方与评判方时，容易放大系统性偏差，因此需要独立的人工评审与自动化测试作为制衡。

用 Claude 造 Claude：自举式开发的意义与边界

「用 Claude ships Claude」这个说法容易被理解为营销口号，但放在工程语境下，它描述的是一个可验证的闭环：让模型参与代码编写、测试生成、文档整理、问题定位等开发环节，再把实践中暴露的短板反馈到工具层和平台设计上。

这种自举式开发的价值在于缩短反馈周期。模型在真实开发任务中的表现，比任何基准测试都更贴近生产环境。不过它的边界也很明显：模型可以加速执行，但目标设定、架构决策和质量标准的判断仍然需要人来把关。把「大脑」和「双手」分开的原则，同样适用于人机分工——人负责定义问题，模型负责扩展解法。

对正在构建 Agent 产品的团队来说，这场分享给出的可操作启示大致有三点：一是尽早把工具层抽象出来，避免与模型逻辑纠缠；二是把平台能力当作长期资产而非一次性脚手架；三是在模型能力快速演进时，把优化重心放在系统鲁棒性上，而不是追逐单点指标。

AI Agent 的竞争，正在从「谁的模型更聪明」转向「谁的系统更可靠」。而可靠性的起点，往往就是那一次看似简单的拆分。