Anthropic谈Agent设计：子Agent分工成本高，单Agent更划算

K3.1 Pro上线后，不少用户反映额度消耗过快，月之暗面随即发公告回应，称“问题出在我们，我们也本应更早修复”。除了给出额度补偿，月之暗面还表示要“减少不必要的子Agent调用和输出长度”。

巧的是，就在这款模型上线前两天，Anthropic发布了一篇题为《构建Agent：何时该把子Agent折叠回主循环》（Building agents: When to fold subagents into your main agent loop）的文章，谈的正是子Agent这个话题。

Anthropic给出的结论来自对多家企业Claude部署情况的对比：一个带技能的Agent，质量比“一群子Agent分工”更好，单任务成本和延迟通常也更低。最要紧的一点是，前者消耗的token远少于后者。

说到底，子Agent是模型能力还不够强的时候，厂商为了让模型多干点活而打的“补丁”。

从任务完成率看，当时的多个子Agent确实比单Agent强出不少。代价则是token烧得更凶，用起来也更贵。

Anthropic的说法是，模型变强、上下文变长之后，这个“补丁”不再带来能力提升，反倒成了“累赘”。

01

Anthropic这篇文章讲了什么

在Anthropic看来，绝大多数任务根本用不着那么多子Agent，单Agent、单模型、单份对话记录、一个循环就够了。

模型在同一个loop里反复干活，每一轮可以一次发出一批工具调用，结果直接回到模型手上，下一步做什么由它自己定。

拿后厨做菜打比方：一道菜要从备菜开始，洗菜、切菜、下锅，最后装盘上桌。

按过去的分工，洗菜的、切菜的、掌勺的、摆盘的各管一摊，每人手里一份任务列表。问题在于，每个人的列表都是上一个人交过来的，比如切菜的那份就从洗菜的手里接。

等菜上了桌才发现咸了，哪一环出的问题很难说清：可能掌勺的盐放多了，也可能菜根本没洗干净。

单Agent省事的地方在于，它不必每轮开头先跟谁解释一遍“我要什么味道”。菜是它自己做的，咸淡它自己也尝过。

文章列出了子Agent的三个问题。

头一个是token复利。

任务里每多加一个子Agent，就多一层分支，成本也随之往上走。多Agent系统的token消耗，大约是普通对话的15倍。

这15倍的关键不在“想”，而在“记”。

每个子Agent都得重新建立自己的身份、规则、工具清单和相关上下文，跑完再压成一段摘要交回去。结果主Agent要把同一份材料读上很多遍。

第二个是信息衰减。

信息在子Agent之间每传一次，保真度就掉一层。传到后面那些子Agent手里时，拿到的可能已经跟最初的需求对不上了。

Cognition在2025年的文章《不要构建多Agent（Don't Build Multi-Agents）》里写过这样一个场景：两个子Agent分头做Flappy Bird复刻，一个负责背景，一个负责小鸟。结果背景做得像超级马里奥，那只鸟也完全不像游戏素材。

第三个是人格碎片。

系统内部是多个子Agent在交流，提示词各不相同，输出风格也差得很远，可用户面对的只有一个入口。

Anthropic在文中举了一家公司的例子：客户端有十几个专项子Agent，公司对它们的评价是“很难维持稳定的品牌口径”，而且用户每次都得等最慢的那个子Agent输出完，才能拿到回复。

不过话说回来，Anthropic并不是主张把子Agent一刀切掉，它的方案是让这些子Agent按需加载，变成Skill。

每个子Agent身上都带着各自的知识，好比切菜的刀法、掌勺的火候。用到的时候把对应的Skill取出来，进入下一阶段再放回去。

这套做法能带来多少改变，是可以用数据衡量的。

Anthropic在文章里写道，配合相应的工具，用这种把子Agent转成Skill的思路，系统提示词能被削减80%以上。

原本臃肿到干扰模型判断的提示词，一下子变得干净简洁，上下文空间因此被大量腾出来，留给任务本身使用。

02

子Agent还有存在的必要吗

子Agent从一开始诞生，就是工程层面的一种妥协产物。

历时还身处

那就得靠某种办法把任务拆开，让模型一步一步去做。

2023年3月底，AutoGPT和BabyAGI两个实验项目出现，思路都是拿一个Agent把大目标拆成若干todo list，自己给自己派活，再自己去执行。

这批项目说明了一点：只要让模型自己决定下一步，循环就能转起来。可它们也暴露出另一个问题——循环里要是缺了可靠的验证环节，错误就会在循环里被不断放大。

一个Agent说“我要去查这家公司的财报”，哪怕它查到的是错的那一份，它照样会顺着错的东西继续往下推，最后交给你一份看上去很认真的胡说八道。再往后就是无限打转，错上加错。

2023年下半年到2024年，行业拿出的办法，是把分工做得像一家真实公司那样。

MetaGPT就是一个例子，它把模型分成产品经理、架构师、工程师、测试四个岗位。

你丢一句“做一个贪吃蛇，带排行榜”，它就按岗位一层层往下走：先由“产品经理”写出需求文档，再由“架构师”把文档翻成系统设计和接口，接着“工程师”照着接口写代码，最后“测试”出来挑毛病，一个完整的程序就这样生成。

当时大家的想法挺朴素，一个模型容易跑偏，那就让几个模型互相照应，子Agent系统的雏形也由此而来。

说白了，子Agent本质上就是“用架构去模拟一台更宽、更稳、内存更大的机器”。

Anthropic在文章中还写到，除了上下文窗口有限，模型的可靠性同样有限，链越长越容易崩。另外，模型只能单线程工作，没法同时思考。

Anthropic表示，他们在2024年做子Agent，动机就是解决这三件事：上下文隔离，别让主上下文被海量中间产物污染，等于变相扩展了上下文窗口；不同任务配不同工具，防止链条某处崩溃时直接影响整个任务；并行，多条独立线索同时推进。

在Anthropic看来，子Agent算是模型的一种“补丁”。可这些补丁，都是要按token付钱的。

过去两年，掏钱的主要是按API计量的开发者和企业，成本明码标价、可以核算。你在token上多花1毛钱，账单上就多1毛，清清楚楚。

随着C端订阅制流行起来，Anthropic表示，是时候改改了。

月度额度是个黑箱。用户只知道“这个月还剩多少”，却不知道“这一轮对话里，这些子Agent到底消耗了多少额度”。

订阅用户是按“我做了几件事”来判断额度的，系统却是按“我调了几次模型、开了几个分支、读了几遍文件”来算的。

所以Anthropic表示，随着模型性能和算力逐步提升，这些“补丁”只有在极其复杂的任务中才派得上用场，对绝大多数任务来说，子Agent只会烧掉更多token。

结论就是这么来的：Anthropic认为子Agent的收益已经盖不住它自身的开销。

他们还把一套名叫single-agent-loop-kit的工具开源了出来，用途很明确——让模型只跑单Agent，不再去调子Agent。

03

K3.1 Pro 的这张账单

子Agent开得太多，月之暗面就栽在这上面。

K3.1 Pro在10月24日上线，性能表现亮眼。Terminal-Bench 4.0上它拿下65.7%，高过GPT-6 Astra的58.2%；对比Claude Opus 5.5的66.4%，差距只有0.7%。

可社区里不少用户反映，额度掉得太快，一两个小任务就能把5小时的额度吃光。

10月26日凌晨，月之暗面官方回应，会削减不必要的子Agent调用，同时压缩输出长度。

在互联网公司待过的人，看这情形多半觉得熟悉。

一个需求提进来，产品、设计、前端、后端、测试、运营各出一个人，谁都得在文档里写上一句，不然就像没参与。折腾到最后，一个人半天能收尾的活，从需求到排期再到测试上线，前后拖了大半年。

放在公司里，这叫组织能力；落到模型身上，它就成了消耗token。

用户这边，能调的只有模型的思考强度，开多少个子Agent由不得他。他想付的是把活干完的钱，不是替一堆子Agent“对齐、开会、做PPT”买单。

更麻烦的是，用户连叫停都做不到。这里牵扯到一个概念，叫失败成本前置。

正常买卖是“事做完了，钱才花出去”。子Agent不一样，只要开了就在烧额度，哪怕它起的作用小到可以忽略。

说句公道话，这毛病不是K3.1 Pro一家有。

Claude的用户也抱怨过：20美元档的订阅，一个提示词就把5小时额度用尽；Opus 5.5处理存量代码库，差不多30分钟就撞上限制。原因同样是Claude开的子Agent太多。

在Anthropic看来，这属于“长程Agent”这一品类的“结构性矛盾”。

任务交到它手上，它得查资料、读文件、写、改，再自己验一遍。几十步跑下来，每一步都要重读上下文，耗上半小时很平常。

模型越强，检索越久，工具调用越多，自查的轮数也跟着涨。

Anthropic的解法是从产品侧替用户判断“哪些子Agent调用没必要”，把子Agent减下来，一个Agent能搞定就绝不开子Agent。

另外，用户还要能自己定步数上限，在单个任务开始前先给出一个预算区间。

Anthropic上市在即，砍子Agent、压token消耗，也是在向自己的C端用户示好。