摘要

  • SAMP 草案第 04 版为 AI 代理管理命令 CONFIG、EXEC 的结果加入 record_revision：结论一旦有实质变化，记录号递增，旧快照保留在只追加的审计历史中。第 03 版没有这个字段。
  • 迟来的成功不能凭“现在看起来正常”认定；证据必须指向原命令。重复请求只取最新记录，不再执行一次。端点若无法确认最新有效版本，就以 back_pressure 回复，不端出一份可能过期的结果。

屏幕可以更新，过去不能重写

设想一家机构让代理修改日志级别。管理台收到 indeterminate，值班员不知道变更是否落地。几分钟后，一个与原命令绑定的运行证据表明变更已经发生。若系统把最初的“不确定”直接涂成“成功”，交接班的人便看不到那段盲区；若把“不确定”当成失败再按一次按钮，则可能制造第二次效果。

10 月 28 日更新的文本要求原操作引用和经过认证的请求绑定保持不变。第一份权威结果从版本 1 开始。后来确有可核验的效果证据，端点才可写入版本 2；原来的判断、授权上下文、补充证据以及查清时间仍留在审计链。相同字节的重试只读取最新结论，不是新的执行许可。

这套做法最关键的一刀切在因果上。目标配置后来出现，不足以证明是这条命令改的，也可能是另一个操作者。草案要求证据配置能够把效果归因于原操作。单独的策略许可、健康检查或后来状态都不能替代它。已经确认的最终结果若遇到矛盾观察，系统记下审计冲突，不能暗改旧结论。

草案还把“执行成败”和“审计证据是否持久保存”分开。一条命令可以成功，而审计写盘失败；只要能提交新的有效记录版本，就要如实同时报告两件事。若重启或副本切换后连最新版本都辨不清，端点返回没有结果载荷的 back_pressure。管理台保存自己见过的最高版本；低版本是回退异常，同号异文则是冲突。谁最后到达，谁就掌权，这条规则在此行不通。

IETF 状态页将它列为个人提交、拟走 Experimental 路线的草案。还缺一条贯穿不确定回复、迟到证据、版本递增与重启恢复的认证操作轨迹，才能判断具体实现是否守住这本账。

来源：第 04 版草案；第 03 版草案；IETF 状态。