AI编码Agent同一任务token消耗为何波动高达30倍？论文实证揭秘

本期我们重点关注那些已经被验证有效的调整方向。

arXiv最新论文“How Do AI Agents Spend Your Money?”对八个前沿LLM在SWE-bench Verified上的完整轨迹进行了分析。结果显示，Agentic编码任务的token消耗是普通代码推理或代码聊天的1000倍左右，而主导成本的正是输入token，即使启用缓存，这一规律依然成立。

从实际部署看，这种波动让企业预算预测变得困难。开发团队修复同一个issue，第一次运行可能顺利通过测试，token在合理范围；第二次却走弯路，上下文膨胀导致成本直线上升，准确率却未必提升，甚至因超时失败。短期内，开发者需加强单次运行监控，考虑早停机制；长期而言，推动模型提升token预测能力（当前相关性最高仅0.39且系统性低估）将成为关键，否则高波动或成Agent规模化落地的隐形瓶颈。

Kimi K2和Claude Sonnet 4.5则处于较高消耗区间，在相同任务下平均多出150万+ token。可能的原因包括更长的迭代循环、不同的上下文管理方式，以及在复杂代码库中更容易陷入反复调试的状态。不过，论文也诚实地指出，这些模型在某些准确率峰值场景下可能仍有优势，尤其当任务需要极致深度推理时。适合对性能有极致追求、预算相对宽松的场景，但多花的token并不总能线性换来更好结果。

此外，前沿模型预测自身token消耗的能力仍较薄弱。论文数据显示，预测值与实际消耗的相关性最高仅0.39，且存在系统性低估。这让开发者在启动任务前难以准确预判开支，预算控制变得充满不确定性。短期内，这可能让中小团队对大规模部署Agentic Coding保持谨慎；长期来看，它或将推动行业向更token-efficient的架构演进，例如优化上下文管理或引入专用成本预测工具。但如果缓存与压缩技术未能快速突破，使用门槛或许会显著抬高。

这篇论文的贡献在于，它不是停留在抽象讨论，而是通过真实轨迹数据拆解了代理任务的token流动规律。与主流认知不同，代理并非简单的一次性交互，而是持续的上下文读取和工具调用循环，这直接推高了总体消耗。数据显示，代理任务的token用量比基准代码任务高出约1000倍，而公众和部分开发者还停留在“用代理就能省力”的阶段，这种认知偏差正在悄然放大部署风险。

无限循环迭代是常见浪费来源之一。Agent反复尝试相似修复方案，每次都重新加载大量上下文，token线性累积。实操中，提前在框架内设置单任务token预算上限，并在接近阈值时记录中间状态，能有效中断无效循环并从检查点重启。这在小规模bug修复中特别实用，避免了从头重跑的开销。

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

模型间的效率差距同样值得注意。在相同SWE-bench任务上，Kimi-K2和Claude-Sonnet-4.5平均比GPT-5多消耗超过150万token。这不是边缘差异，对需要频繁调用Agent的团队来说，选择合适的基础模型能直接节省大笔API费用。论文对比显示，并非所有“大模型”在agentic场景下都同样经济。

模型间的token效率差异也加剧了这一风险。在相同SWE-bench任务上，Kimi-K2和Claude-Sonnet-4.5平均比GPT-5多消耗超过150万token。人类专家对任务难度的主观评定与实际token成本仅呈微弱相关，最高相关系数只有0.39左右，且模型自身系统性低估真实消耗。这说明我们对复杂度的直觉与Agent实际的计算努力之间存在明显鸿沟，值得持续跟踪，现在下结论为时尚早。

这一点目前行业内仍有不同声音。数据支持随机性是主要驱动，但样本量和框架差异可能影响泛化程度。值得持续跟踪，现在下结论为时尚早。

这个转变的深层含义，还需要更多案例来佐证。