原创 Guide Guide JavaGuide 2026-03-25 17:32
你有没有算过一笔账：用 Claude Code 或 Cursor 一整天，到底消耗了多少 token？
我之前没算过，直到有一天收到账单才发现不对劲。明明只做了几个简单功能，token 消耗却高得离谱。后来排查才发现，真正的“凶手”不是我的代码，而是那些命令输出。
npm install跑一次，依赖树打印几百行；cargo test执行完，99% 的通过信息全是绿的；git status列出一堆 untracked 文件……这些内容全被塞进 LLM 的上下文窗口，而 AI 真正需要的信息可能只有 5% 左右。
RTK（Rust Token Killer）就是来解决这个问题的。它是个 CLI 代理，在命令输出到达 LLM 之前先做压缩过滤——把“噪音”去掉，只留“信号”。
RTK 是什么？
RTK是一个用 Rust 编写的命令行代理工具，专门为 AI 编程助手设计。它的工作位置很巧妙：不是替代你的命令，而是“拦截”命令的输出，在送给 LLM 之前做一轮智能压缩。
官方实测数据：30 分钟的 Claude Code 会话，token 从118,000 压到 23,900，省了 80%。
它的技术特点：
| 特性 | 数据 |
|---|---|
| 启动延迟 | <10ms |
| 内存占用 | <5MB |
| 依赖 | 零依赖，单一二进制文件 |
| 语言 | Rust（这也是它名字的来源） |
因为是用 Rust 写的，启动和执行都非常快，几乎感觉不到它的存在。你照常用 Claude Code，照常执行命令，只是 token 消耗悄悄降下来了。
为什么能省这么多？
RTK 的核心是四种压缩策略，针对不同类型的命令输出做针对性处理。
1. 智能过滤
这是最基础的一层。它会把输出里的“无效信息”识别出来并删掉：
- 注释和空白行：代码里的注释、多余的空行
- 进度条和动画：npm install时的旋转光标、百分比进度
- 颜色控制字符：终端输出的 ANSI 颜色码（LLM 根本不需要这些）
举个例子，git push的原始输出可能有 15 行约 200 token，里面包含远程仓库信息、对象计数、压缩进度等。经过 RTK 过滤后，可能只剩一行ok main，约 10 token。
2. 分组聚合
当输出包含大量同类信息时，RTK 会把它们聚合成更紧凑的形式。
比如ls列出 100 个文件，原始输出是 100 行。RTK 会按目录或类型分组，输出变成“src/ 目录下 45 个 .java 文件”、“test/ 目录下 20 个 .java 文件”这样的摘要。
实测数据：ls / tree类命令，2000 → 400 token，省 80%。
3. 截断保留
对于长输出，RTK 会智能截断，但保留关键部分。
比如测试失败时，它不会把所有通过的测试用例都列出来，而是：
- 保留失败的测试详情
- 保留错误堆栈
- 通过的测试只显示摘要：”95 tests passed”
实测数据：cargo test / npm test类命令，25000 → 2500 token，省 90%。
4. 去重合并
很多命令会有重复的输出模式，比如构建日志里反复出现的 “Compiling…”、容器日志里的时间戳前缀。RTK 会识别这些重复模式，合并成一行。
支持哪些命令？
RTK 目前支持 30+ 命令，覆盖大部分日常开发场景：
| 类别 | 支持的命令 |
|---|---|
| 文件类 | ls、read、find、grep、cat、tree |
| Git 类 | status、log、diff、push、pull |
| 测试类 | cargo test、npm test、pytest、go test |
| 构建类 | cargo build、tsc、eslint、ruff |
| 容器类 | docker ps、docker logs、kubectl pods |
基本上，你用 AI 编程助手时频繁执行的命令，RTK 都能处理。
怎么用？
安装非常简单，两种方式任选。
方式一：Homebrew（推荐）
brew install rtk
方式二：curl 脚本
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh
安装完成后验证：
rtk --version
配合 Claude Code/Codex/OpenCode 使用
只需要执行一次初始化：
# Claude Codertk init -g# Codexrtk init -g --codex# OpenCodertk init -g --opencode
-g表示全局配置，之后你在任何目录启动 Claude Code/Codex/OpenCode，RTK 都会自动接管命令输出。
重启 Claude Code/Codex/OpenCode，就生效了。之后你执行的命令会自动被 RTK 压缩过滤，完全无感。
Cursor、Windsurf 等 AI 编程 IDE 也是适用的，甚至 OpenClaw 都能用。
# Cursorrtk init -g --agent cursor# Windsurfrtk init --agent windsurf# OpenClawopenclaw plugins install ./openclaw
如果要卸载的话，也是一行命令即可：
rtk init -g --uninstall
省了多少？
各类命令的压缩效果
| 命令类型 | 原始 Token | 压缩后 | 节省比例 |
|---|---|---|---|
| ls / tree | 2000 | 400 | 80% |
| cat / read | 40000 | 12000 | 70% |
| git status | 3000 | 600 | 80% |
| cargo test / npm test | 25000 | 2500 | 90% |
查看节省统计
RTK 提供了一个命令查看 token 节省情况：
rtk gain
加上–graph参数还能看 30 天趋势图：
rtk gain --graph
加上–daily/–weekly/–monthly 还能按天/周/月查看。
有用户反馈在 Claude Code 上节省了10M token（89%）。按当前 Claude 的定价算，这是一笔不小的费用。
与其他方案对比
RTK 不是唯一能省 token 的方案，但它解决的问题很聚焦。来看看几个常见方案的对比：
| 方案 | 原理 | 效果 | 适用场景 |
|---|---|---|---|
| RTK | 压缩命令输出 | 最高 90% | 频繁执行终端命令的场景 |
| tokf | 类似的 CLI 过滤器 | ~90% | 与 RTK 类似，功能稍少 |
| .claudeignore | 排除特定文件/目录 | 视项目而定 | 减少不必要文件进入上下文 |
| Compact Mode | Claude Code 内置压缩 | 30-50% | 探索阶段，快速浏览代码 |
| PTC | 私有工具调用，中间结果不进入上下文 | 视使用频率 | 复杂任务链，减少中间态 |
怎么选？
- 如果你主要用 AI 执行终端命令（测试、构建、git 操作），RTK 或 tokf 是首选
- 如果你想减少代码文件进入上下文，用.claudeignore
- 如果你在探索阶段想快速浏览，开Compact Mode
- 这些方案可以叠加使用
有什么局限性？
任何工具都有边界，RTK 也不例外。
1. 信息丢失风险
压缩的本质是“删减”，某些场景下可能会删掉你真正需要的信息。
比如调试一个偶发的测试失败，你可能需要看到完整的测试输出，而不是被压缩后的摘要。这时候可以临时禁用 RTK：
rtk off
调试完再开：
rtk on
2. 非标准命令支持有限
RTK 内置了对常见命令的解析规则，但对于一些非标准格式、自定义脚本的输出，压缩效果可能不如预期。
总结
RTK 解决的问题很小众但很真实：AI 编程助手的 token 消耗，很大一部分是被“命令输出噪音”吃掉的。
它的价值在于：
- 省钱：80-90% 的 token 节省，按当前模型定价算，回本很快
- 无感：安装配置一次，之后全自动，不影响原有工作流
- 聚焦：只做一件事，不做大而全的功能堆砌
适合用的场景：
- 重度使用 Claude Code、Cursor 等 AI 编程工具
- 频繁执行测试、构建、git 操作
- token 消耗是真实痛点（无论是成本还是上下文上限）
不太需要的场景：
- 偶尔用 AI 写点代码，token 消耗本来就低
- 主要用 AI 做代码解释、文档生成，很少执行命令
- 已经通过其他方式把 token 消耗控制在合理范围
如果你属于前者，RTK 值得一试。30 秒安装，效果立竿见影。
项目地址：https://github.com/rtk-ai/rtk