作者：先看一段我们复盘项目时复现出来的真实对话，也是多轮对话设计没做好的典型现场（细节已脱敏）：
用户：你们A型号的整机保修几年？ 机器人：A型号整机保修一年，主要部件三年。 用户：那B呢？ 机器人：请问您想了解什么呢？ 用户：就保修啊，我刚问过A了。 机器人：A型号整机保修一年，主要部件三年。
用户第三句话就三个字，机器人当场失忆，绕一圈又回到原点。客户不耐烦，不是因为他等得久，而是他发现自己说了等于白说。类似的对话我们在验收测试里见过太多变体：换型号、换单号、换日期，AI的记性都撑不过一轮。
失忆的根源：上下文没有管理
大模型本身有上下文窗口，能记住当前会话里的内容，为什么还会失忆？因为多数粗糙的实现里，每一轮请求只带了最近一条用户消息，历史根本没传给模型；或者传了，但没做指代消解——“那B呢”里的“那”字指什么，需要把上一轮的话题接过来改写完整，模型拿到的却是一句光秃秃的话，检索自然查不到东西。失忆不是模型能力不够，是工程上没把历史递到它手里。顺带纠正一个误区：上下文窗口大不等于记得对。窗口是容量，不是管理——几十条历史一股脑塞进去，模型照样会被前文的无关信息带偏；还有一类失忆是自己造成的：切分会话记录时按条切丢了顺序，模型读到的时间线是乱的。该精简的精简，该排序的排序。
三个基本手段
第一个是指代消解：把用户的省略说法补写成完整问题，“那B呢”改写成“B型号整机保修几年”再去检索，命中率立刻不一样。改写这一步可以单独用一个轻量模型做，快且便宜，别把主模型的时间花在理解“那”“它”上。第二个是槽位记忆：订单号、型号、收货地址这类关键信息，识别出来就存进会话状态里，后续轮次随时取用，不指望模型“记性好”。槽位记忆最典型的场景是预约类对话：时间、人数、地点、设备，用户东一句西一句，系统逐个补齐，集齐了才提交——没做槽位记忆的，用户说三遍时间它也记不住。第三个是超长对话摘要：咨询聊了几十分钟，历史超过窗口了，把前文压缩成一段摘要接回去，保住关键事实，扔掉寒暄。三个手段都不玄乎，全是确定性的工程活，难的不是写出来，是每个用户的说法都测到。
记多久、记什么，要有边界
会话内的记忆相对简单，难的是边界问题：用户上周来问过A型号，这周来问“B”，要不要记得？这涉及用户级记忆，牵出两个现实问题——隐私与权限（记忆里存了手机号、订单，谁能看到），以及数据时效（订单状态会变，旧记忆反而是干扰）。我们的默认建议：企业场景先只做会话级记忆，业务事实用结构化的会话状态存取，别把什么都塞进对话流——会话一结束状态就清掉，干净；用户级记忆等会话级跑稳、隐私评审过了再上。记忆里存什么也要过一遍法务：聊天记录、订单号属于个人信息，存多久、谁能看，先问再存。部署形态与数据存放的边界，AI客服方案页里有按场景的说明。
换话题和没听懂，也要有预案
真实对话不会乖乖顺着来。用户聊一半突然问别的，槽位要挂起，回头还能接上；AI没听懂时，主动澄清一次，“您是想问保修还是维修？”——最多一次。澄清问题也要设计得省力：给选项比开放提问好，用户按一下就行，“请详细描述您的问题”又把球踢回去了。连着追问两遍，用户的血压就上来了，这时候直接给选项或者转人工，比让AI再猜一轮体面得多。转人工时把前面的对话摘要一并带过去，别让客户把说过的话再打一遍字——多轮对话的愤怒，多半攒在重复这一步。
多轮体验是调出来的，不是设计一次就到位的。想让这个过程短一点，联系我们聊聊，我们把别的项目踩过的坑先讲给你听，能省好几个迭代周期。