RTK：給 AI 編程代理省 token 的命令列代理工具

Wed, 27 May 2026 13:52:01 +0800

rtk-ai/rtk 是一個面向 AI 編程代理的命令列代理工具。它的思路很直接：很多 agent 在開發過程中會頻繁呼叫 ls、cat、grep、git status、git diff、測試命令和建置命令，而這些命令的原始輸出經常又長又重複。RTK 會在命令輸出進入 LLM 上下文之前先做過濾和壓縮，讓模型看到更短、更有用的結果。

專案地址：rtk-ai/rtk

它解決的是什麼問題

AI 編程工具真正貴的不只是模型呼叫次數，還有上下文裡被塞進去的無效資訊。

例如：

ls -la 可能輸出大量權限、時間和無關檔案。
git diff 可能夾雜很多重複上下文。
pytest、cargo test、npm test 失敗時，最重要的是失敗用例和錯誤堆疊，而不是所有通過項。
docker ps、kubectl pods、aws 命令往往欄位很多，但 agent 只需要少數關鍵資訊。

這些輸出如果原樣進入模型上下文，會快速消耗 token。RTK 的目標不是替代這些命令，而是在它們和 AI 編程代理之間加一層「壓縮代理」。

RTK 的基本工作方式

RTK README 裡給出的定位是：它會在命令輸出到達 LLM context 之前，對結果做過濾和壓縮。它是一個 Rust 單檔二進位程式，支援大量常見開發命令，並強調低額外開銷。

它主要做四類處理：

Smart Filtering：去掉註解、空白、樣板內容和低價值雜訊。
Grouping：把相似項目聚合起來，例如按目錄、錯誤類型或狀態分組。
Truncation：保留關鍵上下文，截斷重複或不重要的部分。
Deduplication：把重複日誌折疊成更短的計數表達。

從 agent 的角度看，命令仍然是熟悉的開發命令；變化在於返回給模型的結果更短。

支援哪些命令

RTK 覆蓋的命令範圍比較偏「日常開發現場」：

檔案查看：rtk ls、rtk read、rtk find、rtk grep
Git：rtk git status、rtk git log、rtk git diff
GitHub CLI：rtk gh pr list、rtk gh pr view、rtk gh issue list
測試命令：rtk pytest、rtk go test、rtk cargo test、rtk vitest、rtk playwright test
建置和 lint：rtk lint、rtk tsc、rtk next build、rtk cargo clippy
容器和雲命令：rtk docker ps、rtk docker logs、rtk kubectl pods、rtk aws sts get-caller-identity
資料和日誌：rtk json、rtk deps、rtk env、rtk log

這類工具最適合 agent 高頻讀命令輸出的場景。它不負責替你寫程式碼，而是讓 agent 少讀雜訊。

安裝和接入方式

README 給了幾種安裝方式。

Homebrew：

`1`	`brew install rtk`

Linux/macOS 快速安裝：

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

Cargo：

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

安裝後可以先檢查版本和統計資訊：

1
2

rtk --version
rtk gain

接入 AI 編程工具時，可以用初始化命令：

rtk init -g
rtk init -g --gemini
rtk init -g --codex
rtk init -g --agent cursor
rtk init --agent windsurf
rtk init --agent cline

初始化後需要重啟對應的 AI 工具。對於支援 hook 的 agent，Bash 命令會在執行前被重寫，例如把 git status 變成 rtk git status，讓 agent 收到壓縮後的輸出。

使用時要注意什麼

RTK 的收益取決於 agent 是否真的透過 shell 命令讀取資訊。

README 裡特別提醒：像 Claude Code 的內建 Read、Grep、Glob 這類工具不經過 Bash hook，因此不會自動被 RTK 改寫。要讓 RTK 介入，需要使用 shell 命令，例如 cat、head、tail、rg、grep、find，或者直接呼叫 rtk read、rtk grep、rtk find。

這點很關鍵。RTK 不是全域透明地壓縮所有 agent I/O，它更像是 shell 命令層面的代理。

Windows 使用者也要注意，README 建議不要直接雙擊 rtk.exe，而是把它放到 PATH 裡，透過 Command Prompt、PowerShell 或 Windows Terminal 使用。它也提到，如果想獲得完整 hook 體驗，WSL 會更自然。

適合誰用

RTK 適合三類人：

重度 AI 編程使用者：每天讓 agent 跑很多 git、rg、測試和建置命令。
大倉庫使用者：命令輸出動輒幾百行，agent 經常被無關上下文淹沒。
關心 token 成本和上下文窗口的人：希望模型把注意力放在失敗、變更和關鍵檔案上。

如果你的專案很小，或者 agent 主要透過 IDE 內建工具讀取檔案，RTK 的體感收益可能沒那麼明顯。它真正發力的地方，是命令列輸出又長又頻繁的開發流。

我的判斷

RTK 的方向很實用。現在很多 AI 編程工作流都在強調更強的模型、更大的上下文、更長的任務，但開發現場還有一個樸素問題：agent 經常讀了太多沒必要讀的東西。

把命令輸出先壓縮，再交給模型，能減少 token 消耗，也能降低模型被雜訊帶偏的機率。

不過它不是魔法開關。要用好 RTK，需要把 agent 的工作方式往 shell 命令靠一靠，並確認目前工具的 hook 是否真的生效。對 Codex、Claude Code、Gemini CLI、Cursor、Windsurf 這類場景來說，它更像一個值得測試的「上下文節流器」：不改變開發命令本身，但讓 agent 讀到更乾淨的結果。

RTK on KnightLi的博客