《LLM 上下文压缩选型：Headroom 与微软 LLMLingua 深度对比，谁才是 Agent 的最佳拍档？》

微软 LLMLingua（EMNLP 2023，LongLLMLingua 见 ACL 2024）是困惑度驱动提示压缩的学术标杆：小语言模型为每个 token 打分，丢弃低信息片段，论文宣称最高 20 倍压缩且下游损失极小。Headroom（chopratejas/headroom）走工程路线——本地 8787 端口代理、CCR 可逆存储、按内容类型路由（JSON、AST、散文），以及与 OpenClaw + Headroom 运行手册 等 Agent 一等集成。

构建常开 LLM Agent 的团队面临分叉：在 Python 流水线嵌入 PromptCompressor（偏研究、适合离线 RAG 入库），或将 ANTHROPIC_BASE_URL 指向 Headroom 垫片（偏运维、适合在线网关零改代码）。二者互补而非替代——它们优化不同层级：LLMLingua 在提示词语义层做 token 级剪枝，Headroom 在传输与归档层做结构压缩与可逆 CCR。本文是生产 Agent 运维的决策矩阵：困惑度剪枝 vs 代理 CCR、何时叠加 headroom proxy --llmlingua，以及可复现的八步评测手册——不含租用价格表。

压缩模型并排对比

LLMLingua family (Microsoft Research)
  Small LM (GPT-2-small / LLaMA-7B class)
    → token perplexity p(token | context)
    → drop low-perplexity tokens (budget controller + iterative passes)
    → optional distribution alignment to target LLM
  LongLLMLingua adds:
    → contrastive perplexity p(question | document)
    → document reorder ("lost in the middle" mitigation)
    → coarse-to-fine compression for RAG stacks

Headroom (engineering stack)
  Incoming messages (tools, logs, JSON, code, chat)
    → CacheAligner (KV-cache-friendly prefixes)
    → ContentRouter
         ├─ SmartCrusher (JSON arrays/objects)
         ├─ CodeCompressor (AST: Py/JS/Go/Rust/…)
         └─ Kompress-base (agentic prose, HF model)
    → CCR stores originals locally; model calls headroom_retrieve
    → Proxy forwards /v1/messages to Anthropic/OpenAI/Bedrock

可引用： LLMLingua 靠 SLM 困惑度删 token；Headroom 按内容类型路由并保留可逆 CCR归档——设计目标正交，可单独选型也可叠加。前者擅长同质长文与 RAG 重排序；后者擅长 Agent 工具 JSON、代码 AST 与需审计原文的合规场景。

决策矩阵：学术 vs 工程

场景 A：长文档堆 RAG

画像： 法务、客服或内部 wiki 问答——10–50 份 PDF 切块拼进单一提示，末尾附用户问题。上下文以自然语言段落为主，工具调用较少。

LLMLingua 适配： LongLLMLingua 为此而生。按 微软示例 使用 condition_in_question="after_condition"、reorder_context="sort"、rate=0.55。对比困惑度在文档噪声大、需按问题重排 chunk 时优于 vanilla LLMLingua，论文报告 NQ 多文档 QA 可提升 +21.4%。

Headroom 适配： 块内混有 JSON 元数据 + 散文（工单导出、知识库内嵌 CI 日志）时更强。代理模式可在不改 LangChain/LlamaIndex 胶水代码的前提下压缩上下文，并保留 CCR 供模型按需检索原文段落。

若 X 则 Y： 若瓶颈是多文档排序与 lost-in-the-middle，则先原型 LongLLMLingua。若瓶颈是 Agent 循环里异构 tool+json 上下文，则先原型 Headroom 代理。

场景 B：常开编码 / 运维 Agent（OpenClaw 类）

画像： 夜间仓库审计、MCP stdio 工具、兆字节级 linter JSON——每轮对话上下文持续膨胀，且混入大量结构化工具输出与堆栈跟踪。

LLMLingua 适配： 离线批量压缩静态提示时可作前置步骤。若每次网关调用都跑 compress_prompt()，除非有 SLM 结果缓存，否则每次都会增加 SLM 推理延迟，难以满足 p95 < 2s 的在线 SLO。

Headroom 适配： 为此形态设计——有文档的 OpenClaw 插件、/stats 与 /stats-history Prometheus 指标、headroom mcp install。代理在请求路径上透明压缩，模型可通过 headroom_retrieve 按需取回原文。LaunchAgent 布线见 OpenClaw + Headroom 运行手册。

若 X 则 Y： 若需要 macOS launchd 网关上的即插即用代理，则选 Headroom。若发布带冻结提示的研究流水线，则在入库阶段用 LLMLingua。

场景 C：混合栈（二者兼得）

Headroom 支持 headroom proxy --llmlingua——在 SmartCrusher、CodeCompressor 等结构压缩器之后，可选叠加微软困惑度压缩器做更深一轮 token 剪枝。典型流程：先剥除 JSON 冗余键与重复日志行，再对剩余散文段落做 SLM 困惑度压缩。代价：约 2 GB 额外依赖（torch + SLM 权重），冷启动 10–30 秒（见 Headroom 代理文档）。

若 X 则 Y： 若评测显示 SmartCrusher 仍留 >30% 冗余 JSON 或散文段落，则仅在 24 GB Mac mini M4 上启用 --llmlingua --llmlingua-rate 0.3 做 A/B。若延迟 SLO 要求 p95 < 2s，则仅用结构压缩器 + CCR，不跑 ML 通道。

推荐路径

• 若优化 ACL 式 RAG 基准，则从 LongLLMLingua PromptCompressor 与微软 rate 参数扫描起步。
• 若运维 OpenClaw / Claude Code / Cursor 舰队，则从 Headroom 代理 起步，连续七晚观测 /stats-history。
• 若合规要求逐字审计轨迹，则优先 Headroom CCR，而非仅有损困惑度流水线。
• 若需要 KV-cache 压缩 研究，则评估 LLMLingua-2 与 微软研究院 缓存线。
• 若二者在自有轨迹上均未达 40% 节省，则先修提示设计——压缩救不了冗余工具往返。

八步评测运行手册

1. 冻结黄金提示集

采集 N≥20 条真实 Agent 轮次：工具 JSON、堆栈跟踪、系统指令与典型用户多轮追问。在 ~/compression-eval/fixtures/ 为每条 fixture 记录 SHA-256 校验和。

2. 基线 token 计数（未压缩）

从提供商控制台或 tiktoken 记录每条 fixture 的未压缩输入 token 数，作为后续对比基准。建议同时记录输出 token 与总延迟，便于计算压缩带来的端到端 ROI。

3. 运行 LLMLingua / LongLLMLingua 臂

pip install llmlingua

from llmlingua import PromptCompressor
pc = PromptCompressor(model_name="microsoft/llmlingua-2-xlm-roberta-large-meetingbank")
out = pc.compress_prompt(prompt_list, question=question, rate=0.55,
    condition_in_question="after_condition", reorder_context="sort",
    rank_method="longllmlingua")
compressed = out["compressed_prompt"]

记录 origin_tokens、compressed_tokens 与墙钟耗时（毫秒），并保存压缩后提示词副本供步骤 6 质量门禁复用。

4. 运行 Headroom 代理臂

pip install "headroom-ai[proxy]"
headroom proxy --port 8787 --log-file ~/.headroom/eval.jsonl

经 /v1/compress POST fixture，或将实时 Agent 流量路由至代理；从 /stats 读取 tokens_saved。

5. 可选混合臂

headroom proxy --port 8788 --llmlingua --llmlingua-rate 0.3

对比 p95 延迟与节省率提升，判断混合栈是否值得额外内存与冷启动成本；建议与纯 Headroom 臂并列记录七日滚动均值。

6. 质量门禁（同一下游 LLM）

用生产模型在相同温度下重跑每条压缩 fixture，禁止在评测臂之间切换模型版本。评分：结构化字段精确匹配、摘要由 LLM 评判、人工抽检 5%；任一臂质量门禁失败则不得进入生产 cutover。

7. Agent 回归套件

OpenClaw 运维：用各臂重放夜间审计任务；对比发现数量与已知种子 bug 的漏报率（false-negative）。若压缩导致审计结论漂移，应优先回退至 CCR 可逆路径或降低压缩率，而非直接全量上线。

8. 按工作负载选定方案

记录：RAG 入库 → LongLLMLingua，在线网关 → Headroom 代理，极限压缩实验 → 混合栈——内部发布结论并附 token 月度成本测算。

故障排查

LLMLingua 指令遵循崩溃

现象： 压缩后提示丢失否定词或 JSON 键名。

修复： 调高 rate（0.55 → 0.75，保留更多 token）。用 budget controller 豁免指令块。对照 LLMLingua-2，见 微软研究院。

Headroom 代理省 token 但 Agent 漏行号

现象： 审计 Agent 引用错误的 file:line。

修复： 指示模型在结案前调用 headroom_retrieve；单次复现可设 x-headroom-bypass: true。若 schema 键被剥离，收窄 SmartCrusher 规则。

两臂均慢于未压缩基线

现象： p95 延迟 > 3× 未压缩基线。

修复： LLMLingua——将 SLM 缓存于 GPU/MPS，对静态 fixture 离线批处理，避免在热路径重复加载模型。Headroom——禁用 --llmlingua，仅保留结构压缩器；代理与 OpenClaw 网关同机部署以降低 loopback 以外的网络往返。

若两臂在七晚 /stats-history 中均未稳定达到 40% token 节省，应回到提示工程：减少冗余工具往返、合并重复 linter 输出，再重新跑八步评测。

常见问题

Headroom 是 LLMLingua 的分支吗？

不是。Headroom 是独立的 Apache-2.0 项目，可通过 --llmlingua 可选调用 LLMLingua。默认路径使用 SmartCrusher、CodeCompressor 与 Kompress-base，而非仅依赖困惑度剪枝这一条路径。

何时困惑度剪枝优于按内容类型压缩？

当提示词以同质自然语言为主（长文、少量 JSON 孤岛），且能用已知问题锚点调优 LongLLMLingua 时。异构 Agent 工具输出通常更适合 Headroom 的 ContentRouter。

能否在 OpenClaw 里只用 LongLLMLingua、不用 Headroom？

可以——在 Skill 脚本里用 PromptCompressor 预压缩静态上下文（如仓库 README、固定规范文档）。但会失去每次请求的代理透明性、实时 /stats 观测与 CCR 可逆归档，除非自行实现检索层与原文存储。

LLMLingua-2 与 LongLLMLingua 有何区别？

LLMLingua-2 将压缩重构为 BERT 级编码器的 token 分类，微软报告称比迭代困惑度快 3–6 倍。Headroom 可通过 --llmlingua 叠加；速度与 SLO 需单独评估。

财务该为 20 仓库夜间审计舰队批哪个？

第一周对单仓库跑完八步评测，记录 token $/月 与 p95 延迟。若工具 JSON 占主导，Headroom 代理 + OpenClaw 通常运维集成更快、CCR 便于财务审计；若静态文档 RAG 占主导，LongLLMLingua 可能在质量/美元上更优——用数据说话，勿凭品牌选型。