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

如果你在 Claude Platform 中构建了一个包含多个子代理的代理，请查看哪些子代理可能适合使用我们的迁移工具包合并到主代理循环中。它会运行一个引导式工作流，以识别你的模式、评估替代方案并验证最佳方法。它还包含一个演示，你可以在模拟系统上试用，然后再在你的代理上运行。

子代理——拥有自己的上下文窗口、工具和指令，并由协调器编排的代理——是代理设计的核心组成部分。它们在验证、并行工作和模块化权限管理方面非常有效。我们在使用 Claude Platform 构建的许多自有代理中都使用了它们，例如我们的多代理研究系统。

然而，最近应用 AI 团队发现了一种企业代理部署模式，这些部署从将路由器、规划器和领域子代理合并到主代理循环中获益。在我们对多个企业部署的比较中，一个具备技能的单一代理在质量上经常优于“一个提示词包办一切”的设计和子代理设计，而且通常每个任务的成本和延迟更低。

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

我们还经常看到提议的代理设计遵循一种熟悉的演进路径：意图分类器、固定的多步推理流水线、用户细分桶、独立的推荐分支，以及顶层的多代理编排器。

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

需要明确的是，子代理仍有其用武之地，包括在研究前沿。在以下情况下使用它们：

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

但我们经常看到企业为每个团队或问题类型分配自己的子代理，代理架构变成了其组织架构图的翻版（康威定律在起作用）。

本文解释了何时应考虑将子代理合并到主代理循环中，并分享了我们从大型组织中构建代理所学到的最佳实践。

大型组织的代理构建失败模式

公司通常希望构建一个代理，将多个产品和能力统一到一个客户界面中。

通常，每项能力由不同的团队负责，因此公司一开始让每个团队构建自己的代理，然后由一个中央平台团队在其上构建编排器。这可以采取多种结构，包括编排器-子代理，或将特定代理作为 MCP 工具暴露的单一代理。

这看起来是最简单的解决方案，但会立即引入以下复杂性：

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

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

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

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

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

单智能体循环设计要求严格自律：精心管理的系统提示词、能在恰当时机触发的技能和工具描述，以及对上下文窗口、记忆和笔记的审慎处理。本文后续章节将深入探讨迁移和设计方面的考量。

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

如果你选择多智能体路线，请从能起作用的最简单模式（生成器-验证器、编排器-子智能体或其他）开始。通过按上下文划分：给每个子智能体分配一项几乎不需要系统其余部分参与的工作，并让它交回一个紧凑的结果来有效分解边界（合适的候选包括独立的研究路径、接口清晰的独立组件或黑盒验证）。当智能体按问题类型拆分时，它们会玩起“传话游戏”， 来回传递信息，每次交接都会降低保真度。

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

许多团队已经在生产环境中拥有一个编排器和一组专家智能体。以下是我们建议逐步采用的一种单一循环设计：

• 一个模型和一个上下文窗口运行开放式工具循环，并在 harness 中设置限制（轮次和成本预算、写入闸门）。
• 每一轮，模型发出一批工具调用。harness 并行运行它们，并将原始结果返回给同一个模型，由它决定下一步：再发一批、向用户提问，还是给出答案。
• 当模型给出答案或触及预算时，循环停止。可选地在答案之后运行目标或验证器检查。
• 模型在第一轮将计划写入上下文，并随着结果到达而修订计划。这是与编排器和专家智能体设置的主要区别：编写计划的模型也是执行计划的模型，因此它可以在轮次中途更改计划。
• 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 以及模型选择等选项提出节省建议，每次只改一处。这有助于在给定设计下降低成本和延迟。

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

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