前言

大型语言模型的对话并不是“无限记忆”。每一轮输入、输出、工具调用结果和系统提示词，都会占用上下文窗口。当历史内容逐渐逼近窗口上限，系统必须做出选择：丢弃、压缩，或把信息转移到外部存储。

真正困难的部分不在于“把内容变短”，而在于：如何在减少 Token 的同时，尽可能保住后续推理真正需要的事实、约束、决策和未完成事项。

本文梳理几种常见的上下文压缩策略，并讨论它们适用的场景与代价。

先理解上下文里真正值得保留的是什么？

一段长对话通常混杂了不同价值的信息：

用户目标与成功标准
已确认的事实、偏好与约束
已经做过的操作及其结果
当前任务的进展、未决问题和下一步
中间推理、寒暄、重复说明和已失效的内容

压缩的核心原则是：保留对未来决策有影响的信息，而不是保留所有曾经出现过的信息。

例如，用户说过“希望方案兼容 Windows、不能上传敏感数据、预算有限”，这些约束应长期保留；而某次已经被纠正的排错猜测，通常只需保留最终结论。

策略一：滑动窗口 — 直接保留最近消息

这是最简单的做法：当上下文过长时，删除最早的一部分内容，只保留最近的 N 条消息或最近 N 个 Token。

优点:

实现极其简单，几乎没有额外成本。
最近消息通常与当前对话最相关。
没有二次摘要带来的信息失真。

缺点:

早期的重要约束很容易消失。
对长周期任务不友好，例如持续数天的项目协作。
模型可能重复提问已经回答过的问题，或违背早先约定。

适用场景：短问答、客服式会话、一次性创作请求，以及上下文高度局部化的任务。

策略二：滚动摘要 — 把旧对话浓缩成“记忆”

滚动摘要会在历史达到阈值时，将较早的对话交给模型总结，再用摘要替换原始内容。之后继续对话，必要时再更新摘要。一个有效的摘要不应只是“对话内容概述”，而应包含结构化状态，例如：

用户目标：完成一份面向管理层的 AI 落地方案。
关键约束：中文；预算有限；优先私有部署；截止日期为周五。
已完成：完成需求梳理、比较了三种部署路线。
已决策：采用混合部署方案。
待完成：补充成本测算、风险清单和演示提纲。
重要事实：数据不得离开内网。

优点：

大幅降低 Token 占用。
能维持相对连贯的长期任务状态。
很适合多轮协作、写作、编码和项目推进。

缺点：

摘要天然有损：细节可能被遗漏、误解或过度概括。
多次“摘要的摘要”会造成信息漂移。
如果摘要缺少结构，模型仍可能找不到关键事实。

适用场景：多数长对话任务的默认选择，尤其是复杂但不要求逐字追溯历史的工作流。

策略三：分层摘要 — 短期、长期与档案记忆分开存

分层摘要是对滚动摘要的升级。它不把所有旧内容压成一段文字，而是按时间和重要性维护多个层级：

短期上下文：最近几轮原始消息，保留细节。
工作摘要：当前目标、约束、进度、待办事项。
长期记忆：稳定的用户偏好、长期项目规则、反复使用的事实。
原始档案：完整历史，按需检索，不常驻上下文。

分层摘要

优点：

比单一摘要更稳定、更可控。
能同时保留近期细节与长期关键事实。
方便针对不同任务动态组装上下文。

缺点：

系统设计更复杂，需要定义记忆写入、更新、冲突处理和过期机制。
长期记忆若不治理，会积累错误或过时的信息。
需要额外模型调用或规则引擎，成本更高。

适用场景：长期 AI 助手、复杂代理系统、持续项目协作，以及需要记住用户偏好的产品。

策略四：结构化状态压缩 — 保存“任务状态”，而不是复述对话

对软件开发、流程执行、研究分析等任务，最有价值的往往不是自然语言摘要，而是可验证的结构化状态。

例如，一个编码助手可以维护：

{
  "goal": "修复支付接口的重复扣款问题",
  "constraints": [
    "不能改变已有数据库表结构",
    "必须补充自动化测试"
  ],
  "files_changed": [
    "src/payment/service.ts",
    "tests/payment.test.ts"
  ],
  "findings": [
    "重试机制没有幂等键校验"
  ],
  "next_actions": [
    "增加幂等键校验",
    "执行回归测试"
  ],
  "open_questions": []
}

优点：

信息密度高，且便于程序读取、校验和更新。
对任务型工作尤其可靠。
可避免长篇自然语言摘要中的模糊表达。
很容易与工具调用、数据库、工作流引擎结合。

缺点：

对开放式讨论、情感交流和创意写作覆盖不足。
数据结构设计不当时，关键细节可能无处安放。
状态更新错误会直接误导后续行为。

适用场景：编码代理、工单处理、数据分析、自动化流程和多步骤执行任务。

策略五：检索增强 — 不常驻保存，需要时再找回来

检索增强并不强迫模型把所有历史塞进上下文。系统会将历史消息、文档、工具结果等切分后建立索引；当新问题到来时，根据语义相似度、关键词、时间和任务关联度，取回最相关的片段。

检索增强

优点：

可扩展到远超上下文窗口的历史量。
原始信息仍可保留，必要时可追溯。
对知识库问答、长文档分析、长期项目很有效。

缺点：

“检索错了”会比“忘了”更危险：模型可能自信地依据错误片段回答。
切分粒度、索引质量和重排序策略都会显著影响结果。
检索本身增加延迟、基础设施复杂度和运行成本。
相似不等于相关；时间顺序、权限和任务状态也常常很重要。

适用场景：企业知识库、长文档助手、研究型代理、跨会话项目资料管理。

策略六：重要性评分与选择性保留

不是所有内容都同等重要。系统可以为消息或事实打分，优先保留：

明确的用户偏好与硬约束
已作出的关键决策
尚未完成的待办事项
被多次引用的事实
与当前目标直接相关的信息
近期出现且尚未被替代的信息

相反，可优先淘汰寒暄、重复表达、已解决的问题，以及被后续结论推翻的中间推理。

优点：

比纯时间截断更聪明。
能以较小的上下文预算保留高价值信息。
可以与摘要、检索、分层记忆组合使用。

缺点：

“重要性”本身很难准确判断。
看似不重要的细节，可能在后续成为关键线索。
打分机制会引入偏差；例如系统可能过度偏好近期信息。

适用场景：上下文预算严格、对话内容密集、且任务目标明确的智能体系统。

策略七：语义去重与版本合并

长对话中常常反复出现同一信息：

用户多次强调同一个偏好；
模型反复复述同一个结论；
文件内容经过多轮修改；
某个方案先被提出、再修订、最后确认。

此时不必保留所有版本。更好的做法是保留“最新有效版本”，同时维护必要的变更记录。

例如：

1
2
3

旧约束：预算不超过 10 万元。
新约束：预算可提高至 15 万元，但需分阶段投入。
有效约束：总预算上限 15 万元，优先控制首期投入。

优点：

能显著减少重复 Token。
让上下文更清晰，减少旧信息与新信息冲突。
对反复迭代的需求和文档特别有效。

缺点：

合并时必须识别“修订”与“补充”的区别。
过早删除旧版本会损失决策依据。
对需要审计或追责的场景，仍需保留完整版本链。

适用场景：需求迭代、代码修改、文档协作、方案评审和项目管理。

策略八：外部化记忆 — 把上下文变成可引用的工件

另一种思路是让模型少记一点、多写一点：将长期信息外部化到文档、任务看板、数据库、代码仓库或知识图谱中。

例如：

将需求写入 requirements.md
将决策写入 ADR（架构决策记录）
将待办事项写入任务系统
将实验结果写入结构化表格
将实体关系写入知识图谱

之后模型不必从聊天历史中“记住”一切，而是通过工具读取这些工件。

优点：

信息可审阅、可协作、可版本控制。
降低模型记忆错误的影响。
非常适合真实工作环境中的长期项目。

缺点：

需要额外维护，模型与用户都要遵守记录纪律。
外部工件与对话不同步时，会产生新的混乱。
工具调用失败、权限限制和格式不统一都会影响体验。

适用场景：团队协作、软件工程、研究项目、合规要求高的企业流程。

没有“最佳策略”，只有合适的组合

实际系统通常不是单独使用一种策略，而是组合使用：

任务类型	推荐组合
短问答	滑动窗口
长篇写作	滚动摘要 + 语义去重
编码代理	结构化状态 + 文件检索 + 最近消息
企业知识助手	检索增强 + 权限过滤 + 工作摘要
长期个人助手	分层记忆 + 重要性评分 + 用户可编辑记忆
高风险业务流程	结构化状态 + 外部化工件 + 原始记录可追溯

一个成熟的上下文管理系统，通常遵循这样的顺序：

保留当前任务的原始细节；
将稳定事实、决策和约束提炼成结构化记忆；
将其余历史归档并建立检索能力；
回答前按当前问题动态取回最相关的信息；
定期清理过时、冲突或低置信度的记忆。

总结：压缩的本质，是管理注意力

上下文窗口并非单纯的容量限制，它迫使我们回答一个更本质的问题：在下一步行动前，系统究竟需要知道什么？

好的压缩系统不会追求“记得越多越好”，而是追求：

关键约束不丢失；
已作决策不反复；
当前任务不断线；
历史证据可追溯；
错误记忆可纠正；
有限上下文优先服务于当前目标。

当对话从一次性问答走向长期协作，上下文压缩就不再是幕后优化，而会成为决定 AI 是否真正可靠、连贯和可用的核心能力。

让长对话不断线：上下文压缩的方法

前言