你的 Coding Agent 不是不够聪明，是被 git status 和测试日志淹死了｜RTK 实战指南

你的 Coding Agent 不是「不够聪明」，经常是 git status、测试日志、find 结果把上下文窗口灌满了。RTK（Rust Token Killer）干的事很单纯------在命令输出进模型之前先压短；它自己不写代码，也不替代 Claude Code / Cursor。

GitHub：github.com/rtk-ai/rtk （约7.4 万 Star，Apache-2.0）
形态：单个 Rust 二进制，开销通常10ms，支持 100+ 常见开发命令
发布时间：2026 年初（仓库约 2026-01-22 创建），是面向 Agent 时代的新工具，不是多年老项目

下面这篇会把官方说法讲清楚，并结合我们真实业务仓库（H5 、Web 后台）给出可复现的前后对比。

01｜为什么 Agent 会「淹死」在终端里？

Coding Agent 的典型循环是：

想一步 → 2. 跑 shell → 3. 读输出 → 4. 再想下一步

问题出在第 3 步：很多 CLI 默认输出是给人看的，不是给模型看的。

现象	后果
`cargo test` / `npm test` 全绿也刷几百行	上下文被「通过」占满，真正有用的失败信息被冲淡
`git status` 一堆英文提示	有效信息只有：改了哪些文件
`git diff` 超大	一次工具调用就吃掉上万 token
`ls -la` / `find`	一行一条，目录稍大就爆炸
`git branch -a` 远程分支几百个	一整屏 remote 列表，对「我现在在哪」几乎无用

结果是三件你天天能感受到的事：

会话变短：窗口顶满，只能压缩或新开，丢上下文
推理变糊：噪音多了，模型更难抓住重点
更贵 / 更快触顶：按量计费多花钱；包月更容易撞 rate limit

RTK 的定位：只动「shell 回给 Agent 的那一段字节」，把废话滤掉。

在我们日常开发时，这个痛点特别具体：Agent 要确认改了、要不要回看 diff、要不要切分支。一连串 git status / git branch / git diff，如果不压缩，会话后半段就会开始「忘了刚才改的是室内照片还是门头照」。

02｜它到底省什么？（避免被「省 90%」误导）

官方文档把账算得很老实，公众号里建议原样讲清楚：

plaintext 复制代码

费用
├─ 输入 token
│  ├─ Bash 输出 ← RTK 只动这里
│  ├─ 你的提示
│  ├─ 系统提示
│  └─ 对话历史
└─ 输出 token ← 模型写出来的，RTK 不管

因此：

说法	正确理解
「最高省 90%」	多指某条命令的 bash 输出体积减少
「账单少 90%」	一般不成立------账单还有提示、历史、输出
`rtk gain` 里的 token	用字节 ÷ 4估算，没有内置真 tokenizer
百分比 vs 绝对数	Save% 可靠；绝对 token 数只是量级，对不上账单明细

一句话给读者：RTK 让「命令输出」瘦下来；整单能省多少，取决于你会话里 bash 占比有多高。测试狂魔、git 狂魔，收益通常最大。

结合我们仓库：前端进件页改动频繁，Agent 会话里 git 类命令占比很高；这时 rtk gain 里看到的 80%+ Save%，主要来自 git branch / git status，不是「整个 Cursor 订阅费打一折」。

03｜工作原理

没有 RTK：

plaintext 复制代码

Agent --git status--> shell --> git
  ^                              |
  +-------- 完整原始输出 ---------+

有 RTK：

plaintext 复制代码

Agent --git status--> RTK --> git
  ^                    |       |
  +---- 压缩后输出 ----+-------+

四种常见策略（按命令类型组合）：

Smart Filtering：去样板、空行、进度条噪音
Grouping：按目录 / 规则 / 文件聚合
Truncation：留关键上下文，砍重复
Deduplication：重复日志合并成计数

失败时默认还能 tee 存全文（后面配置会讲），模型需要时可去读完整日志，而不必再跑一遍命令。

重要提醒：RTK 不是让 Agent 少跑命令，而是让同一次命令的回传更短。你该查状态还是查状态，只是模型读到的字少了。

04｜安装（macOS / Linux / Windows）

4.1 macOS / Linux

bash 复制代码

# 推荐：Homebrew
brew install rtk

# 或官方脚本（默认 ~/.local/bin）
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

# PATH 若没有
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc   # 或 ~/.bashrc

也可用：

bash 复制代码

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

撞名警告：crates.io 上另有叫 rtk 的「Rust Type Kit」。装完必须：

bash 复制代码

rtk --version
rtk gain

gain 不对 → 多半装错包，改用上面的 --git 或 Releases 二进制。

4.2 Windows（原生）

打开 Releases，下载 rtk-x86_64-pc-windows-msvc.zip
解压出 rtk.exe，放到 PATH 目录，例如：C:\Users\你的用户名\.local\bin
在 PowerShell / CMD / Windows Terminal 里运行，不要双击（闪一下就退出）
从 v0.37.2 起，自动改写 hook 是原生二进制（rtk hook claude / rtk hook cursor），不依赖 bash/jq

我们本机当前版本：

text 复制代码

rtk 0.44.2

若很早以前装过、还在用旧的 rtk-rewrite.sh，再跑一次 rtk init -g 迁移到新 hook。

部分过滤会调用 ripgrep（rg），建议装上：

bash 复制代码

winget install BurntSushi.ripgrep.MSVC

Windows 注意：rtk ls 依赖系统里的 ls。纯 PowerShell 环境没有 Unix ls 时会报 Binary 'ls' not found------这不代表 RTK 坏了，换 rtk git status / dir 相关命令即可。文章截图也别用 rtk ls 当 Windows 示例。

4.3 Windows + WSL

WSL 内按 Linux 装即可，行为和 macOS/Linux 一致。

能力	原生 Windows	WSL
git/cargo 等过滤	有	有
自动 rewrite hook	有（原生）	有
rtk gain	有	有

05｜接上 Agent：一劳永逸的 `rtk init`

5.1 推荐流程（以 Claude Code / Cursor 为例）

bash 复制代码

rtk init -g                    # Claude Code：装 hook + RTK.md
rtk init -g --agent cursor     # Cursor：写 hooks.json
rtk init --show                # 检查是否装上

然后彻底重启对应工具（旧会话可能还没挂上 hook）。

生效后：Agent 仍写 git status，实际执行变成 rtk git status，你不用改提示词。

其它常用参数：

bash 复制代码

rtk init -g --hook-only     # 只要 hook，不要 RTK.md
rtk init -g --auto-patch    # 非交互（CI 友好）
rtk init -g --uninstall     # 卸掉 hook / RTK.md / settings 项

5.2 各工具怎么 init

工具	命令	机制
Claude Code	`rtk init -g`	PreToolUse，原生二进制 hook
Copilot（VS Code）	`rtk init -g --copilot`	PreToolUse 透明改写
Copilot CLI	同上	能力受限，偏 deny + 建议
Cursor	`rtk init -g --agent cursor`	hooks.json
Gemini CLI	`rtk init -g --gemini`	BeforeTool
Codex	`rtk init -g --codex`	AGENTS.md + RTK.md 指引
Windsurf	`rtk init -g --agent windsurf`	项目规则
Cline / Roo	`rtk init --agent cline`	.clinerules
OpenCode	`rtk init -g --opencode`	TS 插件
Hermes	`rtk init --agent hermes`	Python 插件改写

层级差别：

Hook/插件类（Claude Code、Cursor、Gemini...）：改写有保障
纯规则文件类（部分 IDE）：靠模型遵守说明，效果可能打折

完整列表以官网 Supported Agents 为准：www.rtk-ai.app

5.3 我们在 Cursor 上怎么验证「真的生效了」

只装二进制 ≠ 自动省 token。必须 init，并且 Cursor 进程能找到 rtk（建议把 ~\.local\bin 写进用户级 PATH，再完全退出 Cursor）。

验证步骤（我们实测过）：

先记：rtk gain 的 Total commands（例如 10）
新开 Agent 对话，只说：「执行 git status，不要自己加 rtk 前缀」
再看 rtk gain：次数 +1，且输出是压缩格式

没走 RTK 时（原始 git）：

text 复制代码

On branch develop_selfDelivery_20260728
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  ...
    modified:   src/page/merchant/into/hf/index.tsx

走了 RTK 时（我们进件仓库实测）：

text 复制代码

* develop_selfDelivery_20260728
 M src/page/merchant/into/hf/index.tsx
 M src/page/merchant/into/ys/index.tsx

一眼能认：星号分支 + 短路径列表，没有那堆英文 use git add 提示。

5.4 必看限制：内置 Read / Grep / Glob

Hook 只拦 Bash（终端）工具调用。

Claude Code / 部分 Agent 的 Read、Grep、Glob 不走 hook，不会自动变瘦。

想压缩这些场景：

bash 复制代码

rtk read path/to/file
rtk read path/to/file -l aggressive
rtk grep "pattern" .
rtk find "*.ts" src/

或在提示里要求 Agent：「尽量用 shell 的 rg/find，或显式调用 rtk ...」。

对我们项目：src/page/merchant/into/ys/index.tsx、hf/index.tsx 都是两千行级大文件。若 Agent 用内置 Read 整文件塞进上下文，RTK 帮不上；这时更该用「只读相关片段」或 rtk read -l aggressive。

06｜前后对比（官方示例 + 我们仓库实测）

官网示例适合建立直觉；下面这组是我们在真实业务仓跑出来的。

6.1 仓库与场景

项目 A：easyhome-h-5-wolaicai（H5）
分支：develop_selfDelivery_20260728
当时未提交改动：图片上传相关（ys/index.tsx、hf/index.tsx）
项目 B：easyhome-web-wolaicai（Web）

6.2 H5 进件仓：字节级对比

命令	原始体积	RTK 后	行数变化	Save%
`git status`	377 B	113 B	9 → 4 行	约 70%
`git branch -a`	29347 B	450 B	669 → 21 行	约 98.5%
`git log --oneline -20`	904 B	705 B	21 → 11 行	约 22%
`git diff`（当前进件改动）	10478 B	10172 B	241 → 229 行	约 2.9%
`git status -sb`	114 B	113 B	4 → 4 行	约 0.9%

怎么读这张表：

git branch 是大赢家：我们远程分支六百多个，原始 git branch -a 接近 30KB；RTK 把 remote-only 收成 remote-only (652): + 少量样例，Agent 仍知道「远程很多」，但不会把 600+ 分支名全读进上下文。
git status 中等收益：去掉英文提示后，模型直接看到「改了 hf / ys 两个进件页」。这对「室内照片只能传一张」这类 UI 修复会话非常够用。
git diff 本次几乎不省：因为改动本身不大（两个 tsx、约百行级），压缩空间有限。大重构、全仓格式化时，diff 的 Save% 才会好看。
git status -sb 几乎不变：你本来就用短格式时，RTK 没有魔法可变------这也说明它不是「永远省 90%」。

6.3 输出长什么样

原始 git status 片段：

RTK 后：

原始 git branch -a：本地十几条 + remotes/origin 下列几百行。

RTK 后：本地分支列表 + remote-only (652): 再列一小段，后面省略。

这正好对应我们业务现实：活动页、进件、补贴、鸿蒙......历史分支极多。Agent 若每次 git branch -a 都吞全量，会话质量会肉眼可见地塌。

6.4 `rtk gain` 实况

在 H5 + Web 上多跑几轮后，本机看到类似：

text 复制代码

Total commands:    21
Input tokens:      42.1K
Output tokens:     5.4K
Tokens saved:      36.7K (87.3%)

By Command
1. rtk git branch     4次   省 34.2K   Avg 98.7%
2. rtk deps           1次   省 1.4K    Avg 91.6%
3. rtk git status     9次   省 543     Avg 62.8%
4. rtk git diff       2次   省 398     Avg 11.3%
5. rtk git log        5次   省 139     Avg 16.2%

解读给读者：

绝对省下来的大头在 git branch，不是 status。
deps 对 package.json 依赖摘要也很猛（我们 H5 依赖 70+，全量 list 很长）。
Save% 高 ≠ 每次都省出几万 token；要看命令频率和原始体积。

自己立刻可测：

bash 复制代码

# PowerShell 可改成测字符串长度
git status | Measure-Object -Character
rtk git status | Measure-Object -Character

或 Linux/macOS：

bash 复制代码

git status | wc -c
rtk git status | wc -c

07｜放进真实业务流：进件页怎么「配着 RTK 用」

这一节不是命令清单，而是我们改自主进件时，Agent 会怎么消耗上下文。

场景 A：修「室内照片传一张后又出上传框」

典型 Agent 路径：

git status → 确认动到了 ys/index.tsx / hf/index.tsx
git diff → 看 maxCount、renderImageUploader
可能再 git log → 看最近进件相关提交
改完再 status / diff 一轮

没有 RTK：每一步都带英文样板、远程分支噪音（若误跑 branch -a）。有 RTK：status 只剩两行路径；模型更不容易把「银商室内」和「汇付收银台+内景」搞混------汇付本来就是两个单图位，银商才是误设成 maxCount=2。

场景 B：Web 仓发版前「我在哪个分支」

easyhome-web-wolaicai 远程分支同样爆炸。人用 IDE 看分支还好，Agent 一旦 git branch -a，就是一次上下文炸弹。RTK 把 remote 收成计数，足够判断「别在错误的 release 分支上改」。

场景 C：依赖排查

rtk deps 把 package.json 收成「Dependencies (75) + 前几项 + more」，适合问「有没有某个 @dm 包」这类问题；若要完整 lockfile，再用 rtk proxy 或原始命令。

08｜命令手册

下面百分比多是 README/官经验值，不是账单保证；我们实测以第 06 节为准。

8.1 文件与搜索

bash 复制代码

rtk ls .
rtk read app.tsx
rtk read app.tsx -l aggressive
rtk smart file.rs
rtk find "*.tsx" src/
rtk grep "TODO" .
rtk diff file1 file2

8.2 Git / GitHub

bash 复制代码

rtk git status
rtk git log -n 10
rtk git diff
rtk git add .
rtk git commit -m "msg"
rtk git push
rtk git pull
rtk gh pr list
rtk gh pr view 42

8.3 测试 / 构建

bash 复制代码

rtk jest
rtk vitest
rtk test "npm test"
rtk tsc
rtk lint
rtk prettier --check .
rtk pnpm list
rtk deps
rtk err <任意命令>

8.4 全局开关

bash 复制代码

rtk -u git status    # --ultra-compact
rtk -v ...           # 更啰嗦，调试过滤时有用
rtk proxy <原命令>   # 几乎原样透传，但仍可统计

09｜看收益：gain / discover / session

bash 复制代码

rtk gain
rtk gain --graph
rtk gain --history
rtk gain --daily
rtk gain --all --format json

rtk discover
rtk discover --all --since 7

rtk session

怎么读 rtk gain：

列	含义
Input	过滤前估计 token（bytes/4）
Output	过滤后估计 token
Saved	二者之差
Save%	bash 输出字节减少比例（最值得看）

history 里 Save% = 0% 的命令 = 没有匹配过滤器、原样透传------这是以后提需求/写自定义 filter 的线索。

对我们：进件小 diff 的 Save% 低是正常的；不要因为「这次只省 3%」就觉得 RTK 没用------真正值钱的是高频大输出命令（branch、全绿测试、大 log）。

10｜配置：排除命令、失败留底

配置文件位置大致为：

Linux：~/.config/rtk/config.toml
macOS：~/Library/Application Support/rtk/config.toml
Windows：一般在用户配置目录下的 rtk/config.toml（以本机 rtk config 提示为准）

示例：

toml 复制代码

[hooks]
# 这些命令不要自动改写成 rtk（需要完整输出时）
exclude_commands = ["curl", "playwright"]

[tee]
enabled = true
mode = "failures"    # failures | always | never

失败时，Agent 可能看到类似：

text 复制代码

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

需要完整原文时，让 Agent 去读 tee 文件，比再跑一遍测试更省。

11｜推荐工作流

个人日常（Cursor / Claude Code）

安装 rtk，确认 rtk gain 正常（排除撞名包）
rtk init -g 与/或 rtk init -g --agent cursor → 重启
把 ~\.local\bin 放进用户 PATH（Windows 尤其重要）
正常写需求；抽查：裸 git status 是否已是压缩格式、rtk gain 是否涨次数
每周看一次 rtk gain、rtk discover
大文件：提示里写「优先分段读 / rtk read」，别整文件 Read

我们这类前端进件仓库

常跑：git status、git diff、git branch、偶发 tsc / eslint / 单测。

分支爆炸 → RTK 收益最大
小 UI 修复的 diff → 别期待夸张 Save%
商户进件 ys/hf 大文件 → 额外注意 Read 工具不走 hook

需要「完整输出」的任务

配置 exclude_commands
或 rtk proxy 原命令
或失败后读 tee 日志

12｜和其它工具怎么配着理解

工具	关系
Claude Code / Cursor / Codex	干活的人；RTK 是他们的「传话筒瘦身」
Graphify	把代码建成知识图谱；解决的是「结构导航」，不是命令输出胖
planning-with-files	把计划落到 md，防上下文腐烂；和 RTK 互补
Ralph	负责循环跑完；循环越长，RTK 越值钱
peon-ping	任务完成语音提醒；和 token 无关
ZCF	配 Claude Code 环境；装完再挂 RTK 更合适

不替代好的提示词、好的测试分层；它只解决「输出太胖」这一层。

13｜隐私与遥测

默认不采集；rtk init 时可显式同意才开匿名汇总
采集的是版本、OS、命令类别计数、估计节省等，不是源码、路径、参数、密钥

bash 复制代码

rtk telemetry status
rtk telemetry enable
rtk telemetry disable
rtk telemetry forget

export RTK_TELEMETRY_DISABLED=1   # 强制关

14｜卸载

bash 复制代码

rtk init -g --uninstall
rtk init -g --agent cursor --uninstall
brew uninstall rtk          # 若 brew 安装
# 或删掉 PATH 里的 rtk.exe / 二进制

15｜从 0 到稳定使用的检查清单

rtk --version + rtk gain 正常（排除撞名包）
rtk init -g（或 Cursor 等对应参数）成功，rtk init --show 能确认
用户 PATH 含 rtk 所在目录；Cursor 完全重启
Agent 跑裸 git status，输出明显短于原生命令，且 rtk gain 次数增加
跑一轮测试命令，全绿时输出是摘要、失败时仍看得到要点
知道 Read/Grep/Glob 要另想办法（rtk read 等）
需要完整日志时会用 tee 路径或 proxy
一周后看 rtk gain / discover，决定要不要加 exclude_commands
（可选）在自己最大的 monorepo 上专测一次 git branch -a------往往是最震撼的截图

16｜再展开：一次「自主进件」会话里，token 是怎么被吃掉的？

很多人装完 RTK 会问：「我平时也不跑 cargo test，有必要吗？」------把问题换成我们自己的业务，答案就清楚了。

假设你在 Cursor 里跟 Agent 说：「银商进件页室内照片只能传一张，传完别再出上传框。」这是一句很短的需求，但 Agent 为了把活干对，往往会自动跑一串命令。下面按「没有 RTK」粗估一遍（只算 shell 输出侧，不计你的提示词）：

第一次 git status：确认工作区是不是干净、当前分支对不对。原始输出带一堆英文提示，大约几百字节；我们实测约 377 字节。看起来不多，但一轮会话可能 status 五六次。
git branch 或 git branch -a：想确认有没有误切到 uat / prod_release。一旦带上 -a，我们 H5 仓轻松蹦出六百多个 remote，原始约 29KB。这一下就相当于把一篇短文塞进上下文，而有效信息其实只有：「我在 develop_selfDelivery_20260728」。
git diff：看 ys/index.tsx 里 maxCount 是不是写成了 2。小改动时省得少；但如果 Agent 为了「全面了解进件模块」又去 diff 别的文件，体积会很快涨。
可能的 git log：找「自主进件」相关提交。收益中等（我们约 22%），但连续多跑几次也会堆。
改完再 status / diff：验收。

把上面加起来：哪怕你完全不跑单测，只 git 一类命令，在「分支地狱」仓库里也能把窗口灌胖。RTK 对第 2 步几乎是降维打击（我们实测 Save% ≈ 98.5%）；对第 1 步则是稳定小赚（≈ 70%）。这就是为什么说「git 狂魔收益大」------不是口号，是仓库形态决定的。

再对比汇付页：室内照片在 UI 上是「收银台 + 内景」两个缩略图位，各自 maxCount=1。Agent 若上下文里还残留着银商「曾经 maxCount=2」的噪音日志，有时会把两套规则搅在一起。输出越干净，越不容易串台。这不是玄学，是注意力带宽问题。

17｜Windows + Cursor 踩坑实录

我们从安装到验证，踩过几个坑，读者很大概率也会遇到：

坑 1：以为装了 exe 就自动省 token

只把 rtk.exe 丢进 ~\.local\bin，Agent 仍跑裸 git status。必须执行：

bash 复制代码

rtk init -g --agent cursor --auto-patch

并确认 ~\.cursor\hooks.json 里有 rtk hook cursor。

坑 2：hooks.json 有了，但 gain 不涨

常见原因是 Cursor 进程找不到 rtk。临时在终端里 $env:PATH 加了目录没用------GUI 启动的 Cursor 读的是用户/系统 PATH。解决：把 C:\Users\你\.local\bin 写进用户环境变量，然后托盘里彻底退出 Cursor 再开。

我们验证失败过一次：裸 git status 仍是完整英文格式，Total commands 不变。修好 PATH 并重启后，同操作立刻变成压缩格式，次数 +1。

坑 3：演示脚本里的 `rtk ls` 报错

Windows 没有 Unix ls。截图请用 git status / git branch / rtk gain，别用 rtk ls，否则读者以为工具坏了。

坑 4：把 Save% 当成账单折扣

同事看 rtk gain 显示 87% 会兴奋：「是不是 Cursor 费用少 87%？」------要泼冷水：那是 bash 输出字节估算，不是发票。会话里还有系统提示、历史、模型输出。但若你每天 Agent 会话里一半注意力都在消化 git/测试输出，体感提升会非常明显。

坑 5：卸了又装、数据还在

rtk gain 的统计存在本机数据库/本地状态里。卸载二进制再装回来，历史次数可能还在（我们重装后仍看到此前累计）。写文章时注明「累计值」，避免读者以为「刚装就有 21 次」。

18｜什么时候不该迷信 RTK？

诚实边界，反而更能建立信任：

你几乎不用 Agent 跑 shell：全程手敲终端，RTK 对你个人零收益（对团队里用 Agent 的人仍有用）。
仓库极小、分支极少：git branch -a 只有三条时，省不下什么。
你需要完整原始输出做审计：例如要把完整 diff 贴进工单。用 exclude_commands 或 rtk proxy。
瓶颈在 Read 大文件：进件页两千行 tsx，Agent 用内置 Read 吞文件时，去优化提示词和阅读范围，比纠结 RTK 更要紧。
命令本身已经很短：git status -sb 我们只省 0.9%，别指望奇迹。

RTK 是「输出层瘦身」，不是「架构银弹」。它和 Graphify（结构图谱）、planning-with-files（任务计划落盘）、好的 code review 习惯，是不同层的东西。

19｜给团队推广时的三句话话术

如果你要在组里推（尤其前端组），别一上来甩官网 90%：

「它不替代 Cursor，只是让 Agent 少读废话。」
「我们仓库远程分支几百个，git branch -a 能少灌进两万多字节。」（用自己仓库测一遍更有说服力）
「装一次挂 hook，以后不用改提示词；不放心可以随时 uninstall。」

落地建议：先在一人机器 + 一个真实业务仓跑通验证清单，把 git status / git branch 前后截图丢到群里，比发十篇概念文有效。

20｜写给读者的结语

RTK 不会让模型突然「更懂业务」，也不会替你写好、不会自动把室内照片 maxCount 从 2 改成 1。它解决的是更土、但更真实的问题：Agent 每一轮对话里，被终端废话占掉的那部分注意力。

在我们这种「分支多、进件页文件大、一天要查很多次 git」的业务里，最值的不是某一个神奇百分比，而是：

少读几百个远程分支名
status 一眼看到 hf / ys
把上下文留给真正的业务推理：字段校验、上传上限、回显、渠道差异、法人证件叠图

装一次，挂上 hook，然后就可以几乎忘掉它------直到你某天打开 rtk gain，才发现这周又默默少灌进去好几万「假 token」。

若你只记住一件事：先跑 rtk --version 和 rtk gain 确认没装错包，再 rtk init 并重启 Agent，最后用自己仓库的 git branch -a 做一张前后对比图。那张图，往往比任何形容词都管用。

作者：洞窝-长炜

你的 Coding Agent 不是不够聪明，是被 git status 和测试日志淹死了｜RTK 实战指南

01｜为什么 Agent 会「淹死」在终端里？

02｜它到底省什么？（避免被「省 90%」误导）

03｜工作原理

04｜安装（macOS / Linux / Windows）

4.1 macOS / Linux

4.2 Windows（原生）

4.3 Windows + WSL

05｜接上 Agent：一劳永逸的 rtk init

5.1 推荐流程（以 Claude Code / Cursor 为例）

5.2 各工具怎么 init

5.3 我们在 Cursor 上怎么验证「真的生效了」

5.4 必看限制：内置 Read / Grep / Glob

06｜前后对比（官方示例 + 我们仓库实测）

6.1 仓库与场景

6.2 H5 进件仓：字节级对比

6.3 输出长什么样

6.4 rtk gain 实况

07｜放进真实业务流：进件页怎么「配着 RTK 用」

场景 A：修「室内照片传一张后又出上传框」

场景 B：Web 仓发版前「我在哪个分支」

场景 C：依赖排查

08｜命令手册

8.1 文件与搜索

8.2 Git / GitHub

8.3 测试 / 构建

8.4 全局开关

09｜看收益：gain / discover / session

10｜配置：排除命令、失败留底

11｜推荐工作流

个人日常（Cursor / Claude Code）

我们这类前端进件仓库

需要「完整输出」的任务

12｜和其它工具怎么配着理解

13｜隐私与遥测

14｜卸载

15｜从 0 到稳定使用的检查清单

16｜再展开：一次「自主进件」会话里，token 是怎么被吃掉的？

17｜Windows + Cursor 踩坑实录

坑 1：以为装了 exe 就自动省 token

坑 2：hooks.json 有了，但 gain 不涨

坑 3：演示脚本里的 rtk ls 报错

坑 4：把 Save% 当成账单折扣

坑 5：卸了又装、数据还在

18｜什么时候不该迷信 RTK？

19｜给团队推广时的三句话话术

20｜写给读者的结语

05｜接上 Agent：一劳永逸的 `rtk init`

6.4 `rtk gain` 实况

坑 3：演示脚本里的 `rtk ls` 报错