省 Token 冷静篇：RTK 自报省下 9620 万 token，实测成本反涨 7.6%

省 Token 冷静篇：RTK 自报省下 9620 万 token，实测成本反涨 7.6%

这个博客的「省 Token」系列已经写过两把刀：749 Headroom 压内容，755 SmartCompact 挑压缩时机。这段时间圈子里最火的还有两个：让 Agent「像洞穴人一样说话」的 caveman，和在 shell 层压命令输出的 RTK。

README 上的数字一个比一个好看：caveman 说输出 token 省 65%，RTK 说省 60%～90%。

这篇不安利，专门「验刀」。我把两份公开的成对实测（JetBrains 的 A/B 测试系列，和一个 7 方同台的 SWE-bench 跑分）放在一起读，看看这些工具在真实写代码任务里到底能省多少，以及你自己该怎么验证。

先说明：下文所有数字都来自文末列出的公开来源，我本人没有复跑这些实验。引用时都标了出处和实验条件。

一、先看结论

一句话：在写代码的 Agent 场景里，README 上的大数字基本都没兑现。有的小省一点，有的反而更贵；好消息是，质量基本都没变差。

下面一个个拆，为什么会这样。

二、RTK：工具自己的计分板，和你的账单是两回事

RTK 在做什么

RTK（Rust Token Killer）是个命令行代理。Agent 跑 git status，RTK 截下来，执行真实命令，再把压缩后的结果交给模型——十一行的 git status 变成三行，一大段 pytest 输出变成「2 passed, 1 failed」加失败原因。它靠 Claude Code 的 PreToolUse hook 自动改写命令，模型甚至不用知道它存在。

压缩本身是真的，而且挺优雅。JetBrains 的测试团队一开始也挺看好。

实验怎么做的

• 环境：Harbor 0.18（Docker 沙箱 + 自动判分）
• Agent：Claude Code 2.1.201，两组版本锁死
• 模型：claude-sonnet-5，低、高两种推理强度各跑一遍全量
• 题库：SkillsBench 87 题里的 86 题，0～1 分，允许部分得分
• A 组：原版 Claude Code；B 组：RTK v0.43.0，按 rtk init -g 默认装好
• 规模：425 次计费试验，花了约 320 美元

发现 1：大部分 token 根本不经过 RTK

这是最关键的一点，而且一分钱不花就能算出来。

JetBrains 先拿 83 份已有的会话记录回放了一遍，问一个问题：如果当时装了 RTK，它最多能碰到多少内容？

• Claude Code 读文件用内置的 Read，搜索用 Grep，都不走 Bash，RTK 的 hook 看不见（RTK 自己的文档也承认）。
• Agent 在 shell 里跑的命令，一半是 python3 … 这类 RTK 不覆盖的；还有约六分之一用了管道、heredoc，RTK 故意不改写。
• 剩下能改写的，只占 Bash 调用的 33%，装着不到 20% 的工具返回内容。
• 而工具返回本身只是账单的一小块，因为整段上下文每一轮都要重读一遍。

结论：就算把 RTK 能碰到的部分压掉 70%，上限也只有输入 token 的约 3%。这个数字直接预言了后面的结果。

发现 2：不但没省，还小幅变贵

全量 86 题、80 对有效数据的结果：

• 每任务成本中位数 +7.6%（p=0.004）
• 对话轮数 +13.8%（p=0.03）
• 缓存读取 +14.3%（p=0.008）
• RTK 唯一真正压缩的「新输入」只动了 +3.2%（p=0.23），统计上就是零

而且 hook 改写的命令越多，惩罚越大：重度命中的任务对贵了约 24%，几乎没命中的只贵约 5%。翻会话记录看，没有一个大罪魁，而是零碎的小税：一个改写坏掉的复合 find 命令导致报错重试、几次因为输出被压而重读文件、外加正常的随机波动。

换成高推理强度再跑一遍，惩罚消失了（+0.1%，p=0.99）。但无论哪种强度，RTK 都没有省下钱。

发现 3：计分板说省了 9620 万 token

低强度全量跑完，RTK 自带的统计（rtk gain）显示省了 9620 万 token，占它处理内容的 99.8%。同一批试验的真实账单却涨了。

JetBrains 拆出三个原因：

1. 反事实算错了。 RTK 把「完整原始输出」当成本来要花的 token。一次 cat 一个 1.2 MB 的 CSV，它记了 32 万 token「已节省」——但 Claude Code 本来就会把超长工具结果截断，模型最多收到几千 token。全量里这种巨型读取有 190 次，平均每次记约 50 万「节省」。
2. 按字符数÷4 估 token，而会话里大部分输入是缓存重读，价格只有正常输入的十分之一。
3. hook 本来就看不到大部分上下文。

原文的总结很狠：计分板在给自己的作业打分。

三、caveman：它压的是「旁白」，而 Agent 很少说旁白

caveman 的思路是让模型用极简句子回答：「Why use many token when few do trick」。代码、命令保持原样，只压缩说明文字。

JetBrains 的 Part 1 用同样方法测了它（Claude Code 2.1.200、claude-sonnet-5 低推理强度、SkillsBench 86 题，约 240 次试验、106 美元），并且每轮都强制开启 caveman——正常使用要靠用户说「caveman mode」触发，所以测出来的是天花板。

结果：

• 输出 token −8.5%（82 对任务，59.2 万 → 54.2 万）。第一轮 10 题小样本「显示」省了 29.5%，扩大样本后没能复现。
• 质量打平：8 题更好、10 题更差、64 题持平，符号检验 p=0.82。
• 成本省得很脆：按 token 推算应该便宜约 10%，但全量里 caveman 组总价反而高 11.6%（40.60 vs 36.39 美元）——原因是某个依赖审计任务在 caveman 组里膨胀过了 20 万 token 的长上下文计价档，一次就花了 8.29 美元（基线组同题 0.33 美元）。这是任务本身的波动，不是 caveman 的锅。

为什么和 65% 差这么多？因为 65% 是聊天问答场景的数字。Agent 写代码时，输出大头是代码、diff、工具调用和原样的报错信息，caveman 本来就不碰这些，能压的只有工具调用之间那几句「我先看看这个文件」。

JetBrains 的建议很中肯：喜欢就用，它不伤质量；但别指望在日常 Agent 任务里省大钱，高个位数百分比是现实上限。

四、同台跑分怎么读：看「每道成功题花多少钱」，也看是谁跑的

第二份材料是 GitHub 上的 Code-Compression Bench，思路比单个工具的 README 靠谱得多：

• 同一个 Agent（无头模式 Claude Code）、同一个模型（claude-sonnet-4-6）
• 同样 100 道 SWE-bench Verified 题，用官方 Docker 判分
• 统一按含缓存折扣的价格算钱
• 只换压缩层，按「每道成功题的成本」排名

排行榜（2026-07-04 那一批，Fermat 是 09-21 补跑）：

读这张表有三个要点。

1. 先看是谁跑的。 README 底部写明：这个基准「Sponsored and operated by Dasein」，而 Dasein 就是排第一的 Parsec 的开发方。代码和逐题数据都公开、号称谁都能复跑，这值得肯定；但它终究是厂商自己办的擂台，第一名的成绩要打个问号，等第三方复现。

2. 解题数的差距可能是噪声。 Parsec 解了 12 道基线没解出的题，基线也解了 7 道 Parsec 没解出的，净差 5 题。JetBrains 在两篇实验里都反复提醒：同一道题、同一组设置，重跑一次分数就可能翻转，相同设置的两次尝试成本中位数就能差 22%。在 100 题的规模下，几道题的差距不足以说明谁更聪明。

3. 同一个工具，两份实验数字不一样。 caveman 在 JetBrains 那里输出只省 8.5%，在这张表里输出省 30%、总成本省 19%。模型不同（Sonnet 5 vs Sonnet 4.6）、题库不同（SkillsBench vs SWE-bench）、开启方式不同，结果就会变。脱离实验条件说「这个工具省 X%」，没有意义。

不过，有两点是两份材料一致的：

• RTK 在写代码的 Agent 场景里没省钱，两边都是持平或更贵。
• 缓存才是大头。 Dasein 的 README 解释了为什么「token 变少了，账单反而涨」：模型每一轮都在重读一段很长、大部分已缓存的前缀，缓存部分按很低的价格计费；如果一个压缩层每轮都改写这段前缀，就会一次次重新付缓存写入的高价，还可能多出轮次。省钱的关键是删对的 token，同时别搅乱缓存、别加轮次。

对本系列前两篇的校准

既然是冷静篇，自己的文章也要校准：

• 749 Headroom：在这张同台表里，Headroom 是总成本最高的一档（+44%）。按 Dasein 的整理，Headroom 宣传的数字主要来自 GSM8K、SQuAD 这类单轮问答，它的文档也写明代码是原样放行不压缩的。所以：如果你的场景是长文档、检索结果多的 RAG/问答，它可能仍然有用；拿来压写代码的 Agent，目前没有证据显示能省钱。
• 755 SmartCompact：它不在以上两份测试里。文中引用的「长会话成本降约 7%～44%」是作者自测，目前还没有看到独立的成对实测。它的思路（在提交、测试转绿这些停顿点才压缩）和「别频繁打断缓存」是一致的，但省多少，请按下一节的方法自己量。

五、自己验刀：照着 JetBrains 的方法做一次成对 A/B

不管是这几个工具，还是下一个刷屏的「省 90%」，都可以用同一套方法验证。下面是从 JetBrains 两篇实验的方法论里整理出来的步骤，个人开发者用自己的任务也能做。

第 1 步：先算天花板，不花钱

拿你过去的会话记录回放，算一算：这个工具到底能碰到多少内容？

• 只改写 Bash 命令的工具，碰不到 Read/Grep 读进来的内容；
• 只压缩说明文字的工具，碰不到代码和工具调用；
• 别忘了大部分输入是缓存重读，价格只有正常输入的十分之一左右。

Claude Code 的会话记录一般存在 ~/.claude/projects/ 下的 JSONL 文件里，每轮都带用量字段，统计一下各类工具返回的体积占比就行。如果天花板只有几个百分点，后面就不用花钱测了。

第 2 步：固定一切，只换一层

模型、Claude Code 版本、推理强度、任务集、工具版本全部锁死。两组唯一的区别就是装没装这个工具。

第 3 步：成对比较，看中位数，别看总价

每道题算「B 组成本 − A 组成本」，再取中位数。不要直接比两组总价——一个任务膨胀过 20 万 token 的长上下文计价档，就能把总价翻过来，caveman 那次就是这么「变贵」的。

第 4 步：别信只跑一次的结果

JetBrains 的跑法是一级级加码：免费回放 → 1 次连通性检查 → 10 道题各跑 1 次 → 同 10 道题各跑 3 次 → 全量。caveman 的 −29.5%、RTK 的 +35%，都是在小样本阶段出现、扩大样本后消失的假象。

第 5 步：按 token 类型拆开看

把新输入（未缓存 + 缓存写入）、缓存读取、输出分开统计。工具宣称压缩哪一类，就重点看哪一类有没有真的下降，再看其他类有没有被连带推高（比如 RTK 的轮次和缓存读取都涨了）。

第 6 步：最终只看两个数

质量（测试通过率 / 判分）和每道成功题的成本。省了 token 但多失败几道题，就不算省。

第 7 步：用账单计量，别用工具自报

用模型供应商的用量数据，或者自己的网关日志来计量。如果你想给每个 Agent 分别记账，可以参考本系列的 759 自建 LLM 聚合网关：给 A、B 两组各发一把虚拟 Key，用量自然就分开了。

一个小脚本：成对比较 + 显著性检验

假设你把每次试验记成 trials.csv，字段是 task,arm,cost,score（arm 取 A 或 B，每道题每组一行；跑了多次就先取平均）：

## pip install pandas scipy
import pandas as pd
from scipy.stats import wilcoxon, binomtest

df = pd.read_csv("trials.csv")
wide = df.pivot_table(index="task", columns="arm", values=["cost", "score"], aggfunc="mean").dropna()

cost_a, cost_b = wide["cost"]["A"], wide["cost"]["B"]
delta_pct = (cost_b - cost_a) / cost_a * 100
print(f"成对任务数: {len(wide)}")
print(f"每任务成本变化中位数: {delta_pct.median():+.1f}%")
print(f"Wilcoxon 符号秩检验 p = {wilcoxon(cost_b, cost_a).pvalue:.3f}")

score_diff = wide["score"]["B"] - wide["score"]["A"]
better, worse = int((score_diff > 0).sum()), int((score_diff < 0).sum())
ties = len(score_diff) - better - worse
p_quality = binomtest(better, better + worse).pvalue if better + worse else 1.0
print(f"质量: 更好 {better} / 更差 {worse} / 持平 {ties}，符号检验 p = {p_quality:.2f}")

这就是 JetBrains 用的两种检验：成本用 Wilcoxon 符号秩检验，质量用只看非平局的符号检验。p 值大于 0.05，就说明两组差异和随机波动分不开。

六、那还装不装？

• caveman：喜欢就装。它不伤质量，Agent 少说废话看着也舒服；但在写代码任务里，期望值是高个位数百分比，别按 README 改预算。
• RTK：压缩后的输出对人看日志很友好；但按两份测试，它不能帮 Claude Code 省钱，低推理强度下还可能小幅变贵。
• Headroom / SmartCompact 这类：先按你的场景判断它能碰到多少内容，再做一次小规模成对测试。
• 任何新出的「省 90%」：先问三个问题——它压的那部分在我的账单里占多少？它会不会打断缓存或者加轮次？它的数字是在什么模型、什么任务上测的？

省 Token 这件事，最有效的往往不是再装一把刀，而是先装一块表：知道钱花在哪，才知道哪把刀值得留下。

参考来源

• JetBrains AI Blog，Denis Shiryaev：Does “rtk” skill really cut agent tokens by 60–90%? We tested it
• JetBrains AI Blog，Denis Shiryaev：Does Speaking to Agents Like Cavemen Really Save 65% of Tokens? We Test
• Dasein：Code-Compression Bench（GitHub），同台数据另见 Parsec 对比页（厂商页面，注意立场）
• 本系列：749 Headroom · 755 SmartCompact · 759 自建 LLM 网关