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、单模型、单份对话记录和一个循环。

模型在一个循环中反复工作，每轮可同时发出一批工具调用，结果直接返回给模型，由它决定下一步操作。

打个比方，后厨做一道菜，需从备菜开始，再到洗菜、切菜、下锅，最后装盘上菜。

换成以前的分工，洗菜、切菜、掌勺、摆盘各一人，每人都有任务列表。问题在于，每个人的任务列表由上一个人提供，比如切菜者从洗菜者手中获取。

菜端上桌发现咸了，很难判断是哪一环的问题——可能是掌勺的多放盐，也可能是菜没洗干净。

单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，而是建议将其按需加载为Skill。每个子Agent携带各种知识，如切菜的刀法、掌勺的火候。需要时调用这些Skill，完成后即收回。这种方法效果可测。Anthropic提到，通过配套工具将子Agent转化为Skill，可削减80%以上的系统提示词，使原本臃肿的提示词变得简洁，节省出大量上下文空间用于任务本身。

我们真的还需要子Agent吗

子Agent在诞生之初，本就是工程上的妥协。当时还在OpenAI的卡帕西曾发推文称，GPT并不知道自己有上下文限制，执行任务时易填满上下文导致失败。因此需通过手段拆分任务，让模型分步完成。

2023年3月底，AutoGPT和BabyAGI进行了两个实验项目，核心是用一个Agent将大目标拆成多个待办列表，自行分配任务并执行。这些项目证明，让模型自行决定下一步，循环即可运行。但也暴露了问题：若循环中缺乏可靠的验证环节，错误会在循环中自我放大。一个Agent说“我要查这家公司财报”，即使查到的数据有误，它仍会基于错误信息继续推导，最终输出看似合理但实际荒谬的结果，甚至无限循环、错上加错。

2023年下半年至2024年，行业给出的解决方案是让分工模拟真实公司。例如MetaGPT，将模型分为产品经理、架构师、工程师、测试四个岗位。输入“做一个贪吃蛇，带排行榜”后，系统按岗位层层推进：产品经理编写需求文档，架构师将其转化为系统设计和接口，工程师按接口写代码，测试挑出问题，最终生成完整程序。当时思路朴素：一个模型易跑偏，就让多个模型相互照应，这形成了子Agent系统的雏形。

简而言之，子Agent本质上是“用架构模拟一台更宽、更稳、内存更大的机器”。除了上下文窗口有限，Anthropic在文章中还提到，模型可靠性有限，链越长越易崩溃；且模型只能单线程工作，无法同时思考。Anthropic表示，2024年开发子Agent的动机正是解决这三件事：上下文隔离，防止主上下文被海量中间产物污染，变相扩展上下文窗口；不同任务分配不同工具，防止链条某处崩溃影响整体；并行处理，多条独立线索同时推进。

Anthropic认为，子Agent算是模型的一种“补丁”，但这些补丁需按token付费。过去两年，付费方多为按API计量的开发者和企业，成本明码标价、可核算。随着C端订阅制流行，Anthropic表示是时候改改了。

月度额度是一个黑箱。用户只知道“本月剩余额度”，却不知“这一轮对话中，子Agent消耗了多少”。订阅用户按“完成了几件事”判断额度，系统却按“调用了几次模型、开了几个分支、读了几遍文件”计算。因此，Anthropic表示，模型性能和算力逐步提升，这些“补丁”仅在极其复杂的任务中有效，对绝大多数任务而言，子Agent只会消耗更多token。最终结论是：子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一旦开启就消耗额度，即使其作用微乎其微。

公平地说，这不是K3.1 Pro独有的问题。Claude用户也吐槽过，20美元档订阅中，一个提示词就用完5小时额度；Opus 5.5处理存量代码库，约30分钟触发限制，原因都是Claude开启了太多子Agent。Anthropic认为，这是“长程Agent”品类的“结构性矛盾”。给模型一个任务，它要查资料、读文件、写、改、再自行验证，需跑几十步，每步重读上下文，跑半小时是常事。模型越强，搜索更久，工具调用更多，自查轮数也更多。

Anthropic给出的解决办法是，从产品侧替用户判定“哪些子Agent调用是不必要的”，进而减少子Agent，能用单Agent解决就坚决不开子Agent。此外，让用户能决定步数上限，在单任务开始前提示预算区间。眼瞅着Anthropic即将上市，减少子Agent以降低token消耗，也是为了讨好C端用户。在探索类似优化方案时，九游娱乐的技术团队也关注到这类架构调整对用户体验的影响。

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