678 字
3 分钟
上下文压缩怎么做:该保留什么,哪些信息可以再生
判断原则压缩不是删除历史,而是把可随时恢复的信息移出上下文,把会改变后续决策的信息留下来。
应保留的四类信息
- 用户意图与偏好:包括原始需求、用户中途的纠正和明确偏好。
- 关键决策与理由:不仅记录“做了什么”,还记录“为什么这样做”,防止压缩后推翻已有结论。
- 踩坑记录:保留报错现象和修复方式,避免重复尝试已失败的路径。
- 当前状态:正在做什么、剩余待办、下一步计划。
可丢弃信息的判断标准
判断标准可以概括为:可再生即可丢弃。
| 信息 | 为什么可压缩 | 保留方式 |
|---|---|---|
| 文件内容 | 可以再次读取 | 记录文件路径或关键结论 |
| 命令输出、搜索结果 | 可以重新执行 | 保留命令、结论和必要上下文 |
| 中间推理草稿 | 通常没有独立复用价值 | 仅保留最终决策与理由 |
| 图片、长文档 | 需要时可回读 | 用占位符或引用路径代替 |
丢弃不等于删除。完整 transcript 可以留在磁盘,摘要中附上路径;需要细节时再回读原始记录。
Coding Agent 的分层压缩思路
一种典型实现会分层处理:
- 微压缩:优先把较旧的 Read、Bash、Grep 等工具输出替换为占位符,只保留最近几条。文件内容本身可重新读取,因此最适合先移出上下文。
- 全量压缩:当 token 接近阈值时,单独请求模型生成摘要,重点保留用户意图、关键决策、踩坑与修复、当前状态和下一步。
- 恢复注入:压缩后按预算重新注入最近读取的文件、当前计划和已使用的 skill,让 Agent 不必从头检索。
- 原始记录兜底:完整对话仍保留在 transcript 中,摘要附上可回读路径。
摘要请求本身也超长怎么办?
将摘要对象继续分块:先对较旧内容做更细粒度摘要,再合并为高层摘要;同时保留原始记录的可回读路径。这样不会因为“为压缩而压缩”再次超出窗口。
压缩会影响性能和成本吗?
会有影响:摘要和检索本身都需要额外调用、额外 token 与一定延迟。但与持续携带大量无关上下文相比,分层压缩通常能让后续任务更稳定、成本更可控。关键是只在必要时压缩,并让摘要真正服务于当前任务。
上下文压缩怎么做:该保留什么,哪些信息可以再生
https://blog.xqcherry.top/posts/interview/ai-engineering/context-compression/ 目录