摘要

  • GRP 修订 01 在发布者认证和会话核验之后，新增对 (publisher_id, event_id) 是否已在当前会话准入的检查。
  • 重复事件以 ALE-064 / duplicate_event_id 记录，并在影响评估与任何重试、回退或人工升级之前丢弃，成为真正的无操作。
  • 已准入配对集合因此成为安全状态；持久化、崩溃恢复、多节点一致性以及与第一次处置的原子关系仍需实施者证明。

一个正确会话里的错误重复

智能体正在执行任务，依赖服务发布了一条变化事件：某个关键组件不可用，严重级别需要回退。接收方查到登记过的发布者，验过签名，也确认 session_nonce 正是本次会话的值。随后它评估影响并切换路径。由于确认包丢失，上游又投递了一次完全相同的事件。

第二次投递没有伪造任何字段。签名仍会通过；会话令牌也不会失效，因为草案明确指出该值在一次会话内保持不变；签名覆盖的时间戳仍是原来的声明。若系统只问这三道题，它会得到三次“正确”，却漏掉唯一决定后果的问题：这个发布者的这条事件是否已经获得过准入？

《The Governed Remediation Protocol (GRP) for Agentic AI Systems》修订 01 把这个问题写入接收流程。Datatracker 将其列为活跃的个人 Internet-Draft。作者希望走 Standards Track，但个人草案不是 IETF 标准，也不代表共识、认可、互操作性或部署。本次变化值得观察的是控制边界本身，而不是它获得了机构地位。

GRP 的变化事件用于描述活动会话中依赖、资源或任务授权条件的改变。必备字段包括 event_id、publisher_id、发布者类型与签名、session_nonce、事件时间、变化类别、受影响组件和严重性。event_id 被要求在该发布者的事件流中全局唯一。

修订 00 已经按发布者类型检查其身份或密钥，并在会话令牌不匹配时以 ALE-064 / session_nonce_mismatch 拒绝。修订 01 的直接文本差异显示，在这些检查之后新增了第六步：查询发布者与事件编号这一配对是否已经准入。

先记住第一次，才能拒绝第二次

如果配对已经存在，接收方记录 ALE-064 / duplicate_event_id，在再次做影响评估和处置之前直接丢弃。草案称之为真正的 no-op：第一次准入已经生成相应审计记录并触发适用动作，第二次到达不应再创造任何业务效果。

必须使用配对而不是脱离来源的事件编号。发布者验证回答谁有权发出声明，会话令牌回答声明属于哪次会话，准入集合回答这条具体声明是否已经跨过行动边界。强签名不能替代接收方记忆，正如门禁卡是真的，并不能证明持卡者今天还没有进过门。

检查的位置比名称更重要。如果先调用回退服务、发起重试或向人发送告警，再给审计记录加上“重复”，处置已经发生。修订 01 把阻断点放在影响评估之前，使一条真实消息的第二份副本在获得行动权之前结束。

草案还把重放与处置循环分开。重放只需要捕获一条有效事件并重复发送；处置循环则来自多次真实发生的瞬时故障。精确配对能识别前者，不能自动判断几个新编号是否其实描述同一个长期根因。把两者混为一谈，既可能放过副本，也可能错误压制新的故障信号。

签名标准不保存到达历史

RFC 7515 提供 JWS 的签名机制，RFC 7517 定义 JWK 的密钥表示，草案所引 RFC 9846 提供 TLS 1.3 传输背景。它们能支撑内容完整性、密钥表达和通道保护，却不会替某个 GRP 接收方维护已准入集合。

这里呈现的是智能体治理中常见的层级错置。签名有效只说明内容能在某把密钥下通过验证；正确 nonce 只说明它声称属于当前会话；时间戳只是一项被签声明，除非协议另有接收窗口和比较状态。首次准入是另一个事实，必须由权威状态给出。

剩余风险也说明了边界。若发布者签名密钥已经被攻破，攻击者可以生成带新 event_id 的新事件。它们不会命中旧配对。防重放解决的是同一条已准入消息被再次使用，不是对失陷发布者重新建立信任。

一条规范要求背后的恢复难题

修订 01 要求在当前会话内跟踪配对。已审阅的文本没有规定它存在哪里、进程崩溃后如何恢复、多个接收节点怎样收敛、会话结束何时回收，也没有完整定义首次准入记录与首次处置之间的原子提交。这些是实施与采购需要回答的问题，不能反过来宣称草案已经失败。

但它们决定承诺是否成立。若集合只在内存里，重启就会把旧事件洗成新事件；若两个节点查询各自副本，它们可能同时认为自己是第一；若先记配对后崩溃，系统需要知道首次动作该恢复还是已完成；若先动作后记配对，副本已有机会再次执行。

现有证据只证明草案内容和版本变化，不证明已有实现、独立审计、互操作测试、真实部署、事故、攻击或性能数据。SOOS 角色名和 ALE 编号是提案语言，不是生产系统的观测记录。

来源