原文：https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop

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

不过，Applied AI 团队最近发现，一些企业级 Agent 部署通过将路由器、规划器和领域 Subagent 并入主 Agent 循环而获益。在多项企业部署的对比中，配备 Skills 的单个 Agent在输出质量上往往同时优于“一个 Prompt 包揽一切”的设计和 Subagent 设计，而且单个任务的成本与延迟通常也更低。

例如，有家公司发现，面向客户的 Agent 中包含十余个专家 Subagent，不仅难以持续提供符合品牌调性的体验，还增加了延迟，损害了用户体验。

我们还经常看到一些拟议中的 Agent 设计沿着熟悉的路径展开：先做意图分类，再进入固定的多步推理流水线，然后划分用户群组、设置独立的推荐分支，最后在最上层加一个多 Agent 编排器。

在这些案例中，反馈往往指向同一个问题：这些结构大多在替模型做它已经不需要别人代劳的工作。一个清晰的系统 Prompt、4–5 个轻量数据工具，再加上明确的输出护栏，便足以覆盖大部分用例。

需要明确的是，Subagent 仍有其用武之地，包括在研究前沿。遇到以下情况时，应当使用 Subagent：

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

但太多企业习惯于让每个团队或每种问题类型各自拥有一个 Subagent，最终让 Agent 架构变成组织架构图的翻版，正是康威定律的体现。

本文将结合我们在大型组织中构建 Agent 时总结的最佳实践，说明何时应该考虑将 Subagent 并入主 Agent 循环。

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

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

由于每项能力通常由不同团队负责，企业往往先让各团队分别构建自己的 Agent，再由中央平台团队在上面搭建编排器。具体形式既可以是“编排器—Subagent”，也可以是单个 Agent 将特定 Agent 作为 MCP 工具调用。

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

• 上下文管理： 你需要决定 Agent 之间交换哪些上下文，而细节往往会在来回传递中丢失。
• Subagent 泛滥： 每个团队都交付自己的 Subagent，企业最后可能积累数百个相互重叠的 Subagent，既没有强制标准，也无人明确负责。
• Frankenprompt： 每个团队都往系统 Prompt 里加一句话，最终规则相互冲突，表达风格也无法统一。
• 未经验证、过度局部化的评估： 每个团队都会添加自己的评估，并针对各自的子任务过度优化。没有人负责或维护整套评估，领导层只能根据被稀释、仅反映局部的分数做出决策。
• 延迟： 多 Agent 架构的复杂性会增加延迟。一位客户将其多 Agent 运行框架与单 Agent 循环进行对比，发现后者的运行速度约为前者的 2 倍。

采用渐进式披露的 Agent 循环

上述“编排器—Subagent”设计是协调跨团队专家的一种合理方式，但更有效的做法往往是通过 Skills 渐进式披露上下文，并通过 Tool Search 渐进式披露工具。换言之，Agent 起初只看到 Skills 和工具的简短描述，只有在需要时才加载完整内容。

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

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

单 Agent 循环设计要求严格的工程纪律：精心管理系统 Prompt，确保 Skill 和工具描述能在恰当时机触发，并有意识地处理上下文窗口、记忆和笔记记录。后续章节将深入讨论迁移与设计方面的注意事项。

应由一个中央团队负责端到端质量和系统 Prompt，并在任何新工具或评估上线前完成审查。保持这支团队的精简，有助于加快迭代，降低大型组织中的协调成本。

如果选择多 Agent 路线，应从可能有效的最简模式开始，例如“生成器—验证器”“编排器—Subagent”等。要通过按上下文划分来有效设定分解边界：给每个 Subagent 分配一项几乎不依赖系统其他部分的工作，并让它返回紧凑的结果。独立的研究路径、接口清晰的独立组件或黑盒验证，都是不错的选择。如果按问题类型拆分 Agent，它们就会陷入“传话游戏”：信息在 Agent 之间反复传递，每交接一次，保真度就下降一次。

如何将 Subagent 并入主 Agent 循环

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

• 一个模型、一个上下文窗口，运行开放式工具循环，并在运行框架中设置限制，包括轮次与成本预算、写入闸门。
• 每一轮，模型发出一批工具调用。运行框架并行执行这些调用，再将原始结果返回给同一个模型，由模型决定下一步：再执行一批调用、向用户提问，或者给出答案。
• 当模型给出答案或触及预算上限时，循环停止。也可以选择在此之后运行目标检查或验证器检查。
• 模型在第一轮就把计划写入上下文，并随着结果返回不断修订。这是它与“编排器加专家 Agent”架构的主要区别：制定计划的模型也负责执行计划，因此能够在执行过程中调整计划。
• 上下文仍会加载，但改由 Agent 自己管理： 不再需要由代码根据规则目录重写计划，因为每一步都由模型决定。 执行顺序和领域流程移入 Skills。 硬性限制，例如验证和审批闸门，以及对话过程中出现的其他事项，例如记忆查询，移入工具。 对于成本低廉且几乎总是相关的加载工作，例如实体解析，仍可使用代码完成；对于循环所调用工具内部的机械性工作，例如构造负载、解析流式数据、恢复澄清流程，也仍可交由代码处理。

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

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

任务完成评估

第一步是创建一套评估集，帮助你判断是否应该将某个 Subagent 并入主 Agent 循环。我们见过一种行之有效的评估结构：由中央团队维护一套共享的端到端评估集，各团队则随自己负责的 Skill 提供较小的评估集。即使只有 10 个金标准样例，也足以起步。

根据评分细则对 Agent 的最终回复打分，是跟踪答案质量的良好起点。只要编排器仍然存在，你还应该跟踪路由准确率，也就是它是否选对了 Subagent。一旦某个 Subagent 被并入主循环，就应改为检查 Agent 是否加载了正确的 Skill 或调用了正确的工具。随着时间推移，逐步将重心转向任务完成评估会很有帮助，因为比较架构时，这一点最为重要。

在内部系统难以重放、用户参与难以模拟的环境中，这项工作可能很复杂。我们内部采用过一种有效方法：为重要事件记录时间戳，以便之后重放，并开展有针对性的评估。

逐步减少 Subagent

向单 Agent 循环演进，意味着将 Subagent 转化为工具和 Skills。具体可以通过合并领域 Subagent、将它们作为工具调用，或者用 Skills 和工具取而代之来实现。

合并领域 Agent

在第一次合并前，先构建一个小型端到端评估。然后，根据共享上下文的情况逐步并入，从使用频率最高的 Subagent 开始。

如果专家 Agent 之间存在以下情况，就应合并：一个 Agent 的输出会成为另一个 Agent 的输入、它们访问相同的数据，或者经常被一起调用。例如，如果生产环境中有相当一部分流量都是先调用一个专家 Agent，紧接着调用第二个，那么二者就是一对紧密耦合的专家 Agent，适合合并为一个领域 Agent。

将 Subagent 作为工具调用

当上述三个条件之一成立、需要保留 Subagent 时，让主 Agent 将 Subagent 作为工具调用，往往是一种有效方式，这样主 Agent 就能继续与用户对话。

只有当 Subagent 需要直接与用户交流时，我们才建议完全移交，由它接管对话。其他一切都可以由主循环中的 Skill 加工具处理。

这样一来，你可以为 Subagent 定义统一的响应 Schema，让主 Agent 根据真实数据验证结论，并精简最终综合步骤的输入。这是一个很好的第一步，因为你无须重写 Subagent。在决定是否将任何 Subagent 并入主 Agent 之前，它还能为任务完成评估提供一个基线。

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

• 每个专家 Agent 仍有自己的 Prompt、上下文、负责团队和评估；
• 每次调用仍会返回一份有损摘要；
• 每次调用仍是一个嵌套的模型循环，会增加延迟。

通过 Skills 和工具将 Subagent 并入主 Agent

每次处理一个 Subagent，把它的 Prompt 转化为 Skill，把 API 调用转化为 MCP 工具，逐步将其并入主 Agent。比较有无该 Subagent 时的评估表现，再决定是否保留。

比较时，不要只看最终得分，还要检查哪些任务的结果发生了反转。我们在一个示例客服 Agent 上测试时，将一个 Subagent 并入另一个 Subagent 虽然降低了延迟，却也破坏了一个原本能够通过的流程：主 Agent 握着订单查询工具便自行作答，没有向物流专家询问送达日期。

每次修改前，都要确保评估覆盖生产环境中每一条会连续运行的 Agent 链，以及 Agent 必须遵守的每一条规则。每个任务还应运行不止一次，因为上述故障在两次运行中只出现了一次。

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

领域推理所需的内容可以从知识库、Skills 和 MCP 工具中检索。各团队可以把负责对象从 Agent 转为 Skills 和工具，由一支精简的中央团队继续负责系统 Prompt 和端到端质量，包括在上线前审查新的 Skills、工具和评估。

MCP 工具

当 Agent 需要执行操作、从系统读取实时数据，或以固定结构返回结果时，工具是合适的选择。迁移期间，你也可以借助工具继续调用 Subagent。我们建议按用户意图对工具分组，而不是每个 API 对应一个工具，因为一旦系统 Prompt 中的工具定义超过 30–50 个，工具选择效果往往会下降。

使用支持延迟加载的 Tool Search，尽量减少硬性前置条件，并将确实需要的前置条件移入工具。例如，如果 Y 需要 X 的输出，Y 的工具应检查该输出是否存在，并返回一条模型可以据以行动的指令。按用户划分的权限也采用同样的方式。每个工具检查调用用户有权查看或执行的内容，并返回模型能够理解的明确拒绝信息。这样，同一个循环就能服务拥有不同访问权限的用户，而无须为每个权限级别设置单独的 Agent。

Skills

当 Agent 需要了解一个团队如何开展工作，例如过去由专家 Subagent 的 Prompt 所承载的步骤、规则和判断依据时，Skills 是合适的选择。

我们扩展 Skill 库的方法，是把维护工作交还给编写 Skills 的人。Claude 可以借助能够构建、测试和精简其他 Skills 的 Skills，承担繁重的工作。

为了防止 Skills 泛滥，可以为每个团队设置 DRI，由其负责各自的 Skills，确保这些 Skills 设计精良、彼此区分明确，并附带适当的评估。

• /skill-creator 可以帮助你编写结构良好的新 Skills，也能审查现有 Skills，对其进行精简、去重和重构。
• /skill-doctor 可以显示库中每个 Skill 的成本和实际使用频率，帮助你删除无用内容。

知识库

对于 Agent 只是偶尔需要的参考资料，知识库是合适的选择。事实和参考资料，例如政策、指标定义、产品规格，可以放在搜索或查询工具之后，由模型按需调用；也可以作为参考文件随 Skill 一起提供。应避免由代码检索这些上下文，再粘贴到 Prompt 中。

加速这项工作的工具

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

• /claude-api build-eval： 可以帮助中央团队创建第一套端到端评估集，也可以帮助各团队创建随 Skill 提供的小型评估集。
• /claude-api prompt-audit： 可以标记 Prompt、Skills 和工具描述中面向旧模型编写的指令，并以 diff 形式提出修复建议。你可以用它检查系统 Prompt，找出为早期模型添加、如今却导致 Agent 变慢或更加僵化的规则。各团队的 DRI 也可以用它检查自己的 Skills 和工具描述。
• /claude-api hillclimb： 可以基于现有评估，迭代改进应用。它既可用于“并入主循环还是保留 Subagent”的比较——将一个 Subagent 转化为 Skill 加工具后，让它迭代优化 Skill 和工具描述，观察并入后的版本能否达到或超过 Subagent 的表现——也可用于优化系统 Prompt。
• /claude-api cost-optimize： 分析调用成本的去向，每次只修改一项，从 Prompt 缓存、精简不必要的输入和输出 Token、Effort、模型选择等方面提出节省成本的建议。这有助于降低既定设计的成本与延迟。

随着模型不断演进，我们对如何充分发挥模型能力的理解，以及围绕最佳实践的指导也会不断演进。因此，与任何一种具体架构相比，架构背后的原则更重要：持续测量，每次只改一件事，保留经得起验证的做法。

当前情况正是如此。随着模型能力增强、Agent 运行时间延长，更多 Subagent 可以转化为 Skills 和工具。不过，你不必一步完成迁移。先构建一个小型端到端评估，并入一个 Subagent；只有当并入后的版本得分更低时，才继续把它保留为 Subagent。然后不断重复这一过程。