Kimi额度烧太快的背后:Anthropic建议把子Agent折叠回主循环

K3.1 Pro 上线不到三天 , 月之暗面就因“额度烧得太快”公开道歉并补偿用户。几乎同时,Anthropic 一篇关于 Agent 架构的文章给出了另一种解释: 问题不只在模型本身, 还在那些被反复调起的子 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 调用和输出长度。

🔍 一个 Agent 带技能, 为何胜过一群子 Agent

Anthropic 在《构建 Agent: 何时该把子 Agent 折叠回主循环》中给出的结论是: 对绝大多数任务来说, 不需要那么多子 Agent, 单个模型、单份对话记录、一个循环就够了。它对比多家企业的 Claude 部署后发现, 带技能的单 Agent 在质量上反而更好, 单任务成本和延迟往往更低,token 消耗也远小于一群子 Agent。

• token 复利 : 每多一个子 Agent 就多一层分支, 多 Agent 系统的 token 消耗约为普通对话的 15 倍, 而且这笔钱大多花在“记”而不是“想”上——每个子 Agent 都要重建身份、规则、工具清单和上下文, 跑完再压缩成摘要交回。
• 信息衰减 : 信息在子 Agent 之间每传递一次, 保真度就掉一层, 到后面拿到的需求可能已和最初不是一回事。
• 人格碎片 : 不同提示词让子 Agent 输出风格各异, 用户面对的却只有一个入口, 品牌口径难以稳定, 还得等最慢的那个子 Agent 跑完。

💡 子 Agent 本来是“补丁”

子 Agent 并非毫无来由。 上下文窗口有限、模型可靠性有限、只能单线程工作 , 这三点让 2024 年的团队选择用架构去模拟一台更宽、更稳、内存更大的机器: 上下文隔离、工具隔离、并行推进。从 MetaGPT 式的岗位分工到各类多 Agent 实验, 都是这个思路的产物。

代价是按 token 付费。 过去买单的多是按 API 计量的开发者和企业 , 成本清楚可核; 到了 C 端订阅制, 月度额度成了黑箱——用户按“我做了几件事”理解额度, 系统却按“调了几次模型、开了几个分支、读了几遍文件”计费。

📊 该改的是产品侧, 不是用户

Anthropic 提出的办法是把子 Agent 按需加载成 Skill: 需要时取出, 用完放回 , 配合配套工具可砍掉 80% 以上的系统提示词, 把上下文空间留给任务本身。它还开源了 single-agent-loop-kit, 用于让模型只以单 Agent 形式执行任务。

另一层是让用户有控制权: 任务开始前提示预算区间, 允许设定步数上限 。这背后是“失败成本前置”的问题——子 Agent 只要开了就烧额度, 哪怕它的作用几乎可以忽略。

🚀 结语

模型越强, 搜得越久、工具调得越多、自查轮数也越多 , 架构复杂度却该往回收。Kimi 的额度争议和 Anthropic 的这篇文章指向同一个判断: 当模型能力补齐了当年的短板, 子 Agent 从能力放大器变成了成本放大器, 下一步的竞争点, 是谁能把不必要的调用关掉。