多轮对话中用户意图变化怎么办？追问、澄清和任务切换如何设计？
在多轮对话系统里，用户不会老老实实按你的剧本走。他们可能说着说着突然改主意，可能问着问着跳到另一个话题，也可能你的追问太多直接把人家惹烦了。这道题考的就是你怎么设计系统来接住这些"意外"。
核心要搞定三件事：识别意图什么时候变了、变了之后怎么追问或澄清、切换话题时怎么管理状态。
板块1：意图变化的三个陷阱
用户意图变化不是一种情况，是三种完全不同的情况，处理策略完全不同。
意图漂移：用户在同一个话题里微调。比如"帮我订一张去北京的机票"→"算了，高铁吧"→"还是飞机吧，要靠窗的"。这还好办，系统知道还在订票这个框架里，只是参数在变。
意图跳变：用户突然换话题。"帮我订机票"→"对了，明天天气怎么样？"→"刚才那个订单取消吧"。这种跳跃最难处理，因为你要快速判断：是新任务来了？还是临时插一句？还是要切回去？
追问失控：你为了搞清楚用户意图，连着问了一堆问题，用户已经不耐烦了。这往往是系统设计时没设定追问上限导致的。
用开车打个比方：用户就像车上的乘客，他可能突然说"刚才说的目的地不对，改去机场"，也可能刚说完又改口，也可能嫌你问太多直接下车了。系统要能接住所有这些变化，不能一变化就死机。
板块2：追问策略的平衡艺术
追问不是越多越好，关键是什么时候问、问什么、什么时候停。
核心策略是置信度阈值驱动。系统识别用户意图后，会给一个置信度分数。你设定一个阈值：
- 高风险操作：涉及钱、安全、法律合规的，阈值设高一点，置信度不够就必须追问确认
- 低风险操作：查个天气、播个音乐，阈值可以低，直接执行就行
举个例子：用户说"帮我转一万块"，置信度即使有0.8，你也得追问"是转到这个账户吗？"但用户说"放首歌"，置信度0.6直接放就行。
追问还要设定停止条件。通常用两个维度控制：
- 轮次限制：最多追问3-5轮，超过就触发兜底策略
- 用户反馈：用户表现出不耐烦（语气词、"算了算了"），立刻停止追问
类比一下：问路的时候，人家指一次你没听懂，可以再问一次。再问一次还不懂，你就该换个方式了，比如"那您能帮我看看地图吗"。不能一直问下去。
澄清和追问的区别要搞清楚：追问是系统主动发问来获取缺失信息，澄清是用户说了模糊的话系统请求确认。两者都是补全信息的手段，但触发条件不同。
板块3：话题切换与状态恢复
这是最容易出问题的地方。用户说"帮我订机票"→"等等，先看看我下周的日程"→"刚才那个机票还订吗？"
处理话题切换，核心是暂存-切换-恢复的流程：
识别切换信号：用户明确说"等等"、"先看下这个"、"先处理别的事"，或者语义上出现完全无关的话题。
暂存当前状态：把订机票相关的槽位、进度、上下文都存起来。就像秘书处理会议切换，先记录当前议题讨论到哪了。
执行新任务：切换到新话题，正常处理。
恢复之前状态：用户说"继续"或"刚才那个"的时候，把之前存的状态恢复出来，继续执行。
这里有个关键设计：三层记忆系统。
- 工作记忆：当前对话轮次的即时信息，处理完就清
- 短期记忆：当前任务的相关状态，用户可以切回来继续
- 长期记忆：跨任务的全局信息，比如用户偏好、历史订单
类比一下：你在写文档，突然要查个资料打开浏览器，查完关掉继续写文档——这就是工作记忆和短期记忆的配合。长期记忆就像你的个人知识库，随时可以调用。
状态恢复的时候要注意槽位冲突：如果用户在新任务里填了和旧任务同名的槽位，要判断是覆盖还是合并。比如订机票时存了"目的地：北京"，后来查日程时也涉及地点信息，这时候要小心别把北京冲掉。
板块4：对话状态追踪方案对比
对话状态追踪（Dialogue State Tracking）就是系统怎么记住对话进展。有三种主流方案：
隐式追踪：不显式维护状态，靠大模型自己"记住"上下文。优点是简单，缺点是随着对话轮次增加，模型容易遗忘早期信息，状态准确性下降。适合短对话。
显式追踪：每个槽位的值都显式存储、更新。优点是状态清晰可控，缺点是维护成本高，而且不同槽位之间可能有关联，更新逻辑复杂。
增量更新（推荐）：只更新变化的槽位，保留不变的部分。系统维护一个状态快照，每轮对话后对比，只记录diff。这是最实用的方案，兼顾了准确性和效率。
再打个比方：隐式追踪就像不记笔记，全靠脑子想；显式追踪是每句话都写下来；增量更新是只记变化的部分，定期整理。这就像好的学生做笔记的方式。
工程上，增量更新要配合槽位修改日志：记录每个槽位被谁（用户/系统/工具）修改的、什么时候改的、改成什么。这样既能追溯，也能支持撤销操作。
状态追踪的衰减问题也要注意：对话越长，早期槽位的权重越低。你可以在状态里加时间戳，或者用滑动窗口机制，只保留最近N轮的完整状态。
板块5：槽位管理与上下文工程
槽位是填满用户意图的"拼图块"，但这块拼图不是一次性拼完的，而是每轮动态调整。
槽位动态管理：每轮对话后，系统要判断哪些槽位需要新增、修改、删除。比如用户说"订明天的机票"→"改后天"，后天这个值就要覆盖原来的明天。
指代消解：用户会说"它"、"那个"、"刚才说的"，系统要理解这些指代词指向什么。通常需要在上下文里做实体链接，把代词还原成具体实体。
上下文窗口管理：对话长了，上下文token会爆。工程上要处理好哪些信息常驻、哪些按需加载：
- 常驻信息：系统提示词、用户偏好、当前任务框架
- 近期信息：最近3-5轮对话，完整保留
- 按需信息：历史任务摘要，用到再展开
工具返回的结果也要裁剪。比如查天气返回了一周的数据，但用户只问了今天，你就把其他六天的数据扔掉，节省上下文空间。
还有个容易被忽视的问题：AI生成内容对意图识别的干扰。系统自己生成的追问话术，如果太长太复杂，可能包含很多无关语义，干扰下一轮意图识别。解决方案是对AI生成内容做mask，只提取关键槽位信息。
面试怎么答
基础版（能过面试）：
多轮对话中处理意图变化，我主要从三个维度设计。首先是意图变化识别，区分意图漂移和意图跳变，前者在同一话题内微调参数，后者需要暂存当前任务。其次是追问策略，用置信度阈值驱动，高风险操作必须追问确认，但设定3-5轮上限避免失控。最后是状态管理，话题切换时暂存当前状态，恢复时用增量更新恢复上下文。核心原则是：系统要能接住用户的变化，但不能被用户带跑。
加分版（拿高薪）：
我要补充几点工程细节。一是三层记忆架构，工作记忆处理即时信息，短期记忆维护当前任务状态，长期记忆跨任务保留关键信息。二是增量状态更新，只记录每轮的diff，配合槽位修改日志支持追溯和撤销。三是上下文窗口工程，常驻信息压缩、近期信息完整、按需信息加载，工具返回结果也要裁剪。四是AI生成内容的mask方案，避免系统自己的话术干扰意图识别。这些细节决定了系统在实际场景中的鲁棒性。
一句话总结
多轮对话处理意图变化，核心是：识别变化类型 → 用置信度阈值控制追问 → 切换时暂存状态、切回时增量恢复。