Anthropic直接劝退：慎用子 Agent！
原创 小林coding 2026-11-08 15:26 广东
大家好，我是小林。
这两年做 Agent，大家都爱把任务拆给多个子 Agent，每个 Agent 只干一件事，那问题来了，子 Agent 拆得越多，效果就真的越好吗？
最近 Anthropic 在官方博客发了一篇《Building agents: When to fold subagents into your main agent loop》，讲的就是这件事。
Anthropic 的 Applied AI 团队在帮企业落地 Agent 时发现，不少项目把路由器、规划器、领域子 Agent 合回主 Agent 循环之后，效果反而变好了。
在他们对比过的几个企业项目里，「单个 Agent 加 Skills」的方案，质量上经常同时赢过「一个大 prompt 包办一切」和「多个子 Agent 分工」这两种设计，单个任务的成本和延迟往往也更低。
其中有一家公司，面向客户的 Agent 下面挂了十几个专家子 Agent，结果品牌语气很难保持一致，多出来的延迟也拖累了用户体验。
这次我们就一起看看Anthropic 的思路，看看子 Agent 什么时候该拆、什么时候该合。
────一、子 Agent 为什么越拆越多？────
先想一个很常见的场景。
一家大公司想做一个统一的客户入口，用户在一个对话框里就能查订单、办退款、问产品、开发票。可这些能力分别归不同团队管，订单是一个团队，支付是一个团队，售后又是另一个团队。
最省事的做法是什么？每个团队先做自己的 Agent，再由平台团队在上面搭一个编排层（orchestrator），用户的问题来了就分发给对应的 Agent。也有公司换个形式，让一个主 Agent 把各团队的 Agent 当成 MCP 工具来调。
这个方案看起来最简单，组织上也最顺，谁的业务谁负责，互不干扰。
Anthropic 团队给这个现象点了个名，康威定律。
系统的结构，最后会长成设计它的组织的沟通结构。每个团队或者每类问题都分到一个子 Agent，Agent 架构就成了公司组织架构图的复制品。
还有一种拆法，跟组织没什么关系，纯粹是设计上的惯性。
Anthropic 经常看到这样的 Agent 设计方案。先放一个意图分类器，接一条固定的多步推理流水线，再把用户按群体分桶，每个桶走单独的推荐分支，最上面再套一个多 Agent 编排层。
对这类方案，团队给出的反馈往往是，这套结构里大部分环节，都在替模型做它已经不需要别人代劳的事。一个写清楚的 system prompt、4～5 个只负责取数据的轻量工具，再加上严格的输出护栏，就能覆盖大部分使用场景。
看到这估计有同学就问了，多拆几层，最多就是麻烦点，能有多大问题？
问题还真不小。
────二、拆多了会踩哪些坑？────
Anthropic 团队总结了大公司做 Agent 容易踩的五个坑，我一个个说。
坑一：上下文在传话中丢了
子 Agent 有自己独立的上下文窗口。主 Agent 把任务交出去时，要决定给子 Agent 看哪些上下文。子 Agent 干完活，交回来的通常是一段总结。
一来一回，细节就丢了。
举个例子，用户说「我上周买的显示器有个亮点，想换货，但下周要出差，最好这周能送到」。路由把请求分给售后 Agent，售后 Agent 判断可以换，再去问物流 Agent 配送时效。物流 Agent 拿到的可能只剩「查询换货配送时效」这几个字，「这周必须送到」这个关键约束，在交接时没带过去。
按问题类型拆分时，这个问题尤其严重。Anthropic 团队把它比作「传话游戏」，信息在几个 Agent 之间来回传，每多传一手，信息就走样一点。
坑二：子 Agent 泛滥
每个团队都能发布自己的子 Agent，时间一长，公司里就堆了几百个功能重叠的子 Agent，既没有统一标准，也没有明确的负责人。
你想改一条跟退款有关的逻辑，可能得先花半天搞清楚，到底哪几个 Agent 里写了退款规则。
坑三：Frankenprompt
这个词是 Frankenstein（科学怪人）和 prompt 拼起来的，很形象。
每个团队都往 system prompt 里加一句自己的规则。营销团队加一句「每次回答都附上相关活动介绍」，客服团队加一句「回答控制在三句话以内」，订单团队再加一句「涉及金额必须二次确认」。一句一句缝上去，规则开始互相打架，整个 Agent 也没有统一的说话风格。
坑四：评测只看自己那一亩三分地
每个团队都给自己的子任务加评测，而且都针对子任务优化得很好。但整套评测没人负责，也没人维护。
结果就是每个团队的分数都很好看，用户的实际体验却不怎么样。管理层看到的，是一堆只反映局部、参考价值大打折扣的分数，再拿这些分数做决策。
这有点像一个项目里，每个模块的单元测试都是全绿的，却没人写集成测试，上线后才发现模块之间对不上。
坑五：延迟
架构每多一层，延迟就多一截。每调用一次子 Agent，都是在主循环里再嵌套一个完整的模型循环。
有个客户专门做过对比，同样的任务，单 Agent 循环的运行速度大约是他们多 Agent 架构的 2 倍。
这五个坑其实有个共同点。上下文被拆开了，prompt 被拆开了，评测被拆开了，执行也被拆成了好几层。
────三、不拆，上下文不会爆吗？────
讲到这里，估计很多同学心里有个疑问。
当初拆子 Agent，很大一个原因就是一个 prompt 塞不下。订单规则、退款政策、物流时效、几十个工具的说明全塞进 system prompt，上下文直接爆炸，模型也容易被无关信息干扰。现在合回去，这个问题不就又回来了？
Anthropic 给的解法是渐进式披露（progressive disclosure）。
打个比方，你入职一家新公司，没人会在第一天把所有制度文档都塞给你读完。你只需要知道有哪些文档、大概讲什么，真遇到报销的事，再去翻报销制度。
渐进式披露就是这个思路。业务知识放进 Skills，工具交给 tool search 按需查找，Agent 平时只看到每个 Skill 和工具的简短描述，真正需要的时候，才把完整内容加载进来。
Anthropic 团队认为这种做法讲得通，有三个原因。
原因一：共享上下文，答案更好
对长时间运行的 Agent 来说，Anthropic 希望多个任务的上下文都留在主上下文窗口里。
一个看过前面每一步结果的 Agent，能把这些结果串起来，给出的答案和分析，比几个子 Agent 各交一份总结要丰富得多。
回到前面那个换显示器的例子。如果从头到尾都是一个 Agent 在处理，用户说的「这周必须送到」一直留在它的上下文里，查配送时效时自然会带上这个约束。
原因二：渐进式披露防止上下文膨胀
当初拆子 Agent 最主要的原因是上下文装不下，渐进式披露正好把这个原因消掉了。Anthropic 自己就是这么做的，他们把 Claude Code 给更强模型用的 system prompt 砍掉了 80% 以上，其中一部分就来自 Skills 和工具的渐进式披露。
原因三：模型变强了
Anthropic 团队提到，从 Opus 4.5 开始，模型在单个循环里能管的事情，比大多数团队预想的要多得多。
Opus 5.5 和 Fable 5.1 的 thinking 是关不掉的，最近的模型也越来越会边做边汇报进度、边检查自己的结果。这样一来，harness（套在模型外面的那层框架代码，负责调工具、管上下文）里有些专门替模型做规划、做检查的环节就显得多余了。
每出一代新模型，你都可以把更多的决策从 harness 挪给模型自己。
还有一点容易被忽略，循环越简单，越容易迁移到下一代模型。Anthropic 团队在帮客户做模型迁移时发现，往往正是那些僵硬的多 Agent 结构，让新模型没法接手更多工作。新模型明明能自己规划了，编排层还在按旧规矩一步步替它安排。
单循环会有什么代价？
说了这么多好处，单循环 Agent 也不是什么都不用管。
单循环对纪律的要求更高。system prompt 要精心维护，Skill 和工具的描述要写得准，保证在该触发的时候触发，上下文窗口、记忆和笔记也要有意识地管理。
所以 Anthropic 建议，由一个中心团队负责整个 Agent 的端到端质量和 system prompt，每个新工具、新评测上线前都要经过这个团队审核。这个团队还要尽量小，迭代才快，在大公司里协调成本也低。
坦白讲，这一点我觉得特别关键。多 Agent 架构的很多问题，说到底是没人对整体负责。合回一个循环，等于逼着公司把「谁对最终结果负责」这件事定下来。
────四、子 Agent 什么时候该留？────
看到这估计有同学就问了，那子 Agent 是不是一个都别用了？
其实也不是。Anthropic 在原文开头就说了，子 Agent 在做验证、并行干活、给不同模块分配不同权限这几件事上很有效，在前沿研究这类场景里也用得上，Anthropic 自己做深度研究的多 Agent 系统用的就是子 Agent。
符合下面三种情况之一，就可以考虑保留子 Agent。
• 单 Agent 循环因为上下文膨胀，出现了可测量的性能下降。
• 多个任务需要并行处理，每个任务都要一个干净的上下文窗口，做完就可以扔掉。
• 单 Agent 很难选对工具，或者 system prompt 里的指令互相冲突。
注意第一条里的「可测量」。光是感觉上下文可能会爆还不够，得是评测数据真的显示效果变差了。
真要走多 Agent 路线，Anthropic 也给了两个建议。
再就是拆分边界要按上下文划，别按问题类型划。分给子 Agent 的工作，应该很少依赖系统的其他部分，最后交回一个精简的结果。比较合适的例子有独立的调研路径、接口清晰的独立组件，还有黑盒验证。按问题类型拆，信息就又得在几个 Agent 之间来回传，又成了「传话游戏」。
────五、单循环 Agent 长什么样？────
一个模型，一个循环
整个 Agent 只有一个模型、一个上下文窗口，跑一个不预设步骤的工具调用循环。harness 负责设定边界，比如最多跑几轮、最多花多少钱，以及写操作要先过一道关（write gates），像下单、退款这类会改数据的操作不能随便放行。
每一轮，模型发出一批工具调用，harness 并行执行这些调用，再把原始结果交回同一个模型。模型看完结果决定下一步，是再发一批工具调用，还是问用户一个问题，或者直接给出答案。
模型给出答案或者预算用完，循环就停下来。答案出来之后，还可以选择再跑一次目标检查或者 verifier 校验。
写计划的和执行计划的是同一个模型
模型在第一轮就把计划写进上下文，随着结果陆续回来，再不断修改计划。
这是跟「orchestrator 加专家 Agent」架构最大的区别。
在编排架构里，规划器写好计划，交给各个专家去执行。执行过程中发现情况不对，计划很难及时调整，因为写计划的和干活的根本不是同一个。
单循环里，写计划的模型就是执行计划的模型，一轮还没结束就能改计划。
简单来说，以前是项目经理排好期丢给几个外包，现在是一个资深工程师自己规划、自己动手，边干边调整。
原来的东西都去哪了？
上下文还是要加载的，只是改成由 Agent 自己来管。原来多 Agent 架构里的那些模块，在单循环里各有去处。
原来的部分 | 在单循环里的去处 |
|---|---|
按规则表去调整计划的代码 | 不需要了，模型自己决定每一步 |
先做什么后做什么、业务流程 | 放进 Skills |
硬约束（参数校验、审批） | 放进工具 |
对话中途才出现的需求（比如查记忆） | 放进工具 |
成本低、几乎每次都要用的步骤（比如实体解析，把「上周那台显示器」对应到具体订单） | 仍然用代码直接加载 |
机械性的工作（构造 payload、解析流式输出、向用户追问完再接着往下走） | 仍然用代码，放在循环调用的工具里 |
注意表格最后两行。单循环并不意味着把代码删光，全交给模型自由发挥。便宜的、确定的、机械的工作，代码做起来又快又稳，就继续让代码做，只是把它们收进工具里。
────六、拆好的系统怎么合回来？────
很多团队的 orchestrator 和专家 Agent 早就上线了，不可能一夜之间推倒重来。
Anthropic 的建议是分阶段来，先建评测，再用三种办法一点点减少子 Agent，每次只动一个。
步骤一：先建评测集
动手之前，先要有一套评测集，用来判断某个子 Agent 该不该合进主循环。
Anthropic 见过效果比较好的结构是，中心团队负责一套共享的端到端评测集，各团队发布 Skill 时再附带一套小评测。起步不用很大，10 个带标准答案的 golden 样例就够了。
打分可以先从评分细则（rubric）开始，按细则给 Agent 的最终回复打分。如果还处在 orchestrator 架构阶段，还要额外看路由准确率，也就是有没有选对子 Agent。子 Agent 合进来之后，改成看有没有加载对的 Skill、调用对的工具。长期来看，最好逐步建成任务完成度评测，对比不同架构时，这个指标最有说服力。
有些内部系统很难重放，用户交互也很难模拟。Anthropic 内部的办法是在关键事件上记录时间戳，之后回放这些事件，当作针对性的评测来跑。
步骤二：逐个减少子 Agent
评测有了，就可以动手减少子 Agent 了。Anthropic 给了三种办法。
第一种，合并强耦合的专家。 看哪些子 Agent 要用到同一批上下文，就把它们合在一起，先从调用最多的子 Agent 开始。互相接力用对方输出的、操作同一份数据的、经常被一起调用的，都适合合并。比如生产流量里有相当大比例的请求，都是先调专家 A 再调专家 B，这两个就可以合成一个领域 Agent。
第二种，把子 Agent 当工具调用。 如果某个子 Agent 符合前面说的那几种该留的情况，比如任务需要并行处理，或者合进来之后上下文膨胀、测出效果变差了，就可以让主 Agent 把它当工具来调，跟用户对话的始终是主 Agent。只有子 Agent 必须直接跟用户沟通时，Anthropic 才建议做完整交接（handoff），让子 Agent 接管对话。
这种做法还能给子 Agent 定一个共享的响应 schema，让主 Agent 拿真实数据核对子 Agent 的结论，最后汇总时也只需要喂精简过的内容。Anthropic 认为这是不错的第一步，不用重写子 Agent，就能在任务完成度评测上先拿到一个基线。
不过老问题还在。每个专家依然有自己的 prompt、上下文、负责团队和评测，每次调用交回来的依然是有损的总结，嵌套的模型循环也还在拖慢速度。
第三种，改造成 Skills 和工具。 一次只改一个，子 Agent 的 prompt 改写成 Skill，调用的 API 改成 MCP 工具，再对比有它和没它时的评测表现，决定留不留。
步骤三：盯住结果翻转的任务
对比的时候别只看最终分数，要看具体哪些任务的结果翻转了。总分可能差不多，可原来能过的任务挂了，原来挂的任务过了，这两件事都得知道。
Anthropic 在一个示例客服 Agent 上就碰到过。把一个子 Agent 合进另一个之后，延迟降下来了，可一个原本能通过的流程挂了。原因是主 Agent 手里有订单查询工具，就直接拿查到的信息回答了用户，没去找负责配送的专家要发货日期。
更麻烦的是，这个问题在两次运行里只出现了一次。
所以每次改动前，评测集要覆盖生产环境里每一条会一起运行的 Agent 链路，以及每一条 Agent 绝对不能违反的规则，每个任务也要多跑几次。
说实话，这个案例挺真实的。合并之后变快了，大家很容易高兴得太早。偏偏丢掉的是一条「本该去问一下」的路径，平时不显眼，等用户问到发货日期才会露馅。
────七、多个团队怎么一起维护？────
回到开头那个场景，订单、支付、售后各有各的团队。子 Agent 合回一个循环之后，这些团队还干什么？
Anthropic 的答案是，各团队负责的东西从 Agent 换成了 Skills 和工具。另外再由一个人数不多的中心团队统一把关 system prompt 和整体效果，新的 Skill、工具和评测上线前，都要先经过这个团队审核。
原来各团队的领域能力，改成通过 MCP 工具、Skills 和知识库来提供，这三样东西各有适合的场景。
MCP 工具
MCP 工具适合三类需求，Agent 要执行一个动作，要从系统里读实时数据，或者要拿到固定格式的结果。迁移期间，还可以把子 Agent 包成工具继续调用。
工具设计上有两个建议。
第一，按用户意图分组，别一个 API 对应一个工具。system prompt 里的工具定义一旦超过 30～50 个，模型选工具的准确率就容易下降。工具实在多，可以用 tool search 配合延迟加载。
第二，少设硬性的前置条件，必要的那些放进工具里。比如工具 Y 需要工具 X 的输出，那就让 Y 自己检查 X 的结果在不在，不在就返回一条模型看得懂、能照着做的提示。
用户权限也是同样的思路。每个工具自己检查当前用户能看什么、能做什么，没有权限就返回一句模型能读懂的拒绝。这样一个循环就能服务不同权限的用户，不用为每个权限级别单独做一个 Agent。
Skills
Skills 适合承载「这个团队是怎么干活的」，也就是步骤、规则和需要判断的地方，这些原来都写在专家子 Agent 的 prompt 里。
Skill 多了一样会泛滥，Anthropic 的建议是每个团队指定一个 DRI（直接负责人），保证自家 Skill 写得好、彼此不重复，并且附带对应的评测。
维护 Skill 的重活，也可以交给 Claude。Anthropic 提到两个命令，/skill-creator 能写出结构规范的新 Skill，也能审查已有的 Skill，做精简、去重和重组。/skill-doctor 能看到每个 Skill 的成本和使用频率，没人用的就可以删掉。
知识库
知识库适合 Agent 只是偶尔用得上的参考资料，比如政策、指标口径、产品规格。这些资料可以放在一个检索或查询工具后面让模型自己去查，也可以作为参考文件放进 Skill 里。
Anthropic 特别提醒，别用代码把这些资料检索出来，再硬塞进 prompt。
有现成的迁移工具吗？
有。Anthropic 最近放出了一组 Claude API 的 Skills，专门用来把多 Agent 系统迁移到单循环，还开源了一个迁移工具包 single-agent-loop-kit，把这些 Skills 串成一个引导式流程。
工具包自带 demo，可以先在模拟系统上试跑，再用到自己的 Agent 上。
里面用到的四个命令，分别负责建评测、清理老 prompt、对比优化和降成本。
•/claude-api build-eval，搭评测集。中心团队用它建第一套端到端评测，各团队用它给自己的 Skill 配小评测。
•/claude-api prompt-audit，找出 prompt、Skill 和工具描述里那些给老模型写的指令，用 diff 的形式给出修改建议。之前为老模型加的规则，放到新模型上反而会让 Agent 变慢、变死板。
•/claude-api hillclimb，对着已有评测反复优化。把子 Agent 改造成 Skill 加工具之后，可以让它反复改 Skill 和工具的描述，看合进主循环后的版本能不能追平甚至超过原来的子 Agent。
•/claude-api cost-optimize，分析调用都花在了哪里，从 prompt caching、裁掉不必要的输入输出 token、effort（推理力度）和模型选择这几个方面，一次给一个省成本的改动。
────最后────
Anthropic 在文章结尾说，模型在变，最佳实践也跟着在变，所以具体用哪种架构没那么重要。
重要的是背后的原则，先测量，一次只改一处，留下经得住检验的改动。
把子 Agent 合回主循环，也不用一步到位。先建一个小的端到端评测，把一个子 Agent 合进主循环，只有合进来之后分数更差，才把它留成子 Agent，然后一个接一个重复下去。
参考文章：
• Claude 官方博客《Building agents: When to fold subagents into your main agent loop》：https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop