Anthropic 指南：何时把子智能体合并进主 Agent 循环

如果你在 Claude Platform 上构建的智能体包含多个子智能体，可以看看哪些适合用我们的迁移工具包合并进主智能体循环。它会运行一套引导式流程，帮你识别现有模式、评估替代方案，并验证最佳做法。其中还附带一个演示，你可以先在模拟系统上试用，再应用到自己的智能体上。

子智能体——拥有独立上下文窗口、工具和指令，由协调器统一调度——是智能体设计的核心组件。它们在验证、并行工作和模块化权限管理方面很有效。我们在 Claude Platform 上构建的许多自有智能体中都在使用它们，例如我们的多智能体研究系统。

不过，应用 AI 团队最近发现，一些企业智能体部署从把路由器、规划器和领域子智能体合并进主智能体循环中获益。在我们对多个企业部署的对比中，一个具备技能的单智能体在质量上常常优于“一个提示词包打天下”的设计和子智能体设计，而且每个任务的成本和延迟往往更低。

例如，一家公司发现，其面向客户的智能体中那十几个专家子智能体，让维持一致的品牌体验变得困难，还增加了延迟，损害了用户体验。

我们还经常看到一些提议的智能体设计遵循着相似的演进路径：一个意图分类器、一条固定的多步推理流水线、按用户群体划分的桶、独立的推荐分支，最上面再放一个多智能体编排器。

在这些情况下，反馈往往是：这套结构的大部分工作，模型已经不再需要它来做了；一个清晰的系统提示词、4-5 个轻量数据工具，再加上严格的输出护栏，就能覆盖大多数用例。

需要说明的是，子智能体仍有其用武之地，包括在研究前沿。以下情况适合使用它们：

• 单个智能体循环因上下文膨胀而出现可测量的性能下降，或者
• 多个任务需要并行处理，且各自使用全新的上下文窗口，任务完成后即可丢弃，或者
• 单个智能体难以选择合适的工具，或者系统提示词中存在相互冲突的指令。

但我们常常看到企业为每个团队或每类问题各配一个子智能体，智能体架构变成了组织架构图的翻版（康威定律在起作用）。

本文说明何时应考虑把子智能体合并进主智能体循环，并分享我们从大型组织构建智能体的实践中总结出的最佳做法。

大型组织构建智能体的失败模式

公司往往想构建一个智能体，把多个产品和能力统一到单一客户界面中。

通常，每项能力由不同团队负责，于是公司先让各团队各自构建智能体，再由中央平台团队在上面搭一个编排器。这可以采取多种结构，包括编排器-子智能体，或把特定智能体作为 MCP 工具暴露出来的单智能体。

这看起来是最简单的方案，却会立刻带来以下复杂性：

• 上下文管理：你需要决定智能体之间交换哪些上下文，而且往往在来回传递中丢失细节。
• 子智能体泛滥：每个团队都发布自己的子智能体，公司最终会有数百个相互重叠的子智能体，既没有强制执行的标准，也没有明确的负责人。
• 拼凑式提示词：每个团队都往系统提示词里加一句话，结果规则互相冲突，整体语气也不统一。
• 未经审核、过度本地化的评估：每个人都添加自己的评估，且过度针对自己的子任务做优化。整套评估没有人负责或维护，管理层依据的是被稀释、过度本地化的分数来做决策。
• 延迟：多智能体架构的复杂性会带来额外延迟。有一家客户把多智能体框架与单智能体循环做了对比评估，后者的运行速度快了约 2 倍。

采用带渐进式披露的智能体循环

上面说的编排器-子智能体设计，是协调跨团队构建的专家智能体的一种合理做法，但往往更有效的做法是通过技能渐进式披露上下文，以及通过工具搜索渐进式披露工具。也就是说，智能体先看到技能和工具的简短描述，只有在需要时才完整加载。

这种做法之所以合理，有三个原因：

• 共享上下文能带来更好的答案：对于运行时间较长的智能体，我们希望来自多个不同任务的上下文都留在主上下文窗口中。一个看过前面每一步结果的智能体可以把它们串联起来，从而产出比子智能体交回的一组摘要更丰富的结果和更深刻的洞察。这也意味着更少的上下文窗口和更少的有损交接。
• 渐进式披露可防止上下文膨胀：这项技术让团队可以构建单个智能体来完成各种各样的任务，而不必把所有上下文都立刻塞进一段很长的系统提示词里。这就消除了团队过去把工作拆分给子智能体的主要理由。事实上，我们把面向更高级模型的 Claude Code 系统提示词缩减了 80% 以上，其中就包括与渐进式披露技能和工具相关的删减。
• 模型能力更强了：从 Opus 4.5 开始，模型在单个循环中能处理的事情远超大多数团队的预期。Opus 5.5 无法关闭思考，Fable 5.1 也是如此，而且近期的模型会越来越多地叙述自己的进展、边做边检查，这让一些框架要素变得多余。每出一个新模型，你都可以把更多决策从框架移到模型本身。更简单的循环也更容易迁移到下一个模型；在我们帮助客户完成的迁移中，僵化的多智能体结构往往正是新模型无法承担更多工作的原因。

单智能体循环设计需要自律：精心管理的系统提示词、能在恰当时机触发的技能和工具描述，以及对上下文窗口、记忆和笔记的刻意处理。本文后续章节会进一步讨论迁移和设计方面的考量。

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

如果走多智能体路线，先从最简单的模式入手（生成器-验证器、编排器-子智能体或其他），只要能用就行。要有效划分边界，可以按上下文拆分：给每个子智能体分配一块几乎不依赖系统其余部分的工作，让它交回一份精简的结果（合适的候选包括独立的研究路径、接口清晰的独立组件，或黑盒验证）。如果按问题类型拆分智能体，它们就会玩起“传话游戏”， 信息来回传递，每交接一次保真度就下降一截。

如何把子智能体并入主智能体循环

很多团队已经在生产环境中部署了编排器和一组专家智能体。下面是我们建议逐步演进到的单循环设计：

• 一个模型、一个上下文窗口，运行开放式工具循环，并在运行框架中设定限制（轮次与成本预算、写入闸门）。
• 每一轮，模型发出一批工具调用。运行框架并行执行这些调用，并把原始结果返回给同一个模型，由它决定下一步：再发一批调用、向用户提问，还是给出答案。
• 当模型给出答案或触及预算时，循环停止。答案之后可以选择性地运行目标检查或验证器检查。
• 模型在第一轮就把计划写进上下文，并随着结果返回不断修订。这是相比编排器加专家智能体架构的主要变化：写计划的模型同时也是执行计划的模型，因此它能在轮次中途修改计划。
• Context still gets loaded, and is managed by the agent itself:
  • 不再需要从规则目录重写计划的代码步骤，因为每一步都由模型决定。
  • 顺序和领域流程移入技能。
  • 硬性限制（校验、审批闸门）以及对话中途出现的其他事项（例如记忆查询）移入工具。
  • 代码仍可用于加载任何成本低且几乎总是相关的内容（例如实体消解步骤），也可用于在循环调用的工具内部处理机械性环节（构造载荷、解析流、恢复澄清流程）。

这种单循环设计也有助于实现许多团队正在追求的目标状态（一个能理解用户高层目标并代其行动的智能体），因为它把智能体学到的一切都保留在同一个上下文中。

下面的建议说明了团队如何分阶段从多智能体系统过渡到单智能体循环，以及多个团队如何在此过程中持续为该智能体做贡献。

任务完成度评估

第一步是建立一套评估集，帮助你判断是否应该把某个子智能体并入主智能体循环。我们见过的有效评估结构是：由中央团队维护一套共享的端到端评估集，每个技能由所属团队随附一套较小的评估集。哪怕只有 10 个黄金样例，也足以起步。

按评分标准给智能体的最终消息打分，是跟踪答案质量的良好起点。在仍有编排器时，还应跟踪路由准确率（它是否选对了子智能体？）。子智能体并入后，则改为检查智能体是否加载了正确的技能或调用了正确的工具。逐步转向任务完成度评估是有益的，因为在比较不同架构时，这一点最为关键。

在内部系统难以回放、用户互动也难以模拟的环境里，这件事会很复杂。我们内部行之有效的一个做法是：在关键事件上记录时间戳，之后就能回放这些事件，作为有针对性的评测来运行。

逐步减少子智能体

要演进到单一智能体循环，就得把子智能体折叠成工具和技能。具体做法可以是合并领域子智能体、把它们作为工具调用，或者用技能和工具替代它们。

合并领域智能体

在第一次合并之前，先搭一个小规模的端到端评测。然后按共享上下文逐步折叠，从使用最多的子智能体开始。

合并专家：如果它们彼此串联输出、访问同一份数据，或者经常被一起调用，就适合合并。比如，如果生产流量中有相当大一部分是某个专家之后紧接着另一个专家，那这两个就是紧耦合的一对，可以考虑合并成一个领域智能体。

把子智能体作为工具调用

当上述三个条件之一成立、而你决定保留某个子智能体时，让主智能体把子智能体作为工具调用往往很有效，这样主智能体可以继续与用户保持对话。

我们只建议在子智能体需要直接与用户对话时，才做完整交接，由子智能体接管对话。其余情况都可以做成主循环里的一个技能加若干工具。

这样你就能为子智能体定义统一的响应结构，由主智能体用真实数据核验结论，并精简最终综合步骤的输入。这是个不错的起点，因为你不需要重写子智能体。它还能让你在决定是否把子智能体折叠进主智能体之前，先拿到任务完成评测的基线。

不过，有些失败模式仍会存在：

• 每个专家都有自己的提示词、上下文、负责团队和评测
• 每次调用返回的仍是有损摘要
• 每次调用都是一次嵌套的模型循环，会增加延迟

通过技能和工具把子智能体折叠进主智能体

一次折叠一个子智能体：把它的提示词变成技能，把它的 API 调用变成 MCP 工具。对比有和没有该子智能体时的评测表现，再决定保留哪些。

对比时不要只看最终得分，还要看哪些任务的结果发生了翻转。我们在一个示例客服智能体上测试时，把一个子智能体折叠进另一个，延迟降低了，但一个原本能通过的流程却坏了。主智能体自己拿着订单查询工具作答，没有向物流专家询问送达日期。

每次改动之前，确保评测覆盖生产环境中一起运行的每一条智能体链路，以及智能体绝不能违反的每一条规则，并且每个任务都要跑不止一次，因为像这样的问题只在两次运行中的一次里出现。

多个团队如何共同贡献一个智能体

领域推理可以从知识库、技能和 MCP 工具中检索。各个团队可以把归属对象从智能体转为技能和工具，由一个小型中央团队负责系统提示词和端到端质量。这包括在技能、工具和评测上线前进行审核。

MCP 工具

当智能体需要执行操作、从系统读取实时数据，或以固定格式返回结果时，工具就是合适的选择。你也可以把工具当作迁移期间继续调用子智能体的手段。我们建议按用户意图对工具分组（而不是每个 API 一个工具），因为系统提示词里的工具定义一旦超过 30 到 50 个，工具选择的效果往往会变差。

配合延迟加载使用工具搜索，限制硬性前置条件，并把必要的前置条件移入工具内部。例如，如果 Y 需要 X 的输出，就由 Y 的工具检查该输出，并返回一条模型可以据此行动的指令。按用户区分的权限也是同样的思路。每个工具都会检查发起调用的用户能看到什么、能做什么，并返回一段模型可读的明确拒绝，这样同一个循环就能服务权限级别不同的用户，不必为每个权限级别单独做一个智能体。

技能

当智能体需要了解一个团队如何做事时，技能就是合适的选择，比如步骤、规则，以及过去由专家子智能体的提示词承载的那些需要判断的取舍。

我们扩充技能库的思路，是把维护工作交还给编写技能的人。Claude 可以借助能够构建、测试和精简其他技能的技能来完成繁重的工作。

为防止技能泛滥，可以让每个团队指定 DRI 负责自己的技能，确保技能打磨到位、彼此区分明确，并附带适当的评估一起发布。

• /skill-creator 可以让你编写一开始就结构规范的新技能，并审查现有技能，对它们进行精简、去重和重构。
• /skill-doctor 可以让你看到技能库中每个技能的成本以及实际使用频率，并删除无用负担。

知识库

知识库适合存放智能体只需要偶尔用到的参考资料。事实和参考资料（政策、指标定义、产品规格）可以放在模型调用的搜索或查询工具后面，也可以作为参考文件随技能一起提供。避免让代码检索这些上下文并粘贴到提示词里。

加速这项工作的工具

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

• /claude-api build-eval：可以帮助创建第一套端到端评估，由中央团队负责，或者为每个团队提供随其技能一起发布的小型评估
• /claude-api prompt-audit：可以标出你的提示词、技能和工具描述中为旧模型编写的指令，并以 diff 形式提出修改建议。可以对系统提示词运行它，找出那些为更早的模型添加、如今却让智能体变慢或变僵化的规则。各团队的 DRI 也可以对自己的技能和工具描述运行它。
• /claude-api hillclimb：可以针对现有评估反复改进应用。它可用于“并入与保留”的对比（把一个子智能体并入技能加工具之后，让它反复迭代技能和工具描述，看看并入后的版本能否追平或超过原来的子智能体），也可用于你的系统提示词。
• /claude-api cost-optimize：分析你的调用都花在哪里，并针对提示词缓存、精简不必要的输入和输出 token、effort 以及模型选择等选项提出节省建议，每次只改一处。这有助于在既定设计下降低成本和延迟。

随着模型不断演进，我们对如何最好地使用它们的理解、以及围绕最佳实践的指导也在演进。因此，任何单一架构都不如它背后的原则重要：先度量，每次只改一处，保留经得起验证的改动。

这就是其中一种情况。随着模型能力更强、智能体运行时间更长，你的更多子智能体可以变成技能和工具。不过，你不必一步到位。先构建一个小规模的端到端评估，把一个子智能体折叠进去，只有当折叠后的版本得分更差时，才把它保留为子智能体，然后反复迭代。