---
slug: headroom-caveman-rtk-token-compression-layer
title: Headroom、Caveman、RTK：三種 LLM 省 token 工具的分工、原理與公開效果
status: published
excerpt: Headroom 壓上下文，Caveman 壓回答口氣，RTK 壓 shell 與工具輸出。這篇把三者的用法、節省方式、原理 and 公開社群回饋整理在一起。
category: AI
tags: [headroom, caveman, rtk, token-compression, llm, agents]
author: Seer
author_role: Author
read_time: 11 min
cover: "/static/headroom-caveman-rtk-token-compression-layer-cover.png"
closing_note: "在極致壓縮的縫隙裡，大模型才真正學會了如何沉默。"
published_at: "2026-06-19T17:28:20Z"
updated_at: "2026-07-01T15:54:39Z"
---

你用 Claude Code 跑了幾次測試，或者開 Cursor 掃了幾遍 codebase，一轉頭發現今天的大模型額度已經被扣了快一半。在 Agent 開發時代，token 就是真金白銀，如何把上下文壓榨到極致，成了每個人都在想的課題。

這三個工具都在講「省 token」，但它們省的層次其實不一樣：
- **Headroom**：壓 *整個上下文層*。
- **Caveman**：壓 *Agent 說話方式*。
- **RTK**：壓 *shell / 工具輸出*。

如果把複數 Agent 工作流拆成三層，它們剛好各站一層：
1. **你送進模型之前的上下文**
2. **模型回你時的文字風格**
3. **模型看見的命令結果**

這篇直接把三者重新對齊，順便看公開社群裡大家實際踩坑後回報的效果。

## 先講結論

如果你要的是完整工作流，最合理的配置通常是：
- **Headroom** 當主幹：管上下文壓縮與回取。
- **RTK** 當工具層：管命令輸出壓縮。
- **Caveman** 當表達層：管回覆語氣與冗字。

三者不是完全互斥，而是補不同洞。

---

## Headroom：壓上下文，不是只壓摘要

**Repo**：`chopratejas/headroom`

Headroom 的定位很明確：它是 Agent 的 **context compression layer**。README 直接把它描述成「在 LLM 看見之前先壓縮」的中介層，目標是讓同樣的 request 用更少 token 完成。

### 主要用法

你可以用 library 方式直接嵌入程式，或是啟動一個 proxy：

```bash
headroom proxy --port 8787
```
這行指令會在本機啟動一個 proxy 伺服器，監聽 8787 埠號。你只要把原本打 API 的 endpoint 改指向這裡，它就能在 request 送出前自動幫你做 token 壓縮。

你也可以用 wrap 方式直接包住現有的 Agent 工具：

```bash
headroom wrap claude
```
這個命令會包裝指定的 CLI 工具（例如 Claude Code）。當工具對外發送請求時，Headroom 會在中途攔截並壓縮 context，對你的開發流程完全透明。

### 節省方式

Headroom 的壓縮不是單一路徑，而是分流：
- **ContentRouter**：先判斷內容類型。
- **SmartCrusher**：壓 JSON。
- **CodeCompressor**：壓程式碼 AST。
- **Kompress-base**：壓一般文字。
- **CacheAligner**：穩定前綴，讓 provider cache 更容易命中。
- **CCR**：保留原始內容，需要時可回取。

### 原理

它的重點不是把字變短而已，而是把內容當成不同資料型態處理：JSON 就用 JSON 壓法，code 就用 code 壓法，prose 就用文字壓法，而且壓完後還保留原文以利還原。這比較像 **LLM 基礎設施層**，不是單純摘要器。

### 官方效果

README 的公開 benchmark 主打：
- **60–95% fewer tokens**
- code search：**92%**
- SRE incident debugging：**92%**
- GitHub issue triage：**73%**
- codebase exploration：**47%**

它的賣點很完整：壓 prompt、壓 tool output、壓 RAG chunk、壓 file，還能留回取路徑。

---

## Caveman：壓回答口氣，不壓腦袋

**Repo**：`juliusbrussee/caveman`

Caveman 的核心不是壓工具輸出，而是讓 Agent **講話變短**。它是一個給 Claude Code、Windsurf 等 Agent 用的 skill，目標是把回覆從「完整解釋」壓成「高密度短句」。

### 主要用法

你可以直接在對話裡下指令切換模式：

```bash
/caveman ultra
```
這是 Caveman 的斜線指令，切換到極致壓縮模式。它會直接叫 Agent 用最精簡的電報體回覆，省去所有冗長的寒暄和解釋。

你也可以針對特定的 memory 檔案進行壓縮：

```bash
/caveman-compress memory.md
```
這會叫 Caveman 去掃描並重寫指定的 Markdown 檔案。它會把檔案內重複、囉唆的句子過濾掉，但保留所有的核心程式碼與系統狀態。

### 節省方式

Caveman 的壓縮方式比較像「文風壓縮」：
- 刪 filler。
- 刪寒暄。
- 刪重述。
- 保留關鍵結論。
- 保留 code / path / error string。
- 盡量用更短語法說同一件事。

它甚至強調：語言本身不變、內容不變，變的是冗詞與口氣。換句話說，它不是要模型變笨，而是要模型少廢話。

### 原理

Caveman 比較像一個 **輸出風格控制器**：你給的是普通自然語言任務，它把 Agent 的回答風格往更短、更碎、更像電報的方向推，對 code / command / path 類資訊則盡量不動。

### 官方效果

README 的公開說法是：
- 平均約 **65% output reduction**。
- `caveman-compress` 對 memory files 的平均壓縮約 **46%**。

README 裡也有很直觀的 before/after：同一個技術解釋，句子可以從十幾行縮成兩三句。

### 公開社群回饋

但公開世界不是只有官方數字。GitHub issue **#251** 就是個很直接的例子：
- 使用者在問：**能不能看 token savings statistics？**
- 背景是：兩個小任務就燒掉了約 **35% 的 5 小時 token limit**。

這代表 Caveman 的實際效果，至少在某些人手上，未必有 README 那麼漂亮。所以 Caveman 的結論比較像：風格壓縮很有效，但是否真的省到你想像的程度，要看任務類型 and 原始 prompt 密度。

---

## RTK：壓 shell 與工具輸出

**Repo**：`rtk-ai/rtk`

RTK 的定位很像命令列世界的 token optimizer。它的重點不是改模型怎麼講話，而是把 **command output** 先縮過，再送進 LLM context。

### 主要用法

首先需要在專案目錄下進行初始化：

```bash
rtk init --agent hermes
```
這會初始化 RTK 並指定對應的 Agent。它會偷偷在你的 shell 加上 hook，之後只要跑 CLI 指令，輸出的 log 就會先被過濾壓縮後才送給 LLM。

接著你可以像平常一樣下指令，它會自動被 hook 攔截：

```bash
rtk git status
```
這是透過 RTK 包裝後的 Git 指令。它會把 `git status` 吐出來的冗長文字重新整理，只留下真正被修改的檔案路徑，減少模型閱讀不必要資訊的負擔。

### 節省方式

RTK 在 README 裡列得很清楚，主要靠四招：
1. **Smart Filtering**：去噪音、去 boilerplate。
2. **Grouping**：把同類項合併。
3. **Truncation**：保留關鍵上下文。
4. **Deduplication**：重複行折疊成計數。

它最常壓的就是這種東西：`ls`、`git status`、`git diff`、`pytest`、`docker ps`。

### 原理

RTK 更像 **shell proxy / hook layer**：Agent 下命令，RTK 攔到命令與輸出，先做重寫與裁切，再把精簡版送回模型。所以它壓的是 **工具結果的體積**，不是 prompt 本身，也不是 model 回答風格。

### 官方效果

RTK README 的 30 分鐘 Claude Code session 範例宣稱：
- 總體約 **80% savings**。
- 很多常見命令有 **-70% 到 -90%** 的省量。

但這裡要特別看公開反例。GitHub issue **#2001** 直接說：
- 在 41 個 shell commands、5 個 repo 的測試裡，平均 savings 只剩 **+0.2%（Sonnet）**、**+2.7%（Opus）**，幾乎是噪音。

另外 issue **#2299** 還指出：
- `rtk discover` 可能把 hook rewrite 的命令算成 missed savings，代表它的量測系統本身也可能失真。

所以 RTK 的判讀要保守一點：方向是對的，工具層壓縮很實用，但實際節省高度依賴你的 command 型態與工作流。

---

## 三者怎麼分工

可以直接這樣記：

### Headroom = 上下文中介層
- 壓入模之前的資料。
- 管 JSON / code / text。
- 重點是可逆、可回取、可路由。

### Caveman = 回覆風格層
- 壓模型怎麼講。
- 讓回答更短、更像人腦掃讀版。
- 重點是少廢話，不是少資訊。

### RTK = 命令輸出層
- 壓 shell / CLI / test output。
- 讓工具結果更乾淨。
- 重點是少垃圾行、少重複、少噪音。

---

## 如果要一起用

我會這樣配：
- **Headroom** 放最外層，先處理上下文。
- **RTK** 放工具層，先壓 command output。
- **Caveman** 放表達層，讓回答收斂。

這樣的分層比較合理，因為每個工具都管不同東西：Headroom 管「輸入長什麼樣」，RTK 管「工具回來長什麼樣」，Caveman 管「模型最後怎麼說」。如果三個一起用，最怕的是把資訊壓過頭，導致 debug 的細節消失。

## 來源

- [Headroom](https://github.com/chopratejas/headroom)
- [Caveman](https://github.com/juliusbrussee/caveman)
- [RTK](https://github.com/rtk-ai/rtk)
- Caveman issue [#251](https://github.com/JuliusBrussee/caveman/issues/251)
- RTK issue [#2001](https://github.com/rtk-ai/rtk/issues/2001)
- RTK issue [#2299](https://github.com/rtk-ai/rtk/issues/2299)