在智能对话系统实际运行中，随着用户与模型交互轮次不断增加，输入给模型的文本长度会持续累积。当总 token 数超过模型设定的上下文窗口上限时，就会发生长对话上下文溢出，早期对话内容被迫丢弃，模型容易忘记用户之前提到的偏好、身份或待办事项，回答质量明显下降。
为什么长对话会发生上下文溢出
目前主流大语言模型都设有固定的上下文长度限制，例如某些模型支持 4k、8k 或 32k token。在多人协作、心理咨询、长期助手类场景中，用户可能连续对话成百上千轮，每轮都包含提问、模型回复与用户补充。这些历史内容逐轮拼接到提示词中，很快触顶。
一旦溢出，常见做法是直接截断最旧的内容。这种做法虽然让最新对话能送进模型，但会造成“前面说过的话模型听不见了”。比如用户在第一轮说自己对花生过敏，第三百轮模型若已丢失该信息，就可能推荐含花生的食谱，带来实际风险。因此，溢出不是单纯技术限制，更是体验与安全的隐患。
滑动窗口机制如何控制输入规模
滑动窗口指维护一个固定大小的对话缓存，只保留最近 N 轮或最近 M 个 token 的交互记录，更早的内容随窗口滑动被移出。它相当于给模型一个“短期记忆”，始终让最相关的近期语境进入推理过程。实现上可在服务端维护队列，每次组装提示词时取队尾片段。
举例来说，设置窗口为最近 10 轮对话。当用户说到第 50 轮，系统仅把 41 到 50 轮传给模型。这样做计算稳定、延迟低，适合高并发场景。不过滑动窗口的短板也明显：如果用户在第 5 轮定了重要计划，第 45 轮才接着谈，该信息早已滑出窗口，模型便无法衔接。所以它通常要搭配其他机制弥补长期记忆。
滑动窗口的常见参数
| 参数 | 含义 | 设置建议 |
|---|---|---|
| 窗口轮数 | 保留的最近对话轮次 | 客服场景 8 到 12 轮，闲聊可更少 |
| token 上限 | 窗口内最大 token 数 | 留足系统提示与回复空间 |
| 滑动步长 | 每次移出的单位 | 通常单轮或固定块 |
关键信息提取补足长期记忆
关键信息提取是在对话进行中，用模型或规则把用户身份、目标、约束、未结事项等压缩成简短摘要或结构化字段。例如自动生成“用户：张三，过敏源：花生，当前任务：预订下周北京酒店”。这段摘要体积小，可长期置顶在提示词开头，不受滑动窗口影响。
具体落地时，可每隔若干轮调用一次提取模型，输入全量或近期对话，输出更新后的记忆卡。也可借助命名实体识别与意图分类等传统方法降低成本。提取的内容应包含稳定事实与可变状态，避免把闲聊语气也写进去。这样即便滑动窗口丢掉了原文，模型仍能从摘要知晓核心背景。
两者如何配合形成完整方案
将滑动窗口与关键信息提取组合，通常采取“摘要前置加近期窗口”的提示词结构：最前面放提炼出的用户画像与事务状态，中间放最近数轮原文，最后放当前问题。模型既看到长期要点，又看到短期脉络，回答更连贯。
实践中可设定当对话超 20 轮启动提取，窗口固定 10 轮。若提取发现某旧信息被后续推翻，如用户改了出行城市，要及时覆盖原字段，防止摘要过期。通过定期合并与校正，系统能在有限上下文里维持数月级别的长程记忆，而不必盲目升级模型规格。
好的长对话架构不是无限拉长上下文，而是让重要的被记住，让临时的自然流动。
落地时的经验与注意点
首先，提取模型本身也可能出错，建议对关键字段做一致性校验，比如用户明确说不加糖，摘要却写偏好加糖，应在下次交互中由主模型察觉并询问。其次，滑动窗口大小需结合业务测试，过长增加成本，过短丢失语境。最后，把摘要与窗口内容用清晰分隔符标明，可减少模型混淆。
总体而言，面对长对话上下文溢出，滑动窗口解决了规模问题，关键信息提取解决了记忆问题。二者配合是以小博大的实用路线，特别适合资源受限又需长期服务的对话产品。开发团队应先梳理业务中哪些信息必须跨轮保留，再据此设计提取字段与窗口策略，才能事半功倍。