rtk：把智慧體讀到的命令輸出砍掉六到九成的 Rust 單二進位制代理

過去一年，編碼智慧體的使用方式發生了一個不太顯眼的變化：模型花在讀取上的 token，已經遠遠多於它寫出來的 token。每當智慧體執行一條 shell 命令，不管是執行測試、檢視 git 狀態、列出目錄，還是編譯一箇中等規模的工程，命令的全部輸出都會原樣塞進上下文視窗。一次完整的構建日誌動輒幾千行，其中真正影響下一步決策的可能只有寥寥幾行。剩下的內容既要按 token 計費，又會稀釋模型的注意力，還會讓上下文更快逼近上限，迫使系統提前做摘要或截斷。rtk 正是針對這個被長期忽視的浪費點而生。它是 rtk-ai 團隊開源的一個命令列代理，專案口號很直白：高效能的 CLI 代理，最多可以砍掉智慧體所讀 bash 輸出的九成。

從定位上看，rtk 並不是又一個智慧體框架，也不是又一個模型閘道器，而是一個夾在智慧體與 shell 命令之間的薄層。智慧體原本直接呼叫命令並讀取標準輸出，接入 rtk 之後，同樣的命令先經過代理，代理執行命令，再對輸出做過濾和壓縮，最後把精簡後的結果交給模型。專案標題給出的數字是 60% 到 90% 的 token 削減，README 中的說法則是最多約 90%。需要說明的是，這是專案方自己的表述，具體比例取決於命令型別：重複性強、噪聲多的輸出，例如依賴安裝日誌、冗長的測試進度條，可壓縮空間自然更大；而本來就簡短的輸出幾乎沒有可壓縮的餘量。讀者不應把區間的上限當作平均值。 在工程實現上，選擇 Rust 和單一二進位制有很強的現實理由。智慧體的迴圈裡，命令呼叫的頻率很高，一次任務可能觸發幾十甚至上百次。如果代理本身依賴直譯器或龐大的執行時，每次呼叫的啟動延遲都會累積成可感知的等待，還會帶來環境依賴的麻煩。一個沒有外部依賴的原生可執行檔案，啟動開銷低，部署時只需放進路徑即可，也方便在容器、持續整合機器和開發者筆記本之間保持一致。專案目前提供 Homebrew 包，採用 Apache-2.0 許可證，並設有持續整合的安全檢查徽章，README 還提供了英文、法文、中文、日文、韓文、西班牙文和葡萄牙文七種語言的版本，說明維護者很重視面向全球開發者的觸達。這些都是低調但有價值的工程訊號。

然而，任何壓縮都意味著資訊取捨，這一點必須直面。對人類讀者來說，漏掉一行警告往往無傷大雅；對智慧體來說，漏掉一行關鍵報錯，可能意味著它沿著錯誤的假設繼續工作，白白消耗更多輪次，最終比不壓縮時更貴。因此評估 rtk 這類工具，不能只看 token 削減了多少，而要看任務成功率有沒有下降。一個合理的評估辦法是：選取團隊真實的任務集，分別在有無代理的條件下各跑若干次，記錄完成率、總輪次和總 token，再看節省是否真的轉化為更低的單任務成本。對於失敗路徑尤其要核查：編譯錯誤、斷言失敗、堆疊資訊、退出碼，這些內容應當被完整保留，而不是被當作噪聲丟掉。同時，團隊應當保留一條繞過代理、讀取原始輸出的通道，以便在智慧體陷入困惑時回退。

還有一個容易被忽略的維度是可觀測性。當代理介入之後，團隊需要知道它到底丟掉了什麼，否則出了問題很難覆盤。理想的做法是讓每次壓縮都留下可查詢的痕跡，例如記錄原始輸出的長度、壓縮後的長度，以及被摺疊的片段數量，必要時能夠把原始內容還原出來對照。這樣一來，token 節省不再是一個黑箱數字，而是可以被審計、被持續調優的工程指標。對於需要合規留痕的企業環境，原始輸出是否仍被完整儲存在本地，同樣是採用前必須問清楚的問題。 把視角拉遠一些，rtk 反映的是上下文工程正在從提示詞層下沉到工具層。前兩年，行業的注意力主要放在提示壓縮、快取複用和檢索篩選上；而隨著智慧體變成長時間執行的迴圈，工具返回值成為上下文的主要來源，在工具邊界上做裁剪，往往比事後摘要更便宜、更可控。它與提示快取並不衝突：快取降低的是重複字首的單價，而代理減少的是進入字首的總量，兩者可以疊加。它也提醒我們，成本最佳化不一定要靠更小的模型，有時只需要讓模型少讀一些沒用的東西。

當然，我們也要保持克制。截至本文撰寫時，rtk 的具體過濾規則、對各類命令的適配範圍，以及那組 60% 到 90% 的資料是在怎樣的基準下得出的，都應以倉庫中的文件和你自己的實測為準。我們沒有獨立復現這些數字，因此不建議把它們直接寫進預算。對於正在大量使用編碼智慧體的團隊，務實的做法是：先在非關鍵專案裡試用，統計一週的 token 賬單與任務成功率，再決定是否推廣。若資料支援，它是一個以很小代價換取明顯成本下降的工具；若資料不支援，也至少幫助你看清了自己的智慧體究竟把錢花在了哪裡。