05.2 · 执行中的新消息：补充、冲突与并行

执行中的新消息，先确定它要修改哪个Run，再记录新要求，在下一次模型调用前应用；旧要求的结果不能覆盖新要求。

上一篇划清了会话和执行的边界。现在仍看直播复盘：session-S1中的run-1正在分析全场成交额，你发来“只看新品”。这句话怎样真正改变任务？

输入控制位于Session收取消息之后、上下文组织之前：程序确认归属和顺序，上下文层把已接受的要求放进后续输入，报告提交时再核对要求是否仍有效。

1. 收到补充，不等于模型已经按补充执行

传统报表通常把分析范围写进接口参数。Agent可以接收自然语言修订，但也需要把它变成程序可记录、可检查的要求，不能让模型自行猜测这句话要影响哪份报告。

假设全场查询已经发出，模型也正在根据旧数据生成分析。新的“只看新品”不能塞进那次已经提交的模型请求；先保存消息，不代表在途请求的输入发生了改变。

本例采用同一Run吸收补充的规则，分成两个时点：

• 接收时：确认补充属于run-1，保存新要求，阻止旧口径报告成为当前交付。界面显示“已收到，将在下一步应用”。
• 应用时：本轮已发出的工具往返收束后，按新要求重新组织模型输入，补查必要资料。界面此时才能显示“已应用”。

这里的安全边界，就是适合更新要求、又不会把一组工具请求与结果拆散的位置。只读查询可以先完成并记录；若需要尽快停止耗时操作，则走上一篇的取消流程。

2. 用要求版本，让“只看新品”生效

给分析范围分配一个版本：v1表示全场，v2表示只看新品。它记录用户当前认可的要求，不是模型调用次数，也不是消息序号。

沿run-1执行五步：

1. 接收补充，检查会话权限与目标Run，确认它仍在执行。保存消息并把有效要求推进到v2。
2. 阻止按v1生成的报告提交为当前结果。旧模型即使已经写出结论，也不能抢在新要求应用前交付。
3. 保存已发出的全场查询结果及其v1归属，保持工具请求与结果配对。它可以作背景，不能直接当作新品证据。
4. 在安全边界，把v2要求放入下一次模型输入。“新品”若定义不清，先询问，暂不交付旧报告；明确为本周上架商品后，再查对应成交额。
5. 生成候选报告，提交时检查Run仍允许交付、有效要求仍是v2。若又收到修订，旧候选就不能覆盖更新的要求。

同一Run内保留不同版本产物时，可以用runs/run-1/reports/v1.md和v2.md分别保存，在Run记录中指向通过检查的交付文件。把旧报告覆盖写进同一个“最新结果”，会丢掉它对应的范围和来源。

这里的模型负责理解“新品”的含义、提出查询和解释数据；程序负责保存要求版本、限制交付。已经发生的外部通知或写入，不会因为要求变了就自动撤销。

报告恰好完成，补充也恰好到达呢？

补充入口和报告提交入口必须检查同一份Run状态与要求版本：

• 补充先被接受，v1报告的提交条件就失效。
• 报告先完成，补充入口会发现原Run已经结束，创建后续关联Run，并把处理结果告诉用户。

谁先被服务端接受，就按哪条规则处理。不能依据手机显示的发送时间，认定尚未到达服务端的修订已经生效。

3. 手机与电脑同时改范围，怎样避免覆盖？

Session标识说明消息放在哪里，目标Run说明消息影响谁，预期版本说明用户基于哪份要求作修改。这三件事需要分开。

例如两个设备都看见“分析全场”的v1。手机改成“只看新品”，电脑改成“只看老品”，都携带预期版本v1。

如果手机先提交成功，当前要求变成v2，电脑的“当前版本仍是v1”条件就不再成立。服务端返回冲突，展示已生效的新品范围，再让用户决定是否继续改成老品，不能静默覆盖。

收到修改请求时，程序在一个短事务里一起完成：检查账户、目标状态和预期版本，保存消息与去重记录，推进要求版本，登记待应用的补充。任一条件不满足，就不提交这一组变更。

模型调用和远程查询放在事务外。 事务只保护这次检查与写入；查询带着已经确认的版本执行，结果回来时再检查是否还能交付。否则可能长时间持有这条任务记录的锁，让其他修改一直等待。

顺序、冲突、重复请求不是一回事

这些标识由界面和程序携带，不要求用户手填。同一请求因超时重发，应返回原来的受理结果，而不是再创建一个Run或重复应用补充。

如果只是追加一条互不冲突的观察，可以按顺序接受；修改同一份分析范围，才需要相应的版本冲突规则。不要把所有消息都无条件拒绝，也不要用一个时间戳替代所有控制。

4. 另来一项新任务，要排队还是并行？

“只看新品”是在修改当前分析；“再分析库存风险”可能是独立目标。界面可以通过“补充当前任务”“新任务”或回复关系表达归属。多个任务同时存在时，一句“改一下”指向不清，就先澄清。

逻辑任务指业务目标，例如成交额报告与库存分析。同一目标可以有多次Run，比如报告完成后的追问或重新执行；不同目标的状态与结果位置要分开。

收到独立任务时，常见选择是：

排队时保存“想做什么”，不代表立刻把新消息混入当前Run的模型输入。下一项开始时再按规则取材料；如果它依赖成交额报告，就等报告完成并记录引用，不能拿排队时的旧快照冒充新结果。

同一Run里，成交额和流量也可以并行查询，之后汇总进入下一轮。底层查询并行，与共享状态通过一个受控入口写入，并不矛盾。

5. 允许多Run并行，哪些东西必须分开？

新品分析与库存分析可以读取同一份获准共享的商品资料，但不能共用一份可随意追加的模型消息数组。

每次Run分别保存：起始材料及其版本、模型与工具交互、当前要求、操作状态和候选报告。结果返回时带上Session、任务、Run与要求版本，由统一入口核对归属后展示。

因此，即使库存报告先完成，也只能更新库存任务；新品报告晚到，仍归新品任务。聊天界面显示的先后顺序，不改变业务归属。

如果两个Run都想修改同一份报告，就要指定一个整合者，或校验各自基于的版本并处理冲突。不能把最后一次写入成功当成合并方案。某个Run停止或失败时，也只清理它自己的操作和占用，不能清空另一个Run的工作历史。

可以先做一个小验证：让两份模拟报告故意交换返回顺序，再同时提交两条修改。检查旧版本是否被拒收、网络重发是否重复生效、两份结果是否仍归正确任务。这里验证的是程序控制；模拟输出不能证明真实模型已经理解了“新品”。

下一篇进入Data for AI：任务范围确定后，怎样取得口径正确、规模合适、能核对来源的业务数据。