Headroom vs RTK vs lean-ctx：AI 编码 Agent 的上下文压缩工具对比

> 来源：三个项目的 README 与官方文档 > Headroom：https://github.com/chopratejas/headroom (15.8k ⭐) > RTK：https://github.com/rtk-ai/rtk (5.8k ⭐) > lean-ctx：https://github.com/yvgude/lean-ctx (1.8k ⭐) > 关系：三者本地优先、Apache 开源，能叠着用

---

一、问题：Agent 的上下文在燃烧

用 Claude Code、Cursor、Codex 写代码时，你有没有算过账？

一个中等规模的 TypeScript 项目，Agent 30 分钟能干掉 11.8 万 token。

git status 跑 10 次 → 3,000 token
cat 读文件 20 次 → 40,000 token
cargo test 跑 5 次 → 25,000 token
grep 搜索 8 次 → 16,000 token
再加上 RAG 结果、日志输出、历史对话……

这些输出里，80% 是噪音。git status 的 "Enumerating objects" 进度条、cargo test 通过的绿色对勾、Docker 的 ASCII 进度条——Agent 不需要看这些，但它被迫读。

上下文压缩工具就是来解决这个问题的：在 Agent 读到之前，先把噪音删掉。

---

二、一张表看懂三者差异

维度	RTK	Headroom	lean-ctx
压什么	CLI 命令输出（git/status/test/ls/docker…）	一切：工具输出、日志、RAG、文件、历史对话	文件读取、命令输出、MCP 工具结果、整个上下文生命周期
怎么接入	Shell hook（自动重写 `git status` → `rtk git status`）	库/代理/MCP 三种模式：`compress()`、proxy、MCP server	MCP server + Shell hook，69 个工具
是否本地	✅ 单二进制、零依赖	✅ 本地运行，数据不出机器	✅ 本地优先，无默认遥测
是否可还原	❌ 压缩后原文丢弃	✅ CCR 可逆压缩，原文存本地，按需取回	✅ 原文存档，支持 `ctx_expand` 取回
额外能力	无	跨 Agent 共享内存、`headroom learn` 挖掘失败会话	会话记忆、知识图谱、代码图、多 Agent 协作
架构	单 Rust 二进制，命令级过滤	Python/Rust 混合，pipeline 架构（Router + Compressor）	Rust 二进制，认知上下文层（4 维：压缩/路由/记忆/验证）
开销	<10ms	与代理延迟同级	未公开，但含 AST 解析等重操作
开源协议	Apache 2.0	Apache 2.0	Apache 2.0

---

三、RTK：命令行代理的"速溶咖啡"

定位：单二进制、零依赖、<10ms 开销的命令行过滤器。

3.1 压什么

只压 CLI 命令输出。100+ 支持的命令：

Git：git status → 1 行 "ok main"（从 15 行 ~200 token → 1 行 ~10 token）
测试：cargo test → 只显示失败项（从 200+ 行 → ~20 行）
文件：ls -la → 树形摘要（从 45 行 → 12 行）
Docker：docker ps → 紧凑列表
AWS：aws ec2 describe-instances → 精简实例列表（自动脱敏）

3.2 怎么接入

最优雅的方式：Shell hook。

rtk init -g  # 安装 hook，自动重写所有 bash 命令

之后 Agent 调用 git status，hook 在 Agent 不知情的情况下把它改成 rtk git status。Agent 收到的是压缩后的输出，完全透明。

支持 14 个 AI 工具：Claude Code、Cursor、Codex、Gemini CLI、Windsurf、Aider、Copilot……

3.3 是否本地

✅ 单 Rust 二进制，~10MB，零依赖。编译一次，到处运行。

3.4 是否可还原

❌ 不可还原。压缩后的输出直接替代原文，原始输出被丢弃。如果压缩过度导致信息丢失，只能重新执行命令。

不过 RTK 有个补救设计：rtk tee 模式，失败时保存原始输出到 ~/.local/share/rtk/tee/，供 LLM 按需读取。

---

四、Headroom：Agent 的"上下文压缩层"

定位：比 RTK 更大，压 Agent 读到的一切，60%–95% 压缩且答案不变。

4.1 压什么

全部上下文：

工具输出（git status、cargo test……）
日志流（docker logs、kubectl logs）
RAG 检索结果
文件内容（读取的整个文件）
历史对话

不只是命令输出，而是 Agent 上下文窗口里的所有内容。

4.2 怎么接入

三种模式，覆盖所有场景：

模式	用法	场景
Library	`compress(messages, model=...)`	自己写的 Python/TypeScript 应用
Proxy	`headroom proxy --port 8787`	零代码改动，任何语言
Agent Wrap	`headroom wrap claude`	一键包装已有 Agent
MCP Server	`headroom_compress`、`headroom_retrieve`	任何 MCP 客户端

4.3 核心机制：6 种压缩算法

Agent 输出 → ContentRouter → 选择压缩器
              ├─ SmartCrusher（JSON）
              ├─ CodeCompressor（AST）
              └─ Kompress-base（文本，HF 模型）

SmartCrusher：通用 JSON 压缩，数组去重、字段裁剪
CodeCompressor：AST 感知，保留结构、压缩实现体
Kompress-base：基于 HuggingFace 模型，针对 agentic trace 训练
CacheAligner：稳定前缀，让 Anthropic/OpenAI 的 KV cache 真正命中

4.4 是否可还原：CCR（Contextual Compression with Retrieval）

✅ 可还原。这是 Headroom 区别于 RTK 的核心设计。

压缩时，原文存在本地。LLM 如果意识到信息不够，可以通过 headroom_retrieve 工具按需取回原始内容。不是盲目压缩，而是压缩 + 检索的闭环。

4.5 额外能力

跨 Agent 共享内存：Claude、Codex、Gemini 共用同一个压缩后的上下文存储
headroom learn：挖掘失败会话，自动写入 CLAUDE.md / AGENTS.md 的修正规则

---

五、lean-ctx：认知上下文层

定位：不是压缩工具，而是认知上下文层——管理 Agent 与代码之间的全部 token 流。

5.1 压什么

文件读取 + 命令输出 + MCP 工具结果 + 整个上下文生命周期。

5.2 怎么接入

两种模式：

Hybrid（MCP + Shell hook）：MCP 处理文件读取缓存，Shell hook 压缩命令输出
MCP-only：69 个 ctx_* 工具，纯协议接入

支持 24+ 个 Agent：Cursor、Claude Code、Codex、Gemini、Windsurf、Copilot、Aider、JetBrains、VS Code、Zed、Neovim……

5.3 核心设计：四维度

维度	能力	示例
压缩	10 种读取模式、56 个 shell 压缩模块、Tree-sitter AST	`full` → `map` → `signatures` → `lines:N-M`
路由	自适应 `ModePredictor`，根据文件类型和查询复杂度选择最佳模式	简单查询用 `signatures`，复杂查询用 `full`
记忆	会话记忆（CCP）跨 chat 持久、知识图谱、代码属性图	`lean-ctx overview` 恢复任务状态
验证	4 层验证引擎、CI 漂移门、上下文审计账本	`ctx_proof`、`ctx_verify`

5.4 是否可还原

✅ 可还原。ctx_expand 按需取回原始内容。lean-ctx savings 是完整的审计账本，SHA-256 链验证，本地-only。

5.5 额外能力（远超压缩）

知识图谱：代码、测试、提交、CI 运行、知识条目统一在属性图中
代码影响分析：lean-ctx graph impact src/auth.rs 看修改爆炸半径
多 Agent 协作：ctx_agent 注册角色 + ctx_handoff 上下文传递
PR Context Pack：lean-ctx pack --pr 自动生成 PR 就绪的上下文包
LSP 重构：通过 rust-analyzer/tsserver/pylsp 做代码重构

---

六、三者关系：不是对手，是积木

这是最有意思的部分。

Headroom 的 README 里明确写了：

> Attribution. Headroom ships with the excellent RTK binary for shell-output rewriting — git show --short, scoped ls, summarized installers. Huge thanks to the RTK team; their tool is a first-class part of our stack, and Headroom compresses everything downstream of it.

翻译：Headroom 直接把 RTK 的二进制打包进来，作为 shell 输出压缩的第一道过滤。 RTK 处理命令行，Headroom 处理命令行之后的其他内容（RAG、文件、日志）。

Headroom 还可以配置：

> Headroom can also use lean-ctx as the selected CLI context tool; set HEADROOM_CONTEXT_TOOL=lean-ctx before running headroom wrap ....

翻译：Headroom 可以把 lean-ctx 当成底层 CLI 上下文工具。

所以三者的关系是：

Agent 调用命令
    ↓
RTK（第一道过滤：git status → 1 行）
    ↓
Headroom（第二道过滤：RAG、文件、日志、历史）
    ↓
lean-ctx（认知层：路由、记忆、图谱、验证）
    ↓
LLM 收到干净、结构化、有上下文的输入

或者更简单的视角：

RTK = 过滤器（命令输出）
Headroom = 压缩层（全部上下文）
lean-ctx = 认知层（压缩 + 路由 + 记忆 + 验证）

三者都是 本地优先、Apache 开源，不存在竞争关系，而是能力递进。

---

七、怎么选？

如果你只想要一个最轻量的起点

→ RTK

理由：单二进制、零依赖、10 分钟配置好、立刻省 80% token。不可还原是小代价，但 tee 模式能救急。

适合：个人开发者、快速尝鲜、不想改工作流。

如果你需要压缩一切 + 可还原 + 跨 Agent 共享

→ Headroom

理由：覆盖全部上下文类型（不只是命令），CCR 可还原避免信息丢失，跨 Agent 共享内存，还有 headroom learn 自动总结失败模式。

适合：团队、多 Agent 协作、需要可审计和可还原的生产环境。

如果你要管理整个 Agent 的认知生命周期

→ lean-ctx

理由：不只是压缩，而是上下文工程。记忆跨 chat 持久、代码图谱做影响分析、多 Agent 协作、PR 上下文包、审计账本。69 个 MCP 工具意味着几乎无限的可扩展性。

适合：复杂项目、多 Agent 团队、需要上下文治理和知识管理的企业级场景。

如果你想要"全都要"

→ RTK + Headroom + lean-ctx 叠着用

Headroom 已经帮你内置了 RTK，你只需再配置 HEADROOM_CONTEXT_TOOL=lean-ctx。这样：

RTK 处理命令行
Headroom 处理其他上下文压缩
lean-ctx 提供认知层、记忆、图谱

三者协同，token 省到极限，上下文管理到极限。

---

八、数据对比

8.1 RTK：30 分钟会话

操作	频率	标准 token	RTK token	节省
`ls` / `tree`	10x	2,000	400	80%
`cat` / `read`	20x	40,000	12,000	70%
`git status`	10x	3,000	600	80%
`cargo test`	5x	25,000	2,500	90%
总计		~118,000	~23,900	80%

8.2 Headroom：真实工作负载

工作负载	压缩前	压缩后	节省
代码搜索（100 结果）	17,765	1,408	92%
SRE 故障排查	65,694	5,118	92%
GitHub issue 分类	54,174	14,761	73%
代码库探索	78,502	41,254	47%

8.3 lean-ctx：压缩率区间

Shell 输出：60-99% 压缩
文件重读缓存：~13 token（vs 首次读取数百~数千）
10 种读取模式按需选择，AST 签名模式可压到原始大小的 5-10%

8.4 准确率保留

三者都声称答案不变：

Headroom：GSM8K 0.870→0.870（±0）、TruthfulQA +0.03、SQuAD 97% 保留（19% 压缩）
RTK：基于启发式规则（过滤/分组/截断/去重），无 ML 模型，确定性输出
lean-ctx：模式选择可配置，激进模式可能影响准确率，但默认保守

---

九、一个有趣的观察

这三个项目有一个共同点：它们都在解决同一个问题的不同层次。

RTK 解决"命令输出太啰嗦"
Headroom 解决"整个上下文窗口太满"
lean-ctx 解决"Agent 没有记忆和认知"

它们的流行（15.8k + 5.8k + 1.8k = 23.4k stars，而且都是 2026 年的新项目）说明了一件事：

> AI 编码 Agent 的上下文效率，已经成为一个独立的技术领域。

不是模型的能力问题，是系统架构问题。同样的模型，用 RTK 省 80% token，用 Headroom 加 CCR 保证不丢信息，用 lean-ctx 让 Agent 记住昨天聊过什么——效果差距巨大。

这有点像一个没有索引的数据库。你当然可以每次都全表扫描，但有了索引（压缩层）和缓存（记忆层），同样的算力能做 10 倍的事。

---

十、结论

工具	一句话定位	最佳场景
RTK	命令输出的速溶过滤器	个人、快速、零配置
Headroom	全上下文压缩层	团队、多 Agent、可还原需求
lean-ctx	认知上下文层	复杂项目、企业级、上下文治理

三者叠用：RTK → Headroom → lean-ctx，构成一个完整的 Agent 上下文优化栈。

---

参考来源

chopratejas/headroom README, GitHub, 2026
rtk-ai/rtk README, GitHub, 2026
yvgude/lean-ctx README, GitHub, 2026

#Headroom #RTK #lean-ctx #AI编码 #上下文压缩 #Agent #ClaudeCode #Cursor #Codex #MCP #token优化 #开源工具 #Rust #Python

Headroom vs RTK vs lean-ctx：AI 编码 Agent 的上下文压缩工具对比

Headroom vs RTK vs lean-ctx：AI 编码 Agent 的上下文压缩工具对比

一、问题：Agent 的上下文在燃烧

二、一张表看懂三者差异

三、RTK：命令行代理的"速溶咖啡"

3.1 压什么

3.2 怎么接入

3.3 是否本地

3.4 是否可还原

四、Headroom：Agent 的"上下文压缩层"

4.1 压什么

4.2 怎么接入

4.3 核心机制：6 种压缩算法

4.4 是否可还原：CCR（Contextual Compression with Retrieval）

4.5 额外能力

五、lean-ctx：认知上下文层

5.1 压什么

5.2 怎么接入

5.3 核心设计：四维度

5.4 是否可还原

5.5 额外能力（远超压缩）

六、三者关系：不是对手，是积木

七、怎么选？

如果你只想要一个最轻量的起点

如果你需要压缩一切 + 可还原 + 跨 Agent 共享

如果你要管理整个 Agent 的认知生命周期

如果你想要"全都要"

八、数据对比

8.1 RTK：30 分钟会话

8.2 Headroom：真实工作负载

8.3 lean-ctx：压缩率区间

8.4 准确率保留

九、一个有趣的观察

十、结论

🌟 智谱 GLM-5 已上线