AI编码Agent迭代循环如何导致token爆炸式增长？风险防控

金融和制造领域的案例相对丰富，消费和零售则仍在探索阶段。

最近，一篇arXiv论文把开发者们隐隐担忧的成本问题直接量化了：Agentic Coding任务的token消耗，竟然是普通代码聊天或单轮推理任务的约1000倍左右，主要由输入token驱动。

拿一个实际修复GitHub issue的任务对比就能看出效果。优化前单一顶级模型跑完整流程，输入token占70-80%，累计上百万，成本过百。优化后通过路由+缓存+压缩，token总量降到原来的十分之一左右，输入输出比例更均衡，修复成功率没有明显下滑。

人类专家对任务难度的主观判断，与实际 token 成本之间仅呈现弱相关。开发者眼中棘手的复杂 bug，在 Agent 执行时有时消耗有限；而一些看似简单的修复，却因反复审查和上下文维护而大幅推高开支。这种感知脱节，进一步增加了对 agentic software engineering 进行 tokenomics 管理的复杂性。

纠正确认这个误区后，预算规划就从被动挨打转向主动的输入优化工程。值得持续跟踪的是，随着Agent场景快速演进，未来上下文压缩技术或原生长上下文架构可能带来新变量，但当前阶段把注意力转向输入主导，已是能立刻见效的调整方向。

从机制上看，代码审查阶段的高消耗本质源于其高度上下文依赖的对话性质。Agent需要反复将已有代码库、历史修改和测试结果塞入提示中进行分析和反馈，每次交互都重载大量信息，从而形成持续的输入累积。论文将此描述为“对话成本”，并指出这是当前多代理架构的固有特征，而非单纯模型能力问题。优化方向或许在于减少不必要的上下文重复，而非一味追求更强模型。

另一个反直觉发现是准确率与token消耗的关系曲线。高消耗并不必然对应高准确率，峰值往往出现在中间成本区间，继续堆token后表现趋于饱和甚至浪费。Agent可能陷入冗长无效循环，重复验证已知路径，却无实质推进。这反映出人类对任务难度的主观感知，与Agent实际计算努力存在明显脱节：专家觉得棘手的bug，Agent有时用较少token即可解决；反之看似简单的问题，却因路径随机而耗费巨量资源。

除了模型间差异，论文还指出，人为评定的任务难度与实际token消耗仅呈弱相关。人类直觉认为的“复杂Bug”，Agent执行时消耗的计算努力可能完全不同。这解释了为什么一些看似简单的修复任务会突然烧掉巨量token。类似地，前沿模型普遍无法准确预测自身token使用，预测相关性最高仅0.39，且系统性低估真实成本。这意味着预算规划往往不靠谱，值得持续跟踪，现在下结论为时尚早。

Kimi K2 和 Claude Sonnet 4.5 在 token 消耗上明显更高，同一组任务平均多出 150 万 token 以上。论文推测，这可能与它们更长的迭代循环、不同的上下文处理方式有关，尤其在处理大型代码库时容易陷入反复调试。数据还揭示了一个反直觉现象：token 使用具有高度随机性，同一任务多次运行的总消耗可能相差高达 30 倍。

许多开发者在实际部署AI编码Agent时，都会遇到一个隐形陷阱：原本以为一次简单的bug修复任务，几千token就能搞定，结果因为自纠正和反思循环反复迭代，token消耗迅速失控，从初始几千直接攀升到数十万甚至百万级别。arXiv最新论文《How Do AI Agents Spend Your Money?

主流的定价误区在于过度关注“输出token溢价”。很多人以为输出单价高就是主要开销来源，于是在提示词里反复强调“保持简洁”“只输出最终结果”。但在Agentic场景里，模型每一步都需要把之前的上下文、工具输出、历史轨迹全部塞回输入窗口。上下文不断累积，输入token就成了真正烧钱的那个部分。输出token贵是表象，输入token才是Agent长期运行的真凶。

企业需要在平衡技巧与实际落地之间找到更务实的平衡点。