Kimi额度烧太快背后，Anthropic为何反思子Agent架构

月之暗面发布K3.1 Pro后不久，便收到大量关于使用额度消耗过快的反馈。部分用户发现仅执行一两个任务就会耗尽数小时额度。月之暗面随后公开致歉，并明确表示将“减少不必要的子Agent调用和输出长度”。

这一工程痛点并非孤例。就在模型上线前夕，Anthropic发表了技术文章《构建Agent：何时该把子Agent折叠回主循环》（Building agents: When to fold subagents into your main agent loop）。Anthropic指出，通过观察多套基于Claude的企业部署方案，一个具备技能扩展能力的单Agent系统，在输出质量、响应延迟和单任务成本上，往往显著优于多子Agent协同架构。

多Agent架构为何成了新负担

子Agent机制最初是大模型能力有限时期的产物。早期模型上下文窗口较短、推理可靠性较低，且只能单线程处理任务。为防止大任务超出上下文限制或发生单点崩溃，行业通常借助类似MetaGPT或AutoGPT的思路，将任务切分给“产品经理、架构师、工程师”等多角色子Agent协作推进。

然而，随着模型性能增强与长上下文普及，这种工程补丁的副作用日益凸显。Anthropic将子Agent带来的核心缺陷归纳为三点：

1. Token复利与无效消耗：多Agent系统的Token消耗量通常是单次普通对话的15倍左右。大量消耗并未用于深度推理，而是耗费在不同子Agent之间反复传递身份声明、规则提示词与上下文摘要。系统不断重读同一份背景信息，大幅拉高推理成本。
2. 跨层级信息衰减：需求在经过多个子Agent逐层传递、摘要和重构后，保真度呈梯级下降，最终产出往往脱离初始目标。
3. 输出风格与人格碎片化：不同子Agent往往绑定不同的系统提示词，多分支并行工作容易导致最终生成的语言风格割裂，难以保持一致的交互体验。

针对这些问题，Anthropic主张回归“单Agent、单模型、单份上下文、单一循环”的主链路设计，让模型在一个Loop内执行多轮工具调用，并根据即时反馈调整下一步动作。而原本独立的子Agent，应被转化为按需加载的“技能”（Skills）。在进入特定处理阶段时动态载入知识，完成后立即移出上下文，据称该方案可精简80%以上的静态提示词冗余。

从API计费到订阅制：长程Agent的隐性矛盾

在过去以API按Token调用的开发场景下，开发者对子Agent带来的算力开销具有清晰的成本预期。但在面向C端或固定订阅制的场景中，用户只关注“完成了几个任务”，无法直观感知后台调度了多少个子Agent和分支链条。

当执行复杂的代码审查或长程调研时，大模型会反复进行搜索、读取、修改和自我纠错。随着推理链条延长，子Agent一旦启动便会锁定并烧掉大量额度。无论是Claude用户在重度任务中快速触发订阅限制，还是Kimi用户遭遇额度熔断，本质上都是长程Agent系统与用户固定预算感知之间的结构性冲突。

为了推动这一技术路线的演进，Anthropic开源了单Agent架构工具包，倡导在系统底层为用户预设步数上限与预算区间，能用单一Agent主循环解决的任务坚决不开设子分支。伴随基础模型原生推理能力的演进，曾经繁复的“多智能体协作”体系，正在加速向更精简、更集约的架构收敛。