Kimi额度的问题，Anthropic 找到了解决办法

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

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

但话说回来，Anthropic并不认为应直接取缔子Agent，而是要将它们按需加载为Skill。

每个子Agent会携带各种知识，例如切菜的刀法、掌勺的火候。每当需要时，将这些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端用户。有关Anthropic的最新动态，可访问开云官网获取更多信息。

本文来自微信公众号“字母AI”，作者：苗正，36氪经授权发布。