678 字
3 分钟
上下文压缩怎么做:该保留什么,哪些信息可以再生
判断原则

压缩不是删除历史,而是把可随时恢复的信息移出上下文,把会改变后续决策的信息留下来。

应保留的四类信息#

  1. 用户意图与偏好:包括原始需求、用户中途的纠正和明确偏好。
  2. 关键决策与理由:不仅记录“做了什么”,还记录“为什么这样做”,防止压缩后推翻已有结论。
  3. 踩坑记录:保留报错现象和修复方式,避免重复尝试已失败的路径。
  4. 当前状态:正在做什么、剩余待办、下一步计划。

可丢弃信息的判断标准#

判断标准可以概括为:可再生即可丢弃。

信息为什么可压缩保留方式
文件内容可以再次读取记录文件路径或关键结论
命令输出、搜索结果可以重新执行保留命令、结论和必要上下文
中间推理草稿通常没有独立复用价值仅保留最终决策与理由
图片、长文档需要时可回读用占位符或引用路径代替

丢弃不等于删除。完整 transcript 可以留在磁盘,摘要中附上路径;需要细节时再回读原始记录。

Coding Agent 的分层压缩思路#

一种典型实现会分层处理:

  1. 微压缩:优先把较旧的 Read、Bash、Grep 等工具输出替换为占位符,只保留最近几条。文件内容本身可重新读取,因此最适合先移出上下文。
  2. 全量压缩:当 token 接近阈值时,单独请求模型生成摘要,重点保留用户意图、关键决策、踩坑与修复、当前状态和下一步。
  3. 恢复注入:压缩后按预算重新注入最近读取的文件、当前计划和已使用的 skill,让 Agent 不必从头检索。
  4. 原始记录兜底:完整对话仍保留在 transcript 中,摘要附上可回读路径。

摘要请求本身也超长怎么办?#

将摘要对象继续分块:先对较旧内容做更细粒度摘要,再合并为高层摘要;同时保留原始记录的可回读路径。这样不会因为“为压缩而压缩”再次超出窗口。

压缩会影响性能和成本吗?#

会有影响:摘要和检索本身都需要额外调用、额外 token 与一定延迟。但与持续携带大量无关上下文相比,分层压缩通常能让后续任务更稳定、成本更可控。关键是只在必要时压缩,并让摘要真正服务于当前任务。

上下文压缩怎么做:该保留什么,哪些信息可以再生
https://blog.xqcherry.top/posts/interview/ai-engineering/context-compression/
作者
xqcherry
发布于
2026-09-24
许可协议
CC BY-NC-SA 4.0