RTK：高性能 CLI 代理，LLM token 消耗直降 60-90%

不是软文，不是官方枪手，就是一个被 token 账单逼疯了的开发者的自救记录。

前置背景：我为什么开始折腾这个

我常用的 AI 环境是 OpenClaw 接 DeepSeek V4 模型，按 API token 计费。一开始没太在意 token 消耗，觉得 DeepSeek 便宜嘛，随便用。后来仔细分析才发现——token 消耗里至少一半花在了 CLI 命令的输出上，模型根本没用到这些信息。

回过头看一条典型的调试流程：

我：帮我修一下这个登录页的 bug OpenClaw → 执行 ls -la（800 tokens 的权限位和日期）→ 执行 git status（400 tokens 的 git 提示信息）→ 读三个文件（每个几百 tokens）→ 执行 git diff（2500 tokens）→ 改代码 → 跑测试（5000 tokens 的全量日志）→ git commit（带一大段 git config 提示）

一条指令下来，光命令输出就灌进去小一万 token。问题是 DeepSeek 根本不需要知道 drwxr-xr-x 或者 git commit 之后那段"请设置 user.name"的废话。

我需要一个东西，在我和模型之间拦一道，把噪音滤掉再喂给 AI。

RTK 是什么？

RTK（Rust Token Killer）是个单二进制 CLI 工具，用 Rust 写的，安装就一个文件。它做的事情很简单：

正常流程：你让 AI 跑 git status → 原始输出 → 直接塞进 context window
装了 RTK 之后：你让 AI 跑 git status → hook 自动改写成 rtk git status → 过滤压缩 → 精华版塞进 context

原理不复杂，但它对每种命令都做了定制化的过滤策略：去噪音、分组聚合、截断冗余、去重。100+ 命令都有对应处理器，不认识的命令直接 passthrough 不碍事。

对于 OpenClaw 用户来说特别实用——RTK 有专门的 OpenClaw 插件可以直接集成，或者通过 hook 模式自动改写 Bash 工具调用。

我自己的实测：拿真实项目跑了一遍

调研文档里的数字太多。我直接在自己的 Hugo 博客项目 chenshungen.cn（803 个文件）上做了一次严格的 A/B 对照：先用 ls -laR 获取完整目录，记录 token 消耗；重启 OpenClaw 后再跑一次，对比两次的实际开销。测试环境 Ubuntu 24.04，OpenClaw + DeepSeek V4，rtk v0.39.0。

场景一：目录列表 —— 98.7% 的降幅

这是整篇文章最有说服力的一组数据。我用完全相同的命令跑了两次：

不用 RTK（ls -laR）：

drwxr-xr-x 2 root root  4096 May  6 17:32 archetypes
drwxr-xr-x 8 root root  4096 May  6 17:32 assets
-rw-r--r-- 1 root root  5635 May  6 17:38 CLAUDE.md
drwxr-xr-x 7 root root  4096 May  6 14:47 content
drwxr-xr-x 2 root root  4096 May  6 17:32 data
drwxr-xr-x 8 root root  4096 May  6 17:38 .git
-rw-r--r-- 1 root root   128 May  6 14:47 go.mod
-rw-r--r-- 1 root root   205 May  6 14:47 go.sum
-rw-r--r-- 1 root root  6656 May  6 17:32 hugo.toml
... 751 行更多 ...

32,178 字符，761 行，约 8,000 tokens。 这里面每一行都包含权限位（drwxr-xr-x）、owner/group、精确字节数、毫秒级时间戳——全部是对 AI 零价值的噪音。

装了 RTK（rtk ls）：

archetypes/
assets/
content/
data/
i18n/
layouts/
scripts/
static/
.gitignore  462B
CLAUDE.md  5.5K
go.mod  128B
go.sum  205B
hugo.toml  6.5K
hugo_stats.json  18.4K
package.json  225B
start-dev-server.sh  594B
... 30 行总计 ...

414 字符，30 行，约 104 tokens。省了 98.7%。

	无 RTK	有 RTK	节省
字符数	32,178	414	98.7%
行数	761	30	96.1%
预估 tokens	~8,000	~104	98.7%

只保留目录名 + 文件名 + 可读的文件大小（human-readable），权限位、owner、时间戳全部去掉。761 行压缩到 30 行，AI 一眼看完整个目录结构。

场景二：git status —— AI 最常执行的操作

改完代码让 AI 提交之前，它几乎每次都会先跑 git status 确认变更范围。我的项目当前有 20 个修改文件 + 97 个未跟踪文件：

不用 RTK：

On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   content/blog/ai-native-website.md
        modified:   hugo.toml
        modified:   hugo_stats.json
        ... 17 more ...

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        archetypes/authors.md
        archetypes/blog.md
        ... 95 more ...

no changes added to commit (use "git add" and/or "git commit -a")

4,424 字符，约 1,106 tokens。git 自带的提示信息（“use git add”、“use git restore”）占了大量篇幅。

装了 RTK：

* main...origin/main
~ Modified: 20 files
   content/blog/ai-native-website.md
   hugo.toml
   hugo_stats.json
   ... +15 more
? Untracked: 97 files
   archetypes/authors.md
   archetypes/blog.md
   ... +87 more

1,027 字符，约 257 tokens。省了 77%。

场景三：git commit —— 从废话到 “ok”

不用 RTK：

[master 7de98da] test: add new feature module and fix helpers
 Committer: root <root@localhost.localdomain>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:
    git config --global user.name "Your Name"
    git config --global user.email you@example.com
... git config 提示 ...
 3 files changed, 3 insertions(+)

586 字符，约 147 tokens。

装了 RTK：

ok

3 字节，约 1 token。省了 99.3%。

git push → ok main。git add → ok 3 files changed。git pull → ok 3 files +10 -2。能用一个词绝不用一句话。

以上测试的汇总

这三组测试在本地积累了 22 条 RTK 命令记录，rtk gain 给出了整体统计：

═══════════════════════════════════════
总命令数:    22
输入 tokens:  200.2K（原始命令输出）
输出 tokens:  9.7K（RTK 压缩后）
节省 tokens:  190.5K（95.2%）
总耗时:      3.8 秒（平均 174ms/条）
═══════════════════════════════════════

按命令类型：
  rtk grep         2 次  省 186.5K  tokens（48.6%）
  rtk ls           4 次  省 1.0K   tokens（81.4%）
  rtk git status   2 次  省 924    tokens（73.4%）
  rtk git commit   1 次  省 146    tokens（99.3%）
  rtk find         2 次  省 315    tokens（98.0%）

这还只是手动测试，插件自动改写后日常使用中所有 Bash 命令都会走 RTK，积累速度会快得多。

展开说说：哪些命令省得最多

RTK 的压缩策略不是一刀切，而是按命令类型做针对性处理。四种策略：

Smart Filtering：去掉注释、空行、权限位、进度条等噪音
Grouping：把同类条目聚合成一行（比如 lint 结果按规则分组）
Truncation：超过阈值的截断，需要细节时提供 tee 文件路径让 AI 自行读取
Deduplication：重复日志行折叠成 [repeated 42x]

覆盖面相当广，以下是我在真实项目上跑出来的数据，加上调研文档中整理的部分：

命令	原始大小	RTK 大小	节省	来源
`ls`（包含子目录）	12,242 字符	394 字符	97%	本机实测
`git status`（20 修改 + 97 未跟踪）	4,424 字符	1,027 字符	77%	本机实测
`git commit`	586 字符	3 字节	99%	本机实测
`git log`（默认格式 3 条）	823 字符	464 字符	44%	本机实测
`find *.md`	1,043 字符	537 字符	49%	本机实测
`pytest`（含失败）	~8,000 tokens	~250 tokens	97%	调研文档
`go test ./...`（含失败）	~15,000 tokens	~200 tokens	98%	调研文档
`eslint src/`	~5,000 tokens	~400 tokens	92%	调研文档

当然也有不那么夸张的：git diff 小改动场景效果有限，因为 diff 本身信息密度就高，能去的不多。grep 搜一个全项目都出现的 pattern，rtk 也没法去重，因为每行都不一样。

但实话实说，日常 80% 的 shell 命令都属于"噪音远大于信号"的类型，RTK 刚好打在这些痛点上。

不只是压缩：一些让我意外的设计细节

用了一段时间发现几个比"压缩输出"更有意思的点：

1. `rtk read -l aggressive`：只读签名，不看实现

这是我最喜欢的功能。比如你想快速了解一个模块暴露了哪些接口：

rtk read src/core/engine.rs -l aggressive

输出只保留 fn / trait / impl / struct 的声明行，函数体全丢。对于一个 500 行的文件，aggressive 模式可能压缩到 50 行。

三个档位：

none：原样输出，纯 passthrough
minimal（默认）：去注释、合并空行，省 ~30%
aggressive：只留签名，省 ~70%

让 AI 规划阶段用 aggressive 快速了解代码结构，改代码时切回 minimal 甚至 none，很顺手。

2. `rtk smart`：两行看懂一个文件

$ rtk smart src/components/LoginForm.tsx
TypeScript functions (3 fn) - 87 lines
uses: react, @/components/ui, zod | patterns: React hooks, form validation

不读全文，模型就知道这个文件大概干什么的。在 chenshungen.cn 这个博客项目上试了一下：

$ rtk smart content/blog/golang-concurrency/golang-mutex.md
Data code (429 lines)
General purpose code file

对大文件（429 行）直接给出行数和类型判断，模型可以据此决定要不要深入阅读。

3. `tee` 机制：失败时保留完整输出

测试跑挂了，RTK 只显示失败摘要（省 90% tokens），但同时把完整输出写到 ~/.local/share/rtk/tee/ 里。AI 如果真的需要看完整 traceback，可以直接 rtk read 那个文件，不用重跑一遍测试。这个细节想得很到位。

4. 本地收益可验证，不靠官方吹

rtk gain 直接读本地 SQLite 数据库（~/.local/share/rtk/tracking.db，存 90 天），给你看：

总共跑了多少条命令
省了多少 token
按命令类型的详细 breakdown
每日趋势图（rtk gain --daily）

还有一个 rtk discover 能扫描你的 AI 工具历史记录，找出哪些命令没用 RTK 但可以受益——相当于一个漏网之鱼检测器。

接入很简单，但有几个坑要看

安装（30 秒搞定）

# macOS/Linux
brew install rtk
# 或者一行脚本
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

# 装 hook（自动拦截 Bash 工具调用）
rtk init -g
# 重启 AI 编程工具即可

支持 12 家 AI 编程工具：OpenClaw、Claude Code、GitHub Copilot、Cursor、Gemini CLI、Codex、Windsurf、Cline/Roo Code、OpenCode、Kilo Code、Google Antigravity。

OpenClaw 用户可以选两种方式：直接装 OpenClaw 插件（openclaw plugins install），或者用 hook 模式自动改写 Bash 工具调用。

实际踩过的坑

1. Windows 上体验打折扣。 原生的 hook 机制依赖 Unix shell，Windows 上只能用规则注入模式，没有自动改写。建议 WSL2 里用，跟 Linux 体验一样。

2. 中文 locale 下有 bug。 rtk ls 在非英文 locale 下可能对非空目录返回 (empty)，这是已知问题。用中文系统的建议先手动验一轮。

3. 子 agent 的 Bash 调用不走 hook。 AI 工具的 agent 模式下，子 agent 的 Bash 调用可能不会经过 hook 改写。多 agent 场景收益会打折。

4. 不是所有命令都有收益。 git diff 小改动、grep 搜高频词等场景，压缩空间有限。装 RTK 不代表从此不关心 token 消耗，该优化的还是得优化。

真实感受：该装，但别神化

用了这段时间，我的结论是：

如果你日常用 OpenClaw / Claude Code / Cursor 这类 AI 编程工具，RTK 应该属于默认安装的那一类工具，跟 oh-my-zsh、fzf 一个级别——装了就忘了它在工作，但账单一对比就知道值。尤其是像我这样用 DeepSeek API 按量付费的，token 省下来就是真金白银。

它不是银弹：

压缩率取决于你干什么：改 bug 跑测试→省 90%，写新功能频繁读文件→省 30-50%
效果取决于你怎么用：aggressive 模式读文件很爽，但改代码时别忘了切回去
有一些 edge case：非英文 locale、Windows 原生、某些 CI 场景需要额外配置

但这些东西都是可以接受的代价。相比于每天被打断工作流，或者月底看到超出预期的 API 账单，RTK 的 30 秒安装成本几乎可以忽略。

而且它是开源 Apache-2.0 协议，数据存本地，telemetry 默认关闭需要主动 opt-in。没有 vendor lock-in，不想用了 rtk init -g --uninstall 一键卸干净。目前 GitHub 上 44k+ stars，社区活跃，更新很快（差不多每周发新版）。

附：快速判断你需不需要 RTK

如果你符合以下任意一条：

AI 编程工具的 token 消耗远超预期，尤其是按 API 用量付费
项目代码量大（100+ 文件），上下文窗口容易被噪声占满
测试、lint、构建等重复性操作的输出占据了大量 token
团队多人用 AI 编程，总 token 成本在持续上升

那就值得花 30 秒装一个试试。跑一天后用 rtk gain --daily 看数据，自己判断值不值。

以上实测数据全部来自 chenshungen.cn 项目（/root/chenshungen.cn），可在本机复现。安装命令：brew install rtk 或访问 github.com/rtk-ai/rtk。