发现2：没有节省token；反而小幅增加了成本

HN Vibe Coding Practices 2026-07-24T17:15:39.779883

Ai logo

JetBrains AI

在 JetBrains 的多款产品中，用 AI 功能为你的工具加持

“rtk”技能真的能节省 60–90% 的 Agent token 吗？我们测了一下

Denis Shiryaev

rtk 能减少 Claude Code 的 token 用量吗？

这是本系列的第二篇：我们找了一些号称“省 token”的编码 Agent 插件，用同一组成对的 A/B 基准测试依次测评它们。第一篇测的是 thecaveman skill（宣传节省 65%，实测只省了 8.5%）。

太长不看版：rtk 声称节省 60–90%。在真实的 Agent 任务上实测：低推理力度下成本反而高了 7.6%（p=0.004），高推理力度下成本基本持平（±0%）。测试环境：Claude Code 2.1.201 · claude-sonnet-5 低/高推理力度 · SkillsBench。任务质量在两种模式下、两种力度下都没有变化。

太长不看版：rtk 声称节省 60–90%。在真实的 Agent 任务上实测：低推理力度下成本反而高了 7.6%（p=0.004），高推理力度下成本基本持平（±0%）。测试环境：Claude Code 2.1.201 · claude-sonnet-5 低/高推理力度 · SkillsBench。任务质量在两种模式下、两种力度下都没有变化。

为什么我们要测它

rtk（“Rust Token Killer”）是一个命令行代理工具，它的卖点简单又诱人：你的 Agent 执行 git status，rtk 拦截下来，真正跑一遍命令，然后给模型返回压缩后的输出——比如 * master / M a.txt / ?? b.txt 代替原本十一行的 porcelain 格式。Claude Code 的 PreToolUse 钩子能透明地改写符合条件的 shell 命令，模型甚至不知道 rtk 的存在。README 声称能降低 60–90% 的 token 消耗，并展示了一个 30 分钟会话的例子，其中命令输出从 118k tokens 压缩到了 24k。

压缩本身是真实的，而且往往很巧妙。下面是在我们的测试容器中，从命令行直接运行 rtk 的对比效果：

# git status                              # rtk git status
On branch master                          * master
Changes not staged for commit:             M a.txt
  (use "git add <file>..." to update…)   ?? b.txt
    modified:   a.txt
Untracked files:
  (use "git add <file>..." to include…)
    b.txt
no changes added to commit …

发现2：没有节省令牌，但成本小幅显著增加

# python -m pytest  (19 lines)            # rtk pytest
…完整的pytest输出…                       Pytest: 2 passed, 1 failed
                                         Failures:
                                         1. [FAIL] test_fail
                                              test_demo.py:3: in test_fail
                                              E  AssertionError: one is not two

这个想法让我们觉得值得认真测试。但README有两个问题没有回答：

第一，真实的智能体会话中有多少其实是Bash输出？节省表的假设是智能体对所有操作都通过shell调用。但Claude Code使用内置的Read工具读取文件、使用Grep搜索，这两者完全绕过了Bash钩子（rtk的文档也承认了这一点）。无论这些工具携带了多少数据，rtk都无法触及。

第二，压缩会不会损害正确性？一个对测试输出做摘要的过滤器，是在对模型需要什么做出编辑判断。如果它丢弃了关键的一行，智能体就会重新运行命令、直接读取原始文件，或者更糟，在一个失败的构建上宣布成功。以质量损失为代价的令牌节省，不是真正的节省。

实验设置

由于钩子机械地重写每一个符合条件的Bash调用，B组测量的是rtk“开箱即用”的极限：没有“模型是否记得使用它”的争议空间。每个使用rtk的试验还会持久化rtk自身的审计日志和分析数据库，作为处理确实被触发的证据。

发现1：大多数智能体的字节从未触及钩子

在花任何钱之前，我们回放了83个现有的基线转录记录（相同模型、相同基准），并问：如果安装了rtk，它能触及到什么？

有两个结构性原因。第一，Claude Code用内置的Read/Grep工具读取文件，这些工具完全绕过Bash钩子；rtk自己的README在脚注中承认了这一点。第二，智能体在shell中运行的命令有一半是python3 …和其他未覆盖的命令，六分之一使用管道到文件、heredoc和替换，这些rtk故意不重写。剩下的33%的Bash调用，只携带了不到20%的工具结果字符；而工具结果本身也只是会话中按输入计费的一部分，因为相同的上下文在每一轮都会重新读取。将rtk的整个份额压缩70%，上限大约是输入令牌的3%。这个数字无需花费任何计算成本，并且它预测了最终结果。

发现2：没有令牌节省，但成本小幅显著增加

我们按照猿人评估教给我们的阶梯进行了测试。在10个刻意采用Bash密集型任务（rtk的最佳场景）上的k=1烟雾测试显示，使用rtk的组别中位数成本高出35%。这令人警惕，直到你发现同一组别中相同任务的尝试之间成本差异中位数也有22%。在k=3时，大部分恐慌消失为噪声（Wilcoxon p≈0.65），这正是k=1幻象应有的表现。

然后，全部86项任务给出了抗噪声的答案，而且不是零。在80组干净的对比较中，使用rtk的组别每个任务成本中位数高出7.6%（修正了我们中途发现的一个成本计算缺口后，p=0.004），轮次多出13.8%（p=0.03），缓存读取多出14.3%（p=0.008）。而“新输入”——这是rtk唯一实际压缩的令牌类别——只增加了3.2%（p=0.23）：正是上限分析所说整个收益应该存在的地方，结果却是平坦的无效。

钩子重写的命令越多，惩罚就越大。在与头条结果相同的修正成本基础上，钩子覆盖多的任务对成本比基线高出约24%，而钩子几乎没碰到的任务对则仅高出5%。控制任务难度后，这个模式没有重现，因此更困难的任务使用更多Bash似乎并不能解释它。对转录记录的审计没有发现单一罪魁祸首：一个真正坏掉的重写（复合find谓词变成了用法错误并重试），几次压缩导致的重新读取，以及极端任务对上大量普通方差。这是一种细微、系统性的附加成本，而非灾难性失败。

发现3：在高推理强度下，惩罚甚至消失

“你只在低推理强度下测试了”是明显的批评，所以我们又用高推理强度运行了全部86个任务——这是整个系列中最昂贵的一次运行。结果：成本惩罚没有重现。中位数配对差异+0.1%（p=0.99），轮次+0.0（p=0.74），质量仍然持平。在高推理强度下，模型似乎浪费更少的轮次来应对压缩后的输出；不过，在k=1时我们只能说惩罚没有出现，不能说明两种强度模式可能不同。无论如何，rtk在任何时候都没有节省任何东西。

发现4：质量未受影响

rtk追踪器中那些可怕的失败模式——比如过度过滤测试输出、掩盖退出码、被压缩文本的管道——几乎没有出现。对6组轮次差异最大的烟雾任务对的取证检查，在大约150次Bash调用中，只发现了一个真正坏掉的重写（完整运行中也遇到过的复合find失败模式）和一次智能体故意绕过钩子的情况。在这些转录记录中，没有恢复文件被读取，也没有压缩管道产生错误计数（完整运行中恰好只有一次恢复文件读取）；额外的轮次绝大多数是模型选择了不同的解决方案路径，而不是rtk造成的混乱。在完整运行中，任务得分在低推理强度下为5更好/4更差/71持平，在高推理强度下为5/4/62持平（符号检验p=1.0），表明两组在质量上统计上无法区分，并计算了部分得分。

一个诚实的附带说明：在一个任务（dialogue-parser）上，rtk自身的二进制文件拒绝在任务的镜像内启动（它需要更新的glibc），因此使用rtk的试验在两次完整运行中都在设置阶段失败，而普通组得分为0.667。配对分析从两组中都排除了该任务，但这确实是一个真实的兼容性失败，而非Docker噪声。即使将每个出错试验的得分计为零，两组仍然持平（符号检验p=1.0）。

发现5：rtk自己的计分板 vs 账单

这是解释差距的发现。在低推理强度的完整运行中，rtk内置的分析（rtk gain）报告节省了9620万个令牌——占它触及内容的99.8%；而同期测量的账单却上涨了。三个机制导致计分板读数偏高：

首先，rtk将完整的原始输出算作它的反事实。一次对1.2 MB CSV文件的cat，日志显示“节省”了32万个令牌，但Claude Code在任何工具结果远未达到32万令牌之前就会截断它；所以智能体无论如何都只会收到几千个令牌。完整运行记录了190次这样的大读取，平均每次“节省”约50.6万个令牌。其次，rtk在执行的瞬间以字符÷4来估算令牌，而会话的大部分输入成本是缓存的重新读取，按十分之一的价格计费。第三，钩子根本看不到大部分上下文。计分板是在给自己打分。

结论

诚实的工程，错误的反事实。我们真心希望这个工具能赢；演示确实玩起来很爽。过滤器是真实的，而且往往很优雅；质量没有受损；钩子机制按设计完美工作。但在实际的智能体编码工作中，宣传的60-90%节省从未有立足之地：钩子只能看到大约五分之一的工具输出，Claude Code已经截断了rtk吹嘘要压缩的病理输出，而主导输入成本的缓存重读按十分之一的价格计费。剩下的就是测得的低推理强度下中位数+7.6%的成本增加，高推理强度下为零，一个坏掉的重写和一次额外的探索轮次带来的细微附加成本，从未出现节省。

更深的教训超越了rtk本身：一个工具自我报告的节省，是对其反事实的主张，而非对你的账单的承诺。 rtk的计分板说节省了9600万令牌，而账单却上涨了。如果你评估任何上下文压缩工具，请测量配对账单，而不是工具的差异。

方法说明

与第一部分相同的纪律，通过昂贵的经验学到：

永远不要相信k=1。 运行阶梯是：免费转录回放 → 1次测试的连接检查 → 10个Bash密集型任务（k=1） → 同样的10个（k=3） → 全部86个（k=1，低和高推理强度各一次）。两个组别中每次尝试的每个任务得分自由翻转；只有能经受阶梯考验的配对差异才被报告。
仅配对分析。 每个数字比较同一任务在两个组别中相同作业下的结果；任何一组中出错的都从两组中排除。质量使用非平局情况的精确符号检验；令牌/成本差异使用每个任务的中位数加Wilcoxon符号秩检验，因为组别总数受离群值主导，一个会话跨越20万长上下文定价层级可能产生25倍正常水平并翻转原始总数。
终点预先注册。 主要终点：每个任务在成本和“新输入”令牌（未缓存+创建缓存；压缩后的工具结果实际落在这里）上的配对差异。在任何付费运行之前就确定了，并与采用分层分割一起。
采用被检测，而非假设。 每个使用rtk的试验都持久化rtk的钩子审计日志和其history.db，因此我们可以证明每个试验中重写确实触发并执行——并区分“rtk没节省”和“rtk从未运行”，这是截然不同的发现。根据运行情况，钩子重写了它看到的Bash调用的三分之一到一半（33-50%，扣除我们自身的每次试验连接检查后）；模型自己在86次试验中输入了6次rtk。
来源. rtk v0.43.0发布二进制（SHA256固定），Claude Code 2.1.201在两个组别中固定，claude-sonnet-5，Harbor 0.18，SkillsBench中排除了bike-rebalance（其allow_internet=false导致本地Docker作业崩溃）。rtk、Harbor和SkillsBench均为Apache-2.0。