RTK 代币节省：基准测试揭示 AI 编码中的成本降低有限

RTK 无法为 AI 编码代理提供普遍的成本节省

Rust Token Killer (RTK) 的设计目的是通过在终端输出到达 AI 代理之前进行过滤和压缩，从而降低 AI 编码的成本。然而，对 Terminal-Bench 2.1 的实证基准测试显示，RTK 并未持续降低总成本。对于某些模型，它甚至会因迫使代理完成任务需要更多回合而增加支出，从而抵消了单个提示变短所带来的任何节省。

基准测试方法：Terminal-Bench 2.1

为了评估 RTK 的影响，研究人员使用 Claude Code（搭配 Fable 5.0）和 OpenCode（搭配 DeepSeek V4 Pro 0813）在 Terminal-Bench 2.1 上进行了 1,740 次尝试。该基准测试聚焦于代理通常能通过的任务，因为成本优化仅对成功完成的任务有意义。

成本与通过率结果

结果显示总支出几乎没有或呈负向影响：

• Claude Code (Fable 5.0)： 总成本下降了 5%（基准 $731 对比使用 RTK 后 $698），但其中大部分节省归因于单个任务（winning-avg-corewars）。排除该异常值后，节省不足 1%。
• OpenCode (DeepSeek V4 Pro 0813)： 总成本上升了 5%（基准 $51 对比使用 RTK 后 $54）。在任务级别衡量中，平均每个任务的成本增加了 17%。

通过率基本保持稳定，使用 RTK 时略有下降（Fable 为 1%，DeepSeek 为 2%）。

为何 'rtk gain' 是一个误导性指标

RTK 报告了一个称为 rtk gain 的指标，该指标计算原始输出与过滤后输出的字节数差值再除以四。这并非计费令牌的数量，也无法反映实际节省的金钱。

基准测试显示，rtk gain 可能被严重夸大。例如，在某个任务中，RTK 因将 head 的有限读取与整个文件大小进行比较，即使原始命令从未返回完整文件，仍记录了 2.41 亿个令牌的节省。由于 rtk gain 未考虑代理后续反应或额外回合的成本，它可能使一次昂贵的尝试看起来像是经过优化的。

'代币通胀' 效应：更多回合，更高成本

减少单个回合的输入大小并不能保证总账单更低。在代理式编码中，上下文通常会被缓存，使得后续读取终端输出的成本显著降低（Fable 为 1/10，DeepSeek 为 1/30）。

当 RTK 压缩输出时，可能会误导模型或移除关键信息，导致出现“代币通胀”问题：代理需要更多回合才能得出相同结论。对于 DeepSeek，RTK 尝试在 58 个任务中需要更多回合，其中 44 个任务的总成本更高。平均而言，DeepSeek 每回合输入减少了 7%，但总回合数增加了 18%，导致成本净增加。

技术风险与局限性

工具不兼容与循环问题

RTK 会重写 shell 命令，这可能引入错误。一次基准测试尝试陷入连续 339 次错误的循环，原因是 rtk find 不支持标准 find 命令所支持的特定标志。代理反复尝试同一个失败的命令，导致成本比基准高出 9 倍。

绕过机制

RTK 仅作用于 shell 命令。许多 AI 编码平台使用独立工具执行 Read、Grep 和 Glob 操作，这些操作完全绕过了 RTK。此外，前沿模型越来越高效地自行使用终端，通常会手动使用 head、tail 或 wc 来限制输出。

社区见解与替代方案

行业从业者和开发者提出了若干反论和替代方案，反对原始输出压缩：

"如果输出不符合预期，LLM 可能会比之前发出更多工具调用，因为它会认为工具出错了……这会产生更多令牌。"

"我只需在最便宜的范围内（例如 flash-lite）启动一个子代理来总结工具使用情况。根据我的基准测试，这是唯一有效的方法。"

一些用户认为，RTK 仍可能对特定且高度冗余的工具（如 Maven 或 Cargo）有用，但普遍认为对所有终端输出进行封装通常适得其反。其他人建议使用显式代理规则（例如 COMMAND 2>&1 | head -c 4000）来限制输出，而无需通过第三方包装器改变命令行为。