子 Agent 越拆越慢？Anthropic 讲清 Agent Loop、Skills 和多 Agent 的边界

前面在 Claude Code 能力演进里，我们讲过 Subagents 用独立上下文承接专项任务。接下来就有个问题：什么时候值得拆，什么时候拆完反而更麻烦？

Anthropic 在 2026 年 10 月 22 日发布了《Building agents: When to fold subagents into your main agent loop》，作者是 Diane Sarkis。文章讨论的是 Claude Platform 上的企业 Agent 架构，不能直接理解成“Claude Code 的子 Agent 功能该停用了”。

它提出了一个值得验证的方向：把部分路由、规划和领域子 Agent 收回主循环，用 Skills 和工具承接它们的能力。官方在若干企业部署中观察到了质量、成本或延迟的改善，这属于实践观察，不是所有任务都适用的性能保证。

读这篇文章，我更关心一个工程问题：给系统增加一个 Agent，到底解决了什么可测量的问题？

一、别把公司组织图直接变成 Agent 架构

假设你在做电商客服：订单团队维护订单 Agent，支付团队维护支付 Agent，售后团队维护售后 Agent，再由平台团队加一个总调度。

代码归属很清楚，用户的一句话却可能要经过好几轮传递。

下面是一个自拟场景：用户说，“这单重复扣款了，帮我核实后退回多扣的钱，别取消订单”。订单、支付、售后三类知识都可能用上，但它们处理的是同一件事。

如果订单 Agent 交回“订单正常”，支付 Agent 交回“发现两笔扣款”，售后 Agent 却只拿到“用户要求退款”，最后那句“别取消订单”就可能丢了。

组织上分三个团队，不等于运行时必须分三个上下文。 对这种紧密相连的任务，我会先试共享上下文，让同一个主 Agent 持续掌握用户约束、订单状态和处理进度。

团队仍可以分别维护订单工具、支付工具和售后操作手册。代码责任边界与推理边界，可以分别设计。

二、合并后，能力放在哪里？

合并最容易做错的地方，是把三个子 Agent 的 Prompt 拼在一起，形成一个更长的系统提示词。规则仍然互相打架，模型每轮还要读大量无关内容。

更合适的做法，是先把能力拆清楚：

内容	放置位置	客服示例
始终适用的角色与基本约束	系统提示词	服务范围、基本交互原则
专项操作步骤与判断方法	Skills	重复扣款核查流程
实时查询与业务执行	工具，可通过 MCP 提供	查询支付流水、发起退款
偶尔需要的事实资料	知识库或参考文件	不同产品的售后政策

这里的关键是渐进式加载：先让模型知道有哪些能力，需要处理退款时，再读取退款 Skill；工具也可以通过 Tool Search 按需发现和加载。Skills 的组织方式可以接着看这篇实战文章。

主循环负责持续判断下一步：读到新证据后，是继续查、执行动作，还是向用户澄清。计划也应当允许根据结果调整，具体可结合 Agent Loop理解。

拿上面的例子来说，退款 Skill 可以教模型先核对两笔支付是否对应同一订单；退款工具则负责检查用户身份、退款额度、交易状态以及必要审批。涉及钱和权限的硬约束，要由实际执行入口校验。

主 Agent 可以在同一轮发出多个互不依赖的查询，由运行框架并行执行，再把结果交回同一上下文。一个主循环，也可以有工具并行。

三、哪些子 Agent 还值得保留？

原文保留了三类理由：上下文膨胀已造成可测量的性能下降；任务适合在独立的新上下文中并行完成；单 Agent 的工具选择或指令冲突问题确实需要拆开解决。

落到项目里，我会这样判断：

• 是否需要大量彼此无关的材料？ 比如分别阅读几家供应商的长合同。每份合同独立分析，只带回关键条款和证据位置，可以减少主上下文负担。
• 是否真的能独立完成？ 比如三条不同的资料调研路线。子任务中途不用反复追问其他 Agent，独立执行才有意义。
• 拆开是否真的改善行为？ 如果一个 Agent 老是混淆查询和写入工具，可以对比精简工具集后的效果，再判断是否需要独立角色。

相反，如果每一步都要依赖上一位的详细推理，还经常要补问“你刚才为什么这么判断”，我会先检查拆分边界。

需要保留的子 Agent，也可以作为工具被主 Agent 调用：完成独立工作、交回证据，由主 Agent 继续服务用户。这样既能保持独立执行，又不必每次都把整段对话转交出去。

四、已经上线的系统，怎么逐步收回来？

先留住基线，每次只合并一个，再检查业务结果。 别同时更换模型、改 Prompt、合并 Agent，否则结果变化了也很难定位原因。

继续用前面的自拟客服场景，可以选这样一组任务做对比：

任务	需要检查的结果
重复扣款，退回多扣款项	找对交易，只退多扣部分，不取消订单
查询他人的支付流水	工具拒绝越权，回复不泄露流水
退款服务暂时失败	如实说明状态，不声称退款成功
用户中途改为只查原因	停止退款动作，保留新的用户意图

记录原方案的任务完成情况、成本和延迟，再把一个高频子 Agent 的操作说明整理成 Skill，把业务调用交给工具，复跑相同任务。

评测时要读失败轨迹：有没有漏查关键证据？有没有跳过退款前置条件？有没有答得很好看，实际却没完成动作？重要任务还要重复运行，检查偶发退步。

别只盯平均分。对退款系统来说，多答对几条普通咨询，也抵不过一次错误退款。

如果合并后的结果变差，先检查 Skill 是否容易被发现、工具是否返回了足够证据、执行入口是否缺少校验。确认这些问题后仍有差距，保留这个子 Agent 就有了依据。

五、谁对整件事负责

单循环也会失控：Skill 重复建设、描述写不清、工具越来越多，照样会让模型选错能力。

我的建议是，各团队维护自己的 Skills、工具和局部用例，同时有人对端到端任务负责。退款团队证明“退款工具可用”，还得有人验证“用户这次重复扣款的问题解决了”。

下次准备新增一个子 Agent，先写下一条它能改善的失败用例。能用结果证明，再拆。

参考链接

• Anthropic 官方博客（子 Agent 何时合并回主循环）：https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop