目录

前言

一、滑动窗口：先把上下文长度管住

1.1 为什么一定要限制上下文

1.2 滑动窗口的正确用法

二、历史摘要：旧对话不丢，但必须“压缩”

2.1 为什么不能直接丢弃历史

2.2 摘要不是复述，而是“信息提纯”

三、对话状态跟踪：别让模型“回忆人生”

3.1 任务型对话：直接抽象成变量

3.2 指代消解：别让模型猜你在说谁

3.3 Prompt 不是一句话，而是一套结构

（1）角色与职责写死

（2）历史信息结构化呈现

（3）行为约束与行为指引

四、长期记忆：决定体验上限的不是模型

4.1 为什么“每次都当新用户”体验很差

4.2 什么该进长期记忆

总结

---

前言

很多人一做 AI 对话产品，就把问题归结为一句话：

“模型记不住上下文。”

但在真实项目里，90% 的多轮对话问题，并不是模型不行，而是对话系统的设计不过关。

如果你指望一个 LLM 在几十轮对话后，自动理解你在说谁、要干嘛、哪些信息是确定的、哪些是历史噪音——那不是在做产品，是在“祈祷”。

本文从工程与产品视角，总结一套可落地的多轮对话设计方法，核心目标只有一个：
👉 让模型少猜，让系统多负责。

---

一、滑动窗口：先把上下文长度管住

简而言之就是：模型对话过程中的短期记忆机制，让模型在对话过程中能够保持历史对话记忆，如“你”、“我”、“它”这种指代词出现在多轮对话过程中时，模型可以根据历史对话准确推动指的是谁，而不是瞎猜。

1.1 为什么一定要限制上下文

多轮对话最基础、也最容易被忽视的问题是：上下文无限增长。

后果只有三个：

• Token 成本不可控

• 推理时间越来越慢

• 模型注意力被历史噪音稀释，反而“变笨”

所以第一条铁律是：上下文必须有上限。

---

1.2 滑动窗口的正确用法

最简单、也最稳定的方案是：

• 只保留最近 N 轮对话（如 5 轮）

• 每一轮 = 用户 + 模型完整一次交互

这样做的好处：

• Token 长度线性可控

• 最近语境最相关，命中率最高

• 系统复杂度最低，易维护

滑动窗口不是“简陋方案”，而是所有复杂记忆机制的地基。

---

二、历史摘要：旧对话不丢，但必须“压缩”

2.1 为什么不能直接丢弃历史

只保留最近 5 轮会有一个明显问题：

• 用户早期明确过的诉求

• 已确认的重要事实

• 关键实体（人、地点、项目、案件）

这些信息不该因为时间久就消失。

---

2.2 摘要不是复述，而是“信息提纯”

历史摘要的目标不是“总结聊天内容”，而是保留对后续决策有价值的信息，例如：

• 用户的核心诉求

• 已确认的约束条件

• 明确出现过的关键实体

• 已达成的结论或阶段性结果

一句话原则：

只保留能解决 80% 上下文问题的信息。

实现方式可以是：

• LLM 自动摘要（带固定 schema）

• 规则 + LLM 混合抽取

• 任务完成后阶段性固化摘要

---

三、对话状态跟踪：别让模型“回忆人生”

3.1 任务型对话：直接抽象成变量

只要是任务型对话，就不该靠“聊天记忆”来维持。

比如：

• 出发地

• 目的地

• 时间

• 人数

• 偏好条件

正确做法是：

• 把它们抽象成结构化状态

• 每一轮更新状态

• Prompt 里只传当前状态

模型的职责不是记忆，而是基于当前状态做决策。

让模型填表，而不是翻聊天记录。

---

3.2 指代消解：别让模型猜你在说谁

用户最常见、也是最容易翻车的一类输入是：

“那明天呢？”
“这个可以吗？”
“换一个试试？”

这不是“自然语言很难”，而是系统没有做好指代消解。

正确的系统行为是：

在送给模型之前，先做 Query Rewrite：

• ❌ 那明天呢？

• ✅ 北京明天的天气怎么样？

实现方式可以是：

• 专用指代消解模型

• 规则 + 上下文实体池

• 轻量 LLM 重写

核心原则只有一句话：

别让模型猜你在说谁、说什么。

---

3.3 Prompt 不是一句话，而是一套结构

多轮对话里，Prompt 绝对不能“随便写”。

一个合格的 Prompt，至少要包含 3 个不可缺失的部分：

（1）角色与职责写死

• 你是谁

• 你负责什么

• 你不负责什么

这是为了限制模型的身份漂移。

（2）历史信息结构化呈现

• 历史摘要

• 当前状态

• 最近对话

必须有明确分隔符，而不是一坨自然语言。

（3）行为约束与行为指引

Prompt 不是喂信息，而是控行为，例如：

• 不允许编造

• 优先询问缺失字段

• 必须基于状态输出

Prompt 的本质是“控制接口”，不是聊天话术。

---

四、长期记忆：决定体验上限的不是模型

4.1 为什么“每次都当新用户”体验很差

如果用户每次进来：

• 偏好要重说

• 禁忌要重讲

• 使用习惯要重教

那只能叫能用，绝对谈不上好用。

---

4.2 什么该进长期记忆

长期记忆不等于全量记录，重点是：

• 用户偏好（更常选 B，不喜欢 A）

• 固定习惯（输出格式、风格）

• 明确禁忌（不接受某类方案）

下次对话，只需在 Prompt 里加一句：

“用户不喜欢 A，更常选择 B。”

模型的表现立刻就有了“人味”。

---

总结

一、滑动窗口

保留最近5-10轮，长度就可控；

---

二、历史摘要

旧的对话不丢，只留用户的诉求、关键的实体、已经确认的信息（解决80%上下文问题）；

---

三、对话状态跟踪

①任务型对话：直接抽象成变量。出发地、目的地、时间、人数等，模型无需回忆人生，只看状态；

②指代消解：必须前缀。“那明天呢”，这句话本质不是在聊天，是指代消解失败，最简单的优化是在送给模型之前，把问题改写成“北京明天的天气怎么样？”。可用专用模型或做query rewrite。一句话：别让模型猜你在说谁；

③prompt：prompt不是一句话，而是一套结构。多轮对话的prompt绝对不能随便写，3件事必须有：

▲角色和职责写死；

▲历史对话的结构化呈现，必须要有分隔符；

▲明确约束行为和行为指引（prompt不是喂信息，而是控行为）；

▲长期记忆决定体验上限：用户每次当新用户，那叫能用，不叫好用，用户的偏好，禁忌习惯，该存就要存，下次对话在prompt里面加一句：“用户不喜欢A，更常选B”，模型立刻就有了人味；

多轮对话准备不好90%不是模型的问题，而是产品本身设计不过关。

多轮对话系统的真相是：

模型只是执行者，产品设计才是导演。

如果多轮对话效果不好，别急着换模型、堆参数、上 70B+
先回头看看：

• 上下文是不是失控了？

• 该结构化的有没有结构化？

• 该系统做的事，是不是全甩给模型了？

多轮对话准备不好，90% 不是模型的问题，而是产品本身设计不过关。