文 | 字母 AI
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 表示，随着模型变强、上下文变长以后，这个 " 补丁 " 就不再能提升能力，反而变成了一种 " 累赘 "。
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% 以上的系统提示词。
这就让原本臃肿到会影响判断的提示词，瞬间干净简洁，因此节省出了大量的上下文空间留给任务本身。
我们真的还需要子 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。
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 端用户。
