2026年9月16日 · 阅读 —

AI 越用越贵还越用越慢，问题出在你把冗余和关键一起喂进去了

Agent 与 Skills知识与内容工具

AI 越用越贵还越用越慢，问题出在你把冗余和关键一起喂进去了

跑 Agent 跑到后期，你会撞上一堵墙。

不是模型不够聪明，是 token 账单长得太快。

让 Agent 去搜代码库，它读回十万 token 的工具输出；让它排查线上事故，它把一整段日志倒进上下文；让它在一个长会话里干一整天，历史越积越厚。

每一次都是钱，而且都是整份复制——上下文里塞满重复的样板、成片的相似 JSON、日志里挨着的同构行。

上下文一大，模型还变慢、变笨。

很多人第一个反应是：换个便宜的模型，或者干脆把上下文长度砍了。

这是治标。

问题的形状其实是另一个：你喂进去的 token 里，绝大部分是冗余，一小部分是关键，而现成的工具大多不知道怎么把这两者分开。

把冗余和关键一起砍，模型会丢掉 FATAL 错误行——这叫丢信息换省钱，是自杀式压缩。把冗余单独剔掉、关键逐字保留——这才叫工程。

这就是 headroom 想干的活。

它给自己的定位：AI Agent 的上下文压缩层。

Agent 读的一切——工具输出、日志、RAG 检索块、文件、历史对话——在到 LLM 之前先过一遍压缩。同一个答案，几分之一的 token。

关键一条：**压缩在本地跑，你的 prompt 和文件内容不会被发到任何地方去做压缩。**它不是云服务，不是”把你的上下文发给我们”，是你电脑上跑的一个本地层。就贴在你的 Agent 和数据之间。

开源，仓库在 headroomlabs-ai/headroom，Apache 2.0。热度能看出来，Trendshift 拿过 #1 Repository Of The Day。

拆开”压缩”这个词，难点从来不在把字删少。真难的是分辨什么是冗余、什么是关键。

Headroom 绕开了很多方案踩的坑——不用关键词列表来挑保留哪些。

关键词规则一看就懂，一用就崩。以为”FATAL、ERROR 要保留”，结果正经的 JSON 数据里，最关键的往往是那条超出统计范围的异常记录，它既不叫 FATAL 也不叫 ERROR。

它换了个思路，用数据驱动做选择：不看名字，看统计。

分析字段的方差，把”错误项、偏离正常统计范围的值、首尾边界”这些统计上不寻常的东西挑出来保留。为什么？一条日志里真正承载信息的，恰恰是那些不像其他行的行——FATAL 行在成片 INFO 里显得突兀，唯独它要留着。

这个判断我认同，而且觉得是整套设计的底色：压缩要保护的，不是”看起来重要的”，是”统计上稀有的、承载了增量信息的那一部分”。

压缩器它不搞一把刀通吃所有格式，按类型路由：

  • SmartCrusher——通用 JSON。数组、嵌套对象、混合类型都行，靠字段方差统计挑，不靠关键词。
  • CodeCompressor——源代码，AST 感知，懂语法结构地压缩。覆盖 Python、JS/TS、Go、Rust、Java、C/C++、Perl。
  • Kompress-v2-base——自然语言文本，一个在 agentic traces 上训练过的 HuggingFace 模型。

这个分工很：JSON 有 JSON 的冗余形状，代码有代码的冗余形状（AST 懂结构），散文有散文的冗余形状，不能用同一种招式。

还有个容易漏的：图片压缩，能减 40–90%，走训练过的 ML router。工具输出里夹着截图、报错图这类东西其实占很大一块 token，很多人没想到。

压缩最怕动了不该动的。Headroom 在这件事上有两条设计，值得拆开说。

第一条：CacheAligner，绝不改写 prompt。

现在的模型服务大多用 KV-cache 缓存前缀来加速、省钱。每次请求前缀有一点变化，缓存就失效，等于白付一遍钱。CacheAligner 做的事是：**标注出会搞坏缓存前缀的”易变内容”，但从不改写 prompt。**只告诉你”这段是活的”，让缓存策略正确避开，不替你动手改。

第二条：Live-zone compression，只压缩新字节。

Headroom 不是每次请求把整个历史重新压缩一遍——那样既贵、前缀每次都变，缓存全废，历史还可能被误伤。它只压缩”新区”：新鲜的工具输出、最新一轮对话。冻结的前缀保持字节级一致，历史永远不丢。

于是 provider 的缓存照样命中，你的长任务会话也不会因为压缩而失忆。

这两条合起来是同一句话的两个侧面：真正成熟的压缩不是一次性把上下文抹小，而是知道哪些能碰、哪些绝不能碰，只碰安全的增量。

用压缩的收益推不动，工程师大概率会反问：压缩本身要不要花时间？要是要，是不是得不偿失？

README 给了两个数字直接堵住这个问题：

  • 10K token 的 JSON 搜索结果，0.21 ms p50
  • 100K token，1.4 ms

都在一毫秒级。对一次动辄几十秒的 agent 请求，这个开销在延迟上基本无感。

这个数字说明压缩层的设计哲学是对的：它必须快到”存在但感觉不到”，否则用户会为了省 token 付更贵的时延，得不偿失。

省多少钱，空谈没感觉。README 放了四个基于真实 MCP server 输出格式构建、用 provider tokenizer 实测的场景：

场景压缩前压缩后节省
代码搜索（100 结果）17,19913,59721%
SRE 事故排查55,95724,34057%
代码库探索58,80133,89542%
GitHub issue 分类46,06732,42930%

注意那个 SRE 事故排查：55,957 → 24,340，砍掉 57%，而且第 67 行的 FATAL 逐字保住了——这是它第一屏就甩出来的图。

关键结论藏在表格注释里：省多少，取决于你的输入有多冗余。

  • 重复的 JSON 数组、成片的相似日志行——能省掉 90%+。
  • 散文、已经高度致密的输出——几乎不省。

注意力应该放在长任务的工具输出上，别指望短对话也能挤出油水。

所有”省 token”方案都逃不过一个灵魂拷问：你省了钱，会不会把答案也省没了？

Headroom 给了可验证的证据，不是一个”我们觉得没影响”的拍脑袋。

python -m headroom.evals suite --tier 1 跑出来的精确性基准：

基准类别基线Headroom变化
GSM8K数学0.8700.870±0.000
TruthfulQA事实性0.5300.560+0.030
SQuAD v2QA—97%19% 压缩下
BFCL工具调用—97%32% 压缩下

有个细节我挺喜欢：TruthfulQA 那个 +0.030，它自己标注了——N=100 时 ±0.03 落在置信区间内，所以那是**“检测不到差异”而不是”改进了”**。它没把噪音当卖点吹。这种把结论边界说清楚的诚实，在 AI 工具宣传里少见。

而且 SQuAD v2 和 BFCL 这两个更贴近真实场景的基准——QA 在 19% 压缩下保持 97%、工具调用在 32% 压缩下保持 97%——才是这套东西能不能上生产的关键证据。

很多人只盯着送进去的 prompt，忘了另一大块花销：模型写回来的每一个 token 也在付钱，而且 Opus 这类模型的输出价格是输入的 5 倍。

模型吐出来的很大一部分是”仪式感”——“好的，我们开始吧”这种开场白、把代码原封不动再抄一遍、在”读个文件”这种常规步骤上花大量深度思考。

Headroom 也能在代理层把这些删掉，不碰你的代码：

  • Verbosity steering：在 system prompt 末尾追加一句”简短点、别复述上下文”。注意是追加在末尾，这样 prompt 缓存照样命中。
  • Effort routing：这一轮只是工具结果之后的接续（读了文件、测试通过），就把思考力度调低；新问题、报错保持满档。

headroom learn --verbosity 读取过去的会话，把”我要简洁”这个隐含偏好挑出来。它其实是抓住了大多数人不会写进配置的动作：真会省的人不会把”简洁”写进配置，他是在打断长回复、在回复还没读完就切换走的那一刻，用行为表达了”我要简洁”。

得点一句：输出节省是反事实的——你看不到模型本来会写什么，所以它只能给一个带置信区间的估计，并如实标注这是估计值。这又是”把结论边界说清楚”的例子。

headroom learn 是这套系统里最有 Agent 气质的一块。

它会挖掘失败的会话，把找出来的修正写进 CLAUDE.local.md（默认，gitignored，只改本地）、CLAUDE.md（团队共享）、AGENTS.md 或 GEMINI.md。

这一下把”压缩”这个被动优化，升级成”从失败里沉淀”的闭环。失败不白失败，你踩过的坑被写回 Agent 记忆里，下次别再踩。跟前面说的”压缩冗余、留关键”一脉相承——都是让系统在时间维度上累积有价值的东西。

上手很快，README 给的 60 秒路径：

# 1 — 安装
uv tool install --python 3.13 "headroom-ai[all]"   # 自带 CLI
# 或 pip install "headroom-ai[all]"
# 或 npm install headroom-ai                        # 只是 TS SDK，无 CLI

# 2 — 选一种方式接入
headroom wrap claude                 # 包装一个 coding agent
headroom proxy --port 8787           # 零代码改动的透传代理
# 或 from headroom import compress    # 内联库

# 3 — 验证生效
headroom doctor
headroom perf
headroom dashboard                   # 实时看省了多少

四种接入方式，对应四种用法：

  1. Library：compress(messages)，Python / TypeScript，内联在你任何应用里。
  2. Proxy：headroom proxy，零代码改动，任何语言都能用——就是挡在你和模型之间的一层。
  3. Agent wrap：headroom wrap claude|codex|grok|copilot|...，一条命令包装好，headroom unwrap 撤销。内置对一堆 coding agent 的支持，还会顺手装 Serena（语义代码导航）。
  4. MCP server：headroom_compress / headroom_retrieve / headroom_stats，任何 MCP 客户端都能调。

再加上跨 Agent 共享记忆——Claude、Codex、Gemini、Grok 共用一个 store，自动去重。

我最看好的其实是 Library + 框架适配这一路：LangChain、LiteLLM、Vercel AI SDK、Agno、ASGI 中间件全都有钩子，它是长在你的技术栈里的，不是逼你搬进它的生态。

一篇工具文章只报喜是耍流氓。README 自己推荐的”何时用/何时跳过”，比一些营销文诚实得多：

适合如果你：

  • 天天跑 coding agent，想不动代码就省钱
  • 同时用好几个 agent，想要一份共享记忆
  • 需要可逆压缩——原始内容通过 CCR 按配置的 TTL 保留，模型想要全文随时能检索回来

跳过如果你：

  • 只用一个 provider 的原生压缩，不需要跨 agent 记忆
  • 工作在沙箱里，本地跑不了进程

再提一个关键局限：短对话、散文、已经致密的输出，几乎不省，甚至原样返回（min_input_words 以下的块字节级一致返回）。它压的是长 agent 会话里沉重的工具输出，不是闲聊。

还有几个实操坑，README 标得很细。

Telemetry 默认是开的。 一个匿名信标，会上报压缩比率、计数器、provider 和模型 ID、OS 架构，但绝不发送 prompt、补全、代码或文件路径。不想要就 HEADROOM_BEACON=off 关掉，或 HEADROOM_BEACON 继承 DO_NOT_TRACK 惯例，或 --offline。

企业网络踩 SSL 检查的坑。 公司网络做 SSL 中间人拦截，pip install headroom-ai[all] 会报 CERTIFICATE_VERIFY_FAILED。先装 Rust 或在有预编译 wheel 的平台直接装 pip install --only-binary headroom-ai headroom-ai。还有 Python 3.13 + OpenSSL 3.x 默认开 VERIFY_X509_STRICT 的坑，Zscaler 这类检查根的 basicConstraints 没标 critical 位会被拒，HEADROOM_TLS_STRICT=0 只放松 strict flag，校验链、签名、过期、主机名全保留。

Python 版本要选对。 想要 dashboard 里”省了多少钱”那个美元数字，得用 Python 3.13——这个功能依赖 LiteLLM，LiteLLM 装不上 Python 3.14+。

macOS 原生 wheel 目前只覆盖 Apple Silicon 和 Linux。 Intel 的 Mac 得走 Docker 原生安装。x86 的机器还要 AVX2，没有 AVX2（某些 Docker/QEMU、老云虚拟机）会退回到非 ONNX 路径。

这些坑写这么细，反而给我更多好感——说明是真的在被真用户用，真问题被真修过。

README 里有个对比表，能看清它想站在哪：

范围部署本地可逆
Headroom全部上下文——工具、RAG、日志、文件、历史代理 · 库 · 中间件 · MCP是是
Compresr / Token Co.只发给它们 API 的文本托管 API 调用否否
OpenAI Compaction会话历史provider 原生否否

差异一眼就能看清：托管方案把内容发出去换压缩，provider 原生压缩只管会话历史，而 Headroom 长得最像”基础设施”的那个——它就是你终端和模型之间的那一层，什么都经过它，什么都可逆，什么都在本地。这也是它对我这种”先稳后强”的人最有说服力的地方。

它的搭配哲学很干脆：推荐配 Serena 做语义代码导航、Ponytail 精简模型输出，它压缩的是下游所有 MCP server 的输出。不管上游是谁，只要是经过它的，它就压缩。

深度看完这个项目，我最大的感受不是功能多，而是它押在了一个很多人不愿意碰的硬问题上：省 token 谁都会喊，难的是确保省下来的过程中 FATAL 行不丢、缓存前缀不坏、历史不丢、答案是同一个。

这四个”不”，每一个都需要把”怎么判断冗余 vs 关键”做成可重复验证的工程，而不是一个拍脑袋的规则。

它让我服气的，是这四个”不”各自都有了着落：

  • FATAL 行不丢——靠数据驱动挑少数派，不靠”FATAL 这个词该留”
  • 缓存前缀不坏——CacheAligner 只标注、不碰 prompt
  • 历史不丢——Live-zone 只压增量
  • 答案是同一个——精确性基准拿置信区间说话，不把噪音当卖点

如果你也在跑长任务的 agent，而且 token 账单让你皱眉，别急着降模型档次。去 [GitHub 仓库]https://github.com/headroomlabs-ai/headroom 看看，或者直接：

uv tool install --python 3.13 "headroom-ai[all]"
headroom wrap claude
headroom dashboard

先在自己的一条长会话上跑一遍 headroom savings，看看你的数据到底能省多少。

省不省、省多少，结果会告诉你——但方向，我认为是对的。

#LLM #Token成本 #上下文压缩 #Agent #headroom #开源 #AI工程

Continue reading

继续阅读