译文｜构建智能体：何时应将子智能体并入主智能体循环

大型组织构建智能体时的常见失败模式#

公司通常希望构建一个智能体，把多个产品和能力整合到同一个客户界面中。

一般来说，每项能力都由不同团队负责。因此，公司往往先让各个团队构建自己的智能体，再由中央平台团队在上面加一个编排器。这可以形成多种结构，例如“编排器—子智能体”，或者由一个智能体调用以 MCP 工具形式暴露的其他智能体。

这看起来是最简单的解决办法，却会立刻在以下方面引入复杂性：

• 上下文管理： 你需要决定智能体之间交换哪些上下文，而信息在来回传递时往往会丢失细节。
• 子智能体泛滥： 每个团队都发布自己的子智能体，公司最终可能拥有数百个功能重叠的子智能体，却没有统一执行的标准，也没有明确的负责人。
• 拼接而成的提示词： 每个团队都往系统提示词里加一句话，最终形成相互冲突的规则，也无法保持一致的表达风格。原文将其称为“Frankenprompt”。
• 未经审核、过度局部化的评测： 每个团队都加入自己的评测，并围绕各自的子任务过度优化。没有人负责或维护整套评测，而管理层依据的是被稀释、过于局部的分数。
• 延迟： 多智能体架构的复杂性会增加延迟。一位客户将自己的多智能体运行框架与单智能体循环进行比较，发现后者的运行速度约为前者的两倍。

在智能体循环中按需逐步加载信息#

前面描述的“编排器—子智能体”设计，是协调不同团队所构建的专业智能体的一种合理方式。不过，更有效的办法往往是：通过技能逐步加载上下文，通过工具搜索逐步加载工具。换句话说，智能体先看到技能和工具的简短描述，只有需要时才加载完整内容。原文将这种方式称为“渐进式披露”（progressive disclosure）。

这种做法可能更合适，原因有三点：

• 共享上下文能产生更好的答案。 对于长时间运行的智能体，我们希望把多个不同任务的上下文保留在主上下文窗口中。智能体看过前面每一步的结果，就能把这些结果联系起来。与只接收一组子智能体摘要相比，这有助于生成更丰富的输出和更好的洞见，也意味着更少的上下文窗口，以及更少有损的信息交接。
• 按需加载能防止上下文膨胀。 团队可以借此构建能完成多种任务的单智能体，而不必一开始就把所有上下文塞进一段很长的系统提示词。这消除了过去团队将工作拆给多个子智能体的主要理由。事实上，对于更先进的模型，我们已将 Claude Code 的系统提示词缩短了 80% 以上，其中一部分精简就来自按需加载技能和工具。
• 模型的能力更强了。 从 Opus 4.5 开始，模型已经能在单个循环中管理远超多数团队预期的工作。Opus 5.5 和 Fable 5.1 无法关闭思考；近期模型也越来越善于在执行过程中说明进展、检查自己的工作，因此运行框架中的某些部件变得多余。每一代新模型，都让你能把更多决策从运行框架交给模型本身。

更简单的循环也更容易迁移到下一代模型。在我们帮助客户进行的迁移中，僵硬的多智能体结构往往阻碍了新模型承担更多工作。

单智能体循环的设计仍然需要严格管理：认真维护系统提示词，让技能和工具的描述在正确时机触发加载，并有意识地处理上下文窗口、记忆和笔记。本文后面的章节会进一步讨论迁移与设计时需要考虑的问题。

应由一个中央团队负责端到端质量和系统提示词，并在每个新工具和新评测发布前进行审核。让这个中央团队保持小规模，有助于加快迭代，也能降低大型组织内部的协调成本。

如果选择多智能体路线，就从可能奏效的最简单模式开始，例如“生成器—验证器”或“编排器—子智能体”。有效划分边界的方法是按照上下文拆分：给每个子智能体分配一项不太依赖系统其他部分的工作，并让它返回简洁的结果。适合的任务包括独立的研究路径、接口清晰的独立组件，或者黑盒验证。

如果按问题类型拆分智能体，它们就会陷入“传话游戏”：信息来回交接，每次交接都会损失保真度。

图 2：按问题类型拆分与按上下文拆分的比较，以下为中文转写。

如何将子智能体并入主智能体循环#

许多团队已经在生产环境中使用编排器和一组专业智能体。我们建议逐步朝以下单循环设计演进：

• 一个模型、一个上下文窗口，运行开放式工具循环；运行框架负责设置限制，例如轮次预算、成本预算和写入审批关卡。
• 每一轮，模型发出一批工具调用。运行框架并行执行这些调用，把原始结果返回给同一个模型，由模型决定下一步：再调用一批工具、向用户提问，或者给出答案。
• 模型给出答案或达到预算上限时，循环停止。也可以选择在回答后，再进行一次目标检查或验证器检查。
• 模型在第一轮把计划写入上下文，随后根据收到的结果修改计划。这是与“编排器加专业智能体”架构的主要区别：制定计划和执行计划的是同一个模型，因此它可以在一轮执行过程中调整计划。
• 上下文仍然需要加载，但由智能体自己管理：
  • 不再需要专门用代码根据规则目录重写计划，因为模型会自行决定每一步。
  • 执行顺序和领域流程移入技能。
  • 硬性限制，例如校验和审批关卡，以及对话中途出现的其他需求，例如记忆查询，移入工具。
  • 对于成本低、几乎总是相关的内容，例如实体消歧步骤，仍然可以用代码加载。构造请求载荷、解析流式输出、在澄清后恢复执行等机械性工作，也可以由循环所调用的工具内部代码处理。

许多团队最终希望构建一种能够理解用户高层目标、并代表用户行动的智能体。单循环设计也有助于实现这一目标，因为它把智能体已经学到的所有信息保留在同一个上下文中。

下面介绍团队如何分阶段从多智能体系统迁移到单智能体循环，以及多个团队如何在此过程中继续为同一个智能体贡献能力。

多个团队如何共同建设一个智能体#

领域推理所需的内容，可以从知识库、技能和 MCP 工具中获取。各团队可以把负责对象从智能体转为技能和工具，由一个小型中央团队继续负责系统提示词和端到端质量。这包括在新技能、工具和评测发布前进行审核。

加快这项工作的工具#

我们最近发布了一组 Claude API 技能，可以帮助完成上述大部分工作。迁移工具包将这些技能串联成一套引导式流程，用于评估多智能体系统，并将其迁移到单智能体循环。工具包包含一个演示，你可以先试用，再把它用于真实系统：

• /claude-api build-eval： 帮助中央团队创建第一套端到端评测，或者帮助各团队创建随技能发布的小型评测集。
• /claude-api prompt-audit： 找出提示词、技能和工具描述中针对旧模型编写的指令，并以差异对比的形式提出修改建议。你可以用它检查系统提示词，找出那些曾为早期模型加入、如今却让智能体更慢或更僵化的规则。各团队的直接负责人也可以用它检查自己的技能和工具描述。
• /claude-api hillclimb： 根据已有评测，迭代改进应用。它可以用于比较“合并”与“保留”两种方案：将某个子智能体转换为技能和工具后，让它迭代优化技能与工具描述，观察合并后的版本能否达到或超过原子智能体的表现。它也可以用于改进系统提示词。
• /claude-api cost-optimize： 分析调用的开销分布，并逐项提出节省成本的方案，例如提示词缓存、削减不必要的输入和输出 token、调整思考投入程度，以及选择模型。它有助于在既定设计下降低成本和延迟。

随着模型演进，我们对如何更好地使用模型的理解，以及最佳实践建议，也会随之变化。因此，比起任何一种具体架构，更重要的是它背后的原则：先测量，每次只改变一件事，保留经得起检验的做法。

这里讨论的就是这样的情况。随着模型能力增强、智能体运行时间变长，更多子智能体可以转化为技能和工具。不过，你不必一步到位。先建立一套小型端到端评测，尝试并入一个子智能体；只有当合并后版本的评分更差时，才保留它作为子智能体，然后重复这个过程。