超级管理员
楼主
Headroom 是个 39k 星标的项目，定位是 AI Agent 的上下文压缩层，可作为库、代理或 MCP 服务器使用，提供 6 种压缩算法，宣称可减少 60% 到 95% 的 token 消耗，支持本地优先与可逆压缩。
为什么上下文压缩成了独立一层
Agent 跑长任务时，上下文里堆的东西很杂：工具返回的大段 JSON、网页正文、日志、历史对话。真正有用的可能只占一成。
不压缩，窗口很快满，成本直线上升；粗暴截断，关键信息丢了，Agent 开始犯傻。
可逆这一条最关键
压缩如果不不可逆，等于有损。有损压缩在 Agent 场景里很危险：模型看不到原文，却要基于它做判断。
可逆意味着压缩只改变表示形式，需要时能还原原文。技术上通常靠引用、摘要加指针、结构化折叠。
六种算法怎么选
粗略分三类：结构化压缩（去掉 JSON 冗余字段、折叠重复结构）、语义压缩（摘要加检索）、格式压缩（缩写标识符、去空白）。
工具类返回用结构化压缩效果最好，几乎无损；长文档用语义压缩；日志用格式压缩。
代理形态的价值
作为代理插在模型与工具之间，不用改业务代码。这对存量系统最友好。
要注意
一，压缩会引入延迟。省下的 token 成本要和增加的延迟权衡。
二，缓存会失效。压缩后的前缀变化频繁，提示缓存命中率会掉，这一项成本常被漏算。
三，调试变难。出问题时你看到的是压缩后的内容，排查要多一步还原。
建议
先在工具返回这一层做，收益最大风险最小。别一上来压对话历史，那部分最容易出问题。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。
