摘要

  • 2026年9月28日的首版个人 Internet-Draft AAuth Events，允许资源服务把签名事件送到智能体的 Agent Provider（AP），由这个常在线中介代收。
  • AP 只有在持久记录已接受事件后才能返回 HTTP 202；这张回执既不是智能体已收件的证明，也不是智能体在事件令牌过期前完成核验和动作的证明。

一个代收信箱解决了“找不到收件人”的问题，却引出另一道问题：代收者现在知道是谁寄来信、收件人订阅了谁，还能看到信的内容。Dick Hardt于2026年9月28日发布的 AAuth Events 首版草案，不应只当作智能体事件通知的便利功能阅读。它同时改变了消息的保管边界与信息可见范围。两者是同一架构选择的两面。

这份文本是编号 -00 的个人 Internet-Draft，拟走 Standards Track；IETF Datatracker在本次核查时显示其存在，并未把它变成已批准RFC、工作组共识或生产可靠性证明。它依附于另一份AAuth协议草案。父协议努力让智能体代表个人使用哪些资源，不必总由AP掌握；事件扩展则面对异步场景：资源需要在智能体离线或无法接受入站连接时，仍能投递后来发生的消息。把AP设为常在线收件处，正是解决这一接入难题的办法。

流程从订阅开始。智能体对某个资源的事件建立订阅，事件发生后，资源发送带签名的事件令牌与正文到AP。AP检验资源签名、令牌面向的接收方、订阅是否仍有效，以及正文是否吻合令牌内的 body_s256 摘要；草案还允许用签发方与事件标识组合识别重复投递。这些检验可以排除不合条件的第一跳消息，却不能说明最终收件的智能体正在运行，更不能说明它已经理解事件并采取措施。

草案对 202 Accepted 设置了一条实在的门槛：AP不能只因网络请求进来了就立刻回成功；它必须先把已接受的事件持久记录，留待后续交付。资源方因此得到的是“AP已接管保管”的回执，而非随时可能消失的内存队列确认。这个区别有价值，但价值止于资源到AP这一跳。AP怎样把事件交给智能体，草案明确留给平台实现，没有规定通用推送、轮询、智能体收件回执或端到端时限。把 202 写成“智能体已被通知”，是用前一跳替后一跳作证。

事件还有时间边界。智能体最终收到时，须检查令牌有效性、接收对象、正文摘要和本地场景；令牌已过期或正文不符时，不得据此行动。设想某资源通知短暂开放的处理窗口，智能体离线，AP如实记录并在其重新上线后送达。若令牌那时已过期，消息本身可以完好无损，行动窗口却已经关闭。这是说明机制的假设情形，并非已发生事故。持久存储保存的是证据，不会自动给过期令牌续命。

摘要校验也不能替代送达时点。body_s256 能帮助智能体发现AP改动或替换正文；草案同时明确指出，它不能阻止AP扣留或延迟投递。一个没有被篡改的事件完全可能太晚才到。即使到达，智能体还可能因接收对象、上下文或令牌期限不合而拒绝；通过核验，也未必代表最终动作已经执行。收存、交付、核验、行动与过期，应被当作不同事实，而不是一个模糊的“成功”。

隐私代价同样具体。AP从订阅及事件令牌看见智能体订阅了哪些资源，也会看到事件正文。草案并没有掩饰这与父协议尽量避免AP获知个人资源使用情况的目标存在偏离。这不等于每个AP都会滥用信息，也不能凭草案推断已部署产品在跟踪用户；但若运营方宣称“AP只是看不见内容的中转”，就必须拿出额外设计，而不能从此草案自动推得。减少正文内容、限制保留时间、划清资源身份的可见范围，都需要作为具体实现选择来检验。

因此，本轮新闻事实并不只是多了一条“事件传输”草案。它把可靠的第一跳收据与未标准化的最后一跳并列摆出来，又把在线代收的代价写进隐私边界。真正该问的是：AP回成功之后，有没有证据表明智能体在有效期内收到并处理？为提供这项代收，AP究竟获知了哪些资源关系和正文？这两组问题若只用一张绿色回执回答，就会同时误判可靠性与信息暴露。

来源