K3.1 Pro发布之后，由于多位用户反馈额度烧得太快，月之暗面紧急发布公告，称“问题出在我们，我们也本应更早修复”，在补偿额度的同时，月之暗面也表示将“减少不必要的子Agent调用和输出长度”。

(资料图)

就在模型上线前两天，Anthropic发了一篇文章，标题为《构建Agent：何时该把子Agent折叠回主循环》（Building agents: When to fold subagents into your main agent loop），它所讲的，刚好就是关于子Agent这件事。

Anthropic的结论是，通过对比多家企业部署的Claude他们发现，一个带技能的Agent，质量反而胜过了“一群子Agent分工”，而且单任务成本和延迟往往更低。最关键的是，这个Agent所消耗的token，要远远低于一群子Agent。

子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之间交流，这些子Agent由于提示词不同，它们输出的风格截然不同，然而用户面对的只有一个入口。

Anthropic在文章中举例，说有一家公司，它的客户端有十几个专项子Agent，结果这个公司评价这些子Agent“很难维持稳定的品牌口径”，并且用户永远需要等最慢的那个子Agent输出完，才能得到回复。

但话要分两头说，Anthropic并不认为应该直接取缔子Agent，而是要把它们按需加载成为Skill。

每个子Agent会随身携带各种知识，就比如切菜的刀法、掌勺的火候。每到需要的时候，把这些Skill拿出来，到下一个阶段再把这些Skill放回去。

这套办法的效果是可测的。

Anthropic在文章里提到，结合配套工具，通过这种把子Agent变成Skill的方法，就可以砍掉80%以上的系统提示词。

这就让原本臃肿到会影响判断的提示词，瞬间干净简洁，因此节省出了大量的上下文空间留给任务本身。

02

我们真的还需要子Agent吗

子Agent在诞生之初，本就是一种工程上的妥协。

历时还身处OpenAI的卡帕西曾经发过一条推文，大致意思是说，GPT并不知道自己是有上下文限制的，让它执行任务的时候，很容易就把上下文填满，进而导致任务失败。

所以必须要通过一种手段，去拆分任务，让模型能分步完成。

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带来的好处，已经抵不上它本身的成本了。

Anthropic甚至为此开源了一个名为single-agent-loop-kit的工具，专门让模型只以单Agent的形式执行任务，不再调用子Agent。

03

K3.1 Pro 的这张账单

月之暗面正是吃了子Agent开太多的亏。

10月24日，月之暗面的K3.1 Pro上线，性能很强。在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是只要开了就烧额度，哪怕这个子Agent的作用几乎可以忽略不计。

公平地说，这不是K3.1 Pro独有的病。

Claude的用户也吐槽过，20美元档订阅，一个提示词就把5小时额度用完；Opus 5.5处理存量代码库，大约30分钟触发限制。都是因为Claude开了太多子Agent。

Anthropic认为，这是“长程Agent”这个品类的“结构性矛盾”。

你给它一个任务，它要查资料、读文件、写、改、再自己验一遍。它要跑几十步，每一步都得把上下文重新读一遍，跑半小时是常事。

模型越强，搜得更久，工具调得更多，自查的轮数也更多。

Anthropic给出的解决办法是，从产品侧替用户判定“哪些子Agent调用是不必要的”，进而减少子Agent，能用一个Agent解决就坚决不开子Agent。

除此以外还要让用户能决定步数上限，在单任务开始前提示一个预算区间。

眼瞅着Anthropic就要上市了，减少子Agent进而降低token消耗，也是为了讨好他们的C端用户。

标签： 调用 上下文 kimi 显式标识 agent anthropic