RTK hook 让编码代理更贵，而非更便宜

JetBrains AI 团队近日发布了一项针对“Rust Token Killer”（简称 rtk）的基准测试结果，引发了业界对 AI 代理 token 压缩工具实际效能的广泛讨论。rtk 是一个 CLI 代理，通过拦截 git status 等命令，将冗长的输出压缩为简短格式，其 README 声称可在 30 分钟的会话中将 118k token 的命令输出压缩至 24k，节省幅度高达 60-90%。然而，JetBrains 的严谨测试表明，这一数字在实际应用中不仅无法实现，甚至可能产生相反效果。

测试团队使用 Claude Code 2.1.201 和 claude-sonnet-5 模型，在 SkillsBench 基准的 86 个任务上进行了配对 A/B 测试。实验中，arm A 使用标准的 Claude Code，arm B 则集成了 rtk v0.43.0 及其 PreToolUse hook。为了确保结果可靠，团队设计了多阶段测试：先进行 10 个 Bash 密集型任务的 k=1 烟雾测试，接着对相同任务进行 k=3 测试，最后完成全部 86 个任务在低推理成本和高推理成本下的两次完整运行，共计 425 次计费试验。

关键发现之一是：rtk 的实际影响范围极为有限。通过重放 83 个已有基线转录，团队发现 Claude Code 主要使用内置的 Read 和 Grep 工具读取文件和搜索代码，这些工具完全绕过 Bash hook。此外，代理在 shell 中运行的一半命令是 python3 等其他未覆盖命令，另有六分之一的命令使用管道、heredoc 和替换，rtk 故意不重写这些命令。最终，只有约 33% 的 Bash 调用被 hook 拦截，而这些调用携带的字符量不到工具结果总字符的 20%。考虑到工具结果本身只占会话输入 token 的一部分（因为同一上下文会在每一轮被缓存重读），rtk 能影响的最大输入 token 份额仅为约 3%。

在成本方面，低推理成本下，rtk 臂的中位数成本比基线高出 7.6%（p=0.004），回合数增加 13.8%，缓存读取增加 14.3%。而 rtk 唯一声称压缩的“新输入” token 类别仅增加了 3.2%（p=0.23），并无统计差异。有趣的是，当推理成本提高时，成本差异完全消失（中位数差 +0.1%，p=0.99），回合数和质量也无显著差异。这意味着在高推理成本下，模型可能因输出压缩而减少不必要的探索回合，但即便如此，rtk 也从未展现出任何成本节约。

质量方面，团队仔细检查了回合数差异最大的六个烟雾测试配对，在约 150 次 Bash 调用中只发现了一个真正的重写错误（复合 find 谓词被转化为用法错误并触发重试），以及一次代理故意绕过 hook 的情况。在完整运行中，任务得分在低推理成本下为 5 次更好、4 次更差、71 次持平，高推理成本下为 5 次更好、4 次更差、62 次持平（符号检验 p=1.0），表明两组在统计上不可区分。

最引人深思的是第五个发现：rtk 自带的评分板与实际账单之间的巨大差距。在低推理成本的完整运行中，rtk 的内部分析报告节省了 9620 万 token——声称避免了 99.8% 的 token 消耗，但同一试验的实际计费却上升了。这一矛盾源于三个机制：首先，rtk 将完整的原始输出作为反事实进行计数，但 Claude Code 会在工具结果远未达到 320k token 时便进行截断，因此代理无论如何只会收到几千 token；完整运行中记录了 190 次这样的大型读取，每次平均“节省”约 506k token。其次，rtk 在执行时以字符数除以 4 来估算 token，但会话输入成本的主要部分来自按十分之一价格计费的缓存重读。第三，hook 从未看到大部分上下文。正如团队总结的那样：“评分板在给自己打分。”

JetBrains 团队强调，rtk 是一个诚实的工程作品，过滤器本身优雅有效，质量未受影响，hook 机制也如预期般运行。但问题在于其使用了错误的反事实：工具宣称的节省并非相对于实际账单，而是相对于一个不存在的理想状态。这一发现具有更广泛的启示：在评估任何上下文压缩工具时，应测量配对账单而非工具自身的差异。rtk 的案例清楚地表明，看似诱人的 token 节省可能隐藏着意想不到的成本。