RTK：把 AI coding agent 的命令列噪音壓縮成可用上下文

我在使用 AI coding agent 時，最常遇到的問題不一定是模型不夠聰明，而是它被大量「看似有用、實際上很吵」的命令列輸出淹沒。git diff、測試 runner、find、grep、套件清單、Docker 日誌和雲端 CLI 都可能一次吐出幾百行內容。這些文字會進入 agent 的上下文，增加閱讀成本，也讓真正重要的錯誤更難被看見。

RTK（Rust Token Killer）採用一個很直接的想法：不要先改模型，也不要要求每個 agent 自己學會摘要，而是在 shell 指令與 agent 之間放一個 CLI proxy。RTK 執行原本的命令，依命令類型過濾、分組、截斷與去重，再把較短的結果交還給 agent。它是單一 Rust binary，官方 README 宣稱支援超過 100 個常見命令，proxy 額外開銷低於 10ms。

這篇文章不把 RTK 寫成「安裝後帳單立刻少九成」的神奇工具。我會先拆解它到底壓縮了什麼，再用幾個實際工作流程說明如何導入，最後討論它的限制、驗證方式，以及什麼情況不應該開啟自動重寫。

先釐清：RTK 節省的是 bash 輸出，不是帳單

RTK 最容易被誤解的地方，是把「最多削減 90% 的 bash output」直接等同於「最多省 90% 的 token 費用」。官方文件特別把這兩件事分開，這也是我認為它值得被正確理解的地方。

一個 agent session 的 input tokens 通常包含使用者提示、system prompt、對話歷史，以及 shell command 回傳的內容。RTK 只控制最後一項，而且只處理有對應 filter 的命令。即使某個 git diff 被壓縮了 90%，整個 session 的 input tokens 仍可能有其他來源；模型輸出的 token 也完全不在 RTK 的控制範圍內。

RTK 的 gain 指令會用 bytes / 4 估算 token。這個估算器沒有嵌入任何特定模型的 tokenizer，因此絕對數字不應視為供應商帳單上的精確值。相對地，原始輸出與壓縮輸出使用同一個估算方式，所以 reduction ratio 仍然有參考價值。換句話說，Save% 比「saved tokens 的絕對數字」更值得用來比較導入前後的差異。

這個界線很重要：RTK 是上下文噪音管理工具，也可能間接降低 input token 使用量；它不是計費系統、不是模型壓縮器，也不會減少 agent 寫出的文字。

RTK 實際做了什麼

RTK 不是把所有輸出一律截成前幾行。它依不同命令選擇不同的壓縮策略，盡量保留 agent 做決策需要的訊號。

ls 與 tree 會以樹狀結構和檔案計數呈現目錄，而不是逐檔印出冗長清單。
cat 與 read 可以保留檔案簽名與結構，並依讀取層級減少不必要的函式本體。
grep 與 rg 會按檔案聚合匹配結果，處理過長的行。
git status、git log 和 git diff 會留下狀態、摘要、作者、標題與必要差異，去掉重複的格式噪音。
測試命令如 pytest、cargo test、go test、jest 和 vitest 以失敗項目為主，成功項目折疊成計數。
lint 與型別檢查會按規則、檔案或錯誤類型分組，避免相同問題以大量重複行出現。
Docker、Kubernetes、AWS、Pulumi 等命令則只保留操作判斷所需要的欄位，並在適用時把重複日誌去重。

從官方架構文件來看，它的核心策略可以整理成五類：統計抽取、只保留錯誤、依模式分組、重複資料去除，以及只保留結構。這比單純設定一個全域字數上限更合理，因為「保留什麼」取決於命令的語意。

例如，一個測試套件有 800 行成功訊息和 3 行失敗訊息時，agent 真正需要的是失敗測試、錯誤訊息和必要 traceback；一個 git status 則通常需要知道哪些檔案新增、修改或未追蹤，不需要每個內部格式欄位都重複一次。

架構上的關鍵：先執行，再過濾，再追蹤

RTK 的命令生命週期可以簡化成六個階段：解析參數、路由到命令模組、執行原始命令、套用 filter、列印結果，最後把原始與壓縮結果寫入本機歷史資料庫。

它不只輸出摘要，也保留 exit code。這點對 CI/CD 和 agent 的工具呼叫很關鍵：如果測試真的失敗，壓縮器不能把失敗變成成功；如果 filter 自己出錯，官方架構設計是回退到原始輸出，而不是讓資訊整段消失。使用者也可以透過 -v、-vv、-vvv 逐步提高 verbosity，在需要除錯時查看執行命令、原始輸出或 filter 細節。

RTK 的資料追蹤放在本機 SQLite history database，並以估算的 input、output、saved 和 savings percentage 產生 rtk gain 儀表板。這讓導入不必只靠感覺：你可以先在幾個專案跑一段時間，再觀察哪些命令真的產生高比例壓縮，哪些命令幾乎沒有收益。

實作一：先安裝，再用明確命令驗證

我建議先不要一開始就改寫所有 agent 的 shell hook。先把 RTK 當成普通 CLI，確認它對你的專案輸出是否仍然保留足夠資訊。

1. 安裝

macOS 可以使用 Homebrew：

brew install rtk

Linux 或 macOS 也可以使用官方快速安裝腳本。這個腳本會從 GitHub release 下載對應平台的 binary，並驗證 checksums.txt；如果 checksum 取不到，預設會拒絕安裝未驗證的 binary：

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 gain

2. 以三種輸出做基準

不要只測一個 git status。我會選一個檔案很多的目錄、一個差異較大的 branch，以及一個測試會產生大量成功訊息的專案：

rtk ls .
rtk git diff
rtk test <你的測試命令>

比較的不是「畫面看起來短不短」而已，而是 agent 是否仍能回答三個問題：有哪些檔案受影響？真正的錯誤在哪裡？下一步應該執行什麼？如果壓縮後無法回答，就要提高 verbosity 或改用原始命令。

實作二：讓 agent 自動套用 RTK

確認直接執行結果符合預期後，再啟用整合。README 提供多個 agent 入口，包含 Claude Code、Gemini CLI、Codex、Cursor、Windsurf、Cline、Roo Code、Kilo Code、Google Antigravity、Kimi AI、Pi、Hermes 與 Factory Droid。

以全域初始化為例：

rtk init -g
rtk init -g --gemini
rtk init -g --codex

特定 agent 則可指定 adapter：

rtk init -g --agent cursor
rtk init --agent cline
rtk init --agent hermes

Hook-based agent 會在命令執行前把 git status 改寫成 rtk git status。部分 plugin-based agent 則透過 plugin API 進行改寫，因此 agent 不需要在每次呼叫中手動輸入 rtk。初始化後重啟你的 agent，再執行一個可觀察的命令，例如：

git status

接著用 rtk gain --history 檢查是否有紀錄。若完全沒有資料，先不要急著判定 filter 沒有作用，因為不同 agent 的 hook 只攔截特定工具路徑；官方文件也提醒，某些內建的 Read、Grep、Glob 工具不會經過 Bash hook。這種情況可以改用 shell 命令，或直接明確呼叫 rtk read、rtk grep 和 rtk find。

實作三：建立團隊自己的安全導入方式

自動重寫最方便，但不是所有專案都適合無條件啟用。我會把導入分成三層。

第一層是觀察模式。先直接使用 rtk 命令，搭配 rtk gain --history 和 rtk discover 找出高噪音、高收益的命令。這一層不改 agent 行為，適合評估格式是否會隱藏重要資訊。

第二層是受控整合。只對本機開發 agent 或特定專案啟用 hook，保留 -v 旗標與原始命令作為退路。測試、部署、資料庫 migration 這類高風險操作，應先確認 exit code、stderr 和必要的摘要都能被保留。

第三層才是團隊預設。把初始化步驟、可接受的例外命令和排查方式寫進開發環境文件，不要只在某個人的 shell profile 裡偷偷啟用。對 agent 而言，「相同命令在不同開發者機器上輸出格式不同」會增加除錯成本，所以團隊需要先決定哪些輸出壓縮是標準行為。

什麼情況不應該直接使用

RTK 的目標是減少冗餘，不是取代原始輸出。以下場景我會保守處理：

第一次診斷未知工具。 如果 RTK 沒有對該命令提供專用 filter，輸出可能原樣通過；如果有 filter，也應先用 verbosity 比對。
需要完整 diff 或完整 log 的稽核。 壓縮摘要適合讓 agent 做下一步判斷，不適合當作唯一的稽核證據。
輸出本身就是資料。 例如 JSON payload、API 回應、schema 或需要逐欄位比對的設定檔，使用結構摘要可能會移除你真正要檢查的值。
安全敏感的執行。 任何會刪除資源、變更雲端權限或執行 migration 的命令，都應保留原始輸出與明確人工確認。
Filter 造成語意損失。 如果 agent 開始頻繁要求重跑原始命令，代表壓縮策略可能沒有對準工作流程，不要只追求更高的 Save%。

我特別不建議把 RTK 的 Save% 當成唯一 KPI。高壓縮率可能代表輸出很冗餘，也可能代表重要細節被丟掉。真正的驗收標準應是：agent 能否更快找到錯誤、是否減少重跑命令、是否保留正確 exit code，以及團隊是否更容易理解發生了什麼。

我會怎麼評估它

RTK 的價值不在於它「會摘要」，而在於它把 agent 上下文中的一個具體瓶頸放到 shell proxy 層解決。對大量使用測試、lint、git 和基礎設施 CLI 的團隊，這個切入點很務實：不必更換模型，不必改寫每個 prompt，也不必讓每個 agent 都重新實作輸出解析器。

但它仍然是一個有策略判斷的壓縮層。命令輸出不只是文字，還包含上下文、順序、退出狀態與偶爾很重要的細節。我的建議是先用明確命令建立基準，再對高頻工作流逐步啟用 hook；遇到不確定的結果，優先使用 -v 或原始命令驗證，而不是盲目相信摘要。

如果你的主要痛點是 agent 花大量時間閱讀 git diff、測試成功訊息、搜尋結果和重複日誌，RTK 值得放進工具箱。如果你的瓶頸是過長的 system prompt、對話歷史、模型輸出或資料庫查詢本身，那就不是 RTK 能單獨解決的問題。

結論：把上下文當成工程資源管理

AI coding agent 的效率，不只由模型能力決定，也由它每次收到多少雜訊決定。RTK 用單一 Rust CLI proxy 對 shell 輸出做命令感知的壓縮，並用本機歷史資料讓使用者觀察實際收益。它最值得借鑑的地方，是沒有把「省 token」包裝成不加條件的帳單承諾，而是清楚說明真正控制的範圍：bash output。

我會把 RTK 視為上下文治理的一個低侵入入口。先手動測試，再受控啟用，最後以錯誤可見性與工作流可靠性驗收。只要記住摘要不是證據、Save% 不是帳單、原始命令永遠應該可回退，這類 proxy 就能在不更換模型的前提下，讓 agent 更快看到真正需要處理的訊息。

參考資料