RTK：压缩 AI 编程助手读到的终端输出
让编程助手检查一个仓库时，git status、测试和搜索命令经常返回大段文本。模型要读完这些结果，才能决定下一步；其中不少行对当前判断没有帮助。RTK（Rust Token Killer）把自己放在命令与助手之间：照常调用底层工具，过滤或归纳其输出，再把较短的结果交给助手。
RTK 适合终端输出占上下文较多的开发任务。RTK 只处理经过自身代理的命令输出，不能缩短用户提示词、对话历史或模型回复。因此，仓库所说的“节省 60%～90%”是特定命令输出量的参考范围，不是订阅费用会下降同样比例。先手动比较一条命令，再决定是否给编程助手安装自动改写 hook，会比较容易判断这种代理是否适合自己的工作流。
GitHub 仓库信息
| 信息 | 内容 |
|---|---|
| 项目标题 | RTK（Rust Token Killer） |
| 项目描述 | 一个通过代理常见开发命令、压缩其输出以减少进入 LLM 上下文文本量的 CLI 工具；以 Rust 单个可执行文件分发。 |
| GitHub 仓库 | rtk-ai/rtk |
| 官网地址 | rtk-ai.app |
| 主要开发语言 | Rust 95.67%、Shell 2.91%、TypeScript 0.95%（GitHub Languages，2026-09-16） |
| 开源许可证 | Apache-2.0 |
| 最近代码更新 | 2026-09-15（GitHub pushed_at，核对日期：2026-09-16） |
RTK 改变了哪一步
不用 RTK 时，助手发起 git status，终端原样返回所有文本；使用 RTK 后，助手执行 rtk git status，RTK 调用 Git 并把文件按状态压缩展示。类似地，rtk git log -n 10 保留较短的提交摘要，rtk pytest 倾向于突出失败项。具体过滤规则因命令而异，不能把所有命令都理解为“截掉后半段”。官方命令清单按 Git、测试、搜索、容器等场景列出了对应的摘要方式。
正在准备渲染...
查看源码
flowchart LR
A[编程助手发起命令] --> B{命令是否经 RTK}
B -->|手动前缀或 Agent hook| C[RTK 调用底层工具]
B -->|否| D[底层工具原始输出]
C --> E[按命令过滤、分组或截断]
E --> F[助手读取精简输出]
D --> G[助手读取原始输出]
E --> H[本地统计与可选原文召回]这里有两层区别。第一，RTK 是输出代理，不是新的 Git 或测试引擎；过滤之前的命令仍需由相应工具执行。第二，手动输入 rtk git status 和自动接入 Agent 是两个步骤：安装二进制后不会自动改变所有终端命令，只有显式加前缀或安装相应 hook/规则才会让助手改用 RTK。仓库的改写决策代码和Agent 支持文档确认了这层边界。
第一次有效体验
以下以 macOS/Linux 上已有 Homebrew、Git 且当前目录是一个有提交记录的 Git 仓库为例。不在 RTK 源码仓库中操作；无需 API Key，也不必先安装任何 Agent hook。安装是供读者执行的官方步骤，本次写作没有下载或运行上游二进制。
# 如果已安装，先跳到下面的身份检查；否则按官方安装文档使用项目 tap。
brew install rtk-ai/tap/rtk
rtk --version
rtk gainrtk --version 应返回版本号，rtk gain 应打开节省统计面板；刚装好时没有历史数据是正常的。如果版本命令可用，但 rtk gain 无法显示 RTK 的统计面板，先检查 which rtk：另一个名为 Rust Type Kit 的项目也使用 rtk 命令名。不要仅凭命令名判断安装正确。这里选择官方安装页的专用 tap，避免同名包歧义；中文 README 的 brew install rtk 与安装页写法不同，安装前应按当前官方安装页再次核对。
切到自己的 Git 项目根目录，先比较相同任务的两种输出：
git status
rtk git status
git log -n 10
rtk git log -n 10
rtk gain --history成功信号不是两份文本完全相同，而是 RTK 输出仍能回答“哪些文件有变动、最近有哪些提交”；rtk gain --history 应能看到刚才经 RTK 的命令及估算的输出削减情况。空仓库没有提交时，先在已有提交的仓库试 git log。如果某条记录显示接近零的缩减，先看原始命令是否本来就只返回很短的文本，或该命令是否走了透传；不要为了追求百分比而扩大无关命令的输出。遇到具体缺失信息，直接执行原命令，不要依据摘要做需要完整上下文的判断。
没有 Homebrew 的 Linux/macOS 可以按官方安装页选择 Release 二进制，Windows 可以选 winget install rtk-ai.rtk。官方还提供 curl ... | sh，但那会直接执行远程脚本；需要审计安装内容时，先阅读固定版本的脚本或选用可检查的发行包。使用 Cargo 时指定项目 Git URL，不要直接 cargo install rtk，以免安装同名的另一款工具。
接入编程助手
确认手动调用有价值后，再考虑让 Agent 自动改写命令。rtk init 会写入 Agent 的 hook、规则或说明文件，因此先用 --dry-run 看修改范围；项目级与全局级不要混淆。以下代码块只有预览命令。在相应项目根目录，按正在使用的 Agent 选一条执行，不需要全部运行：
# Claude Code：仅当前项目。
rtk init --dry-run
# Claude Code：全局配置，影响该用户的多个项目。
rtk init --global --dry-run
# Codex CLI：仅当前项目，会涉及 .codex/hooks.json 和 AGENTS.md。
rtk init --codex --dry-run
# GitHub Copilot：仅当前项目，涉及 .github/hooks/ 等文件。
rtk init --copilot --dry-run先检查预览列出的每一个目标文件与修改内容，确认作用域、现有配置备份和其他 hook 不会被意外覆盖。确认后单独执行刚才选定的命令，但移除 --dry-run；例如 Claude Code 的项目级命令为 rtk init。这一步才会真正写文件。安装后重启相应 Agent，检查生成的 hook/规则及 Agent 是否把一次受支持的命令改写为 rtk ...。Claude Code 的官方快速开始还给出 rtk init --show 检查 hook 状态。--dry-run 的“Nothing written”只说明预览无改动，不等于 hook 已生效。官方快速开始与Agent 支持表给出了更多目标的安装命令。
不同 Agent 的“接入”并不等价。Claude Code、Codex CLI 等在文档所列版本中有命令执行前的 hook；Cline、Windsurf、Kilo Code 等主要靠规则文件提醒模型主动加前缀，不能保证透明改写。原生 Windows 上 Unix shell hook 的行为也不同，官方建议需要完整 shell hook 时使用 WSL。不要把文章中的命令清单理解为所有 Agent 都有同等可靠的自动接管能力。
Codex 用户还需检查权限边界：仓库的 Codex hook 说明说替换命令仍会进入 Codex 原生审批与沙箱，但安全分类器未必能识别 rtk 包裹下的原始动作。这种分类限制可能增加确认提示，也可能弱化对 rtk git push 等写操作的识别。对部署、推送、数据库写入等命令保留人工审批，不因为 RTK 的输出更短就扩大自动执行权限；本教程也没有验证当前用户的 Codex 安装是否启用了该 hook 协议。
统计、原文与本地数据
rtk gain 中的 Input/Output 是把过滤前后命令输出字节数约除以 4得到的估算值，Saved 是两者的差。这个比值有助于比较输出量，但不是模型专用 tokenizer 的精确 token 数，也不是账单金额。用户输入、系统提示词、历史上下文和模型输出均未计入。官方节省口径与估算实现都指向这一点。知乎的入门介绍提供了场景与简短命令示例，其中的百分比与毫秒级开销属于来源声明，不能当作本次独立基准测试。
本地 RTK 历史库的一次只读聚合补充了一个容易忽略的情况：多数命令记录为空输出或未产生缩减。这个单机观察不能推出 RTK 在其他任务中的总体收益，也不能据此推算账单变化。聚合时没有读取原始命令、项目路径、日志原文或召回内容，文章不公开个人使用数值。评估自己的收益时，应先用 rtk gain --history 找出高频但没有减少输出的命令，再判断是输出原本很短、未匹配过滤器，还是过滤强度不合适；不要只看一个总百分比。
RTK 的历史数据保存在本机 SQLite，默认历史保留 90 天；记录中包括原始命令、项目路径和估算结果，表结构表明本地统计并非“什么都不留”。输出被截断时，当前配置文档描述的默认召回模式还会在本地存放原始输出，让助手按提示执行 rtk recall <hash> 取回被隐藏的细节。这个机制能挽回过滤造成的信息损失，也意味着原文中若含密钥、个人信息或内部日志，相关本地存储需要纳入设备权限、备份与清理策略。可用 rtk config recall 查看模式，必要时根据配置文档设为 disabled；禁用后也会失去原文召回能力。
遥测与本地统计是两回事。隐私说明称远程遥测默认需要明确同意，源码也要求同意状态为真才发送；可用 rtk telemetry status 查看，并用 rtk telemetry disable 撤回。配置示例中出现的 [telemetry] enabled = true 容易造成误读：这是示例键值，不能替代实际同意状态核验。不要把“遥测关闭”误认为本地命令历史与召回原文也已清除。
什么时候不该压缩
需要逐字比对完整 diff、审计每条日志或核查完整测试矩阵时，在受控的本地终端查看原始输出，不以 RTK 摘要代替证据。原文若含凭据、个人信息或内部日志，不要把未脱敏的命令结果或 rtk recall 内容送进 Agent 上下文；先在本地检查、脱敏，无法安全脱敏时不要在 Agent 会话中运行该命令。对不支持的命令，rtk proxy <命令> 可透传并记录使用情况，但不应期待 RTK 自动压缩所有工具。若自动 hook 妨碍一般性调查，可按Agent 支持文档为单次非敏感命令设 RTK_DISABLED=1，或在 [hooks] exclude_commands 中排除指定命令；这只是绕过过滤，仍可能把原始输出交给 Agent。对含敏感数据的任务，还应按配置文档考虑关闭本地原文召回，不能把“绕过 RTK”当作脱敏措施。
经常让 Agent 运行冗长的 Git、测试与搜索命令，并愿意维护一层 hook 的个人开发者，最容易在 RTK 中获得可观察的输出缩减。如果命令结果本来很短，或团队的日志、审批与可审计性要求优先于压缩，直接使用原生 CLI、在调用层限制输出（例如 git log -n 5、更精确的 rg 查询），通常更可控。RTK 没有替代这些工具：RTK 提供的是统一的命令输出压缩与统计层。
下一步可在一个非敏感项目中连续使用几天，分别看 rtk gain --history 的命令分布和实际查回原文的频率。若经常要召回同一类结果，就调低过滤强度、排除该命令，或干脆使用原生输出；不要以宣传中的平均节省比例替代自己的任务判断。
版本与参考
本文以 2026-09-16 核对的公开仓库 develop 分支提交 5e0f92c为静态来源；当时最新非预发布 Release 为 v0.49.0。分支源码、安装文档与二进制发行版本可能不同，安装后的实际 rtk --version 和对应版本文档优先。本次只读检查本机 RTK 历史库与召回库的结构及聚合记录，未读取原始命令、项目路径或日志内容；未执行 RTK、验证 Agent hook 或做性能基准测试。本地观察仅用于说明不同命令分布下的采用判断，不作为读者可复现的收益数字。