多代理协作中的Token浪费：从通信开销到优化路径

这个判断可能需要时间来修正，但趋势已较为明显。

深层拆解显示，软件开发生命周期中各阶段token分布极不均衡。代码审查不仅是token消耗主力，还呈现出输入主导特征（输入51.4%，输出24.7%），因为Agent需要反复将已有代码库、历史修改和测试结果塞入提示中进行分析反馈。相比之下，编码阶段输出占比更高（58%），更接近传统生成任务。不同模型间效率差异同样显著，Kimi-K2和Claude-Sonnet-4.5在相同任务上平均比GPT-5多消耗超过150万token。

最近arXiv上的一篇论文《How Do AI Agents Spend Your Money?》把这个痛点说得很清楚。他们用OpenHands agent在SWE-bench Verified任务上系统分析，发现agentic coding任务的token消耗是普通代码聊天或推理任务的1000倍左右。而且，主导成本的不是输出token，而是输入上下文。同一任务不同运行之间，token用量差异能达到30倍。

为什么 AI Coding Agent 这么“费钱”？agentic 流程涉及大量迭代、工具调用和上下文交互，输入 token 占比远超预期。高消耗并不必然带来高准确率——论文数据显示，准确率往往在中级成本区间就已达峰值，继续追加 token 反而进入收益递减区。

云端买的是顶级大脑的服务，但每一次思考、每一次上下文迭代，你都得持续付费。更关键的是，所有数据需上传，涉及公司核心代码时隐私风险难以忽视。适合低频、追求极致性能的场景，比如快速原型验证或非敏感模块开发——前提是你能接受账单的随机性。

人类专家对任务难度的主观判断，与Agent实际token成本仅呈弱相关。开发者眼中棘手的bug，有时Agent处理起来token开销很低；反之，一些看似简单的修复却触发反复审查循环，吞噬大量资源。这种感知脱节让tokenomics管理变得棘手。我的判断是，迭代验证而非初始生成，才是agentic software engineering的核心成本点——代码审查吃掉近60% token，本质上是高度上下文依赖的对话过程在反复“重温”历史。

上下文压缩与流程优化则从源头遏制膨胀。用廉价模型对检索文档或工具输出做预压缩，只保留核心事实；设置硬性 token 上限，要求输出简洁指令而非冗长解释；将复杂任务拆成子代理，每个子代理只看到必要上下文。LangChain 的压缩模块结合这些操作，行业案例显示单个任务 token 用量能从百万级降到十分之一，同时准确率基本持平甚至略有提升，因为模型注意力更集中。

另一个值得注意的发现是，人类专家对任务难度的主观评判，与实际token消耗只有弱相关。开发者眼中简单的bug修复，Agent可能因反复试错而烧掉大量输入token；反之，一些看似复杂的模块，模型有时能快速收敛。这暴露了感知复杂度与计算实际开销之间的脱节，给预算预估增添了不确定性。数据支持这个观察，但样本量有限，值得持续跟踪。

模型间的效率差距同样显著。在相同SWE-bench任务上，Kimi-K2和Claude-Sonnet-4.5平均比GPT-5多消耗超过150万token。这不是理论数字，对于需要频繁调用Agent的开发团队来说，选择模型就能直接影响月度API费用。论文对比了八个前沿模型，清晰表明不是所有“大模型”在agentic coding场景下都具备同等的token经济性。

云端AI Agent的最大优势在于性能和易用性。以GPT-5、Claude-Sonnet系列为代表的前沿模型，在复杂编码场景下准确率更高，无需自己搭硬件，直接通过API就能上手。开发者可以快速构建多步Agent流程，处理SWE-bench这类真实软件工程问题时往往能取得更好结果。但论文也显示，不同模型间token效率差异明显，有些模型在相同任务上比GPT-5多消耗超过150万token。

当然，成本趋势仍存在不确定性。如果上下文优化、提示缓存以及更高效模型得到普及，单任务开销有望得到更好控制；反之，多代理协作中的通信税若长期未解，规模化ROI的实现时间可能会延后。数据支持这个方向，但样本量和实际落地场景仍有局限，值得持续跟踪，现在下结论为时尚早。

我的观察是，那些愿意在细节上较真的团队，通常半年后会看到明显分层。