Headroom 深度实战：当 AI Agent 学会「省着吃」——从 Token 暴降 60-95% 到可逆上下文压缩的生产级完全指南（2026）

引言：AI Agent 的隐形账单

2026 年，AI 编码助手已经从尝鲜工具变成了开发者的日常标配。Claude Code、Cursor、Windsurf、Codex CLI……你可能同时开着三四个 Agent 在不同项目里跑。但一个被严重忽视的问题正在悄悄吞噬你的钱包——Token 消耗的失控膨胀。

让我用一个真实的场景来说明：

你让 Agent 排查一个 Kubernetes Pod OOM 的问题。Agent 开始工作：

1. 执行 kubectl get pods -A → 输出 2000+ Token
2. 执行 kubectl describe pod xxx → 输出 5000+ Token
3. 执行 kubectl logs xxx --tail=200 → 输出 8000+ Token
4. 执行 docker inspect container-id → 输出 6000+ Token
5. RAG 检索返回 50 条相关日志片段 → 输出 15000+ Token
6. 对话历史累积到第 15 轮 → 之前的上下文还在占用窗口

光这一轮排查，Agent 就"读"了 36000+ Token 的冗余信息。而它真正需要的，可能只有 3000 Token 的关键内容——容器限制配置、内存使用曲线的关键拐点、错误堆栈的前 20 行。

这就是 Headroom 要解决的问题：在 Agent 和 LLM 之间放一个智能压缩层，把那 33000 Token 的"废话"压缩掉，只保留 3000 Token 的精华。

实测效果：Token 消耗降低 60-95%，精度保留率高达 97%。

听起来不可思议？让我们深入拆解它是怎么做到的。

一、为什么传统方案不够用

在 Headroom 出现之前，业界已经有几种处理上下文过长的策略，但每种都有明显的缺陷：

1.1 暴力截断（Sliding Window）

最简单的做法——超过上下文窗口就砍掉最早的内容。问题在于：

• Agent 在第 3 轮对话中获取的关键信息，可能在第 20 轮被截掉
• 没有任何智能判断，可能砍掉最重要的内容
• 无法恢复——信息一旦丢失就永久消失

1.2 Provider 原生压缩（OpenAI Compaction 等）

OpenAI 和 Anthropic 都在自己的 Provider 层面做了上下文压缩。但局限性很明显：

• 不可逆：压缩后的信息无法恢复
• 不透明：你不知道压缩了什么、保留了什么
• 不可控：压缩策略由 Provider 决定，用户无法自定义
• 不通用：只能在特定 Provider 的生态内使用

1.3 lean-ctx / RTK 等 CLI 工具

这些工具专注于压缩终端输出，效果不错但覆盖面有限：

• 只能处理 CLI 输出，无法处理 JSON、代码文件、图片
• 缺乏可逆机制
• 不同工具之间无法共享记忆

1.4 Headroom 的差异化定位

Headroom 不是一个简单的"截断工具"或"压缩 CLI 输出"的脚本。它是一个完整的上下文管理中间层，核心设计原则是：

二、架构全景：六大压缩算法 + 可逆存储

Headroom 的核心架构可以概括为：一个路由器调度六大压缩器，辅以可逆存储和跨 Agent 记忆系统。

2.1 整体数据流

AI Agent 发送请求
    ↓
[Headroom 压缩层]
    ├── ContentRouter（内容类型检测）
    │   ├── JSON → SmartCrusher
    │   ├── 代码 → CodeCompressor（AST 感知）
    │   ├── 文本 → Kompress-base（专用压缩模型）
    │   └── 图片 → Image Compressor
    ├── IntelligentContext（重要性评分）
    ├── CacheAligner（前缀稳定化）
    └── CCR（原始数据存入本地仓库）
    ↓
压缩后的数据 → LLM Provider
    ↓
LLM 响应 → Agent
    ↓
Agent 需要原始数据？
    → headroom_retrieve(id=xxx)
    → 从 CCR 仓库取回原文

2.2 十阶段生命周期

Headroom 的处理流程不是简单的"进来就压缩"，而是一个 10 阶段的精细管线：

Setup → Pre-Start → Post-Start → Input Received → Input Cached
→ Input Routed → Input Compressed → Input Remembered
→ Pre-Send → Post-Send → Response Received

这个生命周期设计很有工程思维——每个阶段都有明确的职责，可以独立监控和调试。后面我们会看到，这种设计在实际使用中带来的好处。

三、六大压缩算法深度解析

3.1 ContentRouter — 智能内容路由器

ContentRouter 是整个压缩管线的调度中心。它的工作流程：

# 伪代码展示 ContentRouter 的路由逻辑
class ContentRouter:
    def route(self, content):
        if is_json(content):
            return SmartCrusher(content)
        elif is_code(content):
            return CodeCompressor(content, language=detect_language(content))
        elif is_text(content):
            return KompressBase(content)
        elif is_image(content):
            return ImageCompressor(content)
        else:
            return KompressBase(content)  # 默认用文本压缩器

看起来简单，但关键在于精确的内容类型检测。Agent 的输入内容经常是混合格式——一个 JSON 里嵌套着代码片段，代码注释里混着 URL。ContentRouter 需要处理这种"套娃"场景，对不同部分应用不同的压缩策略。

3.2 SmartCrusher — JSON 专用压缩器

AI Agent 的工具输出中，JSON 是最高频的格式。一次代码搜索可能返回 100 条结果，每条都是一个 JSON 对象，包含文件路径、行号、代码上下文、匹配分数等字段。

SmartCrusher 针对这种场景做了深度优化。实测效果惊人：

100 条代码搜索结果从 17,765 Token 压缩到 1,408 Token，节省 92%。

它是怎么做到的？

核心思路包括：

1. 结构扁平化：将深层嵌套的 JSON 压平。比如 {"file": {"path": {"dir": "src", "name": "main.rs"}, "lines": [...]}} 可以表示为更紧凑的扁平结构。

2. 冗余消除：当 100 条搜索结果共享相同的键名（file_path、line_number、match_score）时，这些键名重复了 100 次。SmartCrusher 会对重复的键值模式进行去重或用更紧凑的表示方式。

3. 类型感知裁剪：对于数值类型的 score 字段，如果精度对 Agent 判断影响不大，可以用更短的表示；对于布尔类型，可以压缩为单字符。

4. 重要性加权：不是所有字段都同等重要。文件路径和代码上下文比分数和时间戳重要得多。SmartCrusher 会优先保留高信息密度的字段。

// 压缩前（一条搜索结果）
{
  "file_path": "/home/user/project/src/main.rs",
  "line_number": 42,
  "column_start": 8,
  "column_end": 35,
  "match_score": 0.8472,
  "context_before": "fn process_data(input: &mut Vec<u8>) {\n    let buffer = allocate_buffer(1024);",
  "context_after": "    buffer.copy_from_slice(&input[0..len]);\n    transform_buffer(&mut buffer);",
  "match_text": "let buffer = allocate_buffer(1024);",
  "language": "rust",
  "timestamp": "2026-06-09T14:13:00.000Z"
}

// 压缩后（语义保留，Token 大幅减少）
// f:/project/src/main.rs:42:8 L:"let buffer = allocate_buffer(1024);"
// C-: fn process_data(input: &mut Vec<u8>) {
//       let buffer = allocate_buffer(1024);
// C+:     buffer.copy_from_slice(&input[0..len]);

3.3 CodeCompressor — AST 感知代码压缩

这是 Headroom 最具技术含量的设计。

传统的代码压缩是暴力截断——要么只保留前 N 行，要么保留中间 N 行。但这种方式有致命问题：

• 函数签名被截断 → LLM 不知道参数类型
• import 语句被截断 → LLM 不知道依赖关系
• 类定义被截断 → LLM 不知道继承层次
• 保留的是实现细节 → 缺失的是架构信息

CodeCompressor 的 AST 感知方法完全不同：

原始代码（500 Token）:
├── import 语句（50 Token）
├── 类定义（100 Token）
├── 函数签名（30 Token）
├── 函数实现（280 Token）  ← 细节最冗余
└── 注释（40 Token）

AST 感知压缩后（150 Token）:
├── import 语句（50 Token）  ← 完整保留
├── 类定义（100 Token）      ← 完整保留
├── 函数签名（30 Token）     ← 完整保留
└── 函数实现（30 Token）     ← 仅保留骨架，压缩到 10%

LLM 看到压缩后的代码，仍然能理解：

• 这个模块导入了什么
• 定义了哪些类和函数
• 函数的输入输出类型
• 类之间的继承关系

而那些冗长的实现细节——循环体、错误处理、日志打印——被大幅压缩。如果 LLM 真需要看完整实现，可以通过 headroom_retrieve 按需取回。

目前支持六种语言的 AST 解析：Python、JavaScript、Go、Rust、Java、C++。这覆盖了绝大多数 Agent 会处理的代码。

3.4 Kompress-base — 专为 Agent 场景训练的压缩模型

这是 Headroom 团队发布在 HuggingFace 上的专用压缩模型。

为什么需要专用模型？因为 Agent 的对话模式和普通文本有本质区别：

• 大量的工具调用和工具输出
• 中间推理过程（Chain-of-Thought）
• 结构化的错误信息
• 混合格式的内容（代码 + 文本 + JSON 交织）

通用文本压缩模型（如 Gzip）只关注字节级别的重复，不理解语义。通用文本摘要模型（如 BART）又太慢，不适合实时压缩场景。

Kompress-base 在Agent 交互轨迹数据（agentic traces）上专门训练，学会了：

1. 识别工具输出中的关键信息 vs 噪声
2. 保留 Agent 推理链中的关键节点
3. 压缩重复的上下文模式
4. 在压缩的同时保持语义完整性

3.5 Image Compressor — 多模态 Agent 的 Token 节省

当 Agent 处理截图、UI mockup、架构图等图片时，Token 消耗是巨大的——一张高分辨率截图可能消耗数千 Token。

Image Compressor 使用"训练好的机器学习路由器"来选择最优压缩策略，实现 40-90% 的体积缩减。

这在以下场景尤其有价值：

• UI 自动化测试：Agent 截图分析页面元素
• 架构设计评审：Agent 分析系统设计图
• 错误报告分析：Agent 解读错误截图

3.6 IntelligentContext + CacheAligner — 隐形性能杀手锏

这两个组件经常被忽视，但在生产环境中可能是最有价值的。

IntelligentContext 基于学习到的重要性评分，决定上下文中哪些内容保留、哪些压缩、哪些存档。不是简单地按时间顺序截断，而是智能选择——类似于给 Agent 装了一个"注意力机制"的预处理器。

CacheAligner 解决的是一个更隐蔽的性能问题。LLM 推理服务使用 KV Cache 加速推理——如果请求的前缀和之前的请求一样，就不需要重新计算注意力矩阵。但 Agent 的工具输出中充满了动态值：

// 时间戳——每次都不同
"timestamp": "2026-06-09T14:13:22.123Z"

// 进程 ID——每次都不同  
"pid": 48291

// UUID——每次都不同
"request_id": "a3f8e2c1-4b5d-6789-abcd-ef0123456789"

// 哈希值——每次都不同
"commit_hash": "d4e5f6a7b8c9"

这些动态值导致每次请求的前缀都不一样，KV Cache 命中率极低。CacheAligner 将这些动态值替换为固定占位符：

"timestamp": "<TS>"
"pid": "<PID>"
"request_id": "<UUID>"
"commit_hash": "<HASH>"

效果：相同结构的请求产生相同的前缀，KV Cache 命中率大幅提升。在高频调用场景下，不仅节省 Token，还显著降低推理延迟。

四、CCR — 可逆压缩：Headroom 的杀手锏

4.1 传统压缩的致命缺陷

所有传统的上下文压缩方案都有一个共同问题：不可逆。信息一旦压缩就丢失了。

这对于 AI Agent 来说是致命的。想象这个场景：

1. Agent 压缩了 50 条搜索结果
2. LLM 基于压缩后的摘要选择看第 23 条的完整内容
3. 但原始内容已经被压缩掉了，无法恢复
4. Agent 只能重新搜索 → 又一轮 Token 消耗

这就是"压缩-重查"的恶性循环。

4.2 CCR 的解决方案

CCR（Context Compression with Retrieval）的思路是：

1. 原始数据完整存入本地 CCR 仓库（数据不离开你的机器）
2. 压缩后的数据发送给 LLM
3. LLM 需要原始信息时，通过 headroom_retrieve 工具按需取回

Agent 请求 → Headroom 压缩
                ↓
           原文 → 本地 CCR 存储（可逆）
           压缩版 → LLM Provider
                ↓
           LLM 分析压缩内容
                ↓
           需要看原文第 23 条？
           → headroom_retrieve(id="ccr:abc123_23")
           → 从本地仓库取回完整内容
           → Agent 继续工作

这相当于给 LLM 一个**"放大镜"**——平时看摘要提高效率，需要时看原文获取细节。

4.3 <<ccr:HASH>> 占位符机制

CCR 的工程实现非常巧妙。压缩后的文本中，被压缩的内容会被替换为 <<ccr:HASH>> 格式的占位符：

// 压缩后的上下文（发送给 LLM）
搜索到 100 条相关代码片段。关键结果摘要：
- <<ccr:a1b2c3>>: main.rs 中 process_data 函数存在缓冲区溢出风险
- <<ccr:d4e5f6>>: config.rs 硬编码了数据库密码
- <<ccr:g7h8i9>>: utils.rs 的排序算法时间复杂度为 O(n²)
...（其余 97 条已压缩）

当 LLM 判断需要看某个条目的完整内容时：

LLM 调用: headroom_retrieve(hash="a1b2c3")
返回: 完整的搜索结果——文件路径、行号、完整代码上下文、匹配分数等

4.4 跨 Agent 共享记忆

CCR 还有一个杀手级功能：跨 Agent 记忆共享。

当你同时使用 Claude Code、Cursor、Codex 等多个 Agent 时，它们的上下文是隔离的。Agent A 发现的问题，Agent B 不知道。

Headroom 的 CCR 仓库是本地共享的。当 Agent A 将某条关键信息存入 CCR 后，Agent B 也能通过 headroom_retrieve 访问到。这为多 Agent 协作场景提供了基础。

五、基准测试：数字说话

5.1 压缩率测试

5.2 精度保留测试

特别值得注意的是 TruthfulQA 的精度反而提升了 3%。这听起来违反直觉，但仔细想想很合理——压缩去除了上下文中的干扰信息（无关的工具输出、重复的上下文），让模型更专注于关键事实，反而减少了"被噪音误导"的概率。

5.3 成本节省估算

假设一个中等强度的 AI Agent 用户：

对于团队级别（20 个开发者），月节省可达 $2,400+。年度节省近 $30,000。

六、实战指南：从零接入

6.1 安装

# 安装 Headroom（包含所有依赖）
pip install "headroom-ai[all]"

# 或者只安装核心功能
pip install "headroom-ai[core]"

6.2 方式一：Wrap 模式（推荐新手）

最适合快速上手的模式，一行命令即可：

# 包装 Claude Code
headroom wrap claude

# 包装 Cursor
headroom wrap cursor

# 包装 Codex CLI
headroom wrap codex

# 查看压缩统计
headroom stats

headroom wrap 会自动检测你的 Agent 配置，将 Headroom 注入为中间层。你使用 Agent 的方式完全不变，所有压缩在后台静默进行。

6.3 方式二：Proxy 模式（零代码，通用性强）

# 启动 Headroom 代理服务器
headroom proxy --port 8787

# 配置你的 Agent 使用 localhost:8787 作为 LLM endpoint
# 以 Claude Code 为例，修改 API endpoint：
export ANTHROPIC_BASE_URL="http://localhost:8787/v1"
claude

Proxy 模式的好处是完全不侵入 Agent 代码。任何通过 HTTP 调用 LLM 的 Agent 都可以使用，包括自研的 Agent 框架。

6.4 方式三：Library 模式（代码集成）

from headroom import compress

# 你的原始消息列表
messages = [
    {"role": "system", "content": "你是一个 Kubernetes 运维专家"},
    {"role": "user", "content": "帮我排查 pod-xxx 的 OOM 问题"},
    {"role": "assistant", "content": "让我先查看 Pod 状态..."},
    {"role": "tool", "content": kubectl_output},  # 5000 Token 的工具输出
    {"role": "assistant", "content": "Pod 内存限制为 256Mi..."},
    {"role": "tool", "content": logs_output},    # 8000 Token 的日志
]

# 压缩
result = compress(
    messages,
    model="claude-sonnet-4-20250514",
    mode="balanced"  # balanced / aggressive / conservative
)

# 压缩后的消息，直接发给 LLM
compressed_messages = result.messages

# 查看压缩统计
print(f"原始 Token: {result.original_tokens}")
print(f"压缩后 Token: {result.compressed_tokens}")
print(f"节省比例: {result.savings_ratio:.1%}")

6.5 方式四：MCP Server 模式

# 安装 Headroom MCP Server
headroom mcp install

# 之后在任何支持 MCP 的客户端中使用
# Claude Desktop、Cursor、Windsurf 等都会自动发现 Headroom 的工具

6.6 压缩模式选择

Headroom 提供三种压缩模式：

# 在 proxy 模式下指定压缩级别
headroom proxy --port 8787 --compression=balanced

# 在 wrap 模式下指定
headroom wrap claude --compression=aggressive

七、headroom learn：Agent 的"错题本"

这是 Headroom 最具创新性的功能，也是它区别于所有竞品的独特设计。

7.1 工作原理

# 分析失败会话并提取教训
headroom learn

# 查看学到的教训
headroom learn --show

# 清除学习记录
headroom learn --clear

headroom learn 会自动分析 Agent 的失败会话（比如：代码修改后测试失败、部署后服务崩溃、Review 后被拒绝），提取失败原因和修正方案，然后自动写入 Agent 的配置文件：

• CLAUDE.md（Claude Code 用户）
• AGENTS.md（OpenClaw 用户）
• GEMINI.md（Gemini Code 用户）

7.2 实际效果示例

假设 Agent 在一次会话中犯了以下错误：

1. 修改了 utils.rs 中的排序函数，但没有更新对应的单元测试
2. 在 PR 中引入了一个 SQL 注入漏洞
3. 忽略了 .env.example 中新增的环境变量

headroom learn 会分析这些失败，自动写入 CLAUDE.md：

## Headroom Auto-Learned Rules

### 修改 Rust 函数时必须同步更新测试
- 失败案例：修改 utils.rs 的 sort_by_date() 后未更新 tests/utils_test.rs
- 修正方案：使用 `cargo test --test utils_test` 验证

### 用户输入参数化，禁止字符串拼接 SQL
- 失败案例：format!("SELECT * FROM users WHERE name = '{}'", name)
- 修正方案：使用预编译语句或 ORM 查询构建器

### 新增环境变量必须更新 .env.example
- 失败案例：添加了 DATABASE_POOL_SIZE 但未更新 .env.example
- 修正方案：检查 .env.example 和 config/default.toml 是否同步

下一次 Agent 启动时，会自动读取这些规则，避免重蹈覆辙。

这就是 Headroom 最杀手级的价值——不仅仅是省 Token，而是让 Agent 越用越聪明。

八、生产级最佳实践

8.1 CCR 仓库管理

# 查看当前 CCR 仓库大小
headroom ccr stats

# 清理超过 7 天的 CCR 数据
headroom ccr prune --older-than=7d

# 手动存储一条重要信息
headroom ccr store --key="deploy-config" --value="..."

# 手动检索
headroom ccr retrieve --key="deploy-config"

8.2 多 Agent 协作配置

当你使用多个 Agent 时，配置共享的 CCR 仓库：

# 设置统一的 CCR 仓库路径
export HEADROOM_CCR_PATH="$HOME/.headroom/shared-ccr"

# 所有 Agent 都使用同一个 CCR 仓库
headroom wrap claude --ccr-path="$HEADROOM_CCR_PATH"
headroom wrap cursor --ccr-path="$HEADROOM_CCR_PATH"

这样 Agent A 的发现可以被 Agent B 直接引用。

8.3 监控与调试

# 实时监控压缩效果
headroom monitor --live

# 导出压缩日志
headroom logs --output=compress-2026-06-09.json

# 对比压缩前后的内容
headroom diff --session=abc123

8.4 与现有工具链集成

Headroom 不排斥竞品，反而积极集成：

# 使用 RTK 作为 CLI 输出的预处理器
headroom config --preprocessor=rtk

# 使用 lean-ctx 作为替代上下文工具
headroom config --context-tool=lean-ctx

这种"组合优于替代"的思路非常务实——不强制你放弃现有工具，而是在现有工具链上叠加价值。

九、局限性坦诚分析

9.1 不适合的场景

1. 沙箱环境：Headroom 需要在本地运行进程，在严格沙箱环境中无法使用
2. 超低延迟场景：压缩本身需要计算时间（通常 50-200ms），对延迟极度敏感的场景可能不适合
3. Provider 原生压缩已够用的场景：如果你只用 OpenAI 且它的内置压缩效果满足需求，叠加 Headroom 的边际收益可能不大
4. 对 Token 成本不敏感的场景：免费 API 或无限 Token 的场景下，压缩的 ROI 不高

9.2 需要注意的问题

1. 首次使用的学习成本：需要理解 CCR、压缩模式、Agent 记忆等概念
2. CCR 仓库增长：长期使用后 CCR 仓库会增长，需要定期 prune
3. 模型兼容性：Kompress-base 模型主要针对英语优化，中文内容的压缩效果可能略差
4. 调试复杂性：压缩层增加了一层间接性，排查问题时需要考虑「是 Agent 的问题还是压缩层的问题」

十、学术前沿：上下文压缩的下一站

Headroom 不是孤立存在的技术，它站在一个快速发展的学术领域之上。2025-2026 年上下文压缩领域有几个重要方向：

10.1 ACON 框架（微软研究院，ICML 2026）

ACON（Agent Context Optimization）提出在自然语言空间中迭代优化压缩策略。不同于 Headroom 的结构化压缩，ACON 让压缩模型「用自然语言重新表述」关键信息，然后在 Agent 任务上评估压缩效果，迭代优化。

在 AppWorld、OfficeBench 和 Multi-objective QA 基准上，ACON 实现了 26-54% 的 Token 削减，同时提升任务成功率。更令人兴奋的是，将压缩策略蒸馏到小模型后，小模型作为长周期 Agent 的性能最高提升 46%。

10.2 SWE-Pruner（2026.01）

SWE-Pruner 是一个专门针对编码 Agent 的自适应上下文裁剪框架。它使用 0.6B 参数的 Qwen3-Reranker 作为骨干网络，通过 CRF（条件随机场）层进行行级别的保留决策。

在 SWE-Bench Verified 上实现最高 54% Token 减少，交互轮次减少最高 26%。思路和 Headroom 的 IntelligentContext 类似，但更专注于代码场景的行级决策。

10.3 ContextPilot（MLSys 2026）

ContextPilot 引入了上下文复用机制，通过最大化前缀复用和去重来加速 LLM 预填充阶段。在推理延迟上实现了最高 3 倍的加速。

这和 Headroom 的 CacheAligner 思路不谋而合——通过稳定化前缀来提升 KV Cache 命中率。区别在于 ContextPilot 侧重于延迟优化，Headroom 侧重于 Token 成本优化。

10.4 Headroom 的独特定位

在这些研究方向中，Headroom 的 CCR（可逆压缩）和跨 Agent 记忆是独有的。学术方案大多关注单次请求的压缩效果，而 Headroom 关注的是长期、跨 Agent、可逆的上下文管理——这是一个更工程化的视角，也是直接面向生产需求的。

十一、与其他上下文管理方案的对比

十二、总结：为什么 Headroom 值得你关注

Headroom 的核心价值可以用一句话概括：让 AI Agent 在更少的 Token 里看到同样多的信息，而且什么都不丢。

它解决的不是一个边缘问题。随着 AI Agent 从「辅助工具」进化为「生产力基础设施」，Token 成本正在成为规模化部署的最大瓶颈之一。Headroom 提供了一个工程化、可逆、跨 Agent 的解决方案。

五个核心亮点：

1. 60-95% 的 Token 节省：通过六大专用压缩算法，针对不同内容类型做最优压缩
2. CCR 可逆存储：压缩不丢信息，LLM 可按需取回原始数据——这是行业首创
3. 跨 Agent 记忆：打破 Agent 孤岛，Claude Code 的发现可以让 Cursor 直接使用
4. headroom learn 自学习：Agent 从失败中学习，越用越聪明
5. KV Cache 优化：CacheAligner 稳定化前缀，提升推理性能

一个关键判断：在 LLM 推理成本大幅下降之前（可能需要 2-3 年），上下文压缩是最高 ROI 的成本优化手段。Headroom 的可逆设计和自学习能力，让它在众多方案中脱颖而出。

推荐优先尝试的场景：

• 每天使用 AI Agent 超过 4 小时的开发者
• 同时使用 2 个以上 AI Agent 的团队
• 月 Token 费用超过 $100 的重度用户
• 需要在 Agent 之间共享知识的协作场景

项目地址：https://github.com/chopratejas/headroom

文档：https://headroom-docs.vercel.app/docs

压缩模型：https://huggingface.co/chopratejas/kompress-base

License：Apache 2.0