Anthropic Agent实践：subagent并非越多越好，单Loop架构更优

据行业观察，Anthropic发布的一篇关于Agent工程实践的文章，核心结论是：subagent的数量并非越多越好。在多个企业级部署的对比测试中，采用“单主Agent循环+渐进式披露技能与工具”的架构，在性能上优于“单prompt覆盖”和“多subagent编排”两种方案，同时在成本和延迟方面表现更优。

某企业客服Agent中存在十几个subagent，导致统一品牌体验难以维持，延迟还损害了用户体验，这一问题也印证了subagent过多的弊端。

一、Agent架构易长成组织架构图

大型组织构建Agent的经典路径是：各团队分别开发Agent，中央平台再叠加编排器。这种看似高效的模式，实则带来一系列问题：

• 上下文管理混乱：Agent间传递信息时，细节在交接中丢失；
• subagent泛滥：各团队开发的subagent重叠且无标准，最终形成上百个无人认领的模块；
• 提示词冲突：各团队在系统提示词中加入自定义规则，导致规则打架、语气不一；
• 评估碎片化：各团队仅优化自身子任务，无人对整体质量负责；
• 延迟较高：实测显示，单Agent循环的运行速度比多subagent框架快约2倍。

Anthropic将这种现象归结为康威定律在Agent领域的体现：Agent架构成为组织架构的镜像。常见的“老五样”架构——意图分类器、固定多步推理流水线、用户分群、独立推荐分支、多Agent编排器，实际作用有限，因为这些工作模型本身已能独立完成，只需清晰的系统提示词、4-5个精简的数据工具和严格的输出护栏，即可覆盖绝大多数场景。

二、解法：单Agent循环加渐进式披露

针对上述问题，文章提出的解决方案是“单Agent循环+渐进式披露”。其核心是：技能和工具通过渐进加载的方式提供，Agent平时仅看到简短描述，需用时才完整载入。

这一方案的优势体现在三个方面：

• 共享上下文提升答案质量：长运行的Agent将多任务上下文整合在同一窗口，能将各步骤结果串联，比subagent返回的摘要更丰富；
• 渐进式披露缓解上下文膨胀：无需将所有内容塞进超长系统提示词，这也是相关模型系统提示词砍掉80%内容的原因之一；
• 模型能力增强减少依赖：从新一代模型开始，单循环可处理更多任务，模型具备边执行边自查的能力，简化了框架组件。

单Agent循环的具体形态为：单个模型、一个上下文窗口，运行开放式工具循环，仅通过harness控制预算（轮次上限、成本上限、写操作门禁）。每轮模型批量调用工具，harness并行执行后将结果返回模型，由模型决定下一步操作。

当然，subagent并非完全无用，以下场景可保留：

• 单循环因上下文膨胀出现性能退化；
• 多个任务需并行且需用完即弃的干净上下文；
• 单个Agent选不对工具或系统提示词存在指令冲突；
• 研究前沿场景。

三、落地：评估先行，一次只折叠一个

对于已存在大量subagent的生产环境，文章给出的迁移路径强调“稳”，步骤如下：

第一步，建立评估体系：先搭建中央团队的端到端评估集，搭配各技能的小评估集，哪怕只有10条样本也可起步。使用编排器时追踪路由准确率，折叠后则关注Agent是否加载正确技能、调用正确工具。

第二步，逐步折叠subagent，分三个递进阶段：

• 合并耦合紧密的领域Agent，如串行调用、共享数据、常被同时调用的模块；
• 将保留的subagent作为工具调用，主Agent负责与用户对话；
• 将prompt转化为技能，API调用转化为MCP工具。

第三步，控制节奏：每次仅折叠一个subagent，折叠后做对比测试。以客服Agent为例，折叠虽降低了延迟，但可能导致流程问题，需多跑几遍评估任务确保结果稳定。

此外，多团队共建模式需调整：所有权从Agent转移到技能和工具，中央团队负责系统提示词和端到端质量。工具按用户意图分组，避免工具定义过多导致选择退化。配套有相关工具链辅助迁移。

无论何种架构，核心原则是“测量、小步迭代、保留有效方案”。随着模型能力增强，subagent可逐步转化为技能和工具，无需一步到位，通过循环评估和折叠优化架构。