AI Agent 编码任务为何疯狂烧钱？输入 Token 主导成本的 arXiv 论文解析

本篇重点分享几条被反复验证的观察结论。

这一发现对开发者预算规划提出了直接挑战。模型往往系统性低估自身token消耗，预测相关性最高仅0.39，规划时容易过于乐观。短期内，优化prompt设计、实施上下文缓存或将审查拆分为独立子任务，能显著缓解开支压力。长期来看，tokenomics可能成为agentic coding的新瓶颈，推动行业探索更高效的模型架构、多代理分工（如编码代理专注生成、审查代理专注验证）或上下文压缩技术。

输入上下文而非输出生成，成为主导成本的因素，这一点与许多人的直觉相悖。

行业里讨论AI Agent成本时，目光常落在模型单价和输出token上。很多人认为只要控制生成长度，就能有效省钱。论坛和开发者社区也反复提到，Agent虽能处理真实GitHub issue级复杂编码，但单次运行费用难以预估，预算像失控一样波动。这些观察有道理，却忽略了运行间巨大的随机波动，以及“多花token未必带来更好准确率”的实证盲区。

深层观察显示，agentic任务的高耗主要源于反复读取上下文、工具调用和迭代修正形成的“通信税”。高token用量并不必然对应更高准确率——研究指出准确率常在中间成本区间达到峰值，继续投入反而出现饱和。模型间效率差距显著，而人类专家对任务难度的主观判断与实际token成本仅呈弱相关。这说明凭经验预估的复杂度，与Agent真实计算开销之间存在明显鸿沟。

最近arXiv上关于agentic coding的实证研究显示，AI Coding Agent在处理SWE-bench类任务时，token消耗往往比普通代码聊天或单次推理高出约1000倍。主导开销的并非生成代码的输出token，而是反复读取上下文的输入token。即使启用缓存，这种“通信税”依然显著。开发者以为多加几次迭代就能提升准确率，实际却经常陷入边际收益递减的循环。

这些观察来自最新论文轨迹数据和开发者实际反馈，控制好输入 token 和随机性，AI Coding Agent 才能从潜在负担变成真正的高效助力。值得持续跟踪，现在下结论为时尚早。

这些观察共同指向一个开放问题：在token消耗高度随机的agentic coding环境中，开发者如何在效率与成本间找到更稳定的平衡点？随着更多实证研究的积累，这一答案或许会逐渐清晰。

大多数讨论仍停留在代理带来的效率跃升上。在SWE-bench这类真实软件工程基准中，顶级代理系统已展现出不俗表现，许多开发者相信，用好Agentic Coding就能让AI像资深工程师一样独立处理复杂项目，从而显著减少人力投入。主流观点倾向乐观，认为这标志着从简单聊天助手向真正工作伙伴的转变，用对它就能放大生产力。

论文重点考察了需要多步工具调用和上下文累积的agentic tasks。在SWE-bench这类真实软件工程场景中，Agent不断阅读代码、调用工具、生成补丁、验证测试，导致输入token快速膨胀。即使启用缓存，上下文累积效应仍主导整体开销。输出token虽重要，但远不是成本大头。这种输入驱动的特性，让传统“控制生成长度就能省钱”的思路显得不够充分。

第三，不同模型的token效率差异显著。在相同SWE-bench任务上，Kimi-K2和Claude-Sonnet-4.5平均比GPT-5多消耗超过150万token。这反映出架构、提示处理和工具集成方式的本质区别。企业选择部署哪款模型，直接决定了实际运营成本的高低。数据支持这个方向，但样本量仍有限，值得持续跟踪。

只是当时的灰度范围或指标设置，没有把这些信号充分放大。