RTK 上手：别让 Coding Agent 把 token 烧在 ls、cat 和重复命令上

RTK 的定位很直接：CLI proxy，减少 LLM 在常见开发命令上的 token 消耗。它不是让模型更会写代码，而是让 Agent 别把钱和上下文窗口浪费在 `ls`、`cat`、`grep`、重复日志和巨长输出上。README 里提到在常见开发命令上能减少 60% 到 90% 的 token 消耗，这个数字先别当承诺背书，但方向是对的：Agent 工程化不能只算模型单价，还得算工具调用的上下文成本。

很多团队用 Coding Agent 的账不是被一次大模型回答打爆的，而是被一堆看似便宜的命令慢慢磨掉。Agent 每次读文件、列目录、看日志，都可能把大量无关文本塞回上下文。RTK 想做的是在命令层做拦截、压缩和优化，让 Agent 拿到“足够决策”的信息，而不是“原封不动的终端洪水”。

安装：优先包管理器，团队机器用固定版本

如果你用 macOS 或 Linux，可以先走 Homebrew。

brew install rtk

也可以用官方 install script：

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

Rust 用户还可以从源码安装：

cargo install --git https://github.com/rtk-ai/rtk

生产团队建议固定版本，不要每台机器都 `latest`。这类代理工具夹在 Agent 和 shell 之间，一旦行为变化，排查会很烦。先在个人环境跑一周，再写入团队配置。

初始化到你的 Agent 工具

RTK 支持多种 Agent：Claude Code、Copilot、Gemini CLI、Codex、Cursor、Windsurf、Cline/Roo、Kilo Code、Antigravity 等。初始化时要选对目标。

# Claude Code / Copilot 默认路径
rtk init -g

# Gemini CLI
rtk init -g --gemini

# Codex
rtk init -g --codex

# Cursor
rtk init -g --agent cursor

# Windsurf / Cline / Antigravity 等
rtk init --agent windsurf
rtk init --agent cline
rtk init --agent antigravity

初始化后重启对应 AI 工具。别忘了确认它到底有没有接上：让 Agent 执行一个会产生较多输出的命令，再看 RTK 是否参与处理。如果没有效果，优先查 shell PATH、工具配置目录和初始化目标是否选错。

它到底省在哪里

举个简单例子。Agent 想查某个目录，传统做法可能把整个 tree 或一大段日志贴回上下文。人类工程师其实只需要几个信号：文件在哪里、有没有错误、下一步该看哪一段。RTK 的思路就是把终端输出变成更适合 Agent 消化的摘要或优化结果。

这件事和“压缩提示词”不是一回事。提示词压缩是把输入变短，RTK 更像命令层的节流阀：在工具输出进入模型上下文之前，先把无关噪声挡掉。

和手写规则配合效果更好

只装 RTK 不写规则，效果会打折。你可以给 Agent 加一段项目规矩：

读取代码时先用定向搜索，不要全仓库扫描。
查看日志时只取失败附近 80 行，除非需要完整上下文。
大文件先看结构和函数名，再读取具体片段。
重复命令不得超过两次，第三次必须说明新假设。

RTK 负责工具输出层，规则负责行为层。两者合起来，才能减少“Agent 一边省 token，一边疯狂乱跑”的问题。

常见坑：省 token 不等于省判断

有些输出不能压得太狠。比如安全审计、数据库迁移错误、编译器类型报错、测试失败堆栈，如果摘要丢掉关键行，Agent 会做错判断。遇到这类场景，要允许它回退查看原始输出。

另一个坑是把 RTK 当成本优化银弹。真正烧钱的往往是需求不清、反复改方向、没有测试导致多轮返工。RTK 能省工具输出，但省不了产品犹豫。

团队上线检查

上线前看四点：是否支持你们实际使用的 Agent；是否能在 CI/远程开发机里稳定安装；是否有办法关闭或绕过；是否能定位压缩后的输出和原始输出差异。只要其中一项做不到，就先不要全员启用。

RTK 值得关注，是因为它把大家经常忽略的成本显性化了。未来 Agent 不是只拼“会不会写”，还要拼“会不会少废话、少读无关信息、少把上下文烧没”。这事儿挺土，但省钱省命。