会话摘要式记忆是什么
长对话不能无限携带历史：把早期轮次滚动压缩成结构化摘要，最近若干轮保留原文——摘要负责记得住，原文负责细节准确。触发时机按 token 阈值或对话轮数，摘要与会话绑定，以便跨天继续聊。最常见的退化是摘要越滚越抽象：每压缩一次都会磨掉一点细节，最后只剩空泛结论。所以摘要里必须刻意保留具体数字与标识，并定期抽查早期提过的事项还能不能答对。
基本信息
| 触发条件 | 按 token 阈值或对话轮数触发压缩 |
|---|---|
| 摘要结构 | 已确定、待办、关键事实、未解决 四栏 |
| 原文保留 | 最近若干轮不摘要，保持细节准确 |
| 存储方式 | 摘要与会话绑定，支持跨天续聊 |
| 合并规则 | 新摘要在旧摘要基础上合并，不直接覆盖 |
| 退化风险 | 越滚越抽象，具体数字与编号丢失 |
典型使用场景
- 长期陪伴式助手：跨天续聊时保持上下文连贯
- 客服会话：把已有结论与待办带进新会话
- 多轮任务执行：保留任务参数与已确认选项
- 工单协作：交接时把会话要点结构化传下去
- 多轮工具调用：摘要历史以免占用工具回包额度
滚动摘要提示词
滚动摘要提示词
把以下对话压缩为结构化备忘（不要丢数字与专有名词）：
## 已确定
## 待办
## 关键事实
## 未解决
对话：{{early_turns}}
# 若已有旧摘要，与它合并而不是直接覆盖
# 每轮都保留具体数字与订单编号，抽象结论无法替代
# 定期抽查：上周说过的条件现在还能不能答对摘要分区与作用
| 分区 | 放什么 | 为什么需要 |
|---|---|---|
| 已确定 | 已达成的结论与决议 | 避免重复讨论同一问题 |
| 待办 | 任务、负责人与时间 | 跨天续聊时能接着推进 |
| 关键事实 | 数字、编号、专有名词 | 细节最易丢失，必须刻意保留 |
| 未解决 | 悬而未决的问题 | 防止话题被静默丢掉 |
只压不存原文会让用户在追问细节时答不上来；关键会话应保留可回溯的原始记录，摘要只作为上下文压缩手段。
换用更小的模型做摘要可以省钱，但必须抽检质量：摘要错误的后果会沿会话一路传递，越到后期越难纠正。