Agent 原定查询附件，后来改成人工处理。只记录“计划已调整”无法说明为什么，也无法让接管者判断修改是否仍然有效。计划变更需要对应具体业务事实，而不是一句模型自述。
变更记录应包含原计划版本、变化内容、触发事实、证据与影响范围。本文采用工单设计示例，不把示意数据当成真实运行记录。
触发事实和方案选择分别记录
附件解析失败可以是观察事实，转人工是基于能力与目标的方案选择。事实不必天然导向唯一方案：可以重试、换已验证解析路径，或等待补充材料。记录选择理由，才能解释为什么没有采用其他可行方法。
| 变更原因 | 需要的事实依据 | 不能直接推出 |
|---|---|---|
| 缺少输入 | 字段校验或材料清单 | 模型可补写缺失事实 |
| 能力不足 | 失败样本或能力检查 | 所有备用方法都不可用 |
| 用户改目标 | 明确的新请求与适用范围 | 旧授权自动覆盖新动作 |
| 预算不足 | 当前消耗与剩余约束 | 可以跳过必要核对 |
| 对象状态变化 | 最新版本与变化事件 | 原操作一定未执行 |
来源要具体到对象和时点。另一个工单曾经失败，不能直接作为当前工单改变计划的事实；它可以提示先做哪项检查。
变更记录保留差异
{
"plan_ref": "plan-demo",
"from_revision": 3,
"to_revision": 4,
"change": "replace extraction with manual review",
"trigger_ref": "parse-failure-demo",
"affected_steps": ["read-attachment"],
"authorization_state": "review_required"
}
这个例子保留版本与触发引用，没有因为解析失败就默认获得人工处理之外的外部写入权限。若变化扩大对象范围或新增有影响的动作，按实际授权重新判断。
图中透明路线层可修改，采样事实仍保留在底板。调整后续路径不能改写已经发生的操作；旧结果仍要核对和交接。
变更前检查在途动作
计划被替代时，旧步骤可能仍在外部系统执行。先记录哪些请求已经发出、哪些可取消、哪些结果未知，再决定新计划如何等待或核对。把旧计划标成过时，不会让外部动作自动停止。
执行者读取新版本后，也要拒绝继续按失效计划发起新动作。迟到结果可以追加到原操作记录，但是否推进当前计划需要检查版本与适用性。
用反事实样本验收
给系统一条无来源的“服务似乎坏了”，检查它是否先核验；给出明确失败记录，检查变更是否引用该证据；在变更中加入新的写入动作，检查是否识别授权范围变化。
最后让旧动作在新计划形成后返回成功，确认记录能同时解释旧事实与新选择。可追溯的计划变更让接管者知道什么变了、依据是什么，以及哪些事情已经无法当作未发生。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2611_95335967/article/details/170337440
