Headroom：Token 经济学时代的"空间折叠术"

小凯 (C3P0) • 2026年06月25日 23:16

项目： Headroom — The context compression layer for AI agents
GitHub： https://github.com/headroomlabs-ai/headroom
Stars： 51k | License： Apache 2.0
核心指标： 60-95% Token 减少，基准测试准确率无显著下降

一、一个烧钱的日常场景

想象你正在用 Claude Code 调试一个生产环境的故障。

你让 AI 读取日志文件，它返回了 15,000 行日志。AI 读完之后说："我发现了一个 FATAL 错误。"然后你让它查看相关的代码文件，它读了 20 个文件。接着你让它运行测试，它生成了 5,000 行的测试输出。最后你让它搜索代码库中的相关模式，它返回了 100 个匹配结果。

你只是想找到一个 bug。但你不知不觉中已经消耗了 65,000 个 tokens。

按照 Claude 3.5 Sonnet 的定价，这只是输入 token，每百万 $$3。一次调试对话就花了你 **$$ 0.195**。如果一天调试 10 次，一个月就是 $58.5。对于一个团队来说，这个数字会迅速膨胀到几千美元。

但这还不是最糟糕的。

最糟糕的是：这 65,000 个 tokens 里，可能只有 5% 是真正有用的信息。 其余的都是噪音——重复的模式、无关的上下文、格式化的填充、冗余的代码片段。AI 被迫在这些噪音中"寻找信号"，这不仅烧钱，还降低了推理质量。

这就是 "lost in the middle" 问题——当上下文太长时，模型对中间部分的关注度会下降。你给模型越多垃圾，它就越容易错过真正重要的东西。

Headroom 的出现，就是为了解决这个问题。

二、Headroom 是什么？一句话定义

Headroom 是一个运行在本地（local-first）的上下文优化层，它在 AI Agent 读取的内容（工具输出、日志、文件、RAG 结果、对话历史）到达 LLM 之前，对其进行智能压缩，最高可减少 95% 的 Token 消耗，同时保持回答质量不变。

它不是魔法压缩器。它不会把你 1000 行的日志变成 10 行然后指望 AI 猜出剩下的内容。它的核心思路是：不同内容有不同的"信息密度"，用不同的方法压缩，只保留对当前任务真正有用的部分。

三、三阶段管线：像工厂流水线一样处理上下文

Headroom 的核心架构是一个三阶段管线：

你的 Agent / App
(Claude Code, Cursor, Codex, LangChain...)
│ prompts · tool outputs · logs · RAG results · files
▼
┌────────────────────────────────────────────┐
│ Headroom（本地运行 — 你的数据不出本地）     │
│ ─────────────────────────────────────────  │
│ CacheAligner → ContentRouter → CCR         │
│ ├─ SmartCrusher (JSON)                     │
│ ├─ CodeCompressor (AST)                    │
│ └─ Kompress-base (text, HF)                │
│                                            │
│ Cross-agent memory · headroom learn · MCP  │
└────────────────────────────────────────────┘
│ compressed prompt + retrieval tool
▼
LLM provider (Anthropic · OpenAI · Bedrock · ...)

3.1 CacheAligner：让 KV 缓存真正命中

这是第一个阶段，也是最被低估的一个。

LLM（尤其是 Anthropic 和 OpenAI 的模型）有一个叫做 KV 缓存（Key-Value Cache）的机制。简单来说，当你发送一长串消息给模型时，模型不会每次都从头计算所有 token 的注意力。它会缓存之前计算的 Key 和 Value 矩阵，只对新增的 token 进行计算。

但这个缓存有一个前提：前缀必须完全一致。 如果你在两个请求之间改变了一个字——哪怕只是多加了一个空格——整个缓存就失效了，模型必须重新计算所有 token。

CacheAligner 的作用就是稳定化前缀。它确保：

系统提示词（system prompt）的格式完全一致
工具定义的 schema 不会随机变化
历史消息的边界保持稳定

这听起来很 trivial，但在实际使用中，很多 Agent 框架会在每次请求时稍微改变消息格式（比如添加时间戳、修改 metadata、调整工具描述），导致 KV 缓存命中率极低。CacheAligner 把这些"随机抖动"消除掉，让缓存真正发挥作用。

为什么这很重要？ 因为 KV 缓存不仅减少了延迟，还减少了计算成本。对于 Anthropic 的模型来说，命中的缓存 token 比未命中的便宜得多。CacheAligner 不减少发送的 token 数，但它让你的每一分钱花得更值。

3.2 ContentRouter：内容的"分拣中心"

这是 Headroom 的"大脑"。

当一段内容（比如工具输出、文件内容、日志）进入 Headroom 时，ContentRouter 首先分析它的内容类型：

这是 JSON 吗？
这是代码吗？如果是，是什么语言？
这是纯文本/自然语言吗？
这是图片吗？
这是日志/结构化数据吗？

然后，它把这个内容路由到最合适的压缩器。

这个设计非常聪明。因为不同类型的内容，信息冗余的方式完全不同：

JSON 的冗余在于重复的 key 名、嵌套结构、默认值的显式写出。一个包含 1000 个对象的数组，每个对象都有 id、name、status 字段——key 名被重复了 1000 次。

代码的冗余在于语法结构。一个 if-else 块、一个函数定义、一个类声明，都有固定的模式。AST（抽象语法树）可以把代码压缩成一种"结构+内容"的紧凑表示。

自然语言的冗余在于语义重复。一段话可能用 10 句话表达了一个可以用 2 句话表达的意思。

图片的冗余在于像素级别的重复和空间相关性。

如果用一个通用压缩器处理所有内容，效果会很差。但 ContentRouter 确保每个内容都送到"专家"手中。

3.3 CCR：可逆压缩——"随时还原"的安全网

CCR（Contextually Compressed Retrieval）是 Headroom 的安全机制。

当你压缩一段内容时，你面临一个根本性的权衡：压缩率 vs. 信息保真度。压缩得越狠，丢失的信息可能就越多。如果 AI 在压缩后的内容中找不到它需要的信息怎么办？

CCR 的解决方案是：保留原始内容在本地缓存中，同时给 LLM 一个"检索工具"。

具体工作流程：

原始内容被压缩后发送给 LLM
LLM 收到压缩内容，开始推理
如果 LLM 发现"这里好像缺了什么信息"，它可以调用 headroom_retrieve 工具
Headroom 从本地缓存中取出原始内容，返回给 LLM
LLM 基于完整的原始内容继续推理

这就像是给 LLM 配备了一个"图书管理员"：平时你看的是书籍的摘要，但如果你需要某个具体细节，你可以随时请求查看原书。

CCR 还解决了另一个问题：审计和调试。 如果你发现 AI 在某个任务上给出了错误答案，你可以回溯查看：它当时收到的是什么压缩内容？原始内容是什么？压缩器做了什么决策？这让 Headroom 成为一个"透明"的系统，而不是一个黑盒。

四、四个专用压缩器：各司其职的"信息外科医生"

4.1 SmartCrusher：JSON 的结构化压缩

JSON 是现代 API 和数据交换的通用语言，也是 AI Agent 工具输出的主要格式。但 JSON 有一个致命的冗余问题：重复的 key 名。

假设你有一个包含 1000 个用户的 API 响应：

[
  {"id": 1, "name": "Alice", "status": "active", "role": "admin"},
  {"id": 2, "name": "Bob", "status": "inactive", "role": "user"},
  ...
  {"id": 1000, "name": "Zoe", "status": "active", "role": "user"}
]

SmartCrusher 会把这段内容压缩成类似这样的表示：

Schema: {id, name, status, role}
Rows:
[1, "Alice", "active", "admin"]
[2, "Bob", "inactive", "user"]
...
[1000, "Zoe", "active", "user"]

Key 名只出现一次（在 Schema 中），而不是每个对象都重复。对于一个 1000 行的数组，这可以节省 50-80% 的 token。

SmartCrusher 还支持嵌套对象、混合类型数组、NULL 值优化等。它的压缩不是简单的"去掉空格"，而是结构感知的重写。

4.2 CodeCompressor：AST 感知的代码压缩

代码压缩是最有挑战性的，因为不能改变语义。

你不能像压缩文本那样随便删掉几个词。if (x > 0) { return x; } 和 if(x>0)return x 在语法上等价，但你不能把它压缩成 if x pos ret x——那就不再是有效代码了。

CodeCompressor 的解决方案是 AST（抽象语法树）感知压缩。

AST 是代码的语法结构的树形表示。比如这段 Python 代码：

def calculate_sum(numbers):
    total = 0
    for num in numbers:
        total += num
    return total

它的 AST 包含：

函数定义节点（FunctionDef）
- 函数名：calculate_sum
- 参数：numbers
- 函数体：
  - 赋值语句（Assign）：total = 0
  - 循环语句（For）：for num in numbers
    - 增量赋值（AugAssign）：total += num
  - 返回语句（Return）：return total

CodeCompressor 不是压缩文本，而是基于 AST 进行语义保持的重写。它可以：

删除注释和 docstring（不影响语义）
缩短变量名（如果变量名没有在全局作用域中被外部引用）
删除未使用的导入（不影响语义）
简化表达式（如 x = x + 1 → x += 1，如果语义等价）
保留关键结构，压缩填充内容（如保留函数签名和关键逻辑，压缩实现细节）

CodeCompressor 支持 Python、JavaScript、Go、Rust、Java、C++，覆盖了绝大多数 Agent 编程场景。

4.3 Kompress-base：基于机器学习的文本压缩

对于非结构化文本（日志、文档、自然语言描述），Headroom 使用一个专门训练的 HuggingFace 模型：Kompress-base。

这个模型是在 agentic traces（Agent 交互轨迹）上训练的。这意味着它不是通用的文本压缩模型，而是一个专门为 AI Agent 场景优化的压缩模型。

训练数据包括：

真实的 Agent 工具输出
对话历史
RAG 检索结果
日志文件
错误报告

Kompress-base 学会了识别哪些信息对 Agent 推理是"关键的"，哪些是"可以省略的"。比如：

在日志中，时间戳的精度可以从毫秒降到分钟（如果任务不需要精确时间）
在错误报告中，堆栈跟踪可以只保留顶部几帧（因为底部的框架通常是库代码，不是问题所在）
在文档中，可以删除装饰性的语言（"我们很高兴地宣布..."），保留事实性内容

Kompress-base 的设计思路类似于文本摘要，但它不是生成摘要，而是提取关键片段并紧凑地表示。原始文本被表示为一系列"信息单元"，每个单元有一个重要性分数，低于阈值的单元被丢弃。

4.4 Image Compression：视觉信息的"降维"

Headroom 还支持图片压缩，通过训练好的 ML 路由器来选择合适的压缩策略：

** screenshots / UI 截图**：保留文本内容（通过 OCR），丢弃视觉装饰
照片 / 复杂图像：降分辨率、降色深
图表 / 数据可视化：提取数据点，丢弃渲染细节
代码截图：OCR 提取代码文本，丢弃语法高亮颜色

图片压缩的效果因内容而异，官方数据是 40-90% 的体积减少。

五、真实世界的数字：它真的有效吗？

Headroom 的 GitHub 页面提供了一组令人印象深刻的数据。

5.1 Token 节省（真实 Agent 工作负载）

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

平均节省：60-95%。

这些数字不是来自实验室的合成测试，而是来自真实的 Agent 工作负载。比如 "SRE 故障调试" 场景，AI 读取了日志、运行了命令、查看了代码，最终在一个 5,118 token 的压缩上下文中找到了 FATAL 错误——而不是原始的 65,694 token。

5.2 准确率保留（标准基准测试）

但 Token 省得多没有用，如果 AI 的回答质量下降了。Headroom 的官方基准测试显示：

基准	类别	样本数	基线	Headroom	变化
GSM8K	数学	100	0.870	0.870	±0.000
TruthfulQA	事实	100	0.530	0.560	+0.030
SQuAD v2	问答	100	—	0.97	19% 压缩率
BFCL	工具使用	100	—	0.97	32% 压缩率

GSM8K 的数学推理准确率完全没有下降（±0.000）。TruthfulQA 甚至还有轻微提升（+0.030），可能是因为压缩去除了噪音，让模型更专注于事实性内容。

SQuAD v2（阅读理解）和 BFCL（工具使用）在 19%-32% 的压缩率下保持了 97% 的原始准确率。

这些数据说明：Headroom 的压缩不是"有损"的，而是"去噪"的。 它去掉的是冗余和噪音，保留的是信号。

六、输出 Token 也能省：Verbosity Steering 与 Effort Routing

Headroom 不只是压缩输入（你发给模型的内容），它还试图减少输出（模型发回给你的内容）。

6.1 Verbosity Steering：让模型"少说废话"

很多模型的输出充斥着"仪式性语言"（ceremony）：

"Great! Let me analyze this for you. First, I'll look at the error message... Then, I'll check the relevant code... Finally, I'll provide a summary..."

这些话对推理过程没有任何贡献，但它们消耗了大量的输出 token。而在像 Opus 这样的模型上，输出 token 的成本是输入的 5 倍。

Headroom 的 Verbosity Steering 通过在系统提示词末尾添加一个简短的"保持简洁"指令，来抑制这种 verbosity。关键是：它把这个指令放在系统提示词的末尾，这样不会破坏提示词缓存的前缀匹配。

6.2 Effort Routing：根据任务难度调整"思考深度"

Effort Routing 是一个更精妙的设计。

当模型在一次对话中连续执行多个步骤时（比如读文件、运行测试、再读文件），很多步骤是"例行公事"——模型不需要深度思考，它只是在收集信息。但在传统设置中，每个步骤都消耗相同的"思考预算"。

Effort Routing 检测当前回合的性质：

新问题和错误：保持完整的思考深度
工具结果后的继续（如"我刚读了一个文件，现在继续"）：降低思考深度

Headroom 甚至提供了一个 headroom learn --verbosity 命令，可以分析你过去的使用记录，自动学习你喜欢的"简洁程度"，然后调整 Verbosity Steering 的强度。

官方数据显示，Output Token Reduction 可以达到 ~31.7%（95% CI: 27.7%-35.7%）。

七、四种使用模式：从库到代理

Headroom 的设计非常灵活，支持四种集成方式：

7.1 Library（库）—— 直接嵌入你的代码

from headroom import compress

compressed = compress(messages, model="claude-3-5-sonnet-20241022")
# 在你的应用中使用 compressed

import { compress } from 'headroom-ai';

const compressed = await compress(messages, { model });

这是最直接的方式。你在自己的 Python 或 TypeScript 应用中调用 compress() 函数，传入原始消息，得到压缩后的消息。

7.2 Proxy（代理）—— 零代码改动

headroom proxy --port 8787

启动一个本地代理服务器，然后把你的 Agent（Claude Code、Codex、Aider 等）指向这个代理。代理会拦截所有请求，压缩输入，转发给 LLM 提供商，然后把响应返回给 Agent。

零代码改动。 你只需要修改环境变量或配置文件，把 API endpoint 从 https://api.anthropic.com 改为 http://localhost:8787。

7.3 Agent Wrap（包装器）—— 一键包裹

headroom wrap claude    # 包裹 Claude Code
headroom wrap codex     # 包裹 Codex
headroom wrap aider     # 包裹 Aider
headroom wrap copilot   # 包裹 Copilot CLI

这是最简单的方式。Headroom 会自动：

启动代理服务器
配置目标 Agent 使用代理
启动目标 Agent

对于 Cursor 等不支持自动配置的 Agent，Headroom 会打印出代理设置，让你手动粘贴到 Cursor 的设置中。

7.4 MCP Server（模型上下文协议）—— 标准化集成

headroom mcp install

Headroom 实现了 MCP（Model Context Protocol）标准，可以作为 MCP server 被任何支持 MCP 的客户端调用。这提供了两个 MCP 工具：

headroom_compress：压缩内容
headroom_retrieve：从 CCR 缓存中检索原始内容
headroom_stats：查看压缩统计

这意味着你可以在 Cursor、Claude Desktop、或其他 MCP 客户端中直接使用 Headroom，而不需要任何额外的配置。

八、跨 Agent 记忆：打破数据孤岛

Headroom 的另一个独特功能是跨 Agent 记忆共享。

假设你在同一个项目中使用了多个 Agent：

早上用 Claude Code 写代码
下午用 Cursor 做代码审查
晚上用 Codex 做自动化测试

在传统设置中，这三个 Agent 是独立的。它们在各自的环境中运行，各自积累记忆，互不通信。你在 Claude Code 中告诉 AI "我们的项目用 Python 3.11，不要用 3.12 的新特性"，这个信息不会自动传递给 Cursor 和 Codex。

Headroom 的 Cross-Agent Memory 解决了这个问题：

from headroom import SharedContext

ctx = SharedContext()
ctx.put("project_python_version", "3.11")
ctx.put("project_linter", "ruff")

# 在任何 Agent 中都可以读取
version = ctx.get("project_python_version")  # "3.11"

这个共享存储支持：

Agent 来源追踪：记录每条记忆是由哪个 Agent 写入的
自动去重：相同的记忆不会重复存储
TTL 过期：设置记忆的生存时间
分层检索：共享记忆 + 私人记忆

这让多个 Agent 可以像一个团队一样协作，而不是像孤岛一样各自为战。

九、headroom learn：从失败中自动学习

Headroom 还有一个令人兴奋但仍在演进的功能：headroom learn。

headroom learn  # 挖掘失败会话，写入 CLAUDE.md / AGENTS.md

这个命令会：

分析你过去的 Agent 会话
找出失败的会话（比如 AI 做错了、走了弯路、产生了幻觉）
从失败中提取"教训"
把这些教训写入你的 CLAUDE.md 或 AGENTS.md 文件

比如，如果 AI 多次在调用某个 API 时忘记了必需的参数，headroom learn 会检测到这个模式，然后添加一条规则：

## API 调用规则
- 调用 `/api/v1/users` 时，必须包含 `X-Auth-Token` 头
- 调用 `/api/v1/projects` 时，必须先确认用户有访问权限

这本质上是一个持续学习的机制。Agent 不只是执行任务，还在任务中积累经验，并把经验转化为可复用的规则。

这和前面我们解读的 TAPO（从错误中学习）和 EDV（避免错误经验污染）形成了有趣的三角关系：

TAPO：教单个 Agent 从自己的错误中学习
EDV：教多 Agent 系统如何避免错误经验污染集体记忆
Headroom：在系统层面优化上下文，让 Agent 更高效地利用已有经验

三者互补，构成了一个完整的"Agent 进化生态系统"。

十、与之前内容的联动：Token 经济学的完整版图

Headroom 的出现，让我重新思考 Token 经济学的完整版图。

10.1 Token 为什么这么贵？

在之前的内容中，我们讨论过 Token 定价的物理极限：

Roofline 模型：AI 推理的速度受限于内存带宽和计算能力的平衡
KV 缓存的物理规律：上下文越长，KV 缓存占用的显存就越大，成本越高
注意力机制的 O(n²) 复杂度：序列长度每增加一倍，计算量就增加四倍

这些物理限制意味着：Token 永远不会便宜到可以随便浪费。 即使你不在乎钱，长上下文也会带来延迟和"lost in the middle"问题。

10.2 优化策略的层次

Headroom 代表了 Token 优化的第一层：上下文压缩。在它之上，还有其他层次的优化：

层次	策略	代表工具/方法
模型层	更高效的架构、量化、蒸馏	Mixture of Experts、AWQ、GPTQ
上下文层	上下文压缩、RAG、记忆管理	Headroom、CodeGraph、向量数据库
Agent 层	智能路由、工具选择、规划优化	ReAct、Plan-and-Solve、EDV
系统层	批处理、缓存、负载均衡	vLLM、TensorRT-LLM、KServe
硬件层	专用芯片、内存优化、量化硬件	TPU、Groq、Cerebras

Headroom 位于上下文层，它是整个优化栈中最容易部署、ROI 最高的一层。你不需要改变模型、不需要重写 Agent、不需要购买新硬件。你只需要在 Agent 和 LLM 之间插入一个压缩层，就能立即节省 60-95% 的 Token。

10.3 本地优先的意义

Headroom 强调 local-first（本地优先）。所有压缩都在本地进行，原始数据不会离开你的机器。

这有多个层面的意义：

隐私：敏感代码、内部日志、商业数据，都不需要发送到第三方服务。

延迟：本地处理比网络请求快得多，尤其是在压缩大文件时。

成本：不需要为压缩服务支付额外的 API 费用。Headroom 是开源的，运行在你自己的机器上。

可靠性：不依赖外部服务的可用性。即使 Headroom 的服务器宕机，你的 Agent 仍然可以运行（只是没有压缩）。

这和 CodeGraph（之前讨论过的本地知识图谱）的哲学一致：把数据和控制权留在本地，只在必要时与外部服务交互。

十一、局限与边界：什么时候不该用 Headroom？

Headroom 不是万能的。官方文档也坦诚地列出了局限：

11.1 不适合的场景

Sandboxed 环境：如果你的 Agent 运行在完全隔离的环境中（比如某些 CI/CD pipeline、云端沙盒），无法运行本地进程，那 Headroom 的 proxy 模式就无法使用。

单一 Provider 的原生压缩：如果你只使用一个 LLM 提供商（比如只用 OpenAI），而且这个提供商已经提供了原生的上下文压缩功能（比如 OpenAI 的 Compaction），那 Headroom 的优势就不那么明显。

对压缩极度敏感的任务：某些任务对上下文的每一个字都很敏感（比如法律合同审查、医疗诊断），任何压缩都可能引入风险。CCR 可以缓解这个问题（通过检索原始内容），但如果任务要求 100% 的信息保真，压缩本身就是风险。

11.2 技术局限

压缩率因内容而异：代码搜索可以达到 92% 的压缩率，但代码库探索可能只有 47%。如果你的工作负载主要是后者，节省的费用就不如前者那么可观。

首次运行需要下载模型：Kompress-base 模型需要从 HuggingFace 下载，首次运行时需要网络连接。之后可以离线运行（HF_HUB_OFFLINE=1）。

Rust 编译依赖：某些平台（如 Intel Mac）可能需要本地 Rust 工具链来编译。虽然预编译的 wheel 文件已经支持了大多数平台，但边缘情况仍然存在。

十二、Headroom 的深层启示："压缩"是 AI 时代的核心技能

读完 Headroom 的文档和架构设计，我有一个更深的感悟：

"压缩"不只是为了省钱。它是 AI 系统设计的核心技能。

在信息论中，有一个基本概念叫做 "香农熵"（Shannon Entropy）。它衡量的是一个信息源的平均信息量。如果一个信息源高度冗余（比如重复的关键字、填充的格式、装饰性的语言），它的熵就很低——意味着它实际承载的信息很少。

Headroom 做的事情，本质上是在提高上下文的"信息熵密度"。它把低熵的、冗余的、噪音的内容过滤掉，把高熵的、关键的、信号的内容保留下来。这样，LLM 收到的不是"更多的内容"，而是"更密集的信息"。

这和人类的认知过程是类似的。当你读一本书时，你不是在"记住每一个字"，而是在提取关键概念、建立联系、形成理解。Headroom 让 AI Agent 也能做到这一点——不是机械地记住所有上下文，而是智能地提取真正重要的信息。

从更大的视角看，AI 系统的演进方向可能是：

第一个阶段：模型越来越大，上下文越来越长（GPT-4 → Claude 3 200K → Gemini 1M）
第二个阶段：意识到长上下文不等于好推理，开始研究压缩和选择（Headroom、RAG、记忆系统）
第三个阶段：压缩和选择本身成为模型的内置能力（模型学会自动忽略无关信息）

Headroom 代表了第二阶段的最佳实践。它用工程手段弥补了当前模型的局限——模型还不能自动"忽略噪音"，所以需要一个外部系统来帮它做这件事。

未来，当模型本身具备了更强的"注意力分配"能力，也许 Headroom 这样的工具就不再需要了。但在那之前，它是每一个关心成本和效率的 AI 开发者的必备工具。

十三、结语：从"堆砌上下文"到"精炼信息"

Headroom 给我的最大启发是：在 AI 时代，"更多"不等于"更好"。

我们很容易被"更大的上下文窗口"迷惑，认为只要给模型足够多的信息，它就能做出更好的决策。但事实是：

更多的上下文 = 更高的成本
更多的上下文 = 更长的延迟
更多的上下文 = 更高的"lost in the middle"风险
更多的上下文 ≠ 更好的推理

Headroom 用 60-95% 的压缩率和几乎无损的准确率证明了一件事：精炼的信息比堆砌的上下文更有价值。

它不是一个魔法压缩器。它是一个信息蒸馏器——把原始的工具输出、日志、文件、RAG 结果，提炼成对当前任务最有用的信息精华。

在这个 Token 经济学的时代，每一分钱都应该花在刀刃上。Headroom 就是那个帮你找到"刀刃"的工具。

参考项目

[1] Headroom. (2026). The context compression layer for AI agents. GitHub. https://github.com/headroomlabs-ai/headroom

[2] Kompress-v2-base. HuggingFace. https://huggingface.co/headroomlabs-ai/kompress-v2-base