RTK 压缩了终端输出，为何账单可能反而上涨
据 Quesma 9 月 11 日的对照测试，RTK 虽然能过滤终端输出，却没有在测试组合中稳定降低 AI 编程成本。项目自身说明也区分了输出缩减与实际账单。
作者：林岚｜OC 开发者生态编辑
据 Quesma 9 月 11 日的对照测试，RTK 虽然能过滤终端输出，却没有在测试组合中稳定降低 AI 编程成本。项目自身说明也区分了输出缩减与实际账单。
一句话结论：要评估省钱工具，应看完成同一任务的总成本与成功率，而不是工具自行计算的“删掉了多少 token”。
少读一点，为什么会多花钱
RTK 的作用是在命令结果交给模型前进行精简，例如减少目录列表或测试输出中的冗余内容。这种思路本身不难理解：如果信息不影响决策，就没有必要反复放进上下文。
但一次 Agent 任务不是固定输入加固定输出。模型看见不同信息，下一步动作也可能改变。少看到一条线索，可能意味着再搜索一次；错误摘要不够完整，可能意味着重复运行测试。每一轮还包含推理与工具调用，不能只数被过滤的那部分文本。
这就像把说明书缩短，并不必然让安装过程更快。如果被删的是无用页脚，当然有帮助；如果被删的是某个兼容条件，省下的阅读时间可能变成排错时间。
这次测试不能只抄一个平均数
Quesma 在 Terminal-Bench 2.1 上比较 Claude Code 配合 Fable 5.0，以及 OpenCode 配合 DeepSeek V4 Pro 0813；每个任务在开关 RTK 的两种情况下分别安排五次尝试。最终比较包含 1,740 次尝试。
报告中，Fable 组合的总账单略降，DeepSeek 组合则略升。但当每个任务等权比较时，Fable 没有清晰的降本优势，DeepSeek 的平均任务成本上升。这里的差异不是统计在“打架”，而是它们回答不同问题。
总账单容易被少数昂贵任务左右；任务等权更接近“随机挑一种工作时会怎样”。企业如果每天都做同一类任务，应关心自己的分布，而不是从全榜挑一个最顺眼的数字。
“节省计数器”不一定在数付费 token
研究者指出，RTK 的 gain 指标主要由原始与过滤后输出的字节差估算，不是模型供应商出具的计费记录。原本就被命令截断的输出，也可能让比较基准产生偏差。
更重要的是，这类计数器无法知道模型之后是否多走了几轮。即使它准确描述了当前命令省下的内容，也不应该被直接当成整个任务的节省金额。
缓存进一步改变了直觉。输入内容是否命中缓存、模型生成了多少输出、任务有没有反复失败，都会影响最终费用。一个百分比若没有说明分母，只能是局部信息。
版本问题也要与整体结论分开
报告记录了旧版命令改写导致反复出错的案例，同时明确后续版本已经修复。不能把旧缺陷当成今天必然发生的问题，也不能因为修好一个缺陷，就宣布全部成本差异都已消失。
这类工具应该像依赖升级一样验证：记录版本，选取自己的任务，比较成功率、总花费、用时和人工补救。若只对某一类长输出有效，可以局部启用，不必把它变成全部工具调用的必经路径。
OC 更看重一个可撤销的优化：当过滤妨碍判断时，Agent 能否直接取原始结果？开发者能否查看到底删了什么？没有退路的压缩，可能把可见成本换成隐蔽的不确定性。
关键事实
- 这是特定模型、工具版本与 Terminal-Bench 2.1 的实验。
- 输出压缩比例不等于计费 token 的下降比例。
- 总账单、任务等权成本和每次成功成本是不同口径。
- 已修复的旧版问题不应被描述为当前版本必现。
OC 判断
RTK 可以是局部优化，但不是通用省钱承诺。真正可交付的成本指标应是“一个验收通过的任务花了多少”，并把失败、重试和人工修复一起算进去。
为什么重要
- 对开发者：先保留可回溯的原始信息，再考虑精简。
- 对团队：用自己的任务分布测量，而非照搬宣传比例。
- 对采购方：账单证据比工具自报节省量更可靠。
评论
围绕这篇文章补充信息、提出问题或分享观察。