开发团队decentralizedbee在为客户构建AI代理（如代码助手、数据分析工具）时发现了一个反直觉的现象：最大的成本驱动因素并非模型推理，而是上下文长度。而上下文中的主要“罪魁祸首”往往是工具的输出结果。

想象一下这个场景：一个代理在代码库中搜索，`grep`命令返回了500个文件匹配项。代理会把这500个结果全部塞进上下文，然后问模型“哪些是相关的？”用户需要为这500个项目的token付费，而模型可能只从中挑出5个。此时，模型本质上扮演了一个JSON过滤器的角色。

这种模式无处不在——搜索结果、数据库查询、API响应。工具返回的数据量通常远超模型实际所需，但代理为了省事，往往会一股脑地全部传入提示词中。

为此，他们开发了一个名为**Headroom**的压缩层。其核心思路是：在工具输出到达模型之前，先对其进行统计分析，只保留关键信息。

**保留策略包括：**

* **错误信息**：任何包含错误关键词的内容都不会被丢弃。

* **统计异常值**：如果某个数值字段的值偏离均值超过2个标准差，则保留。

* **查询匹配项**：使用BM25算法对用户的实际问题进行相关性评分，保留匹配度高的项。

* **高分项**：如果数据中有相关性或分数字段，则保留排名靠前的N项。

* **首尾项**：保留开头和结尾的少量项目，以提供上下文和最新信息。

**丢弃策略主要是：**

* **重复的中间部分**：如果有500个搜索结果，其中480个看起来基本一样，那就没必要全部保留。


真正的难点不在于压缩本身，而在于**知道何时不应该压缩**。例如，当搜索数据库中的特定用户ID时，每一行都是唯一的，且没有排名信号，此时进行压缩会导致信息丢失。因此，Headroom会先进行“可压缩性”分析。如果数据独特性高且缺乏重要性信号，则跳过压缩，直接传递原始数据。

根据他们的实际工作负载，该工具可以实现**60%到90%的token缩减**。代码搜索（包含数百个文件匹配）和日志分析（包含大量重复条目）的压缩效果显著，而具有唯一行的数据库结果通常压缩不多——这正是预期的正确行为。

压缩带来的延迟开销很小，大约在1-5毫秒。压缩过程很快，模型推理仍然是主要的性能瓶颈。

**项目已开源，提供两种使用方式：**

1. **代理服务器**：可以指向任何OpenAI兼容的客户端。

2. **Python SDK包装器**：适合需要更多控制权的用户。

它可以通过LiteLLM与OpenAI、Anthropic、Google的模型以及本地模型（如使用OpenAI兼容服务器的llama.cpp）协同工作。

GitHub仓库：[https://github.com/chopratejas/headroom](https://github.com/chopratejas/headroom)

此外，这种压缩是**可逆的**。工具会缓存原始内容（带TTL），并在压缩输出中注入检索标记。如果模型需要被压缩掉的数据，可以请求将其恢复。虽然在实际应用中很少需要此功能，但它提供了一个很好的安全网。

有网友评论道：“这确实很巧妙，最近我也一直在为代理成本撞墙，却像个傻瓜一样接受了这种‘token税’。可压缩性分析很聪明——我见过太多‘优化’方案，它们在遇到边缘情况时就会悄无声息地失效。”

另一位网友提出了另一种思路：“我认为解决这个问题的最佳方案是像Claude Code那样，用一个更便宜的模型来处理token密集型的工具使用。”

开发团队表示，大多数代理框架似乎只是盲目地截断上下文，这在他们看来总是不太对劲。要么是随机丢失信息，要么是为不需要的token付费。应该存在一个中间地带。他们也很期待社区的反饋。