很多人调 Claude Code、Codex、opencode 的第一反应，是换更强模型、加更长上下文、买更贵套餐。更便宜的第一步，是先看一次 session 里到底有多少内容值得送进模型。
我今天修 daily-digest 管线时，这个问题很明显：真正要判断的是几条质量门结果，模型却会反复读完整草稿、审稿意见、修复提示和上下文说明。短文只有一千字，review/repair 调用的输入却能膨胀到数千 token。成本不只来自模型价格，也来自喂进去的材料太粗。
一个 Agent 跑任务时，模型经常读到未经处理的工具回声：grep 返回 200 行，只有 8 行相关；日志刷了几屏，核心报错只有一条；RAG 召回 5 个 chunk，其中 3 个在讲同一段背景；文件被整段塞进去，模型只需要函数签名和附近几行。上下文窗口看起来很大，实际被噪声吃掉了。
Headroom 这个 GitHub 项目抓的就是这层浪费。它在 README 里把自己定义为 AI agents 的 context compression layer：内容进入 LLM 前，先压缩 tool outputs、logs、RAG chunks、files 和 conversation history。README 给了多类压缩收益示例，这些数字先当项目方口径看；对工程师更有用的是它提示了一个位置：LLM 入口前需要上下文闸门。
先别急着装工具。先做一次账本。我的本地日志会长成这样：
{"caller":"opencode-user-review","provider":"opencode","prompt_tokens":1450,"completion_tokens":377,"total_tokens":1827}
再用排序命令找大户：
jq -r '[.caller,.provider,.prompt_tokens,.completion_tokens,.total_tokens] | @tsv' calls.jsonl \
| sort -k3,3nr | head
看三件事：哪个 caller 的输入最长；长输入是否主要来自工具输出、文件全文或重复上下文；压缩后答案是否变差。如果只是为了省钱把证据删掉，后面会用更贵的返工还债。
我的接入顺序会很保守：先在日志、搜索结果、RAG chunk 上做局部压缩；记录压缩前后 token、通过率、回取原文次数；连续几天稳定后，再考虑 proxy 或 MCP server。Headroom 支持多种接入形态，但我不会第一天就包住整条调用链。全局代理太容易误伤 patch、审计和配置修改。
适合压缩：搜索结果、重复日志、长堆栈、重叠 RAG chunk、只需局部阅读的大文件。
谨慎压缩：生成 patch、审计配置、合规审查、合同阅读、schema 修改。这些任务里，少一行原文就可能变成错误判断。
一周内能做的事：给自己的 Agent 管线加调用日志，按 prompt_tokens 排序，先挑前三个输入最长的 caller 改。比例降下来，准确率不掉，再引入 Headroom 或自研更窄的压缩器。
参考资料：headroomlabs-ai/headroom GitHub README。
