同意撤回问题：当一个人在智能体已开始执行后改变主意

AI智能体问责架构花费了大量精力关注注册时的同意：谁授权了这个智能体，在何种范围内，代表谁。设计完善的系统中存在的同意层，是工作流启动时授权的表示——在智能体开始之前，记录正确的人已经同意。这一层很重要。但它将同意视为闸门，而非持续条件。一旦闸门打开，智能体便继续执行。同意撤回问题恰恰从闸门打开的那一刻开始。

人们会改变主意。情况会发生变化。今天早上同意AI辅助照护方案的患者，今天下午可能会撤回同意——因为临床状况发生了变化，因为家属提出了疑虑，或者只是因为重新考虑了。"同意即闸门"架构无法回答的问题是：当撤回发生时，信号如何到达已经处于工作流执行中的智能体，智能体收到信号后该怎么办？

同意撤回失效的解剖

一个AI智能体正在为长期照护机构的一位住户管理多步骤照护协调工作流。上午10点，住户的授权代理人审阅了照护计划，并同意了当天预约的AI辅助调度和沟通。智能体开始执行：确认交通、通知现场临床团队、准备下午的用药计划，并为住户的专科医生排队发送通讯。

下午1点30分，住户代理人直接致电照护机构，口头撤回了对当天剩余AI管理计划的同意。一名护理协调员在住户记录中记录了这一撤回。执行下午工作流的智能体无法连接到该记录。下午2点15分，它发送了排队中的给专科医生的通讯——这些行动完全处于早上同意的范围内，也完全超出了已撤回同意的范围。智能体并没有出故障，它在执行一个启动时被授权的工作流，针对的是数小时前已经改变的同意状态。

这一失效模式与恶意智能体或配置错误无关。它是同意建模方式的结构性缺口：同意被视为进入工作流的前提条件，而非工作流在整个执行过程中必须保持在其范围内的持续授权状态。

信号传递问题

最直接的挑战是渠道：撤回信号如何到达正在运行的智能体？在当前大多数架构中，同意表示为数据库中的一个标志，在注册时设置，在工作流启动时读取。没有订阅机制——没有办法让智能体接收该标志已更改的推送通知。智能体不会持续轮询同意存储；它在启动时读取一次值，然后在缓存状态下继续执行，直到工作流完成或遇到明确的检查点。

即使在定期轮询同意状态的系统中，轮询间隔也会产生窗口期。如果智能体每五分钟检查一次同意，而撤回在上次检查后四分钟五十秒到达，智能体将在授权已被撤回的情况下继续运行五秒钟。在物理世界照护中，错误时刻的五秒钟足以发送一条通讯、触发用药提醒或确认一次临床预约——这些行动的后果比轮询周期持续更长。

正确的架构是推送模型：同意撤回产生一个事件，该事件被传递给所有当前在该同意下执行工作流的智能体。这要求智能体具有状态可达性——维护持久连接或消息队列，同意基础设施可以向其写入。这与无状态工作流执行是本质上不同的架构，而当前大多数系统并非如此构建。

认证问题

假设传递渠道存在，还有第二个问题：接收撤回信号的智能体必须能够验证该信号是真实的。虚假撤回——由希望破坏智能体运作的攻击者注入——是伪装成同意事件的拒绝服务攻击。接受任何撤回信号而不进行密码学验证的智能体容易受到操纵。在采取行动之前要求验证的智能体可能延迟足够长的时间，使伤害无论如何都会发生。

处理授权授予的同一基础设施需要处理撤回：带签名、带时间戳、不可否认的信号，智能体可以在采取行动之前针对已知密钥进行验证。在后量子部署环境中，这些签名必须使用能够抵御量子能力对手的算法生成和验证。后量子验证的计算开销——在许多并发智能体实例的聚合下并非微不足道——意味着撤回信号密码学的设计与智能体执行延迟预算的设计是不可分割的。

硬件信任根环境在特定方面有所帮助：智能体的硬件认证可以将同意状态作为已认证执行上下文的一部分，这意味着任何试图注入非由合法同意机构生成的虚假撤回信号的尝试都将通过认证检查失败。但这要求从一开始就将同意基础设施与硬件认证链集成——一个容易推迟但难以改造的设计选择。

在途行动问题

即使有有效的传递渠道和经过验证的认证，第三个问题依然存在：对于在同意撤回时刻与撤回信号到达时刻之间智能体已经分发的行动，该如何处理？这些行动并非因疏忽或错误而未经授权。它们是智能体在采取行动时被授权采取的行动，授权在其效果落地之前已经失效。

下午2点10分发送给专科医生的通讯可能要到2点30分才会被读取。下午2点12分发送的用药提醒在2点15分到达护理团队。智能体在2点20分收到撤回信号并停止了。停止是正确的。但已分发的通讯继续在世界中传播并产生效果——安排了一次临床通话，触发了一次照护行动——这些都是撤回同意的人未曾授权的。智能体在行动时采取了正确的行动。结果不是这个人会授权的。

这是同意撤回问题与回滚问题和交接问题交汇的地方。已经传播到外部系统的行动无法通过停止智能体来召回。对于这些在途行动的问责问题确实很难：智能体在行动时在其授权范围内行动；授权在效果落地之前失效；没有任何一个参与者犯了错误。缺口是架构性的。

将同意视为持续的授权状态

由此得出的设计原则与TOCTOU分析和撤销分析得出的原则相同：授权不能被视为一次检查就假设永久存在的条件。具体而言，同意是一种具有持续表达的人类关系——不是签署一次就永久有效的文件。在架构上，这意味着同意必须被建模为智能体执行上下文的流式属性，而非工作流在初始化时通过的闸门。

在实践中，这需要三件事。首先，具有推送能力的同意基础设施：能够生成撤回事件并以足够短的延迟将其传递给正在运行的智能体，在相关部署域中"足够短"意味着秒级，而非分钟级。其次，可密码学验证的撤回信号，与覆盖授权授予的同一认证链集成，以便智能体能够在不引入无界验证延迟的情况下区分真实撤回和对抗性干扰。第三，针对在途行动的明确处置策略：智能体必须在设计时知道，当撤回到达时已经分发的行动该如何处理——哪类行动可以召回，哪类不能，以及在任何一种情况下必须通知谁。

最重要的同意层不是在工作流启动时记录同意的那个，而是在工作流执行的每一个时刻追踪同意是否仍然有效、并在同意不再有效时及时到达智能体以便采取行动的那个。