Kimi额度烧太快？Anthropic：少开不必要的子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。

Anthropic 这篇文章说了什么

Anthropic 的核心观点是：绝大多数任务根本不需要那么多子 Agent，只靠单 Agent、单模型、单份对话记录、一个循环就足够。

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

打个比方，后厨要做一道菜，得先备菜，再洗菜、切菜、下锅，最后装盘上桌。

换成分工式的做法，是洗菜、切菜、掌勺、摆盘各站一个人，每个人手里都有一份任务列表。问题在于，每个人的列表都是上一个人递过来的，比如切菜的活儿就得从洗菜的手里接。

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

单 Agent 的好处就在这里：它不用在每一轮开头先跟谁解释“我要的是什么味道”。菜是它自己做的，咸淡也是它自己尝过的。

子 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“很难维持稳定的品牌口径”，而且用户永远要等最慢的那个子 Agent 输出完，才能拿到完整回复。

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

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

这套办法的效果是可衡量的。

Anthropic 在文章里提到，配合相关工具，把子 Agent 改造成 Skill 之后，可以砍掉 80% 以上的系统提示词。

原本臃肿到会影响判断的提示词，一下变得干净简洁，省出来的大量上下文空间，就能留给任务本身。

我们真的还需要子 Agent 吗

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

当时还在 OpenAI 的 Karpathy 曾发过一条推文，大意是 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 觉得，这套逻辑也该改改了。

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 端用户的体验。

关于模型额度和子 Agent 开销的讨论，在 云栈社区 也一直没停过。