把历史当数据来管：该留的常驻，该丢的别占位。
多轮对话为什么会"失忆"
一次对话越聊越长，模型却开始忘记前文，通常不是模型变差，而是上下文被挤掉或被截断：
超出窗口的部分被丢弃、或被摘要得只剩大概，关键细节就丢了。
把这件事当作上下文管理问题，而不是模型问题，解法会清晰很多。
三种基本手段
一、滚动摘要
把较早的若干轮压成一段摘要，保留：已确认的事实、用户的硬约束（时间、金额、偏好）、未完成的待办。
摘要要带来源轮次，方便回溯；摘要本身也要版本化，便于比较效果。
二、锚点（关键事实表）
维护一张结构化小表：{字段: 值, 来源: 第几轮, 置信度}。
它不参与摘要压缩，始终原样放进上下文。适合：用户名/ID、地址、金额、日期、已选规格。
这张表能显著减少"前面说过的又忘了"。
三、按需检索历史
不要把所有历史都塞回去，而是把历史存起来，按当前问题检索相关轮次再插入。
和文档检索同理：给历史轮次加标签（主题、时间），检索更准。
该丢什么、该留什么
| 该留 | 该丢 |
|---|---|
| 用户的硬约束与偏好 | 寒暄与重复确认 |
| 已确认的事实与决定 | 被推翻的中间方案 |
| 未完成的待办 | 冗长的工具原始输出（留结论） |
两个工程细节
· 明确"遗忘"的可见性：当摘要导致信息丢失时，让用户可查看"我记住的要点"，避免它悄悄记错；
· 设定会话边界：明确多久算新会话；跨会话只带锚点表，不带全文。
怎么验证
造 20 组多轮脚本，每组 8~15 轮，在中段埋入关键约束（例如"预算不超过 X"），
最后问一个依赖该约束的问题：
1. 全量历史全塞；
2. 摘要 + 锚点表。
比较约束遵守率。多数情况下第 2 种更稳、更省，而且长会话越往后优势越明显。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：提示词版本管理：把提示词当代码来管
下一篇：把 AI 输出接到业务系统：三种接线方式与各自代价 →
第 15 / 171 篇