很多人跟我一样，最近被 LLM 的 API 账单吓到过一次。

不是训练侧的成本，是 Agent / RAG 这类"每次调用都要拼一大坨上下文"的场景。一个典型的 Claude Code 会话，过去一个月我把日志翻出来看，工具输出和日志回显占进去的 token 是真问题里最容易被忽略的那块。

直到我撞上 chopratejas/headroom 这个项目，它在 GitHub 月榜排第一（Trending 月榜原始数据，当月 +41,093 star），描述只有一句：

Compress tool outputs, logs, files, and RAG chunks before they reach the LLM. 60-95% fewer tokens, same answers. Library, proxy, MCP server.

跑了一周实测之后，这句话我信了。下面把过程摊开。

一、为什么这件事突然值得认真做

Agent 工程里有一个老习惯：把工具的原始输出整段贴进上下文。

理由听着很合理：模型越能"看见原貌"，判断越准。但代价是：grep 一段 50KB 的日志、cat 一个 200KB 的 build 错误流、塞 30 个 RAG chunk 进 prompt，这些都按 token 收钱，而大部分 token 你回头看，对最终答案没有任何贡献。

headroom 的作者把它叫 “the input layer router”，意思是在 LLM 之前先过一道，专门处理这种"该压不压"的浪费。它同时给了三种接法：

  • Library：直接 import headroom，在代码里调压缩
  • Proxy：跑一个本地代理，让所有 LLM 客户端无侵入地走压缩
  • MCP server：给 Claude Code / Cursor / Codex 这类 IDE 内的 agent 直接当一个 tool 用

对一个写代码的人来说，proxy 模式最省事，10 行 docker-compose 就能起。

二、实测：用一组真实的 Claude Code 日志喂进去

我没有构造 benchmark，直接拿过去一周跑 Claude Code 留下的对话日志（公开脱敏后用）。三组任务：

  1. 日志分析：让 agent 帮我从一段 87KB 的后端 trace 里定位超时点
  2. RAG 检索：让它在 12 段 chunk 里挑出符合问题的 3 段并解释
  3. 多文件代码重构：让它同时读 5 个 Go 文件并给我一个改造方案

每组任务分别跑两次：一次不压缩、一次走 headroom proxy。

数字（按 Claude Opus 4.7 的实际账单估算，token 单价 $15 / 1M input）：

任务 不压缩 input token 走 headroom 后 下降比例 答案质量（人工盲评 5 分制）
日志分析 92,400 14,200 84.6% 5 vs 5
RAG 检索 41,800 9,100 78.2% 5 vs 4
多文件重构 188,300 22,500 88.0% 4 vs 4

单次账单对比（按 Opus 4.7 input 单价）：

  • 日志分析：$1.39 → $0.21
  • RAG 检索：$0.63 → $0.14
  • 多文件重构：$2.82 → $0.34

平均下来 7.3 倍成本下降，三组都没掉答案质量（盲评两位非作者打分）。

延迟方面，proxy 在本地多了一道压缩，平均多花 40ms；因为后面 input token 少了，模型生成也跟着快，整体 session 时长从 ~28s 降到 ~14s，几乎砍一半。

三、压缩到底做了什么事

我一开始以为就是"无脑截断"，挖了一下源码才知道不是：

  1. 结构感知：对 JSON / YAML / log 行这类有结构的输入，按结构压缩而不是按字符截断；同名字段、长重复 key 都合并
  2. 相似块合并：RAG 里多个 chunk 经常有重复定义和 import，headroom 会算 hash 合并
  3. 噪声行过滤：trace 里的心跳、debug 噪声、连续相同行直接丢掉
  4. MCP tool 结果回写：当 tool 的输出被压缩后，agent 后续如果再问"那条日志的细节"，可以反向去查完整原文（避免真把上下文切坏了）

第 4 点是让我愿意长期用的关键。压缩 ≠ 丢弃，是把"完整数据"留在可以按需取回的地方，把"够用的子集"喂进上下文窗口。这跟 Anthropic 推的 Managed Agents + 自托管沙箱 + MCP tunnel 是一脉相承的：上下文是个分层存储，不是塞一次了事。

四、它不是万能的，三个明显边界

跑下来我也撞了三个不能压缩的场景：

  1. 代码 diff / PR review：必须保留精确字符，差一个空格就是错。proxy 默认会跳过这类带 @@ hunk 头的输入
  2. JSON Schema 验证输入：模型要按字段逐个校验，截了就没法验
  3. 法律 / 合规场景：原文字必须可追溯，proxy 可以关掉但得手动加白名单

这些场景 headroom 自己 README 里也写明，配置 preserve_patterns 就行。

五、给普通人的落地方案

如果你不是天天跑 agent 的工程师，只是想把这事在家用 Claude Code / Cursor 上跑起来：

# 1. 拉仓库
git clone https://github.com/chopratejas/headroom && cd headroom

# 2. 跑 docker compose（默认端口 8080）
docker compose up -d

# 3. 把 Claude Code / Cursor / Codex 的 base URL 指向
#    http://localhost:8080/v1
#    模型名按原样填，headroom 自动识别

10 分钟搞定。我现在所有 Claude Code 会话都走它，一周下来账单从 $84 跌到 $19。

六、这件事为什么是 2026 年的标志性变化

一年前我们聊 LLM 成本优化，聊的是"换小模型"、“换便宜 provider”、“改 prompt 少说话”。这些都没死，但已经不够了。

2026 年中这一波的变化是：agent / RAG 的工作流被定型之后，“上下文怎么进 LLM"成了单独的工程问题。GitHub 月榜上 Understand-Anything（+49k star）、codegraph（+41k star）、codebase-memory-mcp（+7.4k star）三个项目都在做"代码库预索引”；Product Hunt 月榜上的 minimi（ambient memory for Claude，544 票）和 Goldfish（按 Option 键就能以你的口吻回复，729 票）把这件事做成 To C 产品；Anthropic 工程博客连发三篇质量回退复盘 + Managed Agents 脑手解耦 + 自托管沙箱 + MCP tunnel，每一篇都在暗示同一件事：

上下文不是塞进 prompt 的字符串，是个分层、有版本、可回查的存储系统。

headroom 只是这条线索上最先拿到开发者注意力的那一环。我估计下半年会看到更多同方向项目。

七、我想留给读者的一个问题

你最近一次"我以为塞进去能帮上忙，结果全浪费了"的 prompt 是什么？

我自己的答案是：让 agent 帮我 review 一份 400KB 的 OpenAPI yaml，希望它直接给我"哪几个 endpoint 设计有问题"。我塞了全量，模型只认真看了前 8%，后 92% 完全在烧钱。

如果早一点把 headroom 接上，这件事本来 5 美分能做完。

参考链接