RTK（Rust Token Killer）在AI代理读取前过滤并压缩终端输出，如今拥有超过79k GitHub星标，是最流行的降低AI编程成本工具之一。一个X帖子称其能削减Claude Code（Claude Code）令牌最多60%，获得313K浏览。然而JetBrains（JetBrains）的SkillsBench测试发现并无节省，其README免责声明称可削减代理读取的bash输出最多90%。

RTK（Rust Token Killer）会在 AI agent 读取之前过滤并压缩终端输出。它如今在 GitHub 上有超过 7.9 万 star，是最流行的 AI 编程降本工具之一。一条 X 帖子称 RTK 最多能把 Claude Code 的 token 削减 60%，浏览量达 31.3 万。

但 JetBrains 的 SkillsBench 测试没有发现任何节省。README 里也有一条免责声明：

RTK 最多能砍掉你的 agent 读取的 90% bash 输出。……这不等同于把你的账单砍掉 90%。

所以“更少的终端输出”不等于“更便宜的 AI 编程”。它可能有用，可能是无用功，也可能帮倒忙（更多轮次或更差质量）。我们花了好几天、烧掉超过 1500 美元的 token，得到下面这些结果。

RTK 怎么工作

RTK 能改写 agent 通过 shell 工具（Claude Code 里的 Bash、OpenCode 里的 bash）执行的 Git、测试、包管理和文件命令，每次改写都返回同一输出的更精简版本。

例如，RTK 保留文件名、大小和权限（644 就是 rw-r—r—），但丢掉所有者和日期：

$ ls -la /app/warriors -rw-r--r-- 1 root root 824 Sep 13 2025 g2-clear.red -rw-r--r-- 1 root root 487 Sep 13 2025 paper.red

$ rtk ls -la warriors/ 644 g2-clear.red 824B 644 paper.red 487B

在 Terminal-Bench 2.1 上测试 RTK

RTK 压缩的是终端输出，所以我们选了终端交互密集的 Terminal-Bench 2.1 来测。之所以停在 2.1 而不用更新的 3.0 和 4.0：agent 能通过 2.1 的大部分任务，而 3.0 和 4.0 仍是难题，成本只有在通过的任务上才有意义。

我们用 Claude Code 配 Fable 5.0，用 OpenCode 配经 OpenRouter 调用的 DeepSeek V4 Pro 0813。每个任务在同一模型路线、平台和任务超时下，无 RTK 跑 5 次、有 RTK 跑 5 次。

剔除 4 个出现拒绝回答的 Fable 安全任务后，最终比较覆盖 85 个 Fable 任务和 89 个 DeepSeek 任务，共 1740 次尝试。

第一张图看起来有戏

用 RTK 后，Fable 成本降了 5%，DeepSeek 反而涨了 5%。

Claude Code · Fable 5.0：基线 731 美元（通过率 84%），RTK 698 美元（通过率 83%）。 OpenCode · DeepSeek V4 Pro 0813：基线 51 美元（通过率 71%），RTK 54 美元（通过率 69%）。

通过率都略降：Fable 降 1%，DeepSeek 降 2%，差距都很小。

把所有支出（含失败尝试）除以通过数，Fable 用 RTK 便宜 3%，DeepSeek 贵 7%。

换一种算法，给每个任务同等权重，避免一个贵任务压过许多便宜任务：比较每个任务基线与 RTK 尝试的均值，再把这些变化平均。按这个任务级指标，Fable 贵了 1%，与零没有明显差异；DeepSeek 的任务成本平均上升 17%。把失败算进去也不改变趋势：在 10 次尝试全部通过的 36 个 DeepSeek 任务里，涨幅仍有 18%。

一个任务决定了整个基准的结果

Fable 用 RTK 省下的钱几乎全来自一个任务：winning-avg-corewars。两种设置每次尝试都通过，但带 RTK 时轮数大约减半。其余任务的节省不到 1%。

DeepSeek 在同一个任务上结果相反：两边每次都通过，但 RTK 用了更多轮、花得更多。即便去掉这个任务，RTK 的成本依然更高。

rtk gain 不能当成本指标

RTK 官方把 rtk gain 定义为“原始命令输出字节数减去过滤后字节数，再除以 4”，不是计费 token 数。

在 445 次 DeepSeek 的 RTK 尝试中，RTK 报告节省了 3.492 亿 token，降幅 89%。

但报告里的大幅 token 节省并不意味着任务更便宜。

在 train-fasttext 中，模型两次请求 head -1 train.txt。RTK 把这种受限读取与整个文件相比，每次记下 1.205 亿 token 的节省。这两次调用占了该比较节省计数器的 69%，可实际请求的命令根本不会返回整个文件。

把 rtk gain 当作省下的钱，前提是这次尝试的其余部分保持不变。而 RTK 会改变 agent 接下来的轮次，rtk gain 并不计算这些轮次的成本。

社交帖子错就错在这里：rtk gain 数的是被删掉的输出，不是省下的钱，它能让一次更贵的尝试看起来像被优化过。

RTK 的 bug 也会咬人

DeepSeek 的一次 git-multibranch 尝试陷入了循环。agent 运行的 find 带了一个 rtk find 0.45.0 不支持的标志，插件把它改写成 rtk find，后者报错“请直接使用 find”。每次重试都被再次改写。RTK 在我们的测试之后于 0.46.0 修复了这个问题。

agent 累计了 339 次连续错误，直到超时，耗时约 12 分钟。任务最终仍然通过，但成本约为同样通过任务的基线尝试的 9 倍。这是一个离群样本，去掉它趋势依旧。

没有 RTK 时，工具输出约占 Fable 输入 token 的 11%、DeepSeek 的 40%。

在用 RTK 的尝试中，31% 的 Claude Code 终端调用和 51% 的 OpenCode 终端调用走了 RTK。

RTK 只改写 shell 命令：它的 Claude Code hook 匹配 Bash 工具，OpenCode 插件只作用于 bash 调用。两个平台都把文件读取和搜索暴露为独立的 Read、Grep、Glob 工具，这些都会绕过 RTK。Claude Code 约一半的 Bash 调用本来就自己用 head、tail 或 wc 限制了输出。

在 agentic 编程中，上下文在每一轮之后被缓存，所以后续读取终端输出大多表现为缓存读取。Fable 的缓存读取成本是普通输入 token 的 1/10，DeepSeek 是 1/30。

在 DeepSeek 上，RTK 把终端输出字符减少了 9%，prompt token 却上升了 9%。未缓存输入降了 1%，缓存输入升了 9%。模型输出（含推理）在有 RTK 时占成本 56%，没有时占 57%。

agent 轮数变多时，任务成本通常随之上升。

DeepSeek 的 RTK 尝试在 58 个任务上轮数更多，其中 44 个更贵；在 28 个任务上轮数更少，其中 23 个更便宜。

DeepSeek 平均每一轮的输入少了 7%，但总轮数多了 18%。更小的轮次并没有加总成更少的总输入。

多一轮 agent 的成本可能超过压缩省下的钱。这是同一类 tokenflation 问题的另一种形式。JetBrains 在 SkillsBench 上看到同样的模式：RTK 在低 effort 下增加了轮数，在高 effort 下也没有降低成本。

RTK 并不会让 AI 编程更便宜

在 Terminal-Bench 2.1 上，Fable 的节省依赖一个任务，无法跨任务成立。我们不推荐把 RTK 当作通用的省钱工具。

单条轨迹显示，当前的前沿模型已经在高效使用终端（Fable 的上下文中只有约 7% 是终端输出），模型自己就会用 head -n、tail -n 之类的技巧。RTK 对更老的模型可能帮助更大，如今它只是一种小众优化，不是普遍节省的来源。

测试环境为 RTK 0.45.0、Claude Code 2.1.220、OpenCode 1.18.25 和 Harbor 0.20。轨迹可应索取用于后续研究。

社区普遍质疑 RTK 等命令行 token 压缩工具及各类“魔法技能包”是无效甚至有害的蛇油，少数人分享了基于语义索引、子模型总结等真正有效的工程化降本方案。

认为 RTK 等 token 节省工具是无效且有害的蛇油

• 多数评论指出这类工具（RTK、Caveman、Headroom 及各种技能包）缺乏独立基准，实测节省微乎其微甚至反向增加开销（如 Claude 仅省 5% 且靠单一任务，DeepSeek 更贵）。它们篡改模型训练时熟悉的 shell 输出格式，导致模型误判工具损坏而发出更多调用，或得出错误结果拖垮整体表现（较多人） > 这些所谓的技巧全是蛇油，我想我们内心深处都知道。（@aeneas_ory）
• 另有评论补充 RTK 收益统计具欺骗性，例如配合 tail 使用时虚报巨量节省，且可能破坏沙箱隔离并引发随机拦截；直接移除 ls 等命令的预期字段会让模型困惑失败（较多人）

认为简单提示和模型自身能力已足够，无需额外包装

• 大语言模型本身懂得利用 grep、tail 等 shell 原语精简输出，随着模型进化会更擅长防御性适配；直接在 agent 规则里限制输出长度（如 head -c 4000）或开启构建工具静默模式，比引入 RTK 更高效且不易混淆（较多人） > 模型本身就知道如何通过 shell 原语来巧妙节省 token，随着模型变聪明会更擅长预期大输出并防御性调整。（@semiquaver）

认为真正有效的 token 优化需要扎实工程而非噱头

• 部分开发者通过本地代码嵌入模型做语义检索、使用语言专用 MCP（如 Roslyn）、或派发廉价子模型总结输出，在基准中取得可信降本；共识是减少 token 可行但远难于基础脚本，必须有可靠基准背书（少数人） > 有可能减少 token 使用，但这比那些基础方法要难得多。（@psadri）

有价值的补充

• RTK 的收益机制被过度简化，在标准编码 agent 上下文里 1 token 并不等于 4 字节，其节省计算本身有误导性（@santiago-pl）
• RTK 并非毫无用处，用于压缩重复测试运行输出时有一定价值，但只应作用于白名单命令，而非按官方建议全量包装所有命令（@oefrha）
• 不要试图“克扣”智能体，正如经理不该克扣员工，过度限制输出反而让编排器耗时更长（@fwlr）