当用户意图开始漂移，LLM为什么集体掉队？
论文：LLMs Get Lost in Evolving User Intent 作者：Jihoon Tack、Philippe Laban、Jennifer Neville（Microsoft Research） arXiv ID: 2607.20734 提交日期：2026-07-22
核心摘要
你有没有遇到过这种情况：让一个 LLM 帮你做点事，聊着聊着发现它开始"装睡"了——你明明改了需求，它还在按第一轮的设定往下走？
这篇 Microsoft Research 的论文干了一件挺狠的事：他们把大家熟悉的单轮 benchmark（GSM8K、BIRD-SQL、BrowseComp+、SWE-Bench Verified）改造成了多轮动态对话，让用户意图在过程中不断被揭示、修改、甚至整个任务被切换，最后再回到原始问题看模型到底答对没有。
结果让人有点尴尬。GPT 5.5 这种在单轮能拿 99% 的模型，在 GSM8K 上只要 6 次意图转换就掉到 80.5%；DeepSeek V3.2 在 BIRD-SQL 上甚至相对掉了 30.3%；BrowseComp+ 上 Mistral Large 3 从 17% 直接掉到 5%，近乎腰斩。 更扎心的是，作者发现这不是某个模型的特例，而是当下所有 LLM 家族的通病。
我看完第一反应是：过去几年我们一直在卷单轮 benchmark 的天花板，但其实真实的人机交互从来不是一次说清楚的。这篇文章把"意图动态演化"这个长期被忽略的维度摆到台面上，给我们敲了一记警钟。
问题动机：单轮评测正在骗我们
现在所有 LLM 的 benchmark——不管是 MMLU 还是 GSM8K——基本都是这样一个套路：给你一个完整、清晰的问题，你给一个完整、清晰的回答。这种评测方式的最大问题是，它压根不反映真实使用场景。
真实用户是怎么用 LLM 的？很少有人第一次就把需求说清楚。更多的人是这样的：
- 第一句："帮我找家好吃的餐厅"
- 第二句："我在纽约"
- 第三句："哦对，我是素食主义者"
- 第四句："等等，改成布鲁克林吧"
- 第五句："那顺便帮我订个位子吧，晚上7点"
你看，到这里用户其实已经改了 4 次意图——揭露了位置和饮食偏好，修改了一次位置，整个任务从"找餐厅"切换成了"订位"。如果 LLM 还在按第一轮"找纽约的素食餐厅"去执行，那就完全错位了。
问题来了：现在的 LLM 到底能处理多少这种动态变化？
作者调研了现有的多轮 benchmark，发现都有硬伤： - 很多用 LLM-as-judge 打分，可靠性存疑 - 用户侧可控性差，只能模拟"逐步揭露信息"，没法模拟"修改"和"切换任务" - 标注成本爆炸
所以他们换了个思路：既然单轮 benchmark 这么多、这么全、还能自动验证，那能不能把它们"反过来用"？
核心方法：把单轮问题"反推"成多轮对话
这是我觉得最漂亮的地方。传统的多轮 benchmark 是"先设计用户脚本，再看 agent 怎么回应"，但这个团队反着来——先把单轮问题当成多轮对话的"最后一轮"（anchor），然后反推前面几轮可能发生了什么。
意图状态：把"用户想要什么"形式化
作者定义了一个非常干净的结构化意图状态：
别被符号吓到，翻译成人话就是：
- \(f_t\)：用户想干什么（function），比如"找餐厅"
- \(\mathcal{C}_t\)：干这件事需要的所有参数，比如"位置、人数、菜系"
- \(\mathcal{C}_t^{\mathtt{rev}}\)：到现在为止已经告诉模型哪些参数了
- \(y_t\)：最终答案（验证用）
三种意图转换：把"动态变化"拆成三类
有了结构化定义后，用户可能怎么改主意就成了一个枚举问题。作者归纳出三种基本动作：
| 类型 | 用户做了什么 | 模型的难题 | 例子 |
|---|---|---|---|
| Argument reveal（参数揭露） | 告诉你一个新的参数 | 把新信息整合进已有判断 | "我在纽约"→"哦对，我是素食主义者" |
| Argument revision（参数修改） | 改掉之前说过的参数 | 抛弃旧的信念，update 而非积累 | "纽约"→"改成布鲁克林" |
| Function switch（任务切换） | 整个任务换了一个 | 识别任务切换，同时复用相关上下文 | "找餐厅"→"帮我订个位子" |
这三种动作可以发生在同一轮里，但每轮只算一次主要的意图更新。
反向合成：怎么从"最后一题"反推"前面几轮"
整个模拟器分三步走：
- 意图抽取（Intent Extraction）：用 LLM 从单轮数据 \((q, y^*)\) 中抽出 function \(f^*\)、参数集合 \(\mathcal{C}^*\)，这就是最后一轮的 anchor
- 反向扩展（Retrospective Expansion）：为了支持"修改"和"切换"，需要反向生成
- 反事实参数：比如真实答案是"布鲁克林"，那反事实就是"纽约"——用户先说纽约，后面再改回布鲁克林
- 前驱函数：为了支持任务切换，生成"完成这个任务会自然过渡到原任务"的前驱任务，比如"找餐厅"自然过渡到"订位子"
- 情境化模拟（Situated Simulation）：把这些候选拼成一个 T 轮的对话序列，并加上几轮规则约束
- 最后一轮必须是 anchor
- 第一轮至少要有一个 function 和一个参数
- 任务切换只能在当前任务已经"说清楚"之后发生
- 反事实必须在修订之前出现
最后渲染器把每轮的"意图变化量"（\(\Delta \mathcal{I}_t\)，只渲染新增/修改的部分）拼成自然语言，加上一句口语化的前缀（"等等，我忘了说……"、"那顺便……"），让对话读起来像真人。
图1：从单轮 SWE-Bench 实例反推出一个 4 轮多轮对话的示例，GPT 5.5 在四个 domain 平均分从单轮 82.5% 掉到动态 72.1%。
图2：三种意图转换的示意——从同一句"在纽约找家好餐厅"出发，参数揭露是补一个"素食"约束，参数修改是把"纽约"换成"布鲁克林"，任务切换是从"找餐厅"切到"订位子"。
图3：反推合成的三步流程图——4.1 抽取 anchor 意图，4.2 反向扩展生成反事实参数和前驱函数，4.3 把候选按规则调度到具体的 T 轮对话里。
我个人挺喜欢这套设计的。它不依赖 LLM-as-judge，而是用源数据集的原生 verifier 直接打分——最后一轮就是原始问题，那答案对了就是对，错了就是错。这个验证信号在多轮场景下极其稀缺，他们用了一个巧妙的"时间倒流"思路绕过去了。
实验结果：单轮王者，多轮青铜
实验选了 4 个领域的可验证单轮 benchmark：GSM8K（数学）、BIRD-SQL（SQL）、BrowseComp+（搜索）、SWE-Bench Verified（代码）。每个任务做成最多 7 轮、6 次意图转换的多轮对话。
主实验：差距比你想的还大
下面是核心数据，我直接复刻了 Table 1（去掉了 logo 装饰）：
| 模型 | GSM8K 单轮 | GSM8K 动态 | BIRD 单轮 | BIRD 动态 | Browse 单轮 | Browse 动态 | SWE 单轮 | SWE 动态 |
|---|---|---|---|---|---|---|---|---|
| GPT 5.1 | 98.0 | 82.0 (-16.3) | 72.0 | 66.0 (-8.3) | 49.0 | 34.0 (-30.6) | 72.0 | 0.0 (-100) |
| GPT 5.2 | 99.0 | 83.0 (-16.2) | 77.0 | 61.0 (-20.8) | 53.0 | 50.0 (-5.7) | 80.0 | 62.0 (-22.5) |
| GPT 5.5 | 99.0 | 80.5 (-18.7) | 80.0 | 71.0 (-11.3) | 65.0 | 57.0 (-12.3) | 86.0 | 80.0 (-7.0) |
| Gemini 3.1 Pro | 98.0 | 82.0 (-16.3) | 75.0 | 72.0 (-4.0) | 51.0 | 40.0 (-21.6) | 86.0 | 84.0 (-2.3) |
| DeepSeek V3.2 | 96.5 | 78.5 (-18.7) | 76.0 | 53.0 (-30.3) | 36.0 | 15.0 (-58.3) | 76.0 | 76.0 (+0.0) |
| Grok 4.20 | 97.5 | 79.5 (-18.5) | 75.0 | 67.0 (-10.7) | 50.0 | 33.0 (-34.0) | 84.0 | 0.0 (-100) |
| Kimi K2.5 | 97.0 | 75.5 (-22.2) | 72.0 | 66.0 (-8.3) | 44.0 | 30.0 (-31.8) | 82.0 | 70.0 (-14.6) |
| Kimi K2.6 | 96.5 | 79.5 (-17.6) | 75.0 | 68.0 (-9.3) | 55.0 | 52.0 (-5.5) | 86.0 | 72.0 (-16.3) |
| Mistral Large 3 | 95.5 | 73.5 (-23.0) | 61.0 | 56.0 (-8.2) | 17.0 | 5.0 (-70.6) | 56.0 | 0.0 (-100) |
几个特别扎眼的点：
第一，SWE-Bench 上的"清零"现象。GPT 5.1、Grok 4.20、Mistral Large 3 在单轮能拿 56-72%，到多轮直接 0%。作者分析后发现，这些模型在 100 次工具调用预算内跑不完整个 7 轮对话——它们被卡在"extended thinking"里，思考太久了根本来不及答。所以你看，问题不是答错，是根本没答。
第二，工具调用越多不一定越好。在 SWE 任务里，作者统计了模型在多轮场景下平均每轮的工具调用分布：100 次里不到 4 次是真正执行性的（pytest、python、apply_edits），剩下的都是 sed、grep、find、ls 这种探索性操作。模型把时间都花在"找文件"上了，等到要写代码的时候 budget 早就用完了。
第三，单轮分高的模型多轮不一定强。看看 BrowseComp+ 那一列：DeepSeek V3.2 单轮只有 36%，看起来不强，但 6 个模型里它多轮相对跌幅其实是中等的；反过来，Gemini 3.1 Pro 单轮拿 51%，多轮掉到 40%，相对跌幅 21.6%——单轮强不代表多轮强。单轮榜单不能预测多轮表现。
第四，BrowseComp+ 上 Mistral Large 3 从 17% 掉到 5%，相对跌幅 70.6%——这是所有模型、所有任务里最惨的。这任务本来就是深度搜索，需要的"信息整合"能力多，多轮一加几乎要了它的命。
消融实验：哪种转换最要命？
主实验里每个模型都被喂了 6 次转换（2 次揭露 + 2 次修改 + 2 次切换）。消融实验单独抽出每种类型，看它们分别对性能影响多大。
Table 2（GPT 5.1 / 5.5）：
| 场景 | GSM8K 5.1 | GSM8K 5.5 | BIRD 5.1 | BIRD 5.5 | Browse 5.1 | Browse 5.5 | SWE 5.1 | SWE 5.5 |
|---|---|---|---|---|---|---|---|---|
| 单轮基线 | 98.0 | 99.0 | 72.0 | 80.0 | 49.0 | 65.0 | 72.0 | 86.0 |
| 只参数揭露 | 97.0 | 96.0 | 72.0 | 76.0 | 45.0 | 46.0 | 50.0 | 80.0 |
| 只参数修改 | 96.5 | 97.0 | 72.0 | 77.0 | 47.0 | 61.0 | 62.0 | 90.0 |
| 只任务切换 | 87.0 | 87.5 | 59.0 | 65.0 | 45.0 | 62.0 | 0.0 | 82.0 |
| 修改+切换 | 82.0 | 84.5 | 65.0 | 68.0 | 33.0 | 54.0 | 0.0 | 80.0 |
| 三种组合 | 82.0 | 80.5 | 66.0 | 71.0 | 34.0 | 57.0 | 0.0 | 80.0 |
我看完这张表的第一反应："任务切换"是真正的硬骨头。在 GSM8K 上，单独的"参数揭露"和"参数修改"几乎不掉分（5.5 还涨了一点到 97%），但一旦加入"任务切换"，5.1 直接掉 11 个点；BIRD 上切换导致 5.1 从 72 掉到 59。"修改"和"揭露"都是"加信息"，模型只要 accumulate 就行；"切换"是"换任务"，得真去 revise 自己的 belief state。
更绝的是 SWE-Bench 上 5.1 那一列——只要有"任务切换"，直接归零；没有切换的话 5.1 单用"参数修改"能拿 62%，"揭露"也有 50%。对 GPT 5.1 来说，SWE 任务一旦被切就直接崩。
转换越多越糟，且没有收敛迹象
下图是 Figure 4（scaling_transition），把三种转换类型分别从 0 加到 3，看模型在 GSM8K 上的表现：
图4：在 GSM8K 上，三种转换的次数从 0 增加到 3 时的准确率变化。函数切换（最右）下降最陡，参数修改（中）次之，参数揭露（左）最缓。
这个图有几点值得注意：
- 任务切换的下行斜率明显最陡：4 个模型从 ~95% 一路掉到 83-87%
- 参数修改：整体也掉，但有"先掉后回稳"的趋势
- 参数揭露：曲线最平，跟 Table 2 一致——这玩意是"积累"动作，模型还能 handle
直觉上这很好理解：任务切换要求模型丢弃之前的积累，从头来过；参数修改只是换一两个值；参数揭露只是往里加东西。 但这些曲线有个让人不安的共同点——没有任何模型出现"回升"或"收敛"的迹象。这意味着如果对话再长一点、再多几次切换，性能可能继续掉。真实用户那种长达几十轮的对话会是什么表现？想想就头大。
任务切换后，模型很快"忘了"前情
图5：在 GSM8K 含 6 次转换的对话中，对比"切换后立即评估"与"切换后再经历几次其他转换再评估"的准确率。4 个模型在后一种情况都掉了 8-20 个点。
这张图揭示了一个挺反直觉的现象：模型在"刚刚切换完"那一下表现还行，但只要切换之后再混进几次参数揭露/修改，正确率就崩了。
比如 GPT 5.2，切换后立即评估还能拿 88%，但再经历几次其他转换后评估只剩 68%，掉了 20 个点。其他三个模型也都是 8-15 个点的跌幅。这说明模型不是不会处理"切换"，而是没法同时处理"切换"和"切换之后又发生的其他变化"。
这其实是一个长程推理的问题。 真实场景里用户不会一次性说"我要换任务"，而是说"那顺便换个任务吧，顺便这个参数也改一下，顺便那个约束也加一下"——多重变化叠在一起，模型的 belief state 就跟不上了。
困难任务 + 多轮 = 双重打击
图6：在 BIRD-SQL 上，对比"有提示（简单）"与"无提示（困难）"的相对跌幅。单轮场景从易到难只掉 3.6%，多轮场景从易到困难掉 9.0%。
BIRD-SQL 这个任务很有意思——同一个问题，提供 expert hint 就简单，不提供就难。作者用这个特性做了"难度可控"实验。
结果：单轮场景下，难度从简单到困难，GPT 5.5 只掉 3.6%（83% → 80%）；多轮场景下，同样难度变化让它掉了 9.0%（78% → 71%）。
多轮动态环境放大了任务难度的影响。 这个发现的工程意义挺大的——如果用户本来就要处理一个复杂任务（比如 SQL、code），再叠加上意图漂移，模型的表现会比单轮 benchmark 预测的差得多。
模型越大越稳？没那么简单
图7：GPT 5.4 系列在 GSM8K 上的单轮 vs 动态对比。三个规模都从 ~98% 掉到 74-80%。
如果"模型越大越扛得住多轮"就好了，但 Figure 7 告诉我们事情没那么简单。GPT 5.4、5.4 mini、5.4 nano 在 GSM8K 上单轮都拿 97-98%，多轮全部掉到 74-80%。模型大小没救得了它们。
多轮下模型会"想太多"
图8：开源模型在 BIRD-SQL 单轮 vs 多轮下的平均每轮 token 用量。4 个模型在多轮场景下都多用了 21-31% 的 token。
Figure 8 揭示了一个工程上的隐患：多轮场景下模型会"过度思考"。Kimi K2.6、DeepSeek、Mistral 在多轮下每轮多烧 21-31% 的 token。这意味着同样的任务，部署成多轮动态 agent 不仅效果差，成本也变高。
关键深入分析：模型到底在哪儿掉链子？
看到这儿，一个自然的问题浮上来：模型在多轮下的失败，是"读不懂当前意图"还是"理解了但行动错"？
作者做了一个非常巧妙的实验：直接给模型"上帝视角"——在每轮开始前，把当前的真实意图重述一遍（oracle recap）。如果这样能解决问题，说明模型是"读不懂"；如果还是不行，说明是"读懂了但行动错"。
图9：GPT 5.5 在 BIRD-SQL 上，3 种记忆机制（无、Prompt Recap、Oracle Recap）的对比。绿线是单轮基线 80%。
这张图的信息量很大：
- Prompt Recap（每轮提醒"请回顾上下文"）：在大多数场景下有小幅提升，但 function switch 上才 1 个点
- Oracle Recap（每轮直接把真实意图塞进 prompt）：在 function switch 上从 65% 拉到 75%，效果立竿见影
- 但即便 Oracle Recap 也追不上单轮的 80%——绿虚线在所有柱子之上
作者的解释很到位：Prompt Recap 测试的是"能不能从对话历史中提取出当前意图"，Oracle Recap 测试的是"知道意图后能不能在冲突上下文里行动"。两者都帮不了多少，说明模型同时在两个环节都掉了链子。
再看一下 Table 3 的"逐轮意图追踪"数据：
| 转换类型 | 出现 1 次 | 出现 2 次 |
|---|---|---|
| 参数揭露 | 99.0 | 98.0 |
| 参数修改 | 98.0 | 96.0 |
| 任务切换 | 89.0 | 82.0 |
逐轮让模型自己说"用户现在想干什么"——参数揭露/修改几乎 100% 答对，任务切换只答对 82-89%。 这直接告诉我们：任务切换是"识别当前意图"这个环节就出了问题。
这跟前面 Oracle Recap 实验能对应上：即使把意图直接喂给模型，在任务切换场景下还是比单轮低 5 个点。说明：
- 模型识别任务切换有困难（Table 3 数据）
- 即使正确识别了，模型在"切换后融合前情 + 后续更新"这个整合环节也会出错（Figure 5 数据）
- 简单的"加提示词"远远不够
我的判断：这是一份"重塑评测标准"的论文
我读完之后的整体判断：这不是一篇"卷分数"的论文，而是一份"我们的评测方式在骗我们"的诊断报告。 类似 SWE-Bench 那种"清零"的现象，不是因为模型变笨了，而是因为我们压根没在测它们真正会被用到的能力。
它做对了什么
- 方法上的巧妙：把单轮数据"反推"成多轮，既保留了可验证性，又获得了多轮的灵活性。这比"重新标注多轮数据"的成本低一个数量级
- 结构化的意图定义：用 (function, arguments, revealed set) 表达意图，把"动态变化"这个模糊概念拆成了三种可枚举的转换
- 诊断的深度：不仅报告"性能掉了"，还区分了"识别错误"和"行动错误"，这让后续工作有明确改进方向
它没解决的 / 有疑问的地方
- 用户行为的多样性：这套框架假设每轮只有一次意图转换，但真实用户经常一句话里同时改两件事（"改成布鲁克林，顺便订7点的位"）。这限制了它对真实场景的代表性
- 没有中间验证：因为最后一轮才打分，中间轮就算明显跑偏，只要最后一轮对了就算过。这意味着 benchmark 报告的分数可能高估了真实多轮场景的表现
- 实验规模偏小：每个任务只用了 50-200 个样本，再加上多轮场景下成本是单轮的数倍，预算确实吃紧。这可能让一些噪声较大的对比不太稳（比如 K2.5 vs K2.6 在不同任务上的相对位次有反复）
- Render 偏机械：用户侧是用规则 + 模板渲染的，不是 LLM 驱动的 simulation。这意味着评测的"用户侧"风格偏单一。论文自己也在 limitations 里提到了这点
跟同期工作比，定位在哪？
在多轮/Agent 评测这片红海里，这篇论文的独特贡献是"反推式生成"——之前的工作要么是手工标注（贵且死板），要么是 LLM 模拟用户（灵活但难验证），他们用了一种"既自动化又可验证"的中间路线。
另外一个隐藏贡献是任务切换这个维度。之前的 multi-turn benchmark 主要测"逐步揭露信息"（under-specification），而这篇把"修改"和"切换任务"放到了同等重要的位置。特别是 function switch 这个维度，揭示了一个之前被低估的失败模式——单轮榜单上的王者，到了真实动态场景可能就是个青铜。
跟我的工程经验对得上吗？
我之前做过一些 agent 项目，最大的教训之一就是：用户在多轮里会推翻自己。一个常见的失败是：模型"过度记忆"了第一轮的需求，到第三轮用户改主意了，它还是按第一轮的来。还有一种是"过度敏感"——用户随口提了句"那顺便也看看 X"，模型就把主要任务给丢了。
这篇论文的发现跟我的经验完全对得上：单轮 benchmark 高分 ≠ 多轮体验好。如果你想部署一个真正能用的 agent，多轮动态场景的测试是绕不过去的。
给做 Agent 的人几条建议
如果你也在做 LLM agent 相关的项目，这篇论文至少给了这几条启发：
-
别只盯着单轮榜单选模型。Sonnet 这种可能在 MMLU 上 80 分的模型，到你真正的多轮产品里可能掉到 60 分。先在你自己的多轮场景上做小规模 pilot。
-
任务切换的容错设计是关键。参数揭露/修改你的系统勉强能 handle（说到底就是 accumulate），但任务切换需要模型有"重新审视自己当前任务"的能力。可以考虑：
- 每轮开始时显式让模型"重新总结用户当前想做什么"
- 检测到任务切换的信号（function 关键词变化）时，主动 reset 一部分 context
-
记录对话历史用结构化格式（intent tree），而非纯自然语言
-
Memory 不是万能解。这篇论文里 Oracle Recap（把真实意图直接喂进去）都追不上单轮基线，说明光加 memory 没用。真正缺的是"在复杂上下文中选择性关注相关部分"的能力——这其实指向更基础的问题：长上下文推理。
-
别让模型"想太久"。Figure 8 显示多轮下 token 涨 21-31%，但 Figure 5 表明思考时间长了反而更容易在切换后掉链子。长思考 ≠ 高质量。SWE-Bench 上"清零"现象就是模型在 extended thinking 里耗光 budget。
-
设计你的 verifier 时考虑多轮。如果你在做 agent 产品，最后一轮对了不代表多轮体验好。可以考虑"中间验证"——比如在用户明显改主意的那一轮，看模型是否真的更新了 belief。
写在最后
这篇论文让我重新审视了一个基本问题：LLM 评测到底在测什么？
过去几年，大家卷单轮 benchmark 卷得飞起——MMLU 涨 1 个点、HumanEval 涨 2 个点、GPQA 涨 5 个点，新闻稿可以写一整页。但这些数字对真实用户体验的预测力越来越弱了。 一个能在 GSM8K 拿 99% 的模型，在一个 7 轮的动态对话里掉到 80%——这中间的 19 个点，就是"评测"和"使用"之间的鸿沟。
作者在 conclusion 里的一句话我特别认同：
"Today's LLMs do not yet faithfully track and act on the user's evolving intent, a capability invisible to static evaluation yet critical for future collaborative agents."
翻译过来就是：当前 LLM 还不能忠实地追踪并执行用户不断演化的意图——这种能力对静态评测不可见，但对未来的协作型 agent 至关重要。
我们可能需要从"刷分"转向"测真"——评测一个模型，不应该看它能不能答对一个精心设计的标准问题，而应该看它能不能在用户反复横跳的情况下还保持不掉链子。
这篇论文给出了一种可行的路径：用"反推式生成"把单轮数据自动扩展成多轮动态对话，保留可验证性，同时获得了对真实用户行为更高保真度的模拟。这个思路本身的价值，可能比任何具体数字都大。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我。