RTK Skill 真能省 60-90% token？官方实测拆解

'rtk' 能否真的减少 Claude Code 的 token 用量？

这是一个系列的第 2 部分，我们对外界宣称的代理"省 token"插件进行成对的 A/B 基准测试。第 1 部分是 caveman skill（宣称可减少 65%，实测减少 8.5%）。

rtk（"Rust Token Killer"）是一个 CLI 代理，它的承诺很简单、也很吸引人：你的 agent 运行 git status，rtk 拦截这个命令，执行真正的操作，并把压缩后的输出交给模型 —— 用 * master / M a.txt / ?? b.txt 代替原来的十一行详细输出。Claude Code 的 PreToolUse hook 可以透明地重写符合条件的 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 …

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

我们觉得这个想法值得好好测试。README 没有回答的两个问题：

首先，在真实的 agent 会话中，有多少比例的内容是 Bash 输出？这份省 token 的表格假设 agent 在所有事情上都要调用 shell。但是 Claude Code 用它内置的 Read 工具读取文件，用 Grep 搜索，这两个操作都绕过了 Bash hook（rtk 的文档承认这一点）。不管这些工具会产生多少内容，rtk 都永远接触不到。

其次，压缩是否会损害正确性？一个总结测试输出的过滤器是在对模型需要什么做编辑判断。如果它丢掉了至关重要的一行，agent 就会重新运行命令、原始读取文件，或者更糟的是，在构建失败的情况下还声称成功。伴随质量代价的 token 省 token 不是真正的省 token。

因为 hook 机制会对所有符合条件的 Bash 调用进行机械地重写，B 臂衡量的是 rtk 当前版本的理论上限：没有"模型是否记得使用它"的争议空间。每个运行 rtk 的试验也都会持久化 rtk 自己的审计日志和分析数据库，作为该处理确实触发的证明。

发现 1：大多数 agent 字节永远不会接触到 hook

在花任何成本之前，我们重放了 83 个现有的基线会话记录（相同模型、相同基准），并问：如果 rtk 已经被安装，它最多只能接触什么？

有两个结构性的原因。首先，Claude Code 用它内置的 Read/Grep 工具读取文件，这完全绕过了 Bash hook；rtk 自己的 README 在脚注中承认了这一点。其次，agent 在 shell 中运行的东西有一半是 python3 ... 和其他未覆盖的命令，还有六分之一使用管道输出到文件、heredoc 和变量替换，rtk 故意拒绝重写这些。剩下的 33% 的 Bash 调用只携带了不到 20% 的工具结果字符；而工具结果本身只是会话账单中输入部分的一个切片，因为相同的上下文会在每个 turn 中被重新读取。即使把 rtk 整个份额压缩 70%，上限也只算出大约 ≈3% 的输入 tokens。这个数字计算成本为零，它预测了结果。

发现 2：没有省 token；但有一个小的、显著的成本增加

我们按照 caveman 评估教我们的方式运行了完整的测试阶梯。在 10 个故意以 Bash 为主的任务上的 k=1 smoke 测试（rtk 的最佳情况）显示，rtk 臂的成本中位数增加了 35%。这很令人担忧，直到你知道同一臂中相同任务的相同尝试在成本上的差异中位数是 22%。在 k=3 时，大部分惊吓消散在噪声中（Wilcoxon p≈0.65），完全符合 k=1 幻觉的预期。

然后完整的 86 个任务给出了抗噪声的答案，这不是零。在 80 对干净的对比中，带 rtk 的臂每个任务的成本中位数高出 7.6%（p=0.004，在我们发现的成本记账间隙修正后），在 13.8% 更多的 turn 上（p=0.03）以及 14.3% 更多的缓存读取上（p=0.008）。同时"新输入"——唯一被 rtk 真正压缩的 token 类别，只增加了 3.2%（p=0.23）：正好是完全平的 null，恰好在天花板分析说整个收益必须来自的地方。

hook 重写的命令越多，惩罚就越大。在与标题结果相同的修正成本基础上，高度暴露的任务对的成本比基线高约 24%，而 hook 几乎没有接触的对只高 5%。控制任务难度不能重现这个模式，所以更难的任务使用更多的 Bash 似乎不能解释这一点。转录法医分析没有找到单个罪魁祸首：一个真正破损的重写（复合的 find 谓词变成了用法错误和重试）、一些压缩诱导的重新读取，以及极端对上的大量普通方差。一个薄的、系统的代价而不是戏剧性的失败。

发现 3：在高推理工作量下，甚至惩罚也消失了

"你只在低推理工作量下进行了测试"是显而易见的批评，所以我们在高工作量下再次运行了所有 86 个任务 —— 整个系列中最昂贵的单次运行。结果：成本惩罚在那里没有再现。中位数配对差异 +0.1%（p=0.99），turn +0.0（p=0.74），质量仍然持平。在高工作量下，模型似乎浪费更少的 turn 来对压缩输出做出反应；尽管在 k=1 时我们只能说惩罚没有在那里出现，不能说两个工作量制度可能不同。无论如何，在任何时刻，rtk 都没有省钱。

发现 4：质量得以保持

来自 rtk 问题追踪器的可怕失败模式，包括过度过滤的测试输出、掩蔽的退出代码、接收压缩文本的管道，它们几乎没有物化。对最大 turn 差异的六个 smoke 对的法医审计发现恰好一个破损的重写（同一个复合 find 失败模式完整运行击中的）和一个 agent 故意绕过 hook 的情况，跨越 ~150 个 Bash 调用。在那些转录中没有恢复文件被读取，也没有压缩的管道产生错误的计数（完整运行中恰好看到一个恢复文件读取）；额外的 turn 绝大多数是模型选择不同的解决路径，而不是 rtk 困惑。在完整运行中，任务得分在低工作量下着陆于 5 更好 / 4 更差 / 71 平局，高工作量下 5 / 4 / 62（符号测试 p=1.0 两者）；显示两臂在质量上在统计上无法区分，计入部分学分。

一个诚实的警告：在一个任务（dialogue-parser）上，rtk 自己的二进制文件拒绝在任务的镜像内启动（它需要一个更新的 glibc），所以 with-rtk 试验在两次完整运行中都在设置时死亡，而纯臂得分 0.667。配对分析从两臂中都排除了该任务，但这是一个真实的兼容性失败，不是 Docker 噪声。即使将每个错误的试验得分为零，两臂也保持平局（符号测试 p=1.0）。

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

这是解释差距的发现。在低工作量的完整运行中，rtk 的内置分析（rtk gain）报告节省了 96.2 百万 tokens —— 它接触到的一切的 99.8%；而对同一试验的测得账单上升了。三个机制使计分板读起来很高：

首先，rtk 把完整的原始输出作为它的反事实基准。一个 1.2 MB CSV 的 cat 日志记录了 320k tokens"节省"，但 Claude Code 早在 320k tokens 之前就会截断任何工具结果；所以 agent 无论如何都只会接收几千。完整运行记录了 190 个这样的巨大读取，平均每个 ~506k"节省"的 tokens。其次，rtk 在执行时将 tokens 估计为 chars÷4，而会话中的大部分输入成本是缓存重新读取，以十分之一的价格计费。第三，hook 根本永远看不到大多数上下文。计分板在为自己的作业打分。

诚实的工程、错误的反事实。我们希望这个能赢；演示确实很令人满意。过滤器是真实的，经常很优雅；质量不受影响；hook 机制完全按设计运作。但在真实的 agentic 编码工作中，宣传的 60–90% 从来没有任何地方可以存在：hook 只会看到约五分之一的工具输出，Claude Code 已经在 rtk 吹嘘压缩的病态输出之前就会截断，而占主导地位的缓存重新读取以十分之一的价格计费。剩下的是低工作量下的测得中位数 +7.6% 成本增加，以及高工作量下的完全零，来自一个破损重写这里和额外的探索 turn 那里的薄税，永远不是省 token。

更深层的教训推广超越 rtk：工具的自报省 token 是对其反事实的声明，不是对你账单的声明。rtk 的计分板说省了 96 百万 tokens，而账单上升了。如果你评估任何上下文压缩工具，衡量配对账单，而不是工具的差异。

与第 1 部分相同的规范，代价高昂地学到的：

永远不要信任 k=1。运行阶梯是：免费转录重放 → 1 试验接线检查 → 10 个 Bash 密集任务在 k=1 → 同样的 10 个在 k=3 → 完整的 86 个在 k=1，两次（低和高工作量）。按任务的得分在两臂中都自由翻转；只有幸存阶梯的配对差异被报告。

仅配对分析。每个数字在相同的工作下跨臂比较相同的任务；在任何臂中出错的任务从两臂中都被排除。质量对非平局使用精确符号测试；token/成本差异使用按任务中位数加 Wilcoxon 有符号秩，因为臂总计由离群值主导，单个跨越 200k 长上下文定价层的会话可能会开账单 25 倍正常，并翻转原始总计。

端点预注册。主要：按任务配对成本差异和"新输入"tokens 的差异（未缓存 + 缓存创建；压缩的工具结果实际上落地的地方）。在任何付费运行之前决定，连同采用分层的分割。

采用被测试，而不是被假设。每个 with-rtk 试验持久化 rtk 的 hook 审计日志和其 history.db，所以我们可以证明每个试验的重写触发和执行 —— 并区分"rtk 省了什么都没有"和"rtk 从未运行"，这是非常不同的发现。取决于运行，hook 重写了它看到的 Bash 调用的三分之一到二分之一（33–50%，在折扣我们自己的按试验接线检查后）；模型本身在 86 个试验中输入了 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。

系列中的下一部分：说出一个工具名称，我们就会把它放在阶梯上。只需一点点词。我们测试。

P.S. 这篇文章中的抖动图表风格是从 grim 的 dither-kit 借用的，经过钦佩；从头重新实现为无依赖的内联小部件。

谢谢，我们支持你！

这是一个系列的第 3 部分，我们对外界宣称的"省 token"加-ons for coding agents 进行同样的配对 A/B 基准测试。第 1 部分是 caveman skill（宣称 −65%，实测 −8.5%）。第 2 部分是 rtk（宣称 −60–90%，实测 +7.6%）。我们运行了 80 个配对任务来测试小马...

今天，我们推出了 JetBrains Context，一个新的仓库智能层，帮助编码 agent 在复杂代码库上更高效地工作并产生更高质量的结果。作为 JetBrains AI for Teams and Organizations 推出的一部分，JetBrains Context 现在在早期访问中可用...

一个在 Claude Code 上运行 SkillsBench 的 token 压缩 skill Caveman 的配对 A/B 基准：它真的省 token 吗，它会降低 AI agent 输出质量吗？宣传的节省：65%。测得的节省：8.5%。真实 agentic 任务的输出 token 节省，强制激活技能...

由 JetBrains 和 GitHub 的深入伙伴关系孕育，这个集成使 Copilot 在 agent 选择器中原生，并在你已经每天使用的 IDE 中直接提供更稳定的 agent 体验。从 ACP Registry 到原生体验 Copilot 之前通过...