LLM 代理層的成本控制：從 token 計數到架構選擇
rtk 用本地代理層減少 LLM 調用的 token 消耗，核心不在模型選擇，而在工程設計如何避免重複計算。
問題在哪
用 LLM 做開發工具輔助時，最容易被忽視的成本不是 API 調用本身，而是重複的上下文傳輸。一個簡單的代碼補全請求，往往會把整個文件、依賴樹、甚至編譯錯誤信息都塞進 prompt。同一個信息被發送多次，token 被浪費得很徹底。
rtk 這個項目的核心想法很直接：在本地做一層代理，把重複的請求去重、壓縮、或直接用本地計算替代。根據他們的數據，能減少 60-90% 的 token 消耗。這個實現方式值得看。
架構的選擇
他們選擇用 Rust 寫，編譯成單個二進制，零依賴。這個決定反映了一個很清楚的優先級：部署簡單性優先於開發速度。
對於 CLI 工具來說，這很務實。用戶不需要裝 Node、Python、或任何運行時。下載一個文件就能用。維護成本也低，沒有依賴意味著沒有版本地獄，沒有安全補丁的連鎖反應。
但這也意味著開發時的靈活性被犧牲了。如果需要快速迭代或接入複雜的 LLM 生態工具，Rust 的學習曲線和編譯時間會是瓶頸。他們選擇了對用戶友好而非開發者友好的一邊。
token 減少的實際機制
60-90% 這個數字看起來很激進，但可能的。常見的優化包括：
- 請求去重：同一個文件在短時間內被查詢多次，只發送一次
- 增量更新：只傳輸改變的部分，而不是整個上下文
- 本地快取：編譯結果、依賴樹、類型信息可以本地存儲，不需要每次都讓 LLM 推斷
- 智能截斷：根據 token 預算自動裁剪不重要的上下文
這些都不複雜，但組合起來效果很明顯。在開發循環中，開發者通常會問類似的問題——「這個函數簽名是什麼」「為什麼這裡報錯」——LLM 不需要每次都從零開始推理。
現實的限制
單個 Rust 二進制的方案有個隱藏的成本：難以跨平台維護。Windows、macOS、Linux 各自需要編譯版本。更新時用戶需要手動替換。這對個人工具不是問題，但如果要做成企業級的東西，會變成運維負擔。
代理層的效果完全依賴於它能看到多少信息。如果 IDE 或編輯器不提供足夠的上下文接口，代理層就只能猜測。集成的深度決定了優化空間的大小。
值得思考的地方
這個項目提醒了一個被忽視的事實：LLM 的成本瓶頸常常不在模型本身，而在工程實現。一個設計得當的代理層，比選擇更便宜的模型更能降低成本。
但 60-90% 的數字也容易被過度解讀。實際效果取決於你的使用模式。如果你用 LLM 做一次性的複雜任務，代理層的作用有限。如果你用它做重複的、增量的開發輔助，收益會很明顯。
未來的 LLM 工具鏈可能不是更大的模型，而是更聰明的本地代理。簡單的去重、快取、格式轉換放在本地，複雜的推理才發送到 API。成本和延遲都會改善。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。