在 GitHub 拿下超过 7.9 万颗星的命令行工具 RTK,最近被一场耗资超 1500 美元的严密基准测试推到了风口浪尖。这个全称为 Rust Token Killer 的开源插件,号称能在终端输出进入大模型前进行结构化过滤与压缩,不少博主借此宣称其能帮 Claude Code 削减 60% 乃至 90% 的开销。然而独立评测机构 Quesma 在完成 1740 次端到端测试后给出的结论却截然相反:给终端输出做有损压缩,不仅很难帮开发者省钱,甚至可能让最终账单暴涨 17%

在这个人人都在寻找 AI 降本捷径的阶段,RTK 的实测翻车暴露出一个被长期忽视的系统性问题:字符变少并不等于账单变薄。

宣传数字与真实支出的断层对照 RTK 官方指标口径 (宣称) -89% 按 bytes / 4 计算的终端拦截体积 • 汇报节约 3.492 亿 Token • 剥离文件日期、权限与格式冗余 Terminal-Bench 2.1 (实测) +17% DeepSeek V4 Pro 单任务平均支出 • 交互轮数净增 18%,思考代偿激增 • Claude Code 总体账单仅微降 5%

水分过半的节约计数器

Quesma 的测试框架基于 Harbor 0.20,在标准评测集 Terminal-Bench 2.1 下运行。测试分别配置了搭配 Fable 5.0 的 Claude Code 2.1.220,以及走 OpenRouter 调用的 OpenCode 1.18.25 搭配 DeepSeek V4 Pro 0813,每个测试项均执行 5 次基线对照与 5 次 RTK 0.45.0 实验。

实测账本上的数据相当尴尬。搭配 Fable 5.0 时,总花费从 731 美元微降至 698 美元,降幅仅有 5%,且若按每任务等权重平均,单任务成本甚至反涨 1%;而搭配 DeepSeek 时,总支出由 51 美元攀升到 54 美元,单任务均值上涨 17%。在双方全通的 36 个 DeepSeek 任务里,成本增幅同样高达 18%。与此相伴的是任务成功率均下滑了 1 到 2 个百分点。

那么社交网络上铺天盖地的降本 90% 从何而来?秘密藏在 RTK 自带的统计逻辑里。

该工具内置的计量指标按过滤掉的输出字节数除以 4 来估算省下来的量。在 DeepSeek 的 445 次尝试中,面板显示它省下了 3.492 亿个 Token。但深入调用轨迹会发现,在一个名为 fasttext 的训练任务里,模型仅仅连续执行了两次查看首行的操作,RTK 却自作主张拿整个大文件的体积去减去这一行,直接登记了 2.41 亿个节省额度。

仅仅这两次调用,就占掉了整个统计面板里69% 的节约成果。大模型本来就只打算读一行文字,工具却宣称自己帮忙截断了整本书。

Agent 成本结构与信息衰减死循环 输出过度精简 单轮输入减少 7% 关键细节缺失 引发轨迹发散与怀疑 交互轮数激增 轮数膨胀 18%,账单反弹

截断信息的代偿陷阱

古人讲买椟还珠,追求虚表往往要付出预料之外的代价。在自动化编程环境里,大模型不是静态阅读器,而是一个具备动态修正能力的反馈闭环。

在 DeepSeek 的测试中,RTK 的确让每次交互的平均输入字符减少了 7%。但随之而来的代价,是 Agent 整体交互轮数增加了 18%。模型在拿不到完整错误堆栈、文件更新时间或特定返回码时,往往会推断自身环境异常,进而追加多次探测。一个额外的排查回合,其耗费的上下文传递与模型思考开销,足以抹平前五轮挤牙膏挤出来的微弱优势。

这绝非孤例。JetBrains 此前在 SkillsBench 上测试 RTK 0.43.0 配套 Sonnet 5 时,就记录到在低推理强度下,单任务交互轮数增加了 13.8%,单任务成本中位数上升了 7.6%。GitHub Copilot 团队在内部实验里同样证实:机械压缩终端回包,会导致 Agent 反复重试执行或重新拉取文件,最终让耗时与总体消耗双双超标。

更严重的是插件重写带来的系统脆弱性。在 RTK 0.45.0 中,由于重写逻辑不支持某类查找参数,曾导致 DeepSeek 陷入死循环,连续爆出 339 次连续报错,单次尝试的花费直接飙升至基线水准的 9 倍。尽管该问题在 0.46.0 版本中被修复,评测发表时工具也更新到了 0.48.0,但只要外挂拦截器无法百分之百还原系统工具语义,这类致命死锁就始终悬在头顶。


算清编程 Agent 的真实账本

评估降本工具时,如果把目光锁死在终端字符上,往往会犯一叶障目的错误。

Tokbench 的独立测试提供了一组很有价值的解剖数据:RTK 在它能够接管的命令范围里,平均能够压缩约 75% 的字节,但这类调用在 Agent 的全部 Token 支出中,覆盖面其实仅占约 2.5%

支出构成切片真实计费权重RTK 拦截能力实际经济影响
代码文件完整检索高额按次计费无法介入 (专用工具旁路)决定基础成本底线
上下文缓存续期 (Cache)仅占基础单价 1/10 至 1/30微弱影响终端字符被廉价计费对冲
模型深度推理 (Output)全场最贵单价负向激化 (诱发多轮思考)交互轮次直接主导总账单
纯 Shell 输出 (Bash)极低占比 (约 2.5%)强行截断过滤省流上限极低且易引发生病

在真实的工程框架下,Claude Code 原生提供的代码阅读、全局正则搜索等工具会直接绕过终端 Hook。大模型日常打交道的核心资产是完整源代码,而不是敲几行命令打印出来的零碎日志。

雪上加霜的是现代 API 的 Prompt Cache 机制。如今各主流大模型服务商对命中缓存的上下文输入只收取常规价格的十分之一甚至三十分之一。终端输出本就属于会被反复缓存的历史上下文,单价低廉;而 Agent 产生怀疑后多打出来的单轮思考,计费单价却高居不下。

  • 结论.试图靠拦截终端输出实现 90% 降本,无异于在占地千平米的机房里拔掉几盏指示灯来省电费。

真正决定 AI 研发成本分水岭的,从不是单个网络包压缩了多少字节,而是每次成功交付代码所需消耗的系统总投入。当一个优化手段以降低系统信噪比、挑起模型推理代偿为代价时,它带来的往往不是效能提升,而是隐蔽的账单通胀。