多 Agent 架构中的 Subagent 拆分与合并策略

在和多 Agent 协作时，主 Agent 会将复杂的任务拆分给不同的 Subagent。由主 Agent 负责规划和任务分配，Subagent 使用各自的 Prompt、上下文窗口和工具完成主 Agent 分配的工作，再将执行结果返回给主 Agent。

这种主 Agent-Subagent 的架构能方便地隔离不同的任务，还可以让多个 Subagent 并行工作。但当各 Subagent 负责的任务之间存在较强的上下文依赖时，多 Agent 的协作机制就会带来额外的开销。每次子任务的交接都要重新组织输入信息，执行结果也会经过系统压缩或摘要，当中的部分细节无法完整地传递给下一个 Agent。

随着模型的规划、工具调用和指令遵循能力的增强，原先依靠多个 Subagent 完成的任务，部分可以重新整合到单个 Agent Loop 中。

上周，Anthropic 在多项企业 Agent 部署实践中尝试减少 Subagent，将业务流程转移到 Skill，将系统操作转移到工具，再通过渐进式加载来控制主 Agent 的上下文规模。在部分测试中，这种架构能够改善任务的质量，并降低执行的延迟与成本。

在本文中，我们将会解析这个调整涉及到具体的架构问题：Subagent 应该按照业务领域还是上下文关系进行划分？单 Agent Loop 如何管理不断增加的能力？已有的多 Agent 系统，又该如何评估和实施迁移？

企业多 Agent 架构的协作成本

企业在构建 Agent 时，经常需要将多个业务系统整合到统一的入口。例如，一个客服 Agent 可能同时需要处理订单查询、物流追踪、退款申请、会员权益和产品咨询。

一种常见的设计方式是由不同的业务团队分别开发自己的 Agent，再由平台团队通过增加 Orchestrator 去识别用户的意图并分配任务。

这种组织方式能够复用各团队现有的业务逻辑，也方便团队各自维护。但随着 Subagent 数量的不断增加，整个系统的复杂度会逐渐提高。复杂性主要体现在下面几个方面：

上下文管理。 每个 Subagent 都要有独立的上下文窗口，Orchestrator 需要决定向它传递哪些信息。当任务涉及多个 Subagent 时，中间结果需要反复转换、筛选和压缩。如果 Subagent 给主 Agent 返回的结果中没有包含它执行过程中获取的细节的话，后面的 Agent 就不能利用这些细节信息。

Subagent 数量膨胀。 不同团队可能在开发相似功能的 Agent，调用相同的数据接口，却使用不同的 Prompt 和操作规则。一些企业甚至积累了数百个能力高度重叠的 Subagent，缺乏统一的管理标准和明确的维护责任。

系统指令冲突。 各团队在不断地提出新的业务要求，平台团队再将需求对应的规则整合到 Orchestrator 或共享到 Prompt 中。随着规则的不断累积，系统容易出现指令重复、相互冲突等问题，最终形成 Frankenprompt（拼接式提示词）。

局部评测与整体任务脱节。 各业务团队围绕自己的 Subagent 建立 Eval，能够衡量 Agent 某项能力的表现，却难以覆盖完整的用户任务。即使每个 Subagent 都通过了各自的局部评测，任务仍然可能在路由、上下文交接或结果整合的过程中失败。

执行延迟。 多 Agent 系统中的路由决策、嵌套模型调用和上下文传递都会增加额外的开销。尤其对于存在前后依赖关系的任务，多个 Subagent 难以充分的并行，整体执行时间可能随着调用层级的增加而延长。

这些问题在企业部署中也有所体现。在 Anthropic 分享的一项企业对比测试中，单 Agent Loop 的运行速度约为原有多 Agent Harness 的两倍。另一个客服系统包含十多个专业 Subagent，不同 Agent 的表达风格难以保持一致，额外的调用也影响了用户体验。

虽然这些测试结果受到具体的业务和架构条件的影响，但也说明了一个问题：增加 Subagent 带来的专业化收益，需要与额外的协作成本一起评估。

图 1：传统多 Subagent 架构与单 Agent Loop，图源@Claude

此外，部分企业中的复杂架构还保留着早期模型能力不足时建立的辅助流程，例如独立的意图分类器、固定的多阶段规划、专家路由和多层 Orchestrator。在一些企业场景中，一个清晰的系统提示词、4～5 个轻量数据工具和明确的输出约束，其实就能覆盖大部分的任务。

因此，在重新评估多 Agent 架构时，需要先检查现有 Subagent 承担的具体工作，以及它们之间的上下文依赖关系。

单 Agent Loop 与渐进式加载机制

减少 Subagent 后，原先分散在多个 Agent 中的规划、执行和结果分析，需要重新整合到主 Agent Loop 中。

在这种设计中，系统由一个模型、一个主要的上下文窗口，以及持续迭代的工具调用循环构成。Harness 负责控制执行预算、权限限制和必要的验证环节，模型则根据任务的目标决定具体的执行步骤。

一次典型的任务执行过程包括：

• 模型根据用户的目标制定初始计划，并将计划保存在上下文中。

• 模型发起一批工具调用，由 Harness 并行地执行，再将结果返回同一个上下文窗口。

• 模型分析工具返回的结果，并根据实际的情况调整计划，是继续调用工具还是向用户请求补充信息。

• 当任务完成，或者达到轮数、成本等预算限制时，执行循环结束；必要时再进行目标检查或结果验证。

在这种结构中，规划和执行会由同一个模型完成。模型可以根据工具返回的结果持续更新任务状态，减少 Orchestrator 与不同 Subagent 之间的反复交接。

例如，一个企业 Agent 需要先查询客户合同，再核对历史订单，最后生成续费建议。如果发现合同信息存在异常，模型可以根据查询的结果调整后续步骤，进一步访问相关记录，无需再将任务交给独立的规划器。

不过，将更多的能力集中到主 Agent 后，也会带来新的问题。随着业务规则、工具定义和参考资料的不断增加，系统提示词和上下文可能变得越来越庞大。

针对这个问题，Agent 系统可以采用 Progressive Disclosure，即渐进式加载机制。在初始阶段，Agent 只需要知道有哪些 Skill 和工具可以使用，以及它们各自负责什么。当任务涉及特定的领域时，再加载对应的完整指令、工具定义或参考文件。

例如，客服 Agent 可以具备退款、物流、会员权益等多种能力。当用户申请退款时，Agent 加载退款的流程 Skill，再按照流程调用订单查询、退款资格检查等工具。其他业务领域的详细规则仍然保留在外部，不会占用当前任务的上下文空间。

渐进式加载还能同时应用于 Skill 和工具。对于 Skill，模型可以先通过简短的描述去判断是否需要使用 Skill，再读取详细的操作流程和参考资料。对于工具，Agent 系统可以通过 Tool Search 去查找工具，并按需加载完整的工具定义，减少一次性提供大量工具所带来的选择压力。

这种架构主要有三个方面的效果。

首先，多个执行步骤共享同一个任务的上下文。模型可以利用此前工具调用的原始结果，减少跨 Subagent 传递摘要时造成的信息损失。

其次，业务能力可以持续扩展，系统提示词却无需包含所有领域的详细规则。Claude Code 面向较新模型的系统提示词曾缩减超过 80%，其中部分调整与 Skill 和工具的渐进式加载有关。

最后，随着模型能力的增强，部分固定的编排逻辑也可以交由模型自行处理。开发者可以减少 Harness 中不必要的路由、判断和任务重新规划的代码。

不过，单 Agent Loop 仍然需要管理长期任务中的上下文增长。如果执行过程中积累了大量的无关信息，模型的表现也可能下降。因此，渐进式加载、上下文压缩、任务笔记和必要的上下文隔离仍然需要配合使用。

Subagent 的上下文边界

要不要保留 Subagent 是 Agent 架构调整的重点。

图 2：按任务类型拆分与按上下文拆分，图源@Claude

传统的多 Agent 系统容易按任务类型来划分 Subagent。例如，编码 Agent 负责写代码，测试 Agent 负责生成测试，审查 Agent 负责检查代码。

这样的分工看起来很清楚，但不同的任务可能需要共享同一批上下文。编码 Agent 在实现功能时，对需求、代码结构、接口约束，以及实现过程中的技术要有取舍。如果将测试工作交给另一个 Subagent，又要重新传递相关的信息。即使测试 Agent 拿到了最终的代码，可能也不了解此前的实现背景，例如某个异常分支为什么采用当前的处理方式，或者某项任务的兼容性要求来自哪里。

当多个 Agent 之间存在较强的上下文依赖时，按照任务类型来拆分 Agent，反而会增加信息传递的成本。

一种优化方式是让同一个 Agent 完成功能的开发和测试编写任务，再交给独立的 Verifier 进行黑盒验证。Verifier 只用运行测试并返回结果，无需了解完整的实现过程。因此，它可以使用独立的上下文，也能够提供相对独立的验证结果。

从这个例子（图 2）可以看出 Subagent 的划分不一定要按照任务的类型来定，应该从任务之间的上下文依赖关系出发。需要共享大量中间信息的任务，可以交给同一个 Agent 完成；只需要少量输入、能够独立返回结果的任务，则可以继续保留独立的 Subagent。进一步看，以下三种情况可以保留 Subagent：

上下文的增加导致可测量的性能下降。 当主 Agent 需要读取大量的资料、执行长时间的任务，且上下文增加影响了任务质量时，可以将部分工作交给独立的 Subagent。它可以使用新的上下文窗口去处理信息，再将精简后的结果返回主 Agent。

任务之间具有明显的并行关系。 当 Subagent 们负责的任务可以独立执行，且各自只需返回少量的结果时，Subagent 可以通过并行执行来缩短整体的耗时。独立研究、多个代码组件开发等任务，都可能符合这一条件。

工具选择或系统指令存在难以消除的冲突。 如果不同领域使用相似的工具接口，却有不同的执行规则，模型可能反复选错工具或违反领域约束。通过独立的 Subagent 隔离指令和工具，可以减少这类干扰。

此外，权限隔离也是多 Agent 架构的一项能力，但普通的业务权限未必需要通过独立的 Agent 实现。针对不同用户的数据访问限制，可以由工具根据调用者的身份进行权限检查。

因此，在划分 Subagent 时，需要综合考虑上下文依赖、任务的独立性、并行收益、指令冲突和权限要求。其中，上下文依赖可以通过真实的执行轨迹进行分析：哪些 Subagent 经常被连续调用，哪些需要共享大量中间结果，哪些只负责返回结构清晰的最终结论。

从多 Agent 到单 Agent Loop 的迁移

对于正在运行的多 Agent 系统可以采用渐进式迁移的方式，逐步调整现有架构。

迁移过程中，需要在降低 Subagent 协作成本的同时，确保原有系统能够稳定完成各项业务任务。

图 3：Subagent 渐进式合并路径，图源@Claude

端到端评测基线

迁移前，需要先建立端到端 Eval，记录当前架构在真实任务中的表现。评测基线的建立可以由平台团队负责完整的用户任务的评测集，各业务团队则负责各自领域的局部 Eval。初始阶段可以先选取约 10 个经过验证的典型任务，再逐步地扩大评测范围。

评测既要关注最终任务的完成情况，也要检查具体的执行过程。

在原有的多 Agent 架构中，需要检查 Orchestrator 是否选择了正确的 Subagent；合并后，则需要检查主 Agent 是否加载了正确的 Skill、调用了相应的工具，并遵守业务规则。

对于存在前后依赖关系的流程，还应设置专门的评测任务。例如，查询订单后确认物流状态、完成身份验证后提交退款，或者核对账户权限后访问敏感数据。

通过这些评测，可以检查架构调整后是否出现新的工具调用或执行路径错误。

按共享上下文合并 Subagent

建立评测基线后，可以通过生产环境中的调用轨迹，寻找适合合并的 Subagent。优先检查那些经常被连续调用、访问相同数据，或者需要使用彼此执行结果的 Subagent。

例如，如果大量请求都要先调用订单 Agent，再调用物流 Agent，并且这两个 Agent 都需要了解当前的订单状态的话，可以考虑将它们合并到同一个领域 Agent 中，因为这类执行链路存在较强的上下文依赖关系。

对于依赖关系较弱、能够独立完成的任务，则可以继续保留 Subagent。

在迁移初期，也可以先将原有的 Subagent 作为工具提供给主 Agent。这样既能保留原有的专业能力，也能让主 Agent 统一负责用户交互和结果整合。

这种过渡方式无需立即重写 Subagent 的全部逻辑，还可以通过统一的返回结构，让主 Agent 进一步检查 Subagent 的执行结果。

不过，这种方式仍然保留了独立的 Prompt、上下文窗口和嵌套模型调用，因此无法完全消除执行延迟和上下文传递的问题。

将 Subagent 能力转移到 Skill 和工具

对于确定需要合并的 Subagent，可以逐步拆解其内部的能力。

原有 Prompt 中的业务流程、判断规则和执行顺序，可以转移到 Skill；访问业务系统、执行 API 请求和返回结构化结果的能力，则可以转移到 MCP Tool。

例如，一个退款 Subagent 原本负责查询订单、判断退款资格、执行退款并通知用户。

迁移后，主 Agent 可以加载退款处理 Skill，按照其中的规则调用订单查询和退款执行工具。身份验证、金额限制和审批条件等硬性约束，则由工具或 Harness 负责执行。

这样一来，主 Agent 可以保留完整的用户任务上下文，业务团队也能够继续维护退款流程和相关工具。

等要迁移 SubAgent 时，建议每次只处理一个 Subagent，并在修改前后运行相同的 Eval，来对比任务的完成率、成本、延迟以及具体的失败案例。

迁移中的性能回退与可靠性

Subagent 合并后，即使总体评测分数没有明显下降，部分具体任务仍然可能出现性能回退。

在一项客服 Agent 测试中，合并 Subagent 虽然降低了执行延迟，却导致原本能够通过的物流查询流程出现了问题。迁移前，主 Agent 会将配送日期查询交给物流 Subagent；迁移后，主 Agent 拥有了订单查询工具，于是自行读取订单信息并回答配送日期，没有继续调用物流 Subagent。

这个问题在两次测试中只出现了一次。这说明架构调整可能改变模型的工具选择和任务执行路径，原先通过 Subagent 分工形成的流程约束，在合并后可能失效。

因此，评测时需要关注具体任务是否由通过变为失败，以及失败发生在哪个执行步骤。

对于必须遵守的业务规则，还需要设置专门的检查。例如，退款前是否完成身份验证、物流日期是否来自正确的数据源、敏感数据是否经过权限校验。如果这些约束可以通过工具和 Harness 实现，就应尽量采用程序化检查，避免完全依赖 Prompt 指令。

同一个任务也应重复执行，以观察模型输出的稳定性。对于难以完整回放的生产系统，可以记录关键业务事件及其时间戳，再利用这些记录构建针对性的 Eval。在成本评估方面，除了最终的 Token 消耗，还应关注模型调用次数、工具调用数量、嵌套执行深度和端到端延迟。减少 Subagent 后，主 Agent 的上下文可能变长，单次模型调用的成本也可能增加。如果工具调用方式不合理，最终未必能够节省总成本。

因此，评估架构调整的效果时，需要结合实际的执行路径，不能仅根据 Subagent 数量的变化判断架构的优劣。

Agent 架构选择的延伸讨论

单 Agent Loop 与多 Agent 架构的选择，还可以参考其他 Agent 系统的实践经验。

OpenAI 在「[A Practical Guide to Building Agents]」中建议，优先扩展单 Agent 的能力，通过增加工具和完善指令来覆盖更多任务。当系统出现复杂的条件分支、反复的违反指令或无法稳定选择工具时，再考虑拆分为多个 Agent。

其中，工具的数量和相似程度都会影响模型的表现。有些 Agent 能稳定地使用超过 15 个功能差异明显的工具，而另外一些 Agent 即使只用 4、5 个功能高度相似的工具，也会出现选择错误。

因此，相比单纯统计工具数量，工具接口是否清晰、指令是否复杂，更值得关注。

另一方面，多 Agent Research 系统也展示了独立 Subagent 的价值。研究任务可以拆分为多个检索方向，由不同的 Subagent 使用独立的上下文，并行地完成搜索、分析和资料整理，最后再由主 Agent 汇总结果。

这类任务具有较强的并行性，不同研究方向之间的依赖较少，而且每个 Subagent 都可以将大量检索信息整理成简短的结论，再返回给主 Agent。

相比之下，订单处理、客户管理等企业工作流通常需要共享任务状态。多个 Subagent 需要频繁地交换相同的数据，前一步的执行结果也会影响后续决策，额外的上下文交接可能增加执行成本。

这种差异体现了 Agent 架构中的一项重要取舍：共享上下文可以减少信息损失，独立上下文则有利于任务隔离和并行执行。

对于独立性较高的任务，可以继续采用多 Agent 架构；对于需要连续决策和共享状态的流程，则可以优先评估单 Agent Loop。

随着模型能力和工具系统的变化，两种架构的适用边界也可能不断调整。

迁移工具与持续评测

为了支持多 Agent 架构的迁移，Anthropic 还提供了 Single Agent Loop Kit 协助完成 Agent 架构的迁移。

这套工具从评测和架构审计入手，分析现有 Subagent 之间的调用关系，再结合任务特点给出是合并，还是转为工具调用或继续保留 Subagent 的建议。

其中，build-eval 用于建立和扩展评测集；prompt-audit 用于检查旧模型时代遗留的 Prompt 规则；hillclimb 可以根据现有的 Eval，持续优化 Skill 和工具描述；cost-optimize 则用于分析 Token、Prompt Cache 和模型选择等成本因素。

Single Agent Loop Kit 还提供调用的耦合分析、评测覆盖检查和迁移前后结果对比等脚本，用于识别经常被连续调用的 Subagent，并检查评测集是否覆盖了生产环境中的调用链路。

这些工具能够辅助 Agent 架构的迁移，但公开参考实现的真实模型测试覆盖仍然有限，还需要经过更多生产环境的验证。

在实际项目中还是需要根据具体的业务建立评测基线，逐个调整 Subagent，并验证每次架构调整后的效果。

这一过程也可以纳入持续优化机制中。随着模型的升级、工具的变化和业务流程的调整，团队可以定期检查执行轨迹，评估哪些 Subagent 可以合并，以及哪些任务需要重新拆分出来独立执行。

结语

Subagent 的拆分与合并，需要综合考虑任务的上下文、执行依赖关系和系统的协作成本。

对于频繁访问相同数据、需要持续共享任务状态的工作流，可以将部分 Subagent 合并到主 Agent Loop，以减少上下文的交接成本，并简化 Harness 中的编排逻辑。

对于边界清晰、能够并行执行，或者是需要隔离复杂指令的任务，建议保留独立的 Subagent。