RTK：AI Agent 的 Token 杀手
73,000+ stars。一个 Rust 写的 CLI 代理层，拦截 shell 输出，在交给 AI Agent 之前压缩掉 60-90% 的 token。零依赖，毫秒级延迟。
问题
AI Coding Agent 的 Context Window 像冰箱——看起来很大，塞几个 build 日志就满了。每次 cargo test 输出 5000 行，模型得读完才能给你下一步建议。每行都是钱（API Token）。
白物集每天跑几十个 cron 任务：Hermes Agent 出稿、热点采集、知识卡片入库。每个任务都产生大量 shell 输出——git status、npm test、curl 响应、python3 编译错误。这些输出原封不动喂给 LLM，Context 被垃圾填满，Token 账单跟着涨。
RTK 解决的就是这个问题：在 shell 和 AI Agent 之间插一层，把输出压缩成摘要再喂给模型。
核心亮点
亮点一：命令感知的智能压缩
RTK 不是通用压缩器，它知道每种命令的语义。这正是它和 gzip、zstd 这类通用压缩器的本质区别——无损压缩保留所有信息但只有 2-5x 的压缩比，而 RTK 通过语义理解能达到 10-20x 甚至更高。
| 命令 | RTK 做什么 | 典型压缩比 |
|---|---|---|
ls / tree |
树形 + 文件计数，不逐行列文件名 | ~15x |
cat / read |
只读签名和结构，不读完整正文 | ~20x |
grep / rg |
截断长行，按文件分组匹配 | ~10x |
git status |
紧凑格式，按状态分组 | ~8x |
git diff |
减少上下文，去掉头部元数据 | ~12x |
npm test / cargo test |
只保留失败输出，通过的折叠成计数 | ~20x |
docker ps |
只保留必要字段 | ~6x |
pytest |
只保留失败测试，traceback 截断 | ~15x |
ruff check |
按规则和文件分组 | ~10x |
核心思想很简单：Agent 不需要看完整输出，它只需要知道发生了什么。git status 返回 100 个已跟踪文件的状态，Agent 只关心哪 3 个改了——RTK 直接把 97 行不相关信息滤掉。npm test 跑过 50 个测试，Agent 只关心失败的 2 个——通过的折叠成 "48 passed" 一行。
亮点二：零开销感知
RTK 被设计成<10ms 的额外开销。代码是 Rust 写的，单二进制分发，不依赖任何运行时。这意味着：
- 没有 Node.js/Python 运行时依赖
- 没有异步的 GC 暂停
- 安装即用，brew install 一步到位
- 二进制大小不到 10MB
和同类方案比，这是本质优势。有些 Agent 框架尝试在应用层做输出过滤，但每个命令都会引入 100ms+ 的延迟，开发者很快就关掉了。RTK 的 10ms 几乎感知不到。
亮点三：Agent 无关的通用设计
RTK 不绑定任何 AI Agent。它工作在 shell 层，所以所有基于 shell 的 Agent 都能用：
Claude Code → rtk init -g
Gemini CLI → rtk init -g --gemini
Codex → rtk init -g --codex
Cursor → 通过 shell 配置
任何自定义 Agent → export 环境变量即可
白物集使用的 Hermes Agent 完全基于 shell 交互——每个 terminal() 调用背后都是 shell 进程。RTK 在这样的架构下可以无缝插入，不需要改 Agent 的代码。
白物集的实际使用场景
白物集的内容管线每天在 cron 上跑一系列自动化任务，Hermes Agent 频繁执行 shell 命令。这些命令的输出直接进入 Agent 的上下文，产生持续的 Token 消耗。
场景一：构建输出轰炸
建站系列文章发布前，Agent 会执行构建验证。astro build 输出包含详细的文件列表和文件 hash——通常 200-300 行。在 RTK 下，这些被压缩成：
✓ 42 pages built (12.3s)
✓ 156 assets optimized
⚠ 3 deprecated API warnings
从 ~300 行变成 3 行，压缩比 100x。Agent 需要的信息全在——成功/失败/警告——多出来的行只是浪费。
场景二：git 操作在 monorepo 中的信息过载
白物集项目是一个包含 frontend（Astro SSR）、backend（Express API）、小程序（uni-app）、iOS App 的 monorepo。一次改动可能涉及多个子项目。git diff --stat 的内容会让 Agent 看到所有子项目的文件变更，即使 Agent 只关心前端部分。
RTK 的 git diff 处理器会精简输出格式，保留最关键的文件路径和改动行数，去掉头部元数据和多余格式。Agent 拿到的是干净的数据："3 files changed, 42 insertions, 7 deletions"——够用了。
场景三：CI 中的测试输出
pytest 在白物集 API 项目中跑几十个单元测试。失败时输出详细的 traceback——每层堆栈可能会展开到 30+ 行。RTK 的 pytest 处理器会：
tests/test_api.py:
✓ test_list_articles (0.34s)
✓ test_get_article (0.21s)
✗ test_create_article (1.02s) → AssertionError: expected 201, got 400
✓ test_delete_article (0.18s)
Result: 38 passed, 1 failed (2.3s)
Agent 看到了失败的关键信息（错误类型、响应码、耗时）和整体通过率，不需要读完整个 traceback 才知道哪个测试挂了。
场景四：Python lint 输出
ruff check 的输出逐行列明文件、行号、规则名、错误级别。RTK 按规则分组压缩后，Agent 看到的是：
src/api/index.py:
F841 (3) - Local variable assigned but not used
E501 (2) - Line too long
src/api/routes.py:
F841 (1) - Local variable assigned but not used
Total: 6 issues in 2 files
比原始输出少了约 70% 的行数，关键信息（哪几个文件、哪几种问题、各出现多少次）一个不少。
关于 Token 节省的真相
RTK 的 README 诚实地说了一句话，我直接翻译过来：
"RTK 压缩的是 bash 输出，不是你的 API 账单。bash 输出只是 input tokens 的一部分，input tokens 也只是账单的一部分。每层稀释之后，最终节省可能没有 90% 那么夸张。"
这是诚实的。RTK 报告的压缩比是 bytes / 4 的估算值，没有真正的 tokenizer——所以百分比可靠但绝对数字有偏差。
实测来看，在测试/构建密集的工作流中，RTK 大约能减少 30-50% 的总 input tokens。如果 Agent 的主要工作是读代码和写代码（而非跑测试），这个比例会更低。但如果是 CI 密集型的 agent 任务，60%+ 的节省是真实的。
适用场景 & 不适合场景
适合： - AI Coding Agent 的重度用户——每天跑几百次 shell 命令那种 - CI/CD Pipeline 中 Agent 消耗 Token 成为成本瓶颈的团队 - monorepo 项目，git diff / grep 输出量大的开发环境 - 频繁跑测试套件（npm test / cargo test / pytest）的迭代流程 - 需要精打细算 API 预算的独立开发者和小团队
不适合： - 不使用 AI Coding Agent 的纯手动开发流程——没用 - 需要对完整 shell 输出做精确字符串匹配的场景——RTK 截断了原始数据 - Agent 本身已内置输出优化工具链的工具——极少，目前几乎没有 - 纯文本/简单文件操作的工作流——Agent 读文件时 RTK 的压缩有限
快速上手
1. 安装
# macOS（推荐）
brew install rtk
# Linux / macOS（快速安装脚本）
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh
# Cargo
cargo install --git https://github.com/rtk-ai/rtk
安装后验证：rtk --version。应该显示 rtk 0.28.2 或更高版本。
注意：crates.io 上有个同名项目（Rust Type Kit），如果
rtk gain失败说明装错了。用cargo install --git安装正确版本。
2. 初始化到你的 Agent
# Claude Code / GitHub Copilot（默认）
rtk init -g
# Gemini CLI
rtk init -g --gemini
# Codex
rtk init -g --codex
-g 表示全局模式，对所有终端会话生效。也可以不带 -g 仅对当前项目生效。
3. 查看节省仪表盘
rtk gain
打开实时仪表盘，显示当前会话的 Token 节省统计。包括总节省量、压缩比、Top 10 最费 Token 的命令。
4. 测试某个命令的压缩效果
# 看某个命令在 RTK 下的输出会变成什么样
rtk run -- ls -la
rtk run -- git status
rtk run -- cargo test
输出分两段：原始结果和 RTK 压缩后的结果。马上能看到压缩比。
5. 按需 bypass
某些命令你希望 Agent 看到完整输出：
# 对单个命令跳过 RTK
rtk bypass -- crontab -l
# 永久跳过某些命令
rtk config set skip-commands "crontab,top,htop"
底层实现
RTK 通过 LD_PRELOAD / DYLD_INSERT_LIBRARIES 机制拦截 shell 的读写调用。它运行一个后台 daemon（通过 rtk init 启动），daemon 维护一个共享内存的压缩缓存。
每个命令的输出先经过 daemon 的处理器管道：
- 命令识别 — 通过 argv[0] 匹配已知命令处理器（100+ 个）
- 输出拦截 — 读取 pty 输出流
- 语义压缩 — 按命令特定的处理器规则提取关键信息
- 重新输出 — 压缩后的内容写回到 pty
整个过程在用户空间完成，不涉及内核修改。daemon 自动检测进程退出并清理缓存。
单二进制内置了 100+ 个命令处理器。每个处理器独立编译，可按需启用/禁用。
总结
RTK 解决了一个真实的问题：AI Agent 的 Context 被 shell 输出填满，Token 账单越来越高。它不靠魔法——靠的是对每种命令的语义理解。100+ 个命令处理器，每个输出格式都经过设计，只保留 Agent 真正需要的信息。
73K stars、6 个月冲到 GitHub Trending 首页、Homebrew 官方收录——社区验证了需求的真实性。对于那些还在用 AI Agent 但没注意 Token 在 shell 输出上被浪费多少的人，rtk init -g 大概是今天最快见效的操作。
最后提醒：RTK 不是银弹。它的压缩针对「Agent 需要的信号」设计，不是无损压缩。如果你在写一个需要精确完整日志的 debug 流程，建议 rtk bypass 跳过特定命令。把合适的工具用在合适的地方——RTK 解决的是日常开发中的长期 Token 损耗，不是所有场景都适用。