输出 token 溢价 vs 输入主导：AI Agent 定价模型的误区

或许我们该把注意力更多放在用户真正需要什么上。

论文核心数据显示，同一任务不同运行的token消耗可相差高达30倍，输入token而非输出token才是主导成本的因素。准确率通常在中等成本区间达到峰值，继续增加消耗反而出现饱和。这说明AI Agent的“努力”更多体现在反复吞吐上下文、调用工具和试错循环上，而不是像人类那样通过深化“脑力”攻克逻辑深度。

上下文膨胀同样直接推高成本。Agent 运行中不断累积对话历史、工具输出和代码片段，输入窗口迅速扩张。针对这一问题，引入中间检查点机制，每固定步数对上下文进行 summarization 压缩，仅保留关键决策和变更记录；同时启用 caching，对重复文件或工具结果本地缓存，减少重复计费。在中等规模代码库项目中，预先生成架构摘要让 Agent 优先读取摘要而非全量文件，能显著降低输入开销。

Reflexion loop和self-correction cycles这类机制，本意是提升准确性，却让上下文像滚雪球般累积，每一轮都在为历史买单。

许多开发者在实际部署AI编码Agent时，都曾经历过这样的场景：原本针对SWE-bench上一个简单的GitHub issue修复任务，基于OpenHands框架启动后，自纠正机制却让整个过程陷入反复迭代。每一轮反思都将历史轨迹、工具调用结果和先前输出完整塞回提示，token消耗从最初几千迅速膨胀到数十万甚至百万级别。同一任务不同运行路径下，消耗差异可达30倍以上，导致API账单突然失控，不少团队被迫暂停或缩减Agent规模。

更深层的问题在于消耗的随机性，即stochastic consumption。同一任务、同一个模型，不同运行的路径可能天差地别——工具调用顺序、循环次数、无效探索分支、上下文管理方式，这些组合像掷骰子。论文数据显示，某些运行的总token能比另一次高出30倍。开发者往往以为模型越强就越稳定，但实际随机性远超预期，这直接放大了预算不确定性。

表面上看，AI Agent编码被宣传为高效工具，能自动迭代调试、处理复杂仓库，帮团队缩短开发周期。主流报道里常强调输出质量和速度，token费用虽高但被视为值得的投资。可实际运行时，大部分注意力都集中在最终生成的代码片段上，很少有人留意Agent在多轮交互中如何不断把历史对话、工具返回、失败日志和仓库片段塞进输入窗口。这些隐性输入累积起来，迅速把总成本拉高，跟传统单轮任务的输入输出平衡形成鲜明对比。

模型间效率差异同样惊人。在相同任务上，Kimi-K2 和 Claude-Sonnet-4.5 平均比 GPT-5 多消耗 150 万以上 token，即使在所有模型都能解决的简单子集上这一差距依然存在。人类专家对任务难度的主观判断与实际 token 成本仅呈弱相关，这意味着凭经验预估开支很容易失准。大多数开发者以为更强的模型天然更省钱，但现实恰恰相反，聪明模型在 agentic 流程中往往制造更多无效迭代和上下文膨胀。

你部署AI Agent时，是不是总盯着输出token定价，以为控制生成长度就能省钱？结果账单拉出来一看，输入token却占了大头——这正是大多数团队正在踩的坑。

前沿模型对自身token用量的预测能力仍显薄弱，相关系数最高仅0.39，且系统性低估真实成本。这意味着即使顶级LLM，也难以在任务启动前提供可靠的预算预估。值得持续跟踪的是，如果开源轨迹数据被广泛用于优化预测模型，代理经济的规模化落地能否加速；反之，复杂场景的应用可能继续受限。数据支持这个方向，但样本量有限，现在下结论为时尚早。

从部署角度看，这一弱相关性对agent deployment的成本控制提出了现实挑战。短期内，若团队仍依赖人类专家难度标签做预算，容易出现严重超支或资源低估，直接拖累项目ROI。长期而言，它会推动行业开发更精准的token预测工具、优化模型效率，或设计内置预算感知的Agent架构。目前前沿模型自我预测token消耗的相关性最高仅0.39，且系统性低估真实开销。

难点汇总的实际效果，仍需更多中长期实践来验证。