子Agent越拆越多？Anthropic单Agent架构迁移实战指南

很多团队在搭建企业级 Agent，甚至使用 Claude Code 时，都习惯按业务或部门拆出一堆"专家子 Agent"。动辄十几个甚至上百个子 Agent 层层嵌套，觉得这样才算架构清晰。

但就在最近，Anthropic 官方给这股热潮泼了一盆冷水，甚至开始下场"劝退"了。

Anthropic Applied AI 团队对比了多个企业级 Agent 部署后得出一个反直觉的结论：配备了 Skills 的「单 Agent」，在输出质量上往往优于复杂的「子 Agent」架构，单任务的成本和延迟也更低。

这篇文章给出了非常具体的架构判断与迁移方法。核心思路是：按"上下文独立性"决定子 Agent 的去留，将提示词和 API 转化为 Skills 与工具，把合适的子 Agent 逐步并回主循环，最后用端到端评测确保迁移的稳定性。

子 Agent、Skills 和提示词各自该承担多少工作？下面就从多 Agent 架构为什么会变复杂说起。

一、多 Agent 架构为什么变复杂，何时可以简化

最近，一些企业将 Agent 架构中的路由器、规划器和各领域子 Agent 并回「主 Agent 循环」后，取得了显著收益。相比于「一个超长提示词包揽一切」或「复杂的多 Agent 架构」，单 Agent + Skills 的模式表现出了极大的优势。

在此之前，企业 Agent 设计常常沿着一条熟悉的路径层层叠加：先放意图分类器，再接固定的多步推理流程，然后按用户分群设置不同路径，分出独立的推荐分支，最后在最顶层加一个多 Agent 编排器。某家公司的客服 Agent 内部居然塞了 12 个专家子 Agent，不仅导致品牌调性难以统一，还大幅增加了延迟，严重损害了用户体验。

这类设计得到的反馈往往是：绝大部分架构都在替模型做"不再必要"的工作。 如今，一个清晰的系统提示词、4 至 5 个轻量数据工具和严格的输出限制，就能覆盖大部分用例。

很多企业之所以按团队或问题类型分别设置子 Agent，其实是让技术架构照搬了公司的组织架构图——这正是"康威定律"的体现。

当然，子 Agent 并非毫无价值。只有满足以下任一条件时，才建议保留子 Agent：

1. 上下文膨胀导致性能下降：单个 Agent 循环因上下文过长，出现了可测量的性能衰退。
2. 高并发且上下文独立：多个任务需要并行处理，且每个任务只需要一个用完即弃的全新上下文窗口。
3. 工具过载或指令冲突：单个 Agent 难以在海量工具中做出正确选择，或者系统提示词中的指令开始相互打架。

如果不满足以上三点，盲目在大型组织中推行多 Agent，往往会陷入以下五大常见失败模式：

• 上下文丢失：你需要决定 Agent 之间交换哪些信息，细节往往在来回传递中丢失。
• 子 Agent 泛滥：每个团队都交付自己的子 Agent，最后衍生出上百个彼此重叠的子 Agent，既无统一标准，也无明确负责人。
• 拼接提示词冲突：每个团队都在系统提示词里添上一句，最终规则相互冲突，整体口吻极其割裂。
• 评测局部化：各团队只围绕各自的子任务过度优化，完整评测集无人维护，管理层看到的分数被局部任务稀释，无法反映真实的端到端表现。
• 高昂的延迟：多 Agent 的跳转极其耗时。有客户实测对比发现，单 Agent 循环的运行速度约为多 Agent 架构的 2 倍。

二、解法：在单 Agent 循环中用渐进式披露按需加载

对于跨团队协作，与其用"编排器 + 子 Agent"来硬性拼凑，往往更有效的做法是回归单 Agent，并采用渐进式披露机制——通过 Skills 和 Tool Search（工具搜索）按需加载上下文与工具。Agent 一开始只看到简短描述，需要时才加载完整内容。

这种做法之所以在今天行得通，基于三个核心原因：

• 共享上下文能带来更好的回答。 对长时间运行的 Agent，来自不同任务的上下文都留在主上下文窗口中。Agent 看过此前每一步的结果，就能把它们联系起来。相比子 Agent 交回的一组摘要，这样可以产出更丰富的内容和更深入的见解，上下文窗口更少，有损交接也更少。
• 渐进式披露可以防止上下文膨胀。 团队因此能让一个 Agent 处理多种任务，无须把所有上下文一次性装进冗长的系统提示词。这消除了过去把工作拆给多个子 Agent 的主要原因。Claude Code 团队将 Claude Code 面向更先进模型的系统提示词缩减了 80% 以上（见 Claude 官方博客：The new rules of context engineering for Claude 5 generation models），其中包括对 Skills 和工具采用渐进式披露后删掉的内容。
• 模型能力更强了。 从 Opus 4.5 开始，模型在单个循环中能处理的工作已经远超大多数团队的预期。Opus 5.5 和 Fable 5.1 无法关闭思考。近期模型也越来越会在工作过程中说明进展并自我检查，让 harness 中的部分机制变得多余。每一代新模型都让你能把更多决策从 harness 转移给模型本身。更简单的循环也更容易迁移到下一代模型。在 Anthropic 协助客户完成的迁移中，僵化的多 Agent 结构常常阻碍新模型承担更多工作。

单 Agent 循环需要细致的设计和维护。系统提示词需要精心管理，Skills 和工具的描述要在合适的时机触发，上下文窗口、记忆和笔记也要妥善处理。

一个中央团队应负责端到端质量和系统提示词，并审核每个新工具和每套新评测，通过后再上线。中央团队保持精简，有助于快速迭代，降低大型组织内的协调成本。

如果选择多 Agent 路线，先从可行的最简模式开始，例如生成器加验证器、编排器加子 Agent，或其他简单结构。

划分边界时，应按上下文拆分。交给每个子 Agent 的工作应几乎不依赖系统其余部分，并让它返回精简的结果。相互独立的研究路径、接口清晰的独立组件和黑盒验证都是合适的候选。

如果按问题类型拆分 Agent，它们就会像玩传话游戏一样来回传递信息。每交接一次，信息保真度都会下降。

三、理想的单循环设计长什么样？

许多团队已经在生产环境中运行编排器和一组专家子 Agent。下面是 Applied AI 团队建议逐步演进到的单循环设计。

• 一个模型和一个上下文窗口运行开放式工具循环，harness 负责设置轮次与成本预算、写操作限制等约束。
• 每轮，模型发出一批工具调用。harness 并行执行这些调用，并把原始结果返回给同一个模型。模型再决定下一步是继续调用一批工具、向用户提问，还是给出答案。
• 模型给出答案或触及预算（参见 Claude 平台文档：Task budgets）时，循环停止。答案生成后，还可以选择运行目标检查或验证器检查。
• 模型在第一轮把计划写入上下文，并随着结果返回不断修订。这是单循环设计与编排器加专家 Agent 方案的主要区别。写计划和执行计划的是同一个模型，因此它可以在执行中途修改计划。
  • 不再需要由代码根据规则清单改写计划，因为每一步都由模型决定。
  • 执行顺序和领域流程移入 Skills。
  • 硬性限制，包括验证和审批关卡，以及对话中途出现的需求如记忆查询，移入工具。
  • 代码仍可用于加载成本低且几乎始终相关的内容，例如实体解析步骤；也可以在循环调用的工具内部处理机械性工作，例如构造请求体、解析数据流，以及在澄清问题后恢复执行。
• 上下文仍需加载，但改由 Agent 自己管理。

这种单循环设计也有助于实现许多团队期待的最终形态——让 Agent 理解用户的高层目标并代为行动，因为它积累的所有信息都保留在同一个上下文中。

四、实战指南：如何分步将子 Agent 并回主循环？

如果你已经在生产环境中运行着"编排器 + 专家子 Agent"，可以分四个阶段平稳迁移到单 Agent 循环。

第一步：用任务完成评测判断子 Agent 去留

第一步是建立一套评测集，帮助你判断某个子 Agent 是否适合并回主 Agent 循环。

Applied AI 团队见过一种有效的评测结构：中央团队负责一套共享的端到端评测集，各团队则随自己负责的 Skills 提供较小的评测集。即使只有 10 个黄金样例，也足够起步。

用评分标准给 Agent 的最终回复打分，是追踪回答质量的良好起点。

保留编排器时，还应追踪路由准确率，确认它是否选对了子 Agent。子 Agent 并回后，则改查 Agent 是否加载了正确的 Skills 或调用了正确的工具。

逐步转向任务完成评测也很有帮助，因为比较不同架构时，任务是否完成最为重要。

在内部系统难以重放、用户互动难以模拟的环境中，这项工作会比较复杂。Anthropic 内部有一种行之有效的做法：给重要事件记录时间戳，之后重放这些事件，运行有针对性的评测。

第二步：先合并紧密耦合的领域 Agent

向单 Agent 循环演进，要把子 Agent 并回主循环，改用工具和 Skills 承担相应工作。具体可以合并领域子 Agent、把子 Agent 作为工具调用，或用 Skills 和工具替换它们。

第一次合并前，先建立一套小型端到端评测集。随后按共享上下文确定并回对象，先处理使用最频繁的子 Agent。

应当合并那些输出彼此串联、访问同一份数据或经常被一起调用的专家 Agent。例如，如果生产流量中有相当一部分都是先调用一个专家 Agent，紧接着调用第二个，那么这两个 Agent 就紧密耦合，可以考虑合并为一个领域 Agent。

第三步：过渡期，将保留的子 Agent 降级为"工具"

如果符合上述三个条件之一，因而保留了子 Agent，可以让主 Agent 把它作为工具调用。这样，主 Agent 仍能持续与用户对话。

只有当子 Agent 需要直接与用户交谈时，才建议完整交接，让它接管对话。其他场景都可以由主循环中的 Skills 加工具处理。

这样可以为子 Agent 定义统一的响应结构，让主 Agent 对照真实数据核验结论，并精简最终汇总步骤的输入。

这是不错的第一步，因为你无须重写子 Agent。在决定把哪些子 Agent 并回主 Agent 之前，你还能先得到任务完成评测的基线。

不过，以下问题仍然存在：

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

第四步：彻底拆解，将子 Agent 转化为 Skills 和工具

每次只处理一个子 Agent，把它的提示词转成 Skills，把 API 调用转成 MCP 工具，彻底并入主 Agent。分别评测保留子 Agent 和并回后的表现，再决定保留哪一种方案。

比较时，别只看最终分数，还要看哪些任务的结果发生了翻转。

Anthropic 团队在一个示例客服 Agent 上测试时发现，把一个子 Agent 并回另一个子 Agent 后，延迟降低了，但一个原本能通过的流程却失败了。原因是主 Agent 持有订单查询工具，没有向配送专家询问送达日期，便自行给出了回答。

每次改动前，确保评测集覆盖生产环境中会共同运行的每一个 Agent 调用链，也覆盖 Agent 绝不能违反的每一条规则。每个任务都要至少运行两次，因为上述问题在两次运行中只出现了一次。

五、组织协同：多个团队如何共建一个单 Agent？

当子 Agent 被拆解后，各业务团队的交付物就从"独立的 Agent"变成了"知识库、Skills 和 MCP 工具"，并统一交由小型中央团队审核上线。这三类资产的维护规范如下：

MCP 工具（负责执行操作、读取实时数据、返回固定结构）

当 Agent 需要执行操作、从系统读取实时数据，或按固定结构返回结果时，工具是合适的选择。迁移期间，你也可以继续通过工具调用子 Agent。

Anthropic 建议按用户意图给工具分组，不要每个 API 都配一个工具，因为系统提示词中的工具定义超过 30 至 50 个后，模型往往会更难选对工具。

使用 tool search 并延迟加载工具。尽量减少硬性前置条件，必须保留的条件放进工具内部。例如，Y 依赖 X 的输出时，Y 的工具会检查该输出是否存在，并返回一条模型可据此处理的指令。

用户级权限也可以这样处理。每个工具检查调用者有权查看什么、执行什么，并在无权操作时返回一句模型能读懂的明确拒绝说明。这样，同一个循环就能服务权限不同的用户，无须为每个权限级别单独设置 Agent。

Skills（负责承载业务步骤、规则和判断方法）

当 Agent 需要了解团队如何开展工作，例如专家子 Agent 的提示词过去承载的步骤、规则和判断方法时，Skills 是合适的选择。

Anthropic 扩充 Skills 库的做法，是把维护工作交还给编写 Skills 的人。Claude 可以用 Skills 来构建、测试和精简其他 Skills，承担其中的繁重工作。

为了避免 Skills 无序扩张，可以让每个团队的直接负责人（DRI）管理各自的 Skills，确保它们设计得当、彼此有明确区分，并附带合适的评测。

• /skill-creator 可帮助你编写结构规范的新 Skills，也能审查现有 Skills，进行精简、去重和重组。
• /skill-doctor 可查看 Skills 库中每个条目的成本和实际使用频率，并删除无用条目。

知识库（负责存放偶尔需要的静态参考资料）

知识库适合存放 Agent 只偶尔需要的参考资料。政策、指标定义、产品规格等事实性内容和参考资料，可以放在搜索或查询工具后面，由模型按需调用，也可以作为参考文件放进 Skills。尽量避免用代码检索这些内容再粘贴到提示词中。

写在最后

随着模型不断演进，对最佳实践的认知也会持续刷新。因此，比起执着于某一种具体架构，背后的工程原则更重要：建立测量基线，每次只改一个变量，只保留经得起评测验证的方案。

面对多 Agent 架构的简化，完全不必一步到位。现在就可以先建一套包含 10 个样例的小型端到端评测集，挑一个最常用的子 Agent 尝试并回主循环。只有当并回版本的得分确实更低时，才保留它；否则，就果断用 Skills 和工具取代它，然后不断重复这一过程。

Agent 架构的取舍归根结底是工程判断，而不是意识形态之争。企业级 Agent 落地过程中，模型 API 的稳定性与成本控制同样是绕不开的环节，RouteFast.ai 提供了 Claude、GPT、Gemini 等主流模型的统一接入方案，值得关注。更多 AGI 工程实践与资源，也欢迎在云栈社区与开发者们一起交流。