別再把 Token 節省當魔法：Caveman 用可恢復壓縮替 AI Coding Agent 瘦身

先講結論

Caveman 不是另一個 coding agent，而是一層放在既有 agent 與模型供應商之間的本機工具。它把「減少 token」拆成兩條不同路徑：用 skill 讓 agent 少寫一點贅詞，或用 Engine 與 local proxy 壓縮 agent 反覆送進模型的 logs、JSON、diff、HTML、搜尋結果與工具輸出。

真正值得注意的不是「把文字變短」本身，而是它把壓縮設計成可回復的資料管線：先把可能遺失資訊的原始 bytes 存進 Caveman Context Recovery（CCR），再把較小的表示與 recovery handle 交給模型；解析失敗、結果沒有變小、CCR 寫入失敗或安全條件不明時，就退回原文。

這個設計讓 Caveman 比單純的 prompt 技巧更像一個 context middleware。不過，它也不是無條件省錢工具：官方文件明確承認 skill 會增加輸入 token、HTML benchmark 可能退步、local estimate 不是帳單數字，而且本機 CCR 可能保存敏感原文。

Caveman 解決的是哪一段成本？

一個長時間工作的 AI coding agent，通常會重複把幾類內容送回模型：測試輸出、編譯器錯誤、JSON、git diff、搜尋結果、工具 schema、瀏覽器 accessibility tree，以及先前對話留下的 context。這些資料不一定需要逐 byte 保留在模型可見內容裡，但又不能只靠粗暴截斷。

Caveman 的產品模型把系統拆成數層：

Skill、hooks、plugins： 影響 agent 的輸出風格，保留程式碼、命令、識別字與技術細節。
CLI： 安裝元件、啟動 agent、管理本機命令與整合。
Engine： 判斷輸入類型、選擇 compressor、計算估計 token，並保存 recovery data。
Local proxy： 透過 loopback 接住 provider request，把選定的 input transform 套上去，再轉送給原本的模型供應商。
MCP、memory、browser、shrink： 把恢復、長輸出、瀏覽器結構與本機記憶做成 agent 可使用的工具。
SDK： 讓應用程式直接接上 context assembly、provider routing、tracing 與 eval 能力。

這種分層的好處是可以只採用最小必要路徑。只想讓回答少一點贅詞，可以只裝 skill；需要處理長 logs 與工具輸出，才啟用 local runtime；要把自己的應用程式接進去，則改用 SDK 或 provider base URL。

兩條路徑：縮短回答，或縮短輸入

1. Response skill：讓 agent 少說廢話

Caveman skill 是一份會被 agent 載入的規則，要求它縮短常見的冗餘表達，並在較強的模式下允許片段式回答。它不應改寫程式碼、錯誤訊息、命令、路徑或安全警告。

這條路徑的優點是安裝成本低，也不需要把 request 經過代理。不過規則本身會佔用 input token，所以短問題可能反而變貴。官方 HONEST-NUMBERS.md 也指出，skill 並不壓縮 context 或 model thinking tokens；是否有淨節省，必須用同一任務的 provider usage 做 A/B 比較。

2. Engine + proxy：讓 agent 少讀重複資料

第二條路徑才是 Caveman 的核心工程。Engine 會先做 detection，再把資料送給對應的 compressor。官方目前列出的自動辨識類型包含 JSON、terminal output、diff、HTML、tabular data、source code、logs、search results、configuration text 與一般文字；TOON、accessibility tree 與 tool-schema 等較特殊的 transform 則不是一般 detection 自動選擇。

Local proxy 透過 base URL 或環境設定包住既有 agent，並不取代 agent loop。它可為 Claude Code、Codex、Gemini CLI、Aider、Hermes、OpenClaw、opencode 等目標建立 launch profile，也能讓 Anthropic、OpenAI、Google Gen AI、Vercel AI SDK、LangChain、LiteLLM、CrewAI、Pydantic AI 與 OpenAI Agents SDK 等應用使用整合配方。

最重要的設計：壓縮必須可恢復

Caveman Engine 的 pipeline 可以簡化成以下流程：

輸入 bytes
  ↓
Detect：判斷資料形狀
  ↓
Select：選擇 compressor
  ↓
Transform：產生較小表示
  ↓
是否更小且通過安全檢查？──否──→ 傳回原始 bytes
  ↓ 是
是否需要 recovery？──否──→ 輸出 compact bytes
  ↓ 是
把完整原始 bytes 寫入 CCR
  ↓
寫入成功？──否──→ 傳回原始 bytes
  ↓ 是
輸出 compact bytes + recovery handle

這裡有幾個實務上很重要的判斷：

變小不是唯一條件。 解析錯誤、未知 mode、沒有合適 compressor 或輸出反而更大，都會 pass-through。
Lossy output 要先保存原文。 如果 recovery store 不存在或寫入失敗，就不應把壓縮結果交給模型。
Handle 不是品質保證。 它只能讓 agent 在需要時取回原始資料，不能保證模型一定會主動要求缺失內容。
失敗不應偽造成功。 Proxy 的 transform failure 會保持原始 provider traffic，而不是回傳一個看似成功的假結果。

Engine 文件把 Compress、Retrieve、Detect、Stats 列為穩定核心操作，另外提供不提交正常 runtime side effect 的 Simulate。壓縮器本身是純 byte transform，網路、儲存與 token accounting 由 Engine 外層控制，這讓失敗邊界比較容易測試與審查。

從 CLI 到 MCP：不只是一個 proxy

Caveman 的 CLI 主要操作可以分成幾類：

caveman claude                 # 持續啟用整合並啟動 agent
caveman wrap codex             # 單次、暫時性的 wrapped session
caveman tools compress < input.txt
caveman tools retrieve <handle>
caveman tools shrink -- go test ./...
caveman tools mem remember "project uses PostgreSQL"
caveman tools mem recall "database"
caveman tools browse https://example.com "pricing"

其中值得分開看的是三個本機工具：

MCP server： 提供 compress、retrieve、stats、TOON encode、TOON decode 等工具。Agent 何時呼叫由 host 決定，權限應限制在必要範圍。
Cavemem： 以 SQLite 保存 durable facts，使用本機 BM25 做 recall；它是持久化記憶，不是模型訓練，資料也可能過時或錯誤。
Browser bridge： 透過 Chrome DevTools Protocol 取得 accessibility tree，按查詢過濾後回傳元素 reference，必要時仍可 recovery 原始內容。它能 click 或執行 JavaScript，因此 read 與 write 權限必須分開管理。

Output shrinker 則是很直接的入口：把測試、編譯或搜尋的長輸出送進 shrinker，保留錯誤類型、exit status、重要路徑與 recovery handle。文件特別提醒，不能用「只剩一段摘要」取代完整 debugging context。

Benchmark 應該怎麼讀？

Caveman 的 WRAP-BENCHMARK.md 報告一組固定的 agent-shaped tool-output workload：六種 fixture、每個 arm 三次、總共 18 組 direct/Caveman pairs。文件報告 Caveman 端使用 591,673 個 provider-reported input tokens，直接使用 Claude Code 則為 885,793，並且兩邊都是 18/18 exact-answer checks 通過。

這個結果可以支持一個窄化的結論：在該版本、該 provider、該固定 fixture 與該 recovery 方法下，Caveman 對這組大型工具輸入有明顯 input reduction。它不能直接推導成所有 coding session 都會省相同比例，原因包括：

benchmark 是固定的大型工具輸出，不是開放式實際專案。
dashboard HTML 是負面案例，壓縮沒有生效時連 skill overhead 都算進去，結果反而增加 9.9%。
公開 repository 有報告與 provenance hash，但沒有一併提供原始 harness 與 run artifacts，因此文件自己把它標成 pinned report，而不是從 checkout 即可獨立重現的 benchmark。
Engine 本機 token 數通常是 inferred，來自 offline tokenizer 或 fallback estimate，不等於 provider invoice。

這種把負面結果、品質 gate、測量 basis 與不可重現邊界一起寫出的方式，比只放一個「省了 X%」更值得參考。使用者真正應該做的是在自己的 workload 上跑同一任務、同一模型、同一 provider，對照帳單或 provider usage，再決定是否保留某個 transform。

安全與隱私：本機不等於沒有資料風險

Caveman 的本機層不需要 Caveman account，但 request 仍會送到你選定的模型 provider。更重要的是，CCR 會保存可恢復的完整原文；官方安全文件指出，這些內容可能包含 prompts、credentials embedded in content 與 tool results，應把 ~/.caveman/ccr.db 視為敏感資料。

還有幾個部署前必看的邊界：

Standalone proxy 預設綁定 127.0.0.1:8787，loopback 模式接受所有 inbound request；不要把它暴露到 LAN、container bridge 或 public interface。
Shared deployment 需要 CAVEMAN_AUTH_TOKEN，並應放在 private network、在前方終止 TLS；健康檢查與 metrics endpoint 仍可能未驗證。
SSRF protection 預設封鎖 private、loopback、link-local 等不安全目的地；若需要 self-hosted provider，應設定精確的 CAVE_SSRF_ALLOWLIST，不要開過大的網段。
CLI anonymous telemetry 預設開啟，但第一次互動命令會顯示揭露；可用 caveman telemetry off 或 DO_NOT_TRACK=1 關閉。官方列出的 telemetry 是無內容的使用事件與 token aggregate，不包含 prompt、completion body、檔案路徑或 provider credentials。
Browser bridge 可執行 JavaScript、click、表單提交甚至可能觸發購買；它不應被當成單純的 read-only scraper。

因此，部署 Caveman 的思考方式應接近「安裝 coding agent 或本機 proxy」，而不是把它當作無風險的文字格式化工具。

安裝與使用建議

官方 README 提供 skill-only 與 runtime 兩種入口。實際採用時，可以按這個順序降低風險：

先閱讀 pinned release 的 INSTALL.md、SECURITY.md 與 license 邊界，不要直接把未審查的遠端安裝腳本 pipe 進 shell。
只想測試回答風格時，先採用 skill path，並用短任務與長任務各做一次 A/B。
要啟用 runtime 時，先用 caveman setup 檢查元件，再從單一 agent 的 caveman wrap <agent> 開始，不要一開始就改動所有全域整合。
在敏感專案中確認 ~/.caveman/ 的權限、CCR retention 與 telemetry 設定；不要把 secrets 寫進 YAML、benchmark fixture、prompt 或 command history。
先使用 record/pass-through mode 驗證既有流程，再逐一開啟 JSON、logs、diff 或 browser 等 transform。
用 provider-reported usage 與品質結果驗證，若自己的 workload 變差，直接停用該路徑。

License 與採用範圍

這個 repository 不是單一 license。Skill、CLI、SDK 與部分 adoption surface 採 MIT；Engine、proxy、rewriter、browser、MCP、shrink、Cavemem Go core 與 shared platform 等 Engine-linked 元件採 BSL-1.1，並有 first-party self-hosted production 的 Additional Use Grant。若你要把 Engine-linked 功能提供給第三方服務，必須先讀 LICENSING.md 與對應的 BSL 條款。

這個區分會直接影響架構選擇：個人或團隊內部自架，和把壓縮 runtime 包進對外提供的 SaaS，並不是同一種授權情境。文章可以介紹它的設計，但不能把整個 repository 簡化成「MIT 開源 proxy」。

結語：值得研究，但先量自己的資料

Caveman 最有價值的地方，不是把 AI agent 變成更會講電報文，而是把 context compression 做成一個有 detection、recovery、fail-safe、usage basis 與 evidence labels 的本機系統。它讓「壓縮」從 prompt trick 變成可以被拆解、測量與停用的 middleware。

但它的正確使用方式也很清楚：從最小 layer 開始，保留原始資料的復原能力，分清 inferred estimate 與 provider usage，完整評估本機 CCR、telemetry、SSRF、browser permission 與 license 邊界，最後用自己的 coding workload 做 A/B。

如果你的 agent 大量反覆閱讀 logs、JSON、diff 與測試輸出，Caveman 是值得深入研究的實作；如果你的工作主要是短問答、按 request 計費，或每個輸入 byte 都必須直接可見，先不要假設它會帶來淨收益。