Token减少并非成本降低

# Token 缩减不是成本缩减：基于 API 的编码智能体端到端效率的实证研究
来源：https://arxiv.org/html/2607.12161（2026 年 7 月）

###### 摘要

针对基于 API 的编码智能体的上下文缩减层——命令输出压缩器、检索排序器和负载优化代理——通常以其移除的文本量来评估。我们转而提出另一个问题：降低检索上下文或工具输出何时能*实际减少*编码智能体的*计费成本*，同时不降低任务成功率或延长其轨迹？我们的主要证据是一个预先指定、哈希冻结的配对实验，包含 2,908 次供应商计费的 Claude Code 运行（2,848 次被分析；103 个任务，7 个仓库，3 个模型），比较了基线、两个基于钩子的压缩代际以及一个 API 边界代理，该实验包含在一个更广泛的约 5,500 次计费执行的测量计划中。三个发现凸显。第一，提示缓存流量主导成本构成：缓存创建和读取约占重构的四组件成本的 87%（实际账单的约 80%），同时有一个明确披露的 8.7% 的美元加权残差，保留遥测数据无法解释——且在 Haiku 4.5 上，该残差随思考努力程度缩放。第二，工具输出缩减并不能可靠预测计费成本缩减：一个移除了估计原始工具输出 token 38% 的分支显示*更高*的配对成本（+6.8%+6.8%，95% CI [+2.8,+11.3][+2.8, +11.3]），且每任务缩减是成本变化的一个弱而不稳定的预测因子（Pearson r=0.15r=0.15，CI 跨越零）。第三，压缩可能通过破坏行动关键证据损害任务完成：在一项基于 SWE-bench 派生 Go 任务的小型单轮研究中，压缩通过破坏逐字编辑锚点将补丁应用从 27/40 降至 15/40，且压缩接地分支在更高观察到的每解决成本下描述性地产生更少的解决。我们提出一个分层证据标准，最终以成功率调整后的计费成本为目标。

## 1 引言

基于 API 的编码智能体，如 Claude Code[3 (https://arxiv.org/html/2607.12161#bib.bib3)]、SWE-agent[33 (https://arxiv.org/html/2607.12161#bib.bib33)] 和 OpenHands[29 (https://arxiv.org/html/2607.12161#bib.bib29)]，通过迭代调用工具——shell 命令、文件读取、搜索、测试运行——并将结果文本反馈回大型语言模型来运作。每一轮都会重新传输不断增长的上下文：仓库摘录、先前工具输出、测试日志、差异以及对话历史。这种增长使“上下文经济”本身成为工程关注点，并且涌现出一系列缓解层：确定性命令输出压缩器、查询感知检索排序器、语义和结构代码搜索，以及完整在飞行中重写负载的 API 边界代理。几乎所有这些都是通过某种形式的“移除了多少 token”来评估的：捕获命令输出上的压缩比、检索语料库上的预算内召回率、或合成装置上的保留标记数量。本文论证（并为评估的工作负载提供配对实验证据）token 移除对于从业者关心的指标——成功完成任务所需的供应商计费成本——是一个不完整甚至有时具有误导性的指标。

三个机制打破了这种朴素等价。第一，现代服务堆栈对缓存上下文以大幅折扣计费[2 (https://arxiv.org/html/2607.12161#bib.bib2),14 (https://arxiv.org/html/2607.12161#bib.bib14),20 (https://arxiv.org/html/2607.12161#bib.bib20)]；在我们测量的工作负载中，重构支出的大部分是提示缓存流量，其每 token 价格是名义输入价格的 10–125%，因此从中移除文本节省的成本远低于 token 数量暗示的。第二，智能体是一个闭环：如果压缩移除了模型稍后需要的上下文，模型可以再次搜索、重新读取文件或采取额外的诊断轮次，而这些增加轮次会重新传输*整个*上下文前缀。第三，压缩可能损害根本不是模型的下游消费者——在我们分析的一个失败模式中，排序的搜索摘要被导入到期望原始 grep 行数据的 shell 计数管道中，悄无声息地产生错误答案。因此，我们将经常混淆的六个测量层面分开：(1) 组件级压缩比；(2) 检索质量指标；(3) 模型可见的上下文缩减；(4) 计费 API token 缩减；(5) 端到端任务成功率；(6) 每成功执行成本。通过对所有保留的实验工件（日志、账本、清单、门控追踪和分析代码）完成的证据审计，我们将每个存在工件的系统——基线 Claude Code、RTK、RTK-ML 架构、Headroom、一个供应商 CLI 压缩器、ml_lexical 引擎、Caveman，以及词汇、嵌入、结构和联合检索——置于其工件支持的最高证据层，并且我们仅在存在配对且实际计费实验时才报告端到端结果。

#### 更广泛计划的规模。此处报告的结果源自一个显著更大的研究与开发努力：在整个更广泛的计划中，探索性、已取代、调优、失败分析和基础设施实验消耗的 API 资源远超此处分析的实验。本文不将该更广泛支出视为统计样本。相反，它详细报告了那些任务、配置、供应商返回使用量、成功判断、日志和分析工件被保留并可审计的受控实验；这些可审计实验约占实验清单（表 ̃3 (https://arxiv.org/html/2607.12161#S5.T3)，附录 A.2 (https://arxiv.org/html/2607.12161#A1.SS2)）中核对的约 643 美元测量 API 支出。我们披露更广泛的实验投入以传达搜索过程的规模，同时将定量主张限制在满足本研究可重复性和统计要求的较小证据集。¹

¹ 更广泛的开发支出是上下文性的，并排除在本文的所有样本量、置信区间、成本分解和系统比较之外。没有仓库账本汇总它，因此我们在此不陈述其美元数字。

#### 研究问题。
- • RQ1. 在现实配对工作负载中，哪些组件主导了基于 API 的编码智能体的计费成本？
- • RQ2. 其中多少成本可以通过工具输出压缩和检索上下文缩减来解决？
- • RQ3. 组件级压缩和检索增益能否预测端到端任务效率？
- • RQ4. 模型层级、努力程度、任务家族和轨迹结构如何中介系统效应？
- • RQ5. 对于可信的 token 效率主张，需要什么样的基准设计？

#### 贡献。
1. 1. 基于 API 的编码智能体的校准成本解剖：一个四组件分解，以约 ≈≈1% 的中位数每运行残差再现了大多数单个账单，显示缓存创建和读取约占重构成本的 ≈≈87%（实际账单的 ≈≈80%），同时有一个明确量化的 8.7% 美元加权残差，保留遥测数据无法解释（第 ̃6 节 (https://arxiv.org/html/2607.12161#S6)）。
2. 2. 编码智能体上下文缩减层的大规模配对、供应商计费比较——主要实验涵盖 2,908 次运行、103 个任务、7 个仓库、3 个模型、最多 5 个努力程度、以及来自相同新鲜工作副本的 4 个分支，采用块随机顺序，包含在一个 5,493 次计费执行和约 643 美元总 API 支出（其中 5,123 次在仅追加成本账本中）的测量计划内，外加 8,263 次零推理成本组件评估（第 ̃5 节 (https://arxiv.org/html/2607.12161#S5)）。
3. 3. token 缩减与成本缩减脱钩的直接证据：估计原始工具输出 token 减少 38.4% 与 +6.8%+6.8% 的配对成本增加并存，且每任务相关性近乎为零（r=0.15r=0.15）在工具输出缩减与计费成本变化之间（第 ̃7 节 (https://arxiv.org/html/2607.12161#S7)）。
4. 4. 从 13,620 个确定性分类的助手轮次构建的、关于“节省”在何处产生与偿还的轨迹和阶段级描述（第 ̃9 节 (https://arxiv.org/html/2607.12161#S9)）。
5. 5. 两个有记录的压缩安全失败模式——排序搜索输出的 shell 管道污染，以及破坏补丁应用所依赖的逐字编辑锚点——以及修复它们的缓解措施（第 ̃10 节 (https://arxiv.org/html/2607.12161#S10) 和 7.4 节 (https://arxiv.org/html/2607.12161#S7.SS4)）。
6. 6. 基于 SWE-bench 派生的 Go 任务的单轮接地完成研究表明，字节精确上下文接地与观察到的最大解决率改进相关（1/29 到 5/29），而接地原始分支解决的三个任务未被接地压缩分支解决，且没有任务表现出相反模式（精确配对 p=0.25p=0.25；压缩下描述性的每解决成本更高；第 ̃7.4 节 (https://arxiv.org/html/2607.12161#S7.SS4)）。
7. 7. 一个分层证据分类法和未来 token 效率主张的基准设计建议（第 ̃11 节 (https://arxiv.org/html/2607.12161#S11) 和 14 节 (https://arxiv.org/html/2607.12161#S14)）。

## 2 基于 API 的编码智能体的成本构成

### 2.1 术语

我们在全文使用以下术语；它们故意不可互换。
未缓存输入 token
以全额输入价格处理的提示 token（供应商使用字段 input_tokens）。
缓存创建 token
写入供应商提示缓存的提示 token（使用字段 cache_creation_input_tokens），以输入价格的乘数计费。
缓存读取 token
从提示缓存服务的提示 token（cache_read_input_tokens），以折扣计费。
生成输出 token
模型产生的 token（output_tokens），包括可见文本和工具调用参数。
工具使用块
模型在助手轮次中发出的结构化工具调用。
原始工具输出
工具在任何压缩层之前实际产生的字节（在这些实验中仅对 RTK 分支可通过钩子侧账本观察到）。
交付的（模型可见的）工具输出
经过任何压缩或排序层后到达模型的文本。原始和交付的工具输出 token 计数是来自 RTK 嵌入的本地 BPE tokenizer（tiktoken o200k_base 表）的估计值，非供应商 tokenizer。
轮次
一条助手消息；一次运行的*轨迹长度*为其轮次数。
每运行 / 每成功执行成本
每次运行的计费美元金额；以及*每成功执行成本*：分支中所有执行的计费总成本除以成功执行次数；同一底层任务的重复执行保持为单独尝试。我们用*成功率调整后成本*指代更广泛的概念，并且我们不报告每唯一任务估计量。
原始 shell 输出、交付的工具输出和生成输出 token 是三个不同的量；混淆其中任意两个会产生我们在第 ̃11 节 (https://arxiv.org/html/2607.12161#S11) 中讨论的大多数夸大的节省主张。

### 2.2 形式化成本模型

设一次运行消耗 $T_{\mathrm{unc}}$ 未缓存输入 token，$T_{\mathrm{cw}}$ 缓存创建 token，$T_{\mathrm{cr}}$ 缓存读取 token，$T_{\mathrm{out}}$ 生成 token，模型输入价格为 $p_{\mathrm{in}}$，输出价格为 $p_{\mathrm{out}}$（每 $10^6$ token 美元）。每次运行记录的计费成本是供应商的 total_cost_usd；我们的重构为：
$$\widehat{C} = \frac{1}{10^6} \left( T_{\mathrm{unc}} p_{\mathrm{in}} + T_{\mathrm{cw}} \mu_{\mathrm{w}} p_{\mathrm{in}} + T_{\mathrm{cr}} \mu_{\mathrm{r}} p_{\mathrm{in}} + T_{\mathrm{out}} p_{\mathrm{out}} \right), \tag{1}$$
其中缓存乘数 $\mu_{\mathrm{w}}$（写入）和 $\mu_{\mathrm{r}}$（读取）。针对计费金额的校准（第 ̃6.1 节 (https://arxiv.org/html/2607.12161#S6.SS1)）选择供应商公布的标准价格——Haiku 4.5 为 $1/$5，Sonnet 5 为 $3/$15，Opus 4.8 为 $5/$25 每百万输入/输出 token——$\mu_{\mathrm{r}}=0.1$ 且 $\mu_{\mathrm{w}}=1.25$（五分钟缓存 TTL）[4 (https://arxiv.org/html/2607.12161#bib.bib4),2 (https://arxiv.org/html/2607.12161#bib.bib2)]。

分支 a 在运行集合 $R_a$ 上，成功集合 $S_a$（其成功执行）下的每成功执行成本（CPS）为：
$$\mathrm{CPS}_a = \frac{\sum_{r \in R_a} C_r}{|S_a|}. \tag{2}$$

对于缩减层 j，我们区分其*可解决份额* $A_j$——$\widehat{C}$ 中可归因于该层能够修改的上下文的份额（对于工具输出压缩器，交付的工具文本及其下游缓存流量）——与其实际节省，即计费成本的配对变化：
$$\Delta C_j = \mathbb{E}_{\text{tasks}} \left[ \overline{C}_t^{(j)} - \overline{C}_t^{(\mathrm{base})} \right], \tag{3}$$
在配对块上估计（第 ̃5 节 (https://arxiv.org/html/2607.12161#S5)）。两者通过一个*轨迹项*不同：增加或移除轮次会改变方程 ̃1 的每个分量，因为每轮都会重新传输上下文前缀。将 $\Delta \text{turns}_j$ 写为轨迹长度的配对变化，该层的*成功率调整后净效应*是 $\mathrm{CPS}$ 的配对变化，只有当每轮节省超过轨迹和成功率损失之和时，该效应才可为负（即节省）。这是我们视为决策级数量的指标。

#### 交付工具 token 的边际成本。一个简化的边际模型使可解决份额具体化。一个在轮次 t 插入提示的交付工具输出 token 会产生（每 $10^6$ token）：
$$C_{\text{tool-token}, t} = \mu_{\mathrm{w}} p_{\mathrm{in}} + N_{\text{future reads}, t} \mu_{\mathrm{r}} p_{\mathrm{in}}, \tag{4}$$
其中 $\mu_{\mathrm{w}}=1.25$ 是观察到的五分钟缓存写入层级，$\mu_{\mathrm{r}}=0.1$，$N_{\text{future reads}, t}$ 是后续重用包含该 token 的缓存前缀的模型调用次数。其首次缓存创建定价*高于*普通输入；后续重用折扣。因此早期 token 比晚期 token 更具可解决性：在权威实验的约 ≈4.5 个助手轮次的平均轨迹中，第一轮交付的 token 被约 ≈3.5 次后续调用重读，成本约为 $(1.25+0.35) p_{\text{in}} = 1.60 p_{\text{in}}$，而最后一轮 token 的成本为 $1.25 p_{\text{in}}$——并且移除早期 token 也会移除其未来读取。被移除的 token 还可能自身改变轨迹长度，因此可解决性取决于轮次位置和未来重用，而不仅仅是 token 数量。保留的遥测数据并不记录每个 token 的进入轮次和后续调用的重用次数，因此我们将公式 ̃4 呈现为一个有边界的概念模型；精确的每 token 可解决性测量是未来工作。

### 2.3 实证成本堆栈

图 ̃1 (https://arxiv.org/... ) ...