先说结论

大模型应用里最先炸掉的，往往不是模型本身，而是上下文。

你一开始觉得“多喂一点信息总没坏处”，后来就会发现：

• prompt 越塞越长
• 历史对话越堆越多
• RAG 召回越拉越满
• 工具返回越来越杂

最后模型不是不会答，而是看不过来。

所以最近像 Headroom 这类上下文压缩工具才会突然火起来。它们解决的不是“让模型更聪明”，而是一个很现实的问题：怎么在 token 有限、任务复杂、信息越来越多的情况下，把最有用的内容喂进去。

一句话概括：

上下文压缩不是删内容，而是把“该留下的东西”整理成模型能看懂、看得下、看得准的形式。

为什么上下文会越来越膨胀

很多人刚开始做 Agent 时，都会有一个很朴素的想法：既然模型吃上下文，那我就把能拿到的信息都给它。

听起来很合理，实际上很快就会失控。

因为真实任务不是单轮问答，而是连续执行：

• 第一步查资料
• 第二步看日志
• 第三步调工具
• 第四步处理失败
• 第五步再查一次

每一步都会往上下文里塞新的东西。时间一长，历史上下文就像滚雪球，里面混着：

• 原始问题
• 旧的推理过程
• 工具返回
• 中间失败
• 重试结果
• 已经过期的信息

模型不是只怕少，而是也怕多。信息一多，重点就容易被冲掉。

压缩到底在压什么

上下文压缩不是简单的“砍字数”。如果只是粗暴截断，很多时候会把关键证据一起砍掉。

更合理的做法通常是压这几类东西：

• 重复信息
• 过期信息
• 低相关片段
• 结构混乱的长输出
• 工具返回里对当前任务没用的细节

而保留的部分通常是：

• 当前任务目标
• 关键实体
• 时间线
• 决策依据
• 未解决的问题

也就是说，压缩做的是信息重排，不是单纯删除。

Headroom 这类工具为什么会火

因为它们把一件以前很散的事，做成了一个明确的系统层。

传统做法里，上下文管理经常是散装的：

• 在 prompt 里手写裁剪规则
• 在代码里自己拼接片段
• 在 Agent loop 里临时决定放什么

这会带来一个问题：你很难稳定复用。

而像 Headroom 这类工具，核心想法是先把上下文变成一个可治理对象：

• 哪些内容必须保留
• 哪些内容可以摘要
• 哪些内容必须丢弃
• 哪些内容要按优先级排序
• 哪些内容要在进入模型前先重写

这就像给 Agent 加了一个“前置整理台”。

真正好用的压缩，通常不是通用压缩

这点很重要。

如果你把所有任务都交给同一套压缩规则，效果通常一般。因为不同任务关注点不同：

• 修 bug 更看重报错、diff、依赖关系
• 做调研更看重来源、时间、结论冲突
• 写总结更看重事实、主线、结果
• 跑多轮任务更看重状态和未完成事项

所以更好的压缩，往往是任务感知的压缩。

也就是先判断：

1. 这轮任务的目标是什么
2. 现在处于哪一步
3. 当前最值钱的信号是什么
4. 哪些信息已经过期

然后再决定怎么压。

最容易踩的坑

第一，压缩过头。

把关键证据压没了，模型当然会胡说。

第二，只压长度，不压结构。

上下文虽然短了，但顺序乱了，模型还是看不懂。

第三，压缩策略不区分任务。

同一套规则套所有场景，最后往往两头不讨好。

第四，只压输入，不管输出。

工具返回如果不做结构化整理，下一轮上下文还是会炸。

什么时候你真的需要上下文压缩

如果你的系统已经出现这些情况，就该认真做了：

• 一轮任务会跑很多步
• 历史对话越来越长
• RAG 召回越来越多
• 工具输出越来越杂
• 模型开始记错重点

这时候上下文压缩不是优化项，而是生存项。

结尾

Headroom 之所以火，不是因为它发明了什么玄学新技术，而是因为它把大家一直在忍的痛点说破了：

Agent 真正的瓶颈，很多时候不是不会想，而是上下文太乱、太长、太杂。

把上下文整理好，模型才有机会把话说对。
把上下文压缩做好，Agent 才有机会把活干完。