构建 Agent：何时应将子智能体合并回主智能体循环

原文来源：Anthropic Claude Resources

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

子智能体（Subagents）——即拥有各自上下文窗口、工具和指令，并由协调器进行编排的智能体——是 Agent 设计的核心组件。它们在验证、并行工作和模块化权限管理方面都表现出色。我们自己用 Claude Platform 构建的许多 Agent 都使用了子智能体，例如多智能体研究系统。

不过最近，Applied AI 团队发现了一类企业级 Agent 部署模式：把路由层、规划层和领域子智能体合并回主 Agent 循环之后，效果反而更好。在我们对多个企业部署所做的对比中，带技能的单一 Agent在质量上经常同时优于“一个提示词包打天下”的设计和子智能体设计，而且每个任务的成本和延迟往往更低。

举例来说，有家公司发现，其面向客户的 Agent 内部那十几个专家子智能体，让始终如一的品牌一致体验变得难以维持，并且额外增加的延迟也损害了用户体验。

我们也经常看到一些被提出的 Agent 设计方案遵循着似曾相识的演进路径：一个意图分类器、一条固定的多步推理流水线、按用户群体划分的分桶、彼此独立的推荐分支，最后在上面再套一个多智能体编排器。

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

子智能体设计

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

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

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

本文会结合我们在大型组织内构建 Agent 的经验教训，说明何时应考虑把子智能体合并进主 Agent 循环。

大型组织构建 Agent 时的失败模式

企业通常希望构建一个 Agent，把多个产品和能力统一到一个客户界面中。

由于每种能力通常由不同的团队负责，企业的做法往往是先让各个团队分别构建自己的 Agent，再由一个中央平台团队在上面构建一个编排器。这可能呈现出多种结构，包括编排器—子智能体结构，或者把特定 Agent 作为 MCP 工具暴露出来的单一 Agent。

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

• 上下文管理： 你需要决定 Agent 之间交换哪些上下文，而在来回传递的过程中常常会丢失细节。
• 子智能体泛滥： 每个团队都发布自己的子智能体，于是企业最终拥有数百个相互重叠、既没有统一标准也没有明确归属的子智能体。
• 弗兰肯提示词（Frankenprompt）： 每个团队都往系统提示词里加一句话，结果规则相互冲突，语气也不统一。
• 未经审核、过度局部化的评测： 每个人都添加自己的评测，且过度针对自己的子任务进行优化。没有人负责或维护整套评测，而管理层却基于这些被稀释、过度局部化的分数做决策。
• 延迟： 多智能体架构的复杂性会增加延迟。有一家客户将他们的多智能体框架与单一 Agent 循环做了对比，发现后者的运行时间大约快了一倍。

使用带渐进式披露的 Agent 循环

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

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

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

单一 Agent 循环设计要求有纪律性：精心维护的系统提示词、能在恰当时机触发的技能与工具描述，以及对上下文窗口、记忆和笔记记录的刻意管理。本文后续章节会深入探讨迁移与设计上的考量。

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

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

按问题类型切分的子智能体

如何将子智能体合并进主 Agent 循环

许多团队已经在生产环境中部署了编排器和一组专家 Agent。下面是我们建议逐步实现的目标形态——单一循环设计：

• 一个模型、一个上下文窗口，运行一个开放式工具循环，并在框架中设置各种限制（轮次与成本预算、写入闸门）。
• 每一轮，模型发出一批工具调用。框架并行执行这些调用，并把原始结果返回给同一个模型，由它决定下一步：再发一批调用、向用户提问，还是给出答案。
• 当模型给出答案或触及预算时，循环停止。答案给出后，可以选择性地执行目标校验或验证器检查。
• 模型在第一轮就把计划写进上下文中，并在结果陆续返回时修订它。这正是与编排器加专家 Agent 方案的主要区别：制定计划的模型同时也是执行计划的模型，因此它可以在中途改变计划。
• 上下文依然会被加载，但由 Agent 自己来管理：
  • 不再需要那一步按照规则目录重写计划的代码环节，因为每一步都由模型来决定。
  • 顺序安排和领域操作流程移入技能。
  • 硬性限制（校验、审批闸门）以及对话中途出现的其他需求（例如记忆检索）移入工具。
  • 代码仍可用于加载那些廉价且几乎总是相关的内容（例如实体解析步骤），以及处理循环所调用的工具内部的机械性环节（构造请求载荷、解析流式数据、恢复一次澄清流程）。

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

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

任务完成度评测

第一步是建立一套评测集，用来判断是否应该把某个子智能体合并进主 Agent 循环。我们见过行之有效的评测结构是：由中央团队维护一套共享的端到端评测集，同时由各技能的归属团队随技能一起提供更小的评测集。哪怕只有 10 个黄金示例，也足够起步。

按评分标准（rubric）给 Agent 的最终回复打分，是跟踪回答质量的良好起点。当你还有编排器时，也应跟踪路由准确率（它是否选对了子智能体？）。一旦某个子智能体被合并进去，就要改为检查 Agent 是否加载了正确的技能或调用了正确的工具。逐步向任务完成度评测演进是有益的，因为这在比较不同架构时最为关键。

在内部系统难以重放、用户参与难以模拟的环境中，这会很复杂。我们在内部行之有效的一种做法是：为重要事件记录时间戳，以便日后重放，作为有针对性的评测来运行。

随时间逐步减少子智能体

向单一 Agent 循环演进，意味着把子智能体合并为工具和技能。这可以通过合并领域子智能体、把它们作为工具调用，或用技能和工具替代它们来实现。

逐步合并子智能体

合并领域智能体

在第一次合并之前，先构建一套小规模的端到端评测。然后按共享上下文进行合并，从使用最多的子智能体开始。

合并那些专家智能体——它们彼此串联依赖对方的输出、访问同一批数据，或者经常被一起调用。例如，如果生产流量中有相当大比例是“先调用某个专家、再调用另一个专家”，那它们就是一对紧耦合的组合，也就适合合并成一个领域 Agent。

以工具形式调用子智能体

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

我们只建议在子智能体需要直接与用户对话时，才采用完全交接（由子智能体接管对话）。其他一切都可以做成主循环中的技能加工具。

这样可以让你为子智能体定义统一的响应结构（schema）、由主 Agent 基于真实数据核验结论，并精简任何最终综合步骤的输入。这是个不错的第一步，因为你不需要重写这些子智能体。它也让你在决定是否把任何子智能体合并进主 Agent 之前，先在任务完成度评测上获得一个基线。

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

• 每个专家都有自己的提示词、上下文、归属团队和评测
• 每次调用仍然只回传一份有信息损耗的摘要
• 每次调用都是一个嵌套的模型循环，会增加延迟

通过技能和工具将子智能体合并进主 Agent

一次合并一个子智能体：把每个子智能体的提示词转成技能，把其 API 调用转成 MCP 工具。比较有子智能体和没有子智能体时的评测表现，然后决定保留哪些。

做比较时，不要只看最终分数，还要看看哪些任务的结果发生了反转。我们在一个示例客服 Agent 上测试时发现，把某个子智能体合并进另一个之后，延迟降低了，但同时也破坏了一个原本可以通过的流程。原因是主 Agent 自己握着订单查询工具就直接作答了，没有再向物流专家询问送达日期。

在每次改动之前，请确保你的评测为生产环境中所有会一起运行的 Agent 链路都准备了任务，并为 Agent 绝不能违反的每条规则都准备了任务；同时每个任务都要运行不止一次，因为像上面这样的问题，两次运行中也只出现了一次。

多个团队如何共同为一个 Agent 贡献力量

领域推理可以从知识库、技能和 MCP 工具中检索获得。各个团队可以把归属对象从 Agent 转向技能和工具，同时由一个小型中央团队保留系统提示词和端到端质量的所有权。这包括在新技能、工具和评测发布前对其进行审核。

MCP 工具

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

配合延迟加载使用工具搜索，限制硬性前置条件，并把任何必要的前置条件移入工具内部。例如，如果 Y 需要 X 的输出，就让 Y 的工具去检查它，并返回一条模型可以据此行动的指令。按用户区分的权限也是同样的道理。每个工具都检查调用用户能看到什么、能做什么，并返回一段模型能读懂的纯拒绝信息，这样同一个循环就能服务权限级别不同的用户，而无需为每个权限级别单独建一个 Agent。

技能

当 Agent 需要了解一个团队是如何开展工作的——例如过去由专家子智能体提示词承载的步骤、规则和判断取舍——技能就是合适的选择。

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

为避免技能泛滥，你可以让每个团队各设一名 DRI（直接责任人）负责自己的技能，确保它们制作精良、彼此区分，并随附相应的评测一同发布。

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

知识库

当 Agent 只需要偶尔用到某些参考资料时，知识库就是合适的选择。事实和参考资料（政策、指标定义、产品规格）可以放在模型调用的搜索或查询工具之后，也可以作为参考资料文件放进某个技能中。避免让代码去检索这些上下文再粘贴进提示词。

加速这项工作的工具

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

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

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

这就是一个这样的案例。随着模型能力增强、Agent 运行时间变长，你可以把更多的子智能体变成技能和工具。不过你不必一步到位。先构建一套小规模端到端评测，合并进一个子智能体；只有当合并后的版本得分更差时，才把它保留为子智能体，然后如此循环反复。