减少Token不等于降低成本

背景

基于 API 的编码代理（coding agent）已成为软件开发的重要辅助工具，它们通常依赖检索增强生成（RAG）和上下文裁剪层来管理输入 token 数量。常见的裁剪手段包括命令输出压缩器、检索排名器以及 payload 优化代理。业界对这些工具的主流评估指标是它们“去掉了多少文本”，即 token 缩减量。然而，实际 API 调用中，成本并不单纯由输入 token 总数决定——缓存命中、模型推理开销、任务迭代轨迹等因素可能使 token 缩减与账单节省之间出现脱节。这篇来自 arXiv cs.CL 的论文（提交于 2026 年 7 月 13 日）以 Claude Code 为实验平台，系统性地检验了一个核心问题：减少检索上下文或工具输出，到底在什么情况下能真正降低计价成本，同时不损害任务完成率或延长解决时间？

核心内容

作者设计并执行了一套预先指定、哈希冻结（hash-frozen）、成对比较的实验方案。实验共进行 2,908 次按提供商计费的 Claude Code 运行（其中 2,848 次纳入最终分析），覆盖 103 个任务、7 个代码仓库和 3 种模型。在更广泛的测量计划中，总共有约 5,500 次计费执行。实验将基准配置与两代基于 hook 的压缩方案以及一个 API 边界代理（API-boundary proxy）进行了对比。

通过一系列受控对比，研究得到三个核心发现：

1. Prompt-cache 流量主导了成本构成。在重构的四组件成本模型中，缓存创建和缓存读取合计约占 87%；在实际账单中，这一比例约为 80%。此外，存在约 8.7% 的美元加权残差，保留的遥测数据无法解释其来源。在 Haiku 4.5 模型上，该残差与思考努力（thinking effort）程度呈正比缩放。

2. 工具输出缩减量不能可靠地预测计费成本降低。一个实验臂虽然去除了约 38% 的估计原始工具输出 token，但其成对成本却高出 6.8%（95% 置信区间：+2.8% 至 +11.3%）。即使在任务级别，缩减量与成本变化之间的关联也很弱（Pearson r = 0.15，置信区间跨越零）。

3. 压缩可能损害任务完成。在基于 SWE-bench 衍生的 Go 任务的单次小样本研究中，压缩导致补丁应用成功率从 27/40 下降至 15/40，原因是压缩破坏了逐字编辑锚点（verbatim edit anchors）。压缩后的 grounded 分支不仅解决任务数更少，且每个解决任务的观察成本更高。

基于这些证据，论文提出应以成功调整后的计费成本（success-adjusted billed cost）作为核心评价标准，而非仅仅关注 token 缩减量。

关键要点

• Prompt-cache 操作（创建和读取）是成本的最大来源，占总账单约 80%，压缩输入 token 而不影响缓存行为很难节省费用。
• 工具输出减量（38%）反而导致成本上升（+6.8%），表明 token 缩减与成本降低之间没有直接因果关系。
• 任务级别上 token 缩减与成本变化的相关系数仅为 0.15，统计上不显著。
• 压缩可能移除关键证据（如逐字编辑锚点），导致任务成功率显著下降（从 67.5% 降至 37.5%），且单位解决成本上升。
• 作者建议用“成功调整后的计费成本”代替单纯的 token 缩减率作为评估指标，衡量单位成功任务的实际支出。
• 实验使用了多种模型（含 Haiku 4.5）和真实仓库任务，结果具有实际参考价值。

意义与影响

该研究对 API 编码代理的设计与评估提出了重要警示：业界长期依赖的“token 缩减率”指标具有误导性。在实际部署中，工程师更应关注缓存策略优化（例如减少缓存创建失败或提升缓存命中率）而非盲目压缩上下文。对于压缩工具开发者而言，需要保护 action-critical 证据（如编辑命令中的精确字符串锚点）不受破坏。更广泛地，该工作倡导一种分层证据标准，将任务成功、轨迹长度与真实账单挂钩，为 LLM 代理的 cost-aware 设计提供了实证基础。未来 API 定价模型（如区分缓存读写与生成 token 的费率）也使得此类成本建模愈发重要。