Building agents: When to fold subagents into your main agent loop

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

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

不过，应用 AI 团队最近发现了一类企业 Agent 部署模式：把路由器、规划器和领域子 Agent 折叠进主 Agent 循环后反而受益。在对多个企业部署的比较中，带 Skills 的单 Agent在质量上经常优于「一个提示词包打天下」的设计，也优于子 Agent 设计，而且每个任务的成本和延迟往往更低。

例如，一家公司发现其面向客户的 Agent 里有十几个专家子 Agent，导致一致的品牌体验难以维持，还增加了延迟，损害了用户体验。

我们还经常看到一种熟悉的演进路径：意图分类器、固定的多步推理流水线、用户分群桶、独立的推荐分支，最后再叠一个多 Agent 编排器。

在这些案例中，反馈往往是：这套结构里的大部分工作，模型已经不再需要别人替它做了；一个清晰的系统提示词、4–5 个轻量数据工具，再加上硬性的输出护栏，就能覆盖大多数用例。

需要说明的是，子 Agent 仍有其位置，在研究前沿尤其如此。以下情况适合使用子 Agent：

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

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

本文说明何时应考虑把子 Agent 折叠进主 Agent 循环，并总结我们在大组织中构建 Agent 的经验。

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

公司通常希望构建一个 Agent，把多个产品和能力统一到同一个客户界面里。

每项能力通常由不同团队负责，因此公司一开始会让各团队分别构建自己的 Agent，再由中央平台团队在上面加一个编排器。这种结构可以表现为编排器—子 Agent，也可以表现为一个 Agent 把特定 Agent 作为 MCP 工具暴露出来。

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

• 上下文管理： 你需要决定 Agent 之间交换哪些上下文，而在来回传递中经常会丢失细节。
• 子 Agent 泛滥： 每个团队都发布自己的子 Agent，最终公司会拥有数百个相互重叠、没有统一标准、也没有明确归属的子 Agent。
• 拼接怪物提示词（Frankenprompt）： 每个团队都往系统提示词里加一句话，结果规则相互冲突，也没有统一的语气。
• 未经统一审核、过度局部化的评测： 每个团队都加入自己的评测，而且过度针对自己的子任务优化。没有人负责维护整套评测，管理层却依据这些被稀释、过度局部化的分数做决策。
• 延迟： 多 Agent 架构的复杂性会增加延迟。一位客户把多 Agent Harness 与单 Agent 循环做对比，发现后者的运行速度快了约 2 倍。

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

上面描述的编排器—子 Agent 设计，是协调跨团队专家的一种合理方案；但更有效的做法往往是通过 Skills 渐进式披露上下文、通过工具搜索渐进式披露工具。也就是说，Agent 先只看到 Skills 和工具的简短描述，真正需要时才完整加载。

这种做法合理，原因有三：

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

单 Agent 循环设计需要纪律：精心管理的系统提示词、能在正确时机触发的 Skill 与工具描述，以及对上下文窗口、记忆和笔记的刻意处理。本文后面的小节会进一步讨论迁移与设计考量。

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

如果确实要走多 Agent 路线，先从能奏效的最简单模式开始（生成器—验证器、编排器—子 Agent 等）。要有效划分边界，可以按上下文拆分：给每个子 Agent 一块几乎不依赖系统其余部分的工作，并让它交回一个紧凑的结果（合适的候选包括独立的研究路径、接口清晰的独立组件，或黑盒验证）。如果按问题类型拆分 Agent，它们就会陷入「传话游戏」，在一次次交接中不断损失信息保真度。

如何把子 Agent 折叠进主 Agent 循环

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

• 一个模型、一个上下文窗口，运行开放式工具循环，并在 Harness 中设置限制（轮次与成本预算、写入闸门）。
• 每一轮，模型发出一批工具调用。Harness 并行执行这些调用，并把原始结果返回给同一个模型，由它决定下一步：再发一批调用、向用户提问，还是给出答案。
• 当模型给出答案或触及预算时，循环停止。答案之后可以选择运行一次目标检查或验证器检查。
• 模型在第一轮把计划写进上下文，并随着结果返回不断修订。这是与「编排器 + 专家 Agent」方案的主要区别：写计划的模型也是执行计划的模型，因此它可以在轮次中途改变计划。
• 上下文仍然会被加载，但由 Agent 自己管理：
• 不再需要「根据规则目录重写计划」的代码步骤，因为每一步都由模型决定。
• 顺序和领域流程移入 Skills。
• 硬性限制（校验、审批闸门）以及其他对话中途需要的东西（例如记忆查询）移入 工具。
• 代码仍然可以用来加载那些成本低、几乎总是相关的内容（例如实体消解步骤），也可以在循环调用的工具内部处理机械性部分（构造 payload、解析流、恢复澄清状态）。

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

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

任务完成度评测

第一步是建立一套评测集，用来判断是否应该把某个子 Agent 折叠进主 Agent 循环。我们见过有效的结构是：一套由中央团队负责的共享端到端评测集，加上每个团队随自己的 Skill 发布的小型评测集。哪怕只有 10 个黄金样例，也足以开始。

根据评分标准评估 Agent 的最终消息，是跟踪答案质量的好起点。当你还有编排器时，也应该跟踪路由准确率（它是否选对了子 Agent？）。某个子 Agent 被折叠进去之后，则改为检查 Agent 是否加载了正确的 Skill、调用了正确的工具。逐步走向任务完成度评测很有帮助，因为在比较不同架构时，这类评测最重要。

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

逐步减少子 Agent

向单 Agent 循环演进，意味着把子 Agent 折叠成工具和 Skills。可以通过合并领域子 Agent、把它们作为工具调用，或用 Skills 和工具替代它们来实现。

合并领域 Agent

在第一次合并之前，先构建一套小型端到端评测。然后按共享上下文折叠，从使用最多的子 Agent 开始。

合并专家 Agent时，优先选择那些会串联彼此输出、访问同一份数据、或经常被一起调用的 Agent。例如，如果生产流量中有相当比例是「先调用某个专家、再调用另一个专家」，那它们就是紧耦合的一对，适合合并成一个领域 Agent。

把子 Agent 作为工具调用

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

我们只建议在子 Agent 需要直接与用户对话时做完全交接。除此之外，其他都可以是主循环里的一个 Skill 加一组工具。

这样做可以让你为子 Agent 定义共享的响应 schema，由主 Agent 用真实数据验证结论，并裁剪任何最终综合步骤的输入。这是很好的第一步，因为你不需要重写子 Agent；它也给了你一个在决定折叠之前的任务完成度评测基线。

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

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

通过 Skills 和工具把子 Agent 折叠进主 Agent

一次折叠一个子 Agent：把它的提示词转成 Skills，把 API 调用转成 MCP 工具。比较折叠前后的评测表现，再决定保留哪个。

比较时不要只看最终分数，还要看哪些任务发生了翻转。我们在一个样本支持 Agent 上测试时，把一个子 Agent 折叠进另一个，延迟降低了，但也破坏了一个原本通过的流程：主 Agent 自己拿着订单查询工具直接回答，没有向物流专家询问送达日期。

在每次改动之前，确保你的评测覆盖生产环境中每一组会一起运行的 Agent 链路，以及每一条 Agent 不得违反的规则；并且每个任务都要运行不止一次，因为像上面这样的问题只在一半的运行中出现。

多个团队如何共同贡献给同一个 Agent

领域推理可以从知识库、Skills 和 MCP 工具中获取。各个团队可以把归属从「Agent」转向「Skills 和工具」，由一个小型中央团队保留系统提示词和端到端质量的所有权。这包括在新 Skills、工具和评测上线前进行审核。

MCP 工具

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

使用工具搜索配合延迟加载，限制硬性前置条件，并把必要的条件移进工具内部。例如，如果 Y 需要 X 的输出，Y 的工具就检查它，并返回一条模型可以据以行动的指令。按用户的权限也同理：每个工具检查调用用户能看到或做什么，并返回模型可以读懂的明确拒绝，这样一个循环就能服务不同权限级别的用户，而不必为每个权限级别各建一个 Agent。

Skills

当 Agent 需要知道一个团队如何做事时——比如某个专家子 Agent 的提示词过去承载的步骤、规则和判断——Skills 是合适的选择。

我们扩展 Skill 库的方法是：把维护工作交还给编写 Skill 的人。Claude 可以借助能够构建、测试和修剪其他 Skill 的 Skills 来完成繁重工作。

为了防止 Skill 泛滥，可以让各团队的直接负责人（DRI）负责自己的 Skills，确保它们制作精良、彼此区分，并配有适当的评测。

• /skill-creator 让你创作一开始就结构良好的新 Skill，并审计现有 Skill，对其进行修剪、去重和重构。
• /skill-doctor 让你看到技能库中每个 Skill 的成本和实际使用频率，并删除无用负担。

知识库

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

加速这项工作的工具

我们最近发布了一组 Claude API Skills，可以帮助完成上面提到的大部分工作。我们的迁移工具包把这些 Skills 串成一套引导式工作流，用于评估并把多 Agent 系统迁移到单 Agent 循环。它包含一个演示，可以在应用到真实系统之前先试用：

• /claude-api build-eval： 帮助创建第一套由中央团队负责的端到端评测集，或由各团队随自己的 Skill 发布的小型评测集。
• /claude-api prompt-audit： 标出提示词、Skills 和工具描述中为旧模型编写的指令，并以 diff 形式提出修改建议。可以对系统提示词运行，找出那些为更早模型添加、如今却让 Agent 更慢或更僵化的规则。各团队的 DRI 也可以对自己的 Skills 和工具描述运行。
• /claude-api hillclimb： 针对现有评测迭代改进应用。可用于「折叠后 vs 保留」的比较（把一个子 Agent 折叠成 Skill 加工具后，让它迭代 Skill 和工具描述，看看折叠版本能否追平或超过子 Agent），也可以用于系统提示词。
• /claude-api cost-optimize： 分析调用都花在哪里，并逐项提出节省建议，例如提示词缓存、裁剪不必要的输入和输出 token、调整 effort、选择模型。这有助于在给定设计下降低成本和延迟。

随着模型演进，我们对如何最好地使用模型的理解、以及最佳实践指南也会演进。因此，任何单一架构都不如它背后的原则重要：测量、一次只改一件事、保留真正有效的做法。

这就是一个例子。随着模型能力增强、Agent 运行时间变长，越来越多的子 Agent 可以变成 Skills 和工具。你不必一步到位：先构建一套小型端到端评测，折叠一个子 Agent，只有当折叠版本得分更差时才把它保留为子 Agent，然后重复这个过程。