RTK：五万星的 LLM 令牌省钱神器，帮你把 AI 编程成本砍掉八成

用 Claude Code 写半小时代码，token 消耗轻松突破十万。一个月下来，API 账单可能比你的咖啡钱还贵。一个叫 RTK 的 Rust 工具说：我可以帮你砍掉其中 80%。

一、RTK 是什么

RTK（Rust Token Killer）是一个高性能 CLI 代理，位于你的 AI 编程工具和终端之间，在命令输出到达 LLM 上下文之前对其进行过滤和压缩。

它不是什么新框架，不需要改你的工作流——装上之后，git status 还是 git status，只是 AI 看到的输出从 2000 token 变成了 200 token。

核心数据：

• GitHub 星标：50,900+（截至 2026 年 5 月）
• 语言：Rust，单一二进制文件，零依赖
• 开销：<10ms
• 支持命令：100+
• 支持 AI 工具：14 个

从 2026 年 1 月创建到现在不到半年，RTK 就积累了五万星。这个增速在开源工具里相当罕见，背后是 AI 编程工具爆发式增长带来的真实需求。

二、它到底省了什么

RTK 的核心逻辑很简单：AI 编程代理在执行命令时，会产生大量冗余输出——进度条、版权信息、空白行、重复日志——这些内容对 LLM 理解代码毫无帮助，却实实在在消耗 token。

以一个 30 分钟的 Claude Code 会话为例：

按 Claude Sonnet 的 API 定价估算，30 分钟节省约 94,000 input token，折合约 ¥0.7（input 价格 ¥7/百万 token）。一天写 4 小时代码，一个月下来能省 ¥15-20——不多，但对于重度用户和团队来说，这个数字会随着使用频率线性增长。

三、四种压缩策略

RTK 不是简单的截断，它针对不同类型的命令输出有专门的过滤逻辑：

智能过滤：移除噪音。git push 的 Enumerating objects、Counting objects、Delta compression 进度信息对 AI 毫无价值，RTK 直接砍掉，只留 ok main。

分组聚合：把相似项归类。eslint 的 50 条错误按文件和规则分组，ls 的 200 个文件按目录聚合，AI 一眼就能看出模式。

截断保留：保留关键上下文，删除冗余。cat 一个 500 行文件时，RTK 可以只保留函数签名和关键段落（rtk read file.rs -l aggressive）。

去重计数：重复的日志行合并为一行加计数。docker logs 输出 1000 行 health check OK？RTK 给你 health check OK (×1000)。

举个实际例子，git push 的输出对比：

四、安装与上手

安装只需要一行命令：

1
2
3
4
5
6
7
8

# Homebrew（推荐）
brew install rtk

# 或者快速安装脚本
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

# 或者从源码编译
cargo install --git https://github.com/rtk-ai/rtk

初始化 hook：

1
2
3
4
5
6
7
8
9
10
11
12
13

# Claude Code（默认）
rtk init -g

# Gemini CLI
rtk init -g --gemini

# Codex（OpenAI）
rtk init -g --codex

# Cursor
rtk init -g --agent cursor

# 其他工具见文档

初始化完成后重启你的 AI 工具，一切就绪。之后执行 git status 时，RTK 会自动拦截并压缩输出，AI 收到的是精简版本。

验证安装：

1
2

rtk --version   # 应显示 rtk 0.28.x
rtk gain        # 查看 token 节省统计

五、支持的 AI 工具矩阵

RTK 支持 14 个 AI 编程工具，覆盖了市面上绝大多数主流选项：

Hook 的工作原理是拦截 Bash 工具调用，把 git status 重写为 rtk git status。但要注意：Claude Code 内置的 Read、Grep、Glob 工具不走 Bash hook，所以如果想对这些操作也用 RTK，需要手动调用 rtk read、rtk grep、rtk find。

六、常用命令速查

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

# 文件操作
rtk ls .                     # 优化的目录树
rtk read file.rs             # 智能文件读取
rtk read file.rs -l aggressive  # 仅函数签名
rtk grep "pattern" .         # 按文件分组的搜索结果
rtk find "*.rs" .            # 紧凑的查找结果

# Git
rtk git status               # 紧凑状态
rtk git log -n 10            # 单行提交
rtk git diff                 # 精简 diff
rtk git push                 # → "ok main"

# 测试
rtk cargo test               # Cargo 测试（-90%）
rtk pytest                   # Python 测试（-90%）
rtk jest                     # Jest（仅显示失败）
rtk test <cmd>               # 通用测试包装器

# 构建和 lint
rtk cargo build              # Cargo 构建（-80%）
rtk ruff check               # Python lint（-80%）
rtk tsc                      # TypeScript 错误分组
rtk lint                     # ESLint 按规则分组

# 容器
rtk docker ps                # 紧凑容器列表
rtk docker logs <container>  # 去重日志
rtk kubectl pods             # 紧凑 Pod 列表

# AWS
rtk aws sts get-caller-identity  # 单行身份信息
rtk aws ec2 describe-instances   # 紧凑实例列表

# 分析
rtk gain                     # 节省统计
rtk gain --graph             # ASCII 图表（30 天）
rtk discover                 # 发现遗漏的节省机会

七、配置与进阶

配置文件位于 ~/.config/rtk/config.toml：

1
2
3
4
5
6

[hooks]
exclude_commands = ["curl", "playwright"]  # 跳过这些命令的重写

[tee]
enabled = true          # 失败时保存原始输出
mode = "failures"       # "failures"、"always" 或 "never"

tee 功能特别实用：当命令失败时，RTK 会把完整的未过滤输出保存到本地文件，AI 可以直接读取而不需要重新执行命令。输出里会出现类似这样的提示：

1
2

FAILED: 2/15 tests
[full output: ~/.local/share/rtk/tee/1707753600_cargo_test.log]

八、社区争议：它真的省钱吗？

RTK 在 GitHub 上有两个引发广泛讨论的 issue，值得每个潜在用户了解：

安全审计（Issue #640）：一位用户让 Claude Opus 对 RTK 做了全面安全审计，发现了 1 个 Critical（shell 注入 via sh -c）、3 个 High（未经同意的遥测、CI 信任绕过、全局过滤器无完整性检查）级别问题。RTK 团队已标记为 priority:high 并在修复中。

成本不降反升（Issue #582）：更有意思的是这个报告——一位用户发现 RTK 的压缩反而让 Claude Code 的总成本增加了 18%。原因是：输入 token 省了，但 LLM 因为收到的信息不完整，输出了更多 token 来补偿（多了 50% 的输出 token）。根本原因在于人类可读的压缩摘要和 LLM 实际需要的信息之间存在错位。

这个争议揭示了一个本质问题：压缩是有损的。RTK 的过滤逻辑是为人类可读性设计的，但 LLM 可能需要那些被当作“噪音”过滤掉的信息。在实际使用中，省不省钱取决于你的项目类型和 AI 工具的使用模式。

九、Windows 用户注意

RTK 在 Windows 上有限制。自动重写 hook（rtk-rewrite.sh）需要 Unix shell，所以在原生 Windows 上 RTK 会降级为 CLAUDE.md 注入模式——AI 助手收到 RTK 的指令但命令不会被自动重写。

推荐方案：使用 WSL。在 WSL 里，RTK 的所有功能完全正常。

如果你坚持用原生 Windows，过滤功能仍然可用，只是需要手动调用 rtk 命令而不是自动拦截。

十、与类似工具的对比

RTK 不是唯一做 token 优化的工具，但它的定位最纯粹：

RTK 的优势在于：它是一个独立的 Rust 二进制，不依赖任何特定 AI 工具，支持 14 个主流工具，且过滤逻辑是针对真实开发场景优化的（100+ 命令的支持）。

十一、局限性

压缩是有损的：Issue #582 已经证明，在某些场景下压缩反而增加成本。如果你的项目需要 AI 理解详细的测试输出或构建日志，过度压缩可能适得其反。

Hook 只拦截 Bash 调用：Claude Code 的内置工具（Read、Grep、Glob）不走 Bash hook，需要手动调用 RTK 命令。

Windows 支持有限：原生 Windows 没有自动重写 hook，需要 WSL 才能获得完整体验。

安全审计仍在进行：shell 注入等问题尚未完全修复，生产环境使用需谨慎。

遥测争议：虽然默认关闭且支持 GDPR 合规的 opt-in，但安全审计发现遥测实现存在问题。

十二、值不值得装

如果你满足以下条件，RTK 值得一试：

• 重度使用 AI 编程工具（每天 2+ 小时）
• 主要在 macOS 或 Linux 上开发（或愿意用 WSL）
• 项目以 TypeScript/Rust/Python/Go 为主（这些语言的过滤器最成熟）
• 对 token 成本敏感，或者团队有预算控制需求

如果你只是偶尔用 AI 辅助写代码，或者项目类型比较小众（RTK 的过滤器可能覆盖不全），收益可能有限。

相关链接

• RTK GitHub 仓库
• RTK 官方文档
• RTK Discord 社区
• 安全审计 Issue #640
• 成本增加报告 Issue #582
• OpenAI Codex 集成讨论