Headroom：让 AI Agent 成本降低 10 倍的 Netflix 工具

中文العربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский
BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00这是 Headroom，一个开源工具，用于压缩你的 AI 代理读取的所有内容，
00:00:04包括工具调用、代码文件和 RAG，在内容到达大模型之前进行压缩，这意味着你可以减少
00:00:0960% 甚至 95% 的 Token 使用量，同时获得完全相同的答案。巧妙之处在于，它是可逆的，
00:00:14所以当模型确实需要完整信息时，它可以要求将其恢复。但压缩
00:00:18通常意味着你会丢失一些东西，那么你是如何在去除大部分上下文的情况下
00:00:23依然得到正确答案的呢？这确实是一个有趣的问题，点击订阅，让我们一探究竟。
00:00:31如果你曾经使用过像 ClaudeCode 这样的工具，你就会知道它会消耗大量的 Token。每一次工具调用
00:00:35都可能产生海量的 JSON 日志，这些日志大多是噪音，反而掩盖了重要信息，
00:00:40而所有这些都会被塞进上下文窗口中，这正是你所支付的费用来源。
00:00:45尤其是当你使用类似 UltraCode 模式下的 Opus 时，它运行的是动态工作流，
00:00:50会启动并行子代理，且没有 Token 上限。这就是为什么 Netflix 的高级开发人员 Tejas Chopra
00:00:57创建了 Headroom，它的工作原理是检测内容类型并保留重要信息。
00:01:01对于 JSON 数组，它会保留异常值和边缘情况；它有一个读取
00:01:06实际语法树的代码压缩器；当它读取构建日志时，它会保留失败记录并丢弃通过的测试。
00:01:11但有趣的部分在于，对于纯文本，Headroom 使用了它自己的模型，名为 CompressBase，
00:01:17这是 Tejas 专门为压缩训练的，且该模型在你的机器上本地运行。
00:01:22Headroom 声称它已经为用户节省了约 70 万美元的 Token 费用，
00:01:26而且最巧妙的是，它会在压缩后的文本中留下一个痕迹，
00:01:30其中包含一个哈希值，模型可以在需要时利用它检索原始未压缩数据。
00:01:35现在，如果你看过 James 关于 Caveman 的视频，那个工具也能减少上下文，
00:01:39但它是从相反的方向进行的，我稍后会在视频中做详细解释。
00:01:43但现在，让我们看一个 Headroom 的基本示例来了解它是如何工作的。
00:01:46Headroom 通过一个位于你的应用（比如爬取的代码）
00:01:50和 Anthropic 服务器之间的 Python 服务器来工作。
00:01:54当工具调用结果返回时，代理会使用底层的 Rust 对其进行压缩，
00:01:59并仅将压缩后的版本发送到 API。
00:02:01你可以用 pip 安装这个服务器，但我打算使用 uv，并确保 Python 版本
00:02:06是 3.12，因为它在更高版本上无法工作。
00:02:09然后运行该库中的 headroom proxy 命令，从而在端口上启动代理。
00:02:14Headroom 也有 TypeScript 或 Python SDK，
00:02:17为了演示，我们将使用 Python SDK 来创建一个使用 Claude SDK 的应用。
00:02:22这样我们可以像这样安装两者，然后就可以准备运行应用了。
00:02:25计划是稍后向你演示如何将 Headroom 与 Claude Code 结合使用，
00:02:29但我先想让你了解它在后台是如何工作的。
00:02:32对于这个应用，我们有一个用户提示词，要求阅读所有日志文件并找出错误，
00:02:36以及根本原因。在这里，我们将伪造一个工具调用。
00:02:40我们要让 Claude 发起一个 bash 工具调用来读取服务器日志文件，
00:02:44这些日志文件包含一堆伪造的日志，并在上方导入。
00:02:47然后我们将返回工具调用的结果。
00:02:49我们没有直接把文本文件给 Headroom，
00:02:52是因为它只压缩工具调用的输出。
00:02:54所以在这里我们指定了模型，在它下面，我们使用了 headroom compress 函数
00:02:59来处理模型消息，以进行准确的 Token 计数。
00:03:02Headroom 实际上并不使用 Haiku。
00:03:04然后我们提供代理的基准 URL。
00:03:06之后我们有一些用于测试的控制日志，
00:03:08向你展示 Headroom 处理前后的消息，
00:03:11以及一些显示节省比例的额外控制日志。
00:03:13之后，我们将来自 Headroom 的压缩消息传递给 Claude Code，
00:03:17其中也包含了用户提示词。
00:03:18现在，如果我们运行该文件，可以看到 Headroom 节省了 98% 的 Token。
00:03:23这是处理前的 Token 数，这是处理后的 Token 数。
00:03:26它节省了超过 17,000 个 Token。
00:03:28从前后对比中可以非常明显地看出来。
00:03:31如果我们往上翻，这是处理前的情况，也就是通常发送给 Claude Code 的内容。
00:03:35我们有用户提示词、工具调用和工具响应，也就是整个日志文件。
00:03:39如果看这里 Headroom 发送的内容，可以看到用户消息和工具调用是一样的，
00:03:43但工具响应的内容少了很多。
00:03:45它所做的是使用统计压缩来删除了冗余的 Token。
00:03:50它删除了 419 条类似的日志，并将它们压缩成了一个摘要。
00:03:54在这里我们可以看到 Headroom 告诉 Claude 这是压缩后的输出。
00:03:58它可以利用这个哈希值进行检索。
00:04:00现在这里显示了 Headroom 的一个即时缺点，Claude 认为它没有
00:04:05足够的信息来完成任务，但实际上它完全足够了。
00:04:08所以我们要再次运行我们的文件。
00:04:10这次我们依然有 98% 的节省率，但 Claude 给出了更多信息。
00:04:16让我们尝试另一个演示。
00:04:17像往常一样，我们需要运行 Headroom 代理，但这次我添加了更多参数。
00:04:21在这里你可以看到我添加了 ML 值，它在本地使用压缩模型来压缩纯文本。
00:04:26我还添加了代码以启用代码感知压缩器。
00:04:30并且添加了代码感知标志来开启它。
00:04:32现在我们可以看到它在这里已启用。
00:04:34然后我将运行 Claude Code，但我会先将基准 URL 设置为该代理。
00:04:39准备就绪后，我将给 Claude 一个提示词：阅读此项目中的每一个 TS 文件，
00:04:44并提供一份关于该项目正在做什么的深度概述，并附上相关代码的引用。
00:04:49过了一会儿，它给出了响应，告诉我它已经阅读了五个包中的所有 TypeScript 文件，
00:04:53并给出了一个默认的概述。
00:04:56但如果我们运行 context 斜杠命令（我之前已经运行过），可以看到它使用了 89.1k 个 Token。
00:05:02我之前也在没用 Headroom 的情况下在 Claude 中运行了类似的提示词。
00:05:06如果我们滚动到底部查看运行 context 子命令的地方，
00:05:10你会发现它用掉了更多 Token。
00:05:11我不确定为什么它在这里选择了 100 万上下文窗口的 Opus 模型。
00:05:16而在这里选择了 200k 上下文窗口，但我们可以使用 jq 格式化 curl 这个端点，
00:05:21以查明代理压缩的具体位置。
00:05:23这里包含的信息非常多，我花了一点时间才找到。
00:05:26但如果往上翻，我们可以看到 Headroom 压缩节省了多少 Token，
00:05:30甚至可以看到压缩为我们节省了多少金钱。
00:05:32当然，这仅仅是一次提示词的结果。
00:05:35但想象一下如果我有多个 Claude Code 会话在运行，且 Headroom 在压缩所有的工具
00:05:39调用。想象一下我会节省多少 Token。
00:05:42我还要指出，当我用 Opus 的低努力模式运行相同的提示词时，
00:05:46Headroom 实际上没有节省任何 Token。
00:05:49只有当我从低模式切换到中等模式时，Token 节省才变得明显。
00:05:53所以如果我开启高模式、超高模式甚至最大模式，它或许会节省更多 Token。
00:05:57总之，这就是 Headroom 的快速概述。
00:06:00当然，还有很多我没来得及介绍的功能，
00:06:03比如跨代理记忆（Cross-agent memory），它允许 Claude、CodeX 和其他工具
00:06:07共享完全相同的压缩上下文。
00:06:09Headroom Learn，它会挖掘你失败的会话，找出压缩过度的地方，
00:06:12并从中学习，以确保将来不再犯同样的错误，
00:06:15以及与流行 SDK 的集成。
00:06:18但关于 Headroom 有一件相当重要的事情需要考虑。
00:06:21每次模型没有获得所需的信息，
00:06:24并要求 Headroom 提供完整数据时，它就会进行第二次往返调用，
00:06:28这意味着在某些情况下，你使用 Headroom 后反而会消耗更多的 Token。
00:06:33但我认为这就是使用 Headroom Learn 功能的优势所在，
00:06:36它试图在将来阻止这种情况再次发生。
00:06:39还记得我在视频开头提到的 Caveman 吗？
00:06:42Caveman 是通过指导模型以短片段响应来减少 Token 的，
00:06:46省略填充词等等。
00:06:48正如你刚才在演示中所看到的，Headroom 在模型读取内容
00:06:51之前就缩减了内容。
00:06:52所以一个是削减输出，而另一个是削减输入，
00:06:56这意味着从技术上讲，如果你真的非常在乎节省 Token，
00:07:00你可以将它们结合使用以获得最大的节省效果。

Key Takeaway

Headroom 通过在模型读取前对工具调用和代码上下文进行本地智能压缩，在保持相同结果的同时显著降低了 AI 代理的运行成本。

Highlights

  • Headroom 可在内容送达大模型前进行压缩，最高可减少 95% 的 Token 使用量。

  • 该工具通过 Python 代理服务器运行，利用 Rust 进行底层数据压缩。

  • Headroom 可针对 JSON 数组、代码语法树及构建日志采用特定的优化压缩逻辑。

  • 内置的本地运行模型 CompressBase 专门用于纯文本的语义压缩。

  • 系统会在压缩文本中嵌入哈希值，允许大模型在必要时触发原始数据的逆向检索。

  • Headroom 配合 Claude Code 使用时，单次交互可节省超过 17,000 个 Token。

  • 该工具目前已通过减少上下文冗余，累计为用户节省了约 70 万美元的 Token 费用。

Timeline

Headroom 的核心机制与压缩逻辑

  • 该开源工具在内容到达模型前进行预压缩以减少 Token 占用。
  • 数据压缩过程是可逆的，模型能够根据哈希索引要求恢复原始数据。
  • 针对不同数据类型采用差异化处理，如代码语法树分析和日志中的失败记录保留。

Headroom 旨在解决 AI 代理（如 ClaudeCode）在运行中产生海量冗余日志的问题。它通过检测数据类型来动态保留关键信息，丢弃重复的测试记录或无关信息。对于纯文本，它使用 Tejas Chopra 开发的本地模型 CompressBase 进行处理，确保在大幅压缩上下文的同时不丢失核心逻辑。

安装部署与 Python SDK 实践

  • Headroom 部署于应用与 API 之间的中间层，通过 Python 服务器运行。
  • 要求使用 Python 3.12 版本以确保兼容性。
  • 支持 TypeScript 和 Python SDK，便于集成到现有的 AI 应用开发流中。

部署过程涉及安装 Headroom 代理服务器，并在应用配置中指向该代理端口。开发者可以利用 SDK 对模型消息进行处理，实现准确的 Token 计数和压缩。在伪造的 Bash 工具调用示例中，该工具成功通过去除冗余日志，将处理后的 Token 数量大幅缩减。

性能测试与高级功能

  • 在读取 TS 文件项目中，Headroom 实现 98% 的 Token 节省率。
  • Headroom Learn 功能通过挖掘失败会话学习压缩边界，以减少二次往返检索的需求。
  • 跨代理记忆功能允许不同工具共享同一个压缩后的上下文空间。

通过实际项目测试，Headroom 能够将复杂的代码库阅读任务的 Token 开销压低至极低水平。虽然在模型要求完整数据时会触发二次往返调用，导致额外成本，但 Headroom Learn 功能致力于通过优化后续处理逻辑来最小化此类情况，并确保复杂模型运行模式下的成本节省效果最为明显。

与同类工具对比

  • Caveman 通过指导模型输出短片段来削减输出端 Token。
  • Headroom 在输入端即开始削减内容，二者在技术层面具有互补性。

与 Caveman 侧重于压缩模型响应方向不同，Headroom 侧重于优化送入模型的输入数据。由于二者作用阶段不同，将两者结合使用可以进一步压缩整个 AI 交互过程中的 Token 总量。

Community Posts

No posts yet. Be the first to write about this video!

Write about this video