2.1.1 · 演化意图的状态代数

论文：LLMs Get Lost in Evolving User Intent 作者：Jihoon Tack, Philippe Laban, Jennifer Neville（Microsoft Research, AI Interaction and Learning） arXiv：2607.20734（2026-07-22） GitHub：microsoft/evolving-intent

1. 演化意图的构造与评测

演化意图评测从已有的单轮任务出发, 控制新信息何时出现、旧要求何时失效, 同时保留原数据集的可执行答案. 这样才能把意图跟踪造成的错误, 与基础解题能力不足区分开.

构造出来的多轮轨迹还要满足两个条件: reveal、revision 和 function switch 必须真实改变当前目标; 生成过程又不能泄漏答案或制造无法验证的新任务. 论文的数据管线和状态约束都在服务这两个条件.

静态任务遗漏了意图变化，真实协作中, 用户很少在第一轮就把意图说全. 后续消息可能逐步披露参数(under-specification), 也可能修订旧值(revision), 甚至切换到相关但不同的任务(function switch/task switching). 单轮、fully-specified 评测把目标固定在起点, 因而测不到系统能否在目标变化后及时更新计划和动作.

不少 multi-turn benchmark 也只覆盖增量披露, 用户轮次较短, 奖励还可能依赖 LLM-as-judge. revision 与 function switch 带来的覆盖、撤销和继承问题没有进入主测试. 这篇论文因此把已有的可验证单轮任务改造成多轮环境, 终态仍由原 benchmark 的执行器或标准答案判定, 变化只发生在意图呈现过程.

从单轮样本构造多轮意图轨迹，数据不从头手写, 而是从 verifiable single-turn benchmark 出发, 先把任务拆成 function、arguments 和 answer, 再生成局部扰动, 收尾阶段由 turn scheduler 组装多轮对话. 三个对象的含义如下.

前三个阶段负责构造意图组件，1. Intent Extraction：LLM 将单轮样本分解为 function + arguments + answer，并经 coverage / solvability 验证。 2. Retrospective Expansion — Counterfactual：为每个 argument 生成局部值替换的「错误版本」，供 revision turn 使用。 3. Retrospective Expansion — Predecessor：生成相关但不同的 predecessor function，供 function-switch turn 使用；须满足 answer preservation（前置任务的新 argument 不改变终态答案）。

Stage 4–5 负责 Situated Simulation. EvolvingIntent DataLoader 根据 num_turns、num_revisions 和 num_switches 选择场景.

Turn Scheduling(Algorithm 1)先安排 function switch 与 revision, 再填入 reveal slot, 从而保证「先披露错误值、后修正」的因果顺序. 同一轮内按 function event、revision、argument reveal 的优先级排列. Text Rendering 默认使用确定性的规则模板; BrowseComp+ 实验另用了带 token 校验和 fallback 的 LLM naturalization.

Evolve 对 reveal、revision、switch 各应用两次, 一条轨迹共经历 6 次 intent transition 和 7 轮用户 turn(含初始轮). 收尾阶段一轮重新锚定原始任务, 因此仍能使用 SQL execution、SWE test 或 exact match 等原协议评分. 四个任务域分别是 GSM8K、BIRD-SQL、BrowseComp+ 和 SWE-Bench Verified, 过滤与抽样后的规模为 200、100、100、50 条.

1.1. 四个任务域的准确率变化

Table 1 主结果（Accuracy %，Single → Evolve）：

少量 intent transition 已足以造成明显退化; GPT-5.1 在这组 SWE 子集上的 Evolve 准确率降到 0%. 逐轮分析显示, argument reveal 与 argument revision 的识别率较高, function switch 更容易积累错误. Prompt recap 与 Oracle recap 的差距还表明, 瓶颈既有单步推理, 也有从冲突历史中恢复当前意图.

论文把 turn 数与 transition 数分开控制: 只增加重复轮次造成的下降, 小于相同轮数内多次改变意图. Reasoning mode 没有稳定消除差距, 小模型退化更明显. Qwen3-4B 的短程 GRPO 实验表明, 针对性训练可以改善 Evolve, 同时较少损伤单轮成绩; 这个结论仍受实验模型、任务域和样本规模约束.

合成对话的适用边界，合成轨迹让变量可控, 也缩窄了结论的适用范围. 论文证明的是模型在这套生成规则下能否处理意图变化, 还不能覆盖真人对话中的省略、含混授权和临时打断.

真实 Harness 还需要补测自然度、流水线误差、顺序调用成本和更多任务形态. 合成数据的内部有效性成立, 不会自动推出真实用户交互中的外部有效性.

• 合成用户：rule-based / LLM naturalizer 仍非真人；自然度与真实 IM 场景的 gap 未完全闭合。
• LLM 流水线依赖：Extract / Counterfact / Predecessor 均用 GPT-5.1 验证，pipeline 错误会系统性污染数据（虽有 rejection sampling）。
• 成本：7-turn 交互 = 最多 7 次顺序 agent call + 渐长上下文，评测贵于 single-turn。
• 域覆盖有限：四域虽跨 math / SQL / search / SWE，但未覆盖 GUI、长工具链、审批等人机协作形态。
• 训练演示规模小：RL 实验仅 GSM8K + 小模型，未证明大规模 SFT/RL 可完全补齐 intent-tracking 能力。

1.2. 数据管线与状态约束

数据管线决定每轮消息从哪一种意图事件生成, 状态约束则决定这些事件能否组成一条有效轨迹. 二者需要分开: 文本可以自然, 但顺序错误仍会让 correction 失去对象; 顺序可以合法, 但终态不可验证也无法用于稳定评测.

五个阶段从静态样本中抽取目标结构, 生成 counterfactual 与 predecessor, 再把事件排进 turn slot 并渲染成用户消息. 后续约束检查围绕最终答案、事件顺序、局部修改范围和端到端 verifier 展开.

五阶段数据流，Stage 1–3 生成结构化意图材料, Stage 4–5 决定这些材料何时出现、怎样写成对话. 先排事件再渲染文本, 可以避免语言生成反过来改变意图轨迹.

下面的流程图保留了 function、arguments、answer 到用户 turn 的数据流. 最终评分仍回到原任务的 verifier, 因而多轮形式没有改变终态的判定口径.

单轮 benchmark 样本 (q, y*)
        │
        ▼
┌───────────────────┐
│ Stage 1: Extract  │ → function f*, arguments C*, answer y*
└─────────┬─────────┘
          ▼
┌───────────────────┐
│ Stage 2: Counter- │ → 每个 argument 的局部错误值 c_cf
│ factual args      │
└─────────┬─────────┘
          ▼
┌───────────────────┐
│ Stage 3: Prede- │ → 相关 predecessor functions f_pre
│ cessor functions  │
└─────────┬─────────┘
          ▼
┌───────────────────┐
│ Stage 4: Turn     │ → TurnSlots S_1..S_T（intent 轨迹）
│ Scheduler         │
└─────────┬─────────┘
          ▼
┌───────────────────┐
│ Stage 5: Text     │ → 自然语言 user turns
│ Renderer          │
└─────────┬─────────┘
          ▼
   Agent 多轮交互 → 末轮 verifiable 评分

Repo 目录：intent_construction/（Stages 1–3 + per-dataset scripts）、situated_simulation/（EvolvingIntent + turn_scheduler.py）、evaluation/（runners + run_{gsm8k,bird,browsecomp,swe}.sh）。 安装：conda create -n evolvingintent python=3.10 → pip install -e .；API 走 OpenAI / Azure OpenAI（LLM_BACKEND 切换）。

意图轨迹必须满足的约束. 下列条件用于判断一次意图更新是否保持了当前目标的一致性。 任一条件失效，都可能让后续动作建立在过期或互相冲突的目标版本上。

1. Final-turn anchor：无论中间如何 reveal / revise / switch，收尾阶段一轮必须 recover 原始 anchored task，保证与原 benchmark 答案可比。
2. Schedule-before-render：先排 intent 状态机，再生成 surface text——防止「先 correction 后 disclosure」等无效轨迹。
3. Minimal counterfactual edit：revision 必须是单点值替换，不是改写整个 argument——否则 correction 语义不成立。
4. Predecessor answer preservation：switch 引入的新 argument 不得改变终态 gold answer。
5. Verifiable end-to-end：评分仍走 execution-based / test-based 原协议，不用 judge 打分主路径。

与多轮评测方法的差别. 相邻方法解决的状态对象不同，比较时应先对齐目标、输入和 verifier。 只有对齐后，性能差异才能归因于意图维护，而不是工具权限或任务难度变化。

可复用的状态表示. 从论文方法中可以提取若干不依赖具体数据集的工程规则。 这些规则关注状态更新和证据边界，不要求复用论文的用户模拟生成流程。

1. Intent Ledger：会话级结构化记录 {function, revealed_args, revisions[], switches[]}——比纯 chat log 更适合做 belief state。
2. 三态转移类型：reveal / revision / switch 是覆盖真实用户行为的最小生成基；任何「动态意图」评测应至少分解到这三类。
3. Oracle vs Prompt Recap 诊断：分离「跟踪意图」与「在正确意图下行动」两个 failure mode——工程上可对应「显式 intent 面板 + 计划重置」。
4. Transition-count 控制变量：评测时必须区分「轮次变长」与「意图变次」——否则会把 context length 效应误归因于 intent tracking。
5. Benchmark lifting 范式：从 verifiable static task 合成 dynamic dialogue，比手写 multi-turn 便宜且可扩展——可复用到更多域（GUI agent、审批流等）。

意图状态如何进入 Harness，结构化意图只有进入计划、工具调用与恢复流程才有意义. 状态更新要覆盖披露、修订与任务切换, 并让依赖旧版本的动作及时失效.

意图更新可以写成显式状态转移. 状态式给出字段与版本的关系, 手算展示修订如何使旧计划失效, 随后的错误类型直接对应计划绑定和工具参数.

2. 把意图维护写成状态更新

多轮对话日志只记录“说过什么”，没有直接说明“现在什么有效”。一个可执行的意图状态可以写成

$f_t$ 是当前 function，$A_t$ 是已经披露且仍有效的 arguments，$C_t$ 是约束与优先级，$V_t$ 是意图版本。第 $t$ 轮用户消息 $u_t$ 经过解析后生成带类型的状态操作；把消息原样追加到 $I_{t-1}$ 无法表达覆盖与撤销：

reveal(k,v) 为尚未赋值的参数增加值；revise(k,v') 让旧值失效并保存修订关系；switch(f') 改变当前 function，同时明确哪些参数继续适用。版本号在每次有效转移后递增，后续计划、工具调用和产物都应记录自己依据的 $V_t$。这样用户在第六轮改了目标，第七轮仍在执行 $V_3$ 计划时，系统能发现版本落后，而不必期待模型凭长对话“自己记得”。

一个四轮手算. 假设初始请求是“分析销售数据”，状态只有 $f_0=\text{analyze-sales}$，参数集合为空，版本为 0。

1. 用户补充“只看华东区”。执行 reveal(region, east)，得到 $A_1={region:east},V_1=1$。
2. 用户说“时间是第二季度”。执行 reveal(period,Q2)，计划据此生成 SQL，计划版本也记为 2。
3. 用户修正“我刚说错了，是第三季度”。执行 revise(period,Q3)，旧的 Q2 保留在审计历史中，但从有效参数表移除，$V_3=3$。所有依赖 Q2 的未执行 SQL 被标为 stale。
4. 用户改成“先比较华东和华南的退货率”。function 从销售分析切换为退货率比较，period:Q3 仍适用，region:east 需要扩成 {east,south}。这次操作既有 switch，又有参数修订，目标版本升到 4。

如果系统只是把四句话拼起来，最终上下文同时包含 Q2、Q3、“华东”和“华东与华南”。模型可能在自然语言回答中选对最新值，工具链却已经把第二轮 SQL 缓存并执行。结构化状态让无效计划在动作发生前被拒绝，同时保留最终复述意图的准确率。

switch 中哪些东西能够继承. function switch 不能默认清空所有参数，也不能默认全部继承。可以为每个 argument 记录作用域：会话级参数如语言和预算，任务族参数如数据集版本，function 局部参数如 SQL 输出列。切换到新 function 时，只有作用域覆盖新任务的参数自动继承，其余进入待确认集合。 设旧参数共有 $n$ 个，直接继承集合为 $K$，需要重新确认集合为 $Q$，明确失效集合为 $D$，应满足

如果某个参数没有进入三者之一，状态更新就丢了信息；如果同时进入 $K$ 和 $D$，后续执行会遇到冲突。这个集合检查非常简单，却比让模型输出一句“我明白你的新需求了”更能保护长任务。

意图状态怎样影响计划和工具，每个计划节点应保存 (goal_version, preconditions, expected_effect, verifier)。执行前先检查 goal_version == V_t；版本落后时不一定全部删除，可以重新验证前置条件并迁移到新目标。例如已经完成的数据清洗与 Q2/Q3 无关，可以复用；按 Q2 聚合的中间表则必须重算。 工具结果也要绑定意图版本。一个耗时查询在 $V_2$ 发起，返回时系统已进入 $V_4$，结果不能直接写入当前事实表。它可以作为历史证据保存，再由新计划判断是否仍适用。异步 Agent 特别容易在这里出错：旧子任务晚到的高质量答案会覆盖新目标下的正确状态。

冲突时还需要区分“用户明确替换”和“系统推断替换”。“改成第三季度”明确撤销 Q2；“也看看第三季度”可能是新增对照，而非替换。解析器置信度不足时，应把候选解释写入待确认状态，暂停会产生较大副作用的动作。这里询问用户是为了消除产品意图歧义，不是把实现选择甩回用户。

从论文评测走向真实 Harness，论文的 final-turn anchor 让静态 benchmark 的答案仍可复用，是很干净的控制实验。真实协作中的目标却未必回到原始任务，甚至可能没有唯一答案。因此工程评测还要测四类状态错误：

• 遗漏：已经披露的 argument 没进入当前状态；
• 残留：被修订或取消的值仍参与计划；
• 错继承：function switch 后继承了不再适用的局部参数；
• 错失效：本应跨任务保留的预算或安全约束被清空。

可对每轮真实意图状态 $I_t^*$ 与系统状态 $\hat I_t$ 做字段级 precision、recall，再把错误传播到动作层：由错误状态产生了多少无效工具调用、写入和重做成本。只评估模型能否在末轮口头复述最新要求，会漏掉中间已经发生的副作用。 还应分别运行三种 Harness。第一种只给完整聊天记录；第二种在每轮提供模型自己维护的 recap；第三种提供外部状态机维护的结构化意图表。若第三种明显好于前两种，瓶颈主要在状态抽取和保持；若三种都差，问题更可能出在拿到正确意图后仍不会规划或执行。这和论文的 Oracle recap 诊断一致，但工程系统还要计算维护状态的 token、延迟和错误修订成本。

意图表也不是新的绝对真相。解析可能错，用户可能自相矛盾，外部状态还可能与最新消息不同步。每条字段应保留来源 turn、更新时间、是否经过用户确认以及依赖它的计划节点。发现错误时，从来源和依赖关系向下失效，而不是清空整段记忆重来。 放回 Long-Horizon 的框架里，evolving intent 增加的是目标维度的非平稳性。环境状态会变，模型知识会过期，连“要完成什么”本身也会变。系统若没有目标版本和迁移规则，再强的计划器也只是在高效执行过期计划。

2.1. 实验结论与状态评测

论文实验把静态任务转成可验证的多轮意图变化, 为比较单轮与动态设置提供了控制条件. 数字仍需连同样本、预算与 Harness 一起阅读.

工程评测还要观察每轮意图状态和动作副作用. 实验边界决定结论能否外推, 更新规则决定旧值何时失效, 过程指标则记录错误在轨迹中传播了多远.

论文实验究竟证明了什么. 论文 v1于 2026 年 7 月 22 日提交。作者没有另造一套只能由模型裁判的多轮答案，而是从四个已有可验证数据集出发：GSM8K 取 200 个样本，BIRD-SQL 与 BrowseComp+ 各取 100 个，SWE-bench Verified 取 50 个。单轮题目的原始目标被放到对话末轮，原来的数值答案、SQL 执行器、检索答案或测试套件继续担任 verifier。这样控制了一个关键变量：末轮任务不变，变化的是它如何经过多轮披露、修订和切换才到达模型面前。

主实验把三种转移各应用两次，共 6 次意图转移、7 个用户轮次。论文表 1 的结果不能压成一个平均跌幅，因为领域与 Harness 差异很大。例如 GPT 5.5 在 GSM8K 从 99.0% 降到 80.5%，在 SWE-bench Verified 从 86.0% 降到 80.0%；Kimi K2.6 在 BrowseComp+ 从 55.0% 降到 52.0%，在 SWE-bench Verified 从 86.0% 降到 72.0%。这些数值只适用于论文采样、模型版本与预算。SWE 运行使用扩展后的 mini-SWE-agent v2，多数模型每轮最多 100 次工具调用，Kimi K2.6 与 DeepSeek V3.2 提高到 200 次；BrowseComp+ 每轮最多 50 次搜索。不同预算意味着跨模型横向比较需要谨慎。 相对跌幅按

以 GPT 5.5 的 GSM8K 为例，代入 $99.0$ 与 $80.5$ 得

绝对下降是 18.5 个百分点，相对下降约 18.7%，两者不能混写。论文表中的括号报告相对变化；阅读数字时还应同时看单轮基线，避免把低基线上的小绝对变化误作稳健。

实验支持的结论是：强单轮表现不会自动迁移到受控的演化意图设置，且转移增加时准确率会下降。它没有证明真实用户一定以这三种方式变化，也没有证明所有长对话失败都来自意图跟踪。对话由回溯构造，末轮固定回到源任务；真实协作可能永久改目标、撤销任务，或给出互相冲突又无法自动验证的要求。论文提供的是诊断探针，不是现实交互的完整生成模型。

转移规则如何避免「只追加不更新」. 把当前意图写成键值映射更容易实现。设功能为 $f_t$，参数映射为 $C_t$，已披露键集合为 $R_t$，目标状态为

$g_t$ 是递增版本。披露新参数 $k=v$ 时，更新 $C_t[k]\leftarrow v$ 且把 $k$ 加入 $R_t$；修订参数时覆盖旧值并使依赖旧值的计划节点失效；功能切换时，新功能保留共享参数，局部参数进入历史而不参与当前执行。 考虑四轮例子。第一轮「找纽约餐厅」，状态为 $(\text{find},{city:\text{NY}},1)$。第二轮「要纯素」，加入 $diet:\text{vegan}$。第三轮「改到布鲁克林」，这是 revision，必须覆盖 city，不能同时保留 NY 与 Brooklyn。第四轮「订周五七点的那家」，功能切换为 book，restaurant_id、地点与饮食偏好可以继承，搜索排序参数不一定继承。

若状态以追加日志保存，读取器要计算每个键的收尾阶段有效写入：

active 用来排除被撤销的分支。式 (11) 比「取收尾阶段一句包含该词的话」严格：用户可能说「不要改到布鲁克林，仍然纽约」，否定范围必须先解析成状态操作。解析不确定时，应保留候选解释与来源轮次，静默选择会掩盖歧义。 计划节点也要记录依赖。例如工具调用 search(city=NY,diet=vegan) 依赖 city@v1 与 diet@v2。第三轮把城市更新到 v3 后，节点有效性为

城市版本不再等于 v1，乘积变成 0，旧搜索结果不能直接用于预订。这一步把「记住用户改主意」转成可执行失效规则。

评测意图状态而不只评测末轮答案. 末轮 verifier 保证最终答案可核验，却看不到中途副作用。工程评测应在每轮保存真实状态 $I_t^*$ 与系统估计 $\hat I_t$。对离散槽位可计算字段准确率；对集合槽位可算 precision 与 recall；对版本更新则记录修订生效延迟。若第 $r$ 轮修订，系统在第 $u$ 轮首次执行符合新值的动作，则

仅有延迟仍不够。系统可能在 $r$ 到 $u$ 之间执行不可逆动作。应另记旧意图残留成本

这样，同样晚两轮才修正的系统会因期间只是读取文件，或已经发送邮件，而得到完全不同的风险描述。 论文还比较了记忆机制，这类对照需要分清两个瓶颈。Oracle recap 把正确意图直接提供给模型，若表现恢复，说明状态提取或保持是主要问题；若仍不恢复，说明模型即使拿到正确状态，也不能据此规划和执行。模型自己生成的 recap 同时受到写入错误、压缩遗漏和读取失败影响，不能只凭 recap 文本看起来完整就认定状态可靠。

真实 Harness 最低限度应保存：当前功能、每个参数的值与版本、来源轮次、置信状态、全局约束、已失效值、依赖这些字段的未完成动作。对话原文仍保留作审计，但规划器读取结构化当前态。用户再次改变要求时，先更新目标状态，再使旧计划失效，收尾阶段才生成新动作；顺序反过来会让过期动作抢先执行。

工程实现与故障注入，真实系统需要一张可审计的当前意图表, 也需要完整变更事件. 两者分开, 才能兼顾规划效率与来源追溯.

实现完成后还要用修订、切换、并发和含糊要求主动攻击状态机. 最小表结构负责保存当前有效值, 事件日志则负责解释这些值怎样产生.

实现一张可审计的意图表. 意图表不需要复杂本体，关键是把当前值与变更历史分开。当前表可以包含 field、value、scope、version、source_turn、status 六列；事件表另存 reveal、revise、retract、switch 和 confirm。规划器只读状态为 active 的当前值，审计器可以沿事件表解释它为何生效。这样既避免每次规划重读整段对话，也不会因覆盖当前值而丢失来源。 全局约束与局部参数必须分层。例如「不得删除生产数据」在任务切换后仍有效，作用域是 session 或 project；「餐厅在纽约」只属于当前搜索功能。功能切换时可按作用域计算保留集合：

第一项保留覆盖新任务的上层约束，第二项保留两个功能明确共享的参数。其余字段进入 inactive 历史。若共享关系不确定，系统应把字段标为 pending，而不是默认继承。过度继承会把旧任务污染新任务，过度清空则迫使用户重复说明预算和安全要求。 并发更新还需要版本条件。Agent 读取意图版本 $g=12$ 后准备执行，用户同时把目标更新到 $g=13$。动作网关可要求

版本不一致时重新规划。普通读取无需逐次加锁，会产生副作用的动作则在提交前检查版本。搜索和草稿可以宽松，付款、发布、删除与写生产库必须严格。 恢复时也不能只加载最新摘要。checkpoint 应包含目标版本、当前意图表、尚未完成的计划及其依赖版本、已执行副作用的幂等标识。重启后先读取外部环境，再判断旧动作是否已经发生；若服务端已成功而客户端只看到超时，直接重试可能重复下单。意图连续性因此与环境幂等性相连，不只是对话理解问题。

验证这套状态机时，可以把故障注入分成三组。第一组在动作前修订一个关键参数，检查旧计划是否失效；第二组在功能切换后重复出现旧参数词，检查系统是否错误复活历史值；第三组让用户给出含糊补充，检查系统是否在高风险动作前确认。每组同时记录状态字段错误、过期动作数和副作用成本。末轮回答即使正确，只要中途已经执行错动作，仍应判为过程失败。

还应加入反向样本：用户重复旧值可能只是在解释历史，没有恢复它；用户说「保留纽约方案作对照」意味着 Brooklyn 仍是主方案，纽约成为并行分支；用户撤销整项任务时，所有局部参数都应失效，但项目级安全约束继续存在。这些样本检验语义作用域与分支管理，简单的「收尾阶段出现值胜出」规则无法通过。评测报告应同时给解析正确率与实际动作正确率，因为一个系统可能状态表正确，却在调用工具时仍取错字段；分支状态还必须有稳定标识，避免同名参数串线。

2.2. 把五类事件写成状态代数

官方仓库把演化过程分为 argument reveal、argument revision、function switch，并提供 combined 场景。真实系统还会遇到撤销与确认，因此事件集合可以扩成：

每个事件都作用于带版本的意图状态 $I_t$。reveal(k,v) 添加此前未知的字段；revise(k,v') 使旧值失效并产生新版本；switch(f') 更换功能，同时按作用域迁移共享字段；retract(q) 撤销一个字段、分支或完整目标；confirm(q) 把 pending 候选提升为 active。状态更新写成：

$\delta$ 不能只修改当前表，还要返回失效集合 $Z_t$：哪些计划、缓存结果和待执行副作用依赖了被修改字段。计划器随后只重算受影响子图。若修改城市导致餐厅搜索失效，预算上限与「不得自动付款」仍然有效；把整个状态清空会丢掉无关约束，继续沿用旧计划又会把纽约的结果拿去预订布鲁克林。 事件代数还需要作用域。retract(city) 撤销当前分支的城市，与 retract(task) 撤销整个预订任务，影响范围不同。每条事件至少带 target_id、branch_id、scope、source_turn 与 event_id。稳定标识使两个都叫 budget 的字段能够分别属于旅行规划和采购任务，不会因名称相同串线。

并行分支怎样合并. 用户可能要求「纽约和波士顿都保留，分别给方案」，此时 revision 不应覆盖旧值，而应创建两个分支：

trip@v4
├─ branch-NY: city=New York, budget=200
└─ branch-BOS: city=Boston, budget=200

全局约束挂在父节点，城市与搜索结果挂在各自分支。后续一句「纽约那条提高到 260」只更新 branch-NY/budget；一句「两边都不要红眼航班」则更新父级约束，两个分支的相关计划都失效。 合并分支时，要区分结果集合合并与目标合并。用户说「把两份方案放在一张表里」只是聚合结果，两个城市条件仍各自成立；用户说「综合两份方案给一个最终行程」会创建新目标，其输入依赖两个分支的已验证结果。合并节点可以写成：

$\rho$ 是合并规则。任一输入版本变化，$m$ 都应转为 stale。缺少版本条件时，系统会在一个分支更新后继续展示旧的综合结果。

含糊修订与候选状态. 「还是用之前那个吧」只有在指代唯一时才能直接更新。若历史中有两个方案，系统应保留候选集合：

候选概率可帮助决定是否提问，却不能自动授权高风险动作。可以根据动作代价设置阈值：只读搜索在 $p_{max}$ 较低时也可并行探索；发送、购买和删除要求唯一确认。期望风险为：

若不同候选下动作相同，例如两种解释都需要先读取同一文件，就可以继续；若动作分叉且成本高，提问更便宜。这个规则让系统根据歧义的后果选择行为，不必每遇到代词就停下，也不会用一个高置信猜测越过权限边界。 否定范围尤其容易产生候选。「不要把 A 改成 B，保留 C」可能否定整个修改，也可能只否定目标值 B。解析器要把否定作用域映射到事件对象，再由状态机检查当前是否存在对应字段和分支。直接抽取收尾阶段出现的实体，往往会把 B 或 C 当作新值。

状态准确、动作准确与评测设计，意图表写对，只完成了一半。规划器可能读取旧快照，工具层可能使用硬编码默认值，动作提交前也可能漏掉版本检查。评测应把状态准确与动作准确分开。 对每个字段 $k$，定义当前值准确率：

版本也要匹配，因为相同值可能来自一次撤销后重新确认；只有值没有来源版本，旧计划仍可能被误判有效。动作一致率则检查实际工具参数是否来自当前意图：

若 $A_{state}$ 高而 $A_{act}$ 低，问题在状态到动作的连接；两者都低，先修意图解析和更新；状态低但动作偶然正确，可能是默认值碰巧命中，不能当作系统稳健。 还可以建立转移混淆矩阵。真实事件是 revision，系统却判成 reveal，会同时保留新旧值；真实事件是 switch，却判成 revision，可能把旧功能的局部字段带进新功能；真实事件是 confirm，却判成普通重复，pending 状态永远无法提交。把准确率按事件类型拆开，比一个总平均更能定位状态机缺口。

意图债务与污染范围，错误意图若未被及时纠正，会沿依赖图产生「意图债务」。设第 $r$ 轮发生修订，系统在第 $u$ 轮才采纳，期间受旧版本影响的动作集合为 $A_{r:u}^{old}$，其污染范围可写成：

$c(a)$ 是动作成本，后继数反映返工范围。一次错误搜索成本很低，若它的结果被用于预订、付款和通知，污染就会迅速扩大。这个指标与式 (14) 的旧意图残留成本方向一致，额外把下游影响纳入计算。 恢复完成也需要定义。系统删掉旧值还不够，依赖旧值的计划、缓存和副作用都要处理。可将恢复条件写成：当前状态与用户目标一致；旧版本动作全部失效；可逆副作用已经撤销；不可逆副作用已向用户报告并进入补偿流程。只修摘要不修环境，会留下一个看起来正确、实际仍污染的系统。

3. 官方构造管线能验证什么

微软仓库公开了五阶段流程：从源题抽取 function、arguments 与 answer；为 argument 生成 counterfactual；为 function 生成 predecessor；组装 situated simulation；收尾阶段调用原数据集的 evaluator。仓库明确说明这是 code-only release，没有随仓库发布模型或新数据集，使用者仍需准备第三方 benchmark。 这种设计的优势是末轮 verifier 保持稳定。GSM8K 仍核对数值答案，BIRD-SQL 仍执行 SQL，SWE-bench Verified 仍运行测试。因变量主要来自对话中发生的 reveal、revision 与 switch，避免模型裁判同时改变题目和评分标准。Eval mode 使用确定性样本，train mode 支持随机采样；scenario 由 turn、revision 和 switch 数量自动推断。

它的边界也很明确。对话由结构化源题回溯构造，因此 function 与 arguments 比真实用户表达更清楚；末轮锚回原任务，适合保留自动验证，却覆盖不了永久换目标、多个目标并存和用户中途放弃。仓库的 TRANSPARENCY 文件也把它定位为研究框架，不适合直接作为生产认证或高风险领域质量证明。 复现实验时要记录源数据版本、固定 evaluation indices、构造模型、counterfactual/predecessor 数量、turn scheduler 参数和 naturalizer 模型。只给最终对话文本，无法判断不同实验是否用了相同源题与相同演化强度。Naturalizer 还可能意外增加或删除约束，抽样检查自然化前后的结构化事件是否一致很有必要。

一套配对实验. 每个源题生成 fully-specified 基线与演化版本，两者共享最终目标和 verifier。对同一模型分别运行，得到成对结果 $(y_i^{base},y_i^{evo})$。平均退化为：

随后按 reveal、revision、switch 和 combined 分桶，避免 combined 的总体跌幅掩盖某一种转移特别困难。还可以控制总用户轮数，只改变 revision 次数；或固定转移次数，增加两个转移之间的间隔，观察系统是否因时间距离而忘记旧约束。 过程日志再加入三项指标：修订采纳延迟、旧意图残留成本和澄清效率。澄清效率可以计算必要澄清中成功消除歧义的比例，同时报告无谓提问数。一个系统每轮都追问，动作错误可能很少，却把协作负担全部推给用户；只看最终正确率会奖励这种保守策略。

故障注入则在动作边界发生：计划生成后、工具调用前修改关键参数；工具已经部分执行时切换功能；checkpoint 恢复后撤销一个旧约束。每次都记录当前意图表、计划依赖版本、真实环境和下一次动作。只要四者中有一项仍引用旧版本，状态传播链就还没有修好。

生产系统中的确认策略，生产系统需要把确认频率与风险联系起来。每次 reveal 都追问会令人无法使用，任何 revision 都直接执行又可能造成损失。可以给动作设置风险等级，并结合意图状态决定门槛：

确认消息应指出具体分歧和后果，例如「当前有纽约与波士顿两个分支，付款将作用于哪一个？」；泛泛地问「确定吗」不能消除状态歧义。用户回答后生成 confirm 事件，绑定候选 ID 和目标版本。若等待期间目标又发生变化，旧确认自动失效。 这样的确认门也保护并发场景。用户在网页修改参数，Agent 在后台仍握着旧计划；动作提交前比较 goalVersion，不一致就撤销提交。高风险动作多一次版本读取，成本远小于执行错误后再补偿。意图跟踪最终会落到一个很朴素的工程事实：用户改一句话，所有依赖旧话的动作都要知道自己已经过期。

Quick test：intent_construction/intent_extraction/generate.py --dataset gsm8k --num_samples 3。

官方实现与透明度说明：

• microsoft/evolving-intent
• TRANSPARENCY.md

产品落地对照见 ../../../essays/oasis-improvements-2026-08-harness-wave.md。 冲突、切换与持久化，把用户消息全部追加到历史，无法自动得到当前目标。系统需要一个更新算子

$G_t$ 是当前目标状态，$u_{t+1}$ 是新消息，$c_t$ 是任务与环境上下文。$U$ 的输出除了新目标，还应包含变更类型、被替代字段和仍待确认的冲突。 最小变更类型包括增补、覆盖、撤销、优先级调整和任务切换。增补保持旧字段；覆盖只替换指定字段；撤销将字段标为失效；优先级调整改变执行顺序但不删除验收项；任务切换创建新的目标对象，并决定旧任务暂停、结束还是保留后台状态。

自然语言中的「也」「改成」「先别」「不用了」「继续刚才」分别提示不同操作，但词面规则不够。用户说「也别删测试」里的「也」是新增禁止项；说「颜色也改成蓝色」可能覆盖旧颜色。判断需要结合字段和前文值。 目标状态可以表示为带来源的谓词集合

$k_i$ 是字段，$v_i$ 是值，$r_i$ 是关系类型，$\tau_i$ 是生效版本，$s_i$ 指向原始消息。发生争议时可以回到来源，而不依赖多次摘要后的措辞。 更新不能静默丢掉未知字段。新消息只提标题，不意味着正文要求失效；覆盖范围应最小化。若新旧值在同一字段冲突，最新明确指令通常覆盖；若属于不同层级，例如全局禁止与局部许可，需要权限和作用域规则决定。

3.1. 冲突不是都用「收尾阶段一句赢」

时间顺序是常用默认，却不能处理所有约束。系统指令、用户授权、项目规范和当前偏好具有不同优先级；同一用户消息里也可能同时存在互相不兼容的条件。 把约束写成带优先级的集合 $C={(c_i,p_i)}$。若 $c_i$ 与 $c_j$ 不可同时满足，优先保留更高 $p$；优先级相同且没有明确覆盖关系时，状态进入冲突，而非任选一句。冲突状态应阻止依赖该字段的高风险动作。 范围也会消解表面冲突。「不要修改正文」与「修正这一处图片引用」可以同时成立，因为后一条是局部例外；「所有文件使用 UTF-8」与「这个二进制图片保留原格式」作用对象不同。更新器需要记录路径、时间、任务阶段等作用域。

有些约束是软偏好。用户希望语言简洁，又要求完整推导，二者需要在文章不同层次权衡；它们不是逻辑矛盾。硬约束违反即不合格，软偏好进入效用函数。混成同一布尔集合会让系统频繁请求不必要的澄清。 可以用可满足性检查发现硬冲突。例如输出长度必须小于 100 字，同时要求逐步证明一个已知需要更长表达的命题。系统应解释冲突的具体字段并请求选择，而非先写一版再声称尽力满足。

冲突解决结果也要版本化。用户选择其中一项后，旧冲突记录保留作审计，但不再阻塞；若后续又恢复旧要求，系统知道这是显式回滚而非第一次出现。

从消息分类到动作影响. 只判断消息属于「增补」或「覆盖」还不够，系统要知道哪些计划和产物受影响。设目标字段变化集合为 $\Delta G$，依赖图为 $D$，受影响节点为

只有 $I$ 中已经完成或正在执行的节点需要重验、取消或回滚。与变化无关的并行工作可以继续。 例如用户把输出格式从 Markdown 改为 PDF，资料收集和事实核查仍有效，排版与交付流程需要更新；用户更换核心研究问题时，早期来源选择也可能失效。用依赖传播决定范围，比按时间把后续工作全部作废更精确。 正在运行的动作需要抢占语义。可安全取消的任务直接停止；不可取消的外部操作记录为旧版本产物，完成后不自动提交；已经产生副作用的动作需要补偿或请求用户决定。简单忽略旧进程会让它稍后写回过期结果。

目标变化还会影响证据。旧测试证明版本 $G^{(k)}$ 下的产物，目标升到 $G^{(k+1)}$ 后，如果变化字段在测试覆盖范围外，证据可复用；否则状态从已验证降回待验证。验证结果不能只绑定文件哈希，还要绑定对应要求。 动作影响分析应在回复用户之前完成。系统可以先确认新要求和受影响范围，再继续安全分支；若直接说「好的」却没有取消旧路径，表面理解与实际执行分离。

确认策略的决策论，任何不确定都询问用户，会让协作停滞；从不询问会在高风险歧义上擅自决定。确认策略应比较错误行动代价与询问成本。 设解释集合为 $z\in\mathcal Z$，当前后验为 $p(z\mid h_t)$。直接选择动作 $a$ 的期望损失为

询问的期望损失包含交互成本 $C_q$ 和回答后残余损失。若询问带来的预期损失降低超过 $C_q$，才值得打断用户。 高风险、不可逆动作使 $\ell(a,z)$ 很大，即使歧义概率小也应确认；可回滚草稿可以先按最可能解释执行，并明确假设。这个原则比固定置信阈值更贴近任务后果。 问题应针对能改变决策的变量。询问「你能说详细点吗」把组织成本推给用户；询问「这里的‘删除’只指生成文件，还是也包括原始数据？」直接切分两条高影响路径。最多给少量互斥选项，并说明默认方案。

用户没有回复时，系统只能继续不依赖该选择的工作。若所有关键路径都被阻塞，状态应明确等待；不能把沉默当授权。低风险问题可采用可撤销默认值，但要在交付前再次暴露。 确认本身也可能过期。用户回答时环境或目标已经发生变化，需要把答案应用到提问时的字段版本。若同一字段在等待期间又被更新，旧回答不能直接覆盖新值。