意图漂移与分片指令：AI Agent多轮失效对比

一、对比背景：为什么要把这两类失效分开看

在真实的Agent应用里，用户很少一口气把需求说完整。以客服场景为例：用户先说要退货，接着改口说换货就行，最后又决定退货但要加急处理。如果处理请求的Agent最终给出的方案里，混进了用户中途提过、又明确否认的要求，用户的第一感受就是“它没在认真听”。

对聊天机器人来说，这类问题影响的是体验；但对会真正执行操作的Agent——调用工具、写代码、查数据库、改配置——来说，被旧意图带偏的代价可能是生成了错误的代码、在数据库里改错了字段。近期公开的一项研究把这类现象命名为意图漂移（intent drift）：用户的意图在多轮对话中发生了变化，但模型仍被已经过时、被用户推翻的旧意图影响，导致最终答案或操作出错。

不过，多轮对话里的失效并不只有这一种。更早的研究发现，如果把一个任务的信息拆成好几块、分批告诉模型，模型容易丢三落四，完不成任务，这就是分片指令（sharded instruction）场景。两类问题症状相似——最终输出都不符合用户预期，但根因不同，治理手段也完全不同。就像医生不能只说“你生病了”，必须区分是感冒还是过敏，才能对症下药。本文就把这两类失效模式放在同一框架下做系统对比。

二、对象定义：它们分别是什么

2.1 意图漂移（intent drift）

定义：用户意图在多轮对话中被修改、推翻或切换后，模型仍持续受到已被推翻的旧意图影响，在最终输出或执行中误用了过时信息。

关键特征有三个：

• 信息并不缺失，该说的用户都说了；
• 问题出在信息的状态：一部分信息已经“作废”，但听起来依然合理；
• 作废信息一旦被误用，会直接改变任务结果的对错——比如在SQL里多查了一个用户已明确否认的字段。

2.2 分片指令（sharded instruction）

定义：任务的完整信息被拆成多个片段、分批提供给模型，模型在跨轮聚合时丢三落四，导致最终输出覆盖不全、遗漏约束。

关键特征：

• 信息本身没有被推翻，前后片段之间不存在“否定关系”；
• 问题出在信息的完整性：需要模型自己把分散的约束拼起来；
• 错误表现为“少做了该做的事”，而不是“多做了不该做的事”。

三、相同点分析

两类失效虽然根因不同，但有不少共同点，这也是它们容易被混为一谈的原因：

1. 都只在多轮场景暴露。单轮、完整信息的输入下，两类问题基本都不出现；评测若只做单轮，会系统性高估模型能力。
2. 都与上下文管理相关。无论是对被推翻信息的干扰抑制，还是对分散信息的跨轮聚合，都依赖模型对多轮上下文的组织与检索能力。
3. 都会造成最终输出偏离用户真实需求，且偏离可被自动判分。研究上通常借助本身有标准答案、可自动打分的任务做载体，例如代码生成、数学题、SQL查询、文本摘要等。
4. 都无法靠“对话流不流畅”来判断。两类问题的对话过程可能都很自然，只有对照最终标准答案才能发现偏差。

四、核心差异分析

4.1 信息状态：被推翻 vs 未聚合

这是两者最本质的区别。意图漂移场景里，信息是完整的，但其中一部分已经被用户明确否认，属于“过时但听起来依然合理”的陷阱信息；分片指令场景里，信息只是分散，不存在任何一条被推翻的说法，难点在于跨轮拼装。

4.2 错误方向：多做 vs 少做

• 意图漂移的典型错误是“多做”：输出里混进了用户中途提过又明确否认的要求。比如用户已经说“不用管退款了”，最终生成的查询里却出现了退款字段。
• 分片指令的典型错误是“少做”：用户分四轮给出的约束，最终输出只覆盖了三轮，漏掉的部分正是判分扣分点。

这个方向差异在工程上很有价值：如果线上日志里发现Agent频繁执行了用户否认过的操作，优先排查意图漂移；如果频繁被投诉“漏需求”，优先排查分片聚合。

4.3 诊断难度：需要严格参照系 vs 相对直接

分片指令的诊断相对直接：只要拿到完整的约束清单，逐条核对最终输出即可。

意图漂移的诊断则难得多，必须排除其他多轮常见毛病的干扰——模型出错到底是“被旧意图带偏”，还是单纯记性不好、注意力分散？要证明前者，评测设计必须满足三个条件：

1. 参照系一：必须知道用户最终真正想要什么，即对话结束后存在明确的最终意图标注；
2. 参照系二：必须知道哪些信息是“过时但听起来依然合理”的，即陷阱信息要被显式标注；
3. 参照系三：过时信息一旦被误用，必须真的能改变任务的对错判断，即陷阱具备可验证性，而不是无关紧要的措辞差异。

近期研究提出的意图漂移评测框架，核心就是把有标准答案的任务改造成多轮对话：在对话中让用户不断提出、修改、推翻意图，同时保证陷阱信息可判分。相较之下，此前一项更接近的意图演进研究虽然测试了意图被揭示、修改、切换的情况，但只能回答“模型最终有没有跟上任务”，无法区分错误是旧意图带偏还是其他多轮通病——这是两类评测设计的关键差距。

4.4 评测构造方式

给出一个示意性的构造流程（伪代码）：

# 构造一个意图漂移测试样例（以SQL生成任务为例）
base_task      = "生成满足约束的SQL查询"       # 有标准答案，可自动判分
turn_1         = 提出"查询订单数据"             # 初始意图
turn_2         = 改口"顺便看退款信息"           # 意图修改
turn_3         = 明确推翻"不需要退款相关字段"    # 旧意图作废，形成陷阱
turn_4         = 补充"只看最近30天"             # 新增有效约束
ground_truth   = 按最终意图 + 有效约束生成的标准SQL
trap_check     = 最终SQL若包含退款字段 → 意图漂移命中
coverage_check = 有效约束是否全部满足 → 排除分片式遗漏

注意最后一步：先做覆盖性检查排除“漏信息”，再做陷阱检查确认“用错信息”，这是把两类失效解耦的关键。

4.5 缓解手段

• 针对意图漂移：执行前做意图对齐校验；对用户明确否定的内容做显式标记并从有效上下文中降权；执行类操作增加确认环节；在日志中记录意图变更轨迹，便于事后归因。
• 针对分片指令：维护跨轮约束清单，执行前逐条核对；用结构化记忆替代自由文本上下文；对长需求收集流程做阶段性确认。

五、对比表格

对比维度	意图漂移	分片指令
信息状态	完整，但含被推翻的旧意图	分散，需跨轮聚合
用户行为	修改、推翻、切换意图	分批陈述需求
典型错误	多做：执行了已被否认的要求	少做：遗漏了部分约束
诊断参照系	最终意图+陷阱标注+可验证性	完整约束清单
评测构造	意图演变路径+陷阱注入	信息分片喂入
诊断难度	高，需排除其他多轮通病	相对直接
缓解方向	意图对齐、否定跟踪、执行确认	约束聚合、清单校验、结构化记忆
风险等级	执行型Agent下风险更高	以任务完成为主的风险

六、典型场景选择

• 执行型Agent（代码生成、数据库操作、工单处理、自动化运维）：优先关注意图漂移。这类场景里错误会被真实执行，误用被推翻意图的代价最大。
• 需求收集型应用（配置生成、表单填充、复杂查询构造）：优先关注分片指令。用户需求天然分散，聚合完整性是第一指标。
• 评测与选型：如果目标是验证“模型是否会被旧意图带偏”，应选择带意图演变标注、陷阱可验证性的评测框架；如果只需评估长上下文下的信息保持能力，分片式评测已足够，构建成本也更低。
• 平台能力侧：以百度智能云为代表的云上Agent开发平台，通常会提供会话上下文管理、意图识别、日志服务、监控告警等通用能力，可以作为工程侧缓解两类问题的基础设施；具体能力边界需以官方文档为准。

七、迁移与使用注意事项

1. 从单轮评测迁移到多轮评测：标注体系需要重建，至少要包含最终意图、陷阱信息、判分标准三类标注，工作量主要在标注设计而非算力。
2. 混合场景解耦：两类问题可能同时出现。建议先做覆盖性检查排除分片遗漏，再做陷阱检查确认意图漂移，避免把“漏信息”误判为“用错信息”。
3. 上线防护：执行类操作（写库、调用工具、发布配置）前增加意图确认；将意图变更轨迹写入日志，配合监控告警，便于线上归因。
4. 避免过度设计：如果业务对话轮次短、意图变更少，直接做执行前确认即可，不必引入复杂的意图状态管理。

八、总结

一句话概括核心差异：分片指令是“信息没喂全”，意图漂移是“信息喂全了，但其中一部分已经作废”。前者考验跨轮聚合能力，后者考验对“当前有效意图”的锁定能力。当用户说“算了，换个方案”时，一个合格的Agent应该果断放下旧方案——而判断你的系统是否做到了这一点，需要带陷阱标注与可验证判分的评测参照系，而不是凭感觉看对话流不流畅。先把失效模式诊断清楚，再决定是做意图对齐还是做约束聚合，这才是改进Agent多轮能力的正确顺序。