三个时刻，一场竞态：委托的状态在何时被决定

规范解读 · 第 20 篇 · 本文引证来源 · 提问帖（引文逐字）： W3C Agent Protocol CG · post 0095 · Alan Karp · 我们的答复（已上墙）： post 0096 · 同一天的第二轮： 规范解读 · 第 21 篇 · 本轮所延伸的中任务规则： 规范解读 · 第 18 篇 · 底层的租约语义： draft-li-rttp-iqa-addressing-01（全文） · 姊妹双柱： RTTP（rttp://，CRI 27）· IQA（iqa://，CRI 28）

与本系列对话者的交流，今天跑了两轮；本文写第一轮。Alan Karp——其一连串提问自第 15 篇起一路驱动着本系列——抛出了委托线程至今最锋利的问题：一次委托的状态，究竟在哪个时刻被决定？

墙上的提问原文（0095 号帖，中译） · Alan Karp · 墙上原件（原文为英文，引文逐字）
「我一直在与一个 W3C 小组讨论衰减式委托，有人问：『你应当在什么时候考虑一次委托的状态？』相关的时刻有三个：委托成立的时刻、资源被调用的时刻、以及那次调用结束的时刻。」
「我担心在调用中途打断应用会让它留在不一致的状态里，这让我倾向于把调用时刻作为决定因素。我的理由是，各个步骤与状态变化之间存在一场不可避免的竞态。你委托的那个人，可能在调用刚好结束之后、也可能刚好结束之前离开公司。撤销同理；撤销请求可能在调用刚好结束之前、也可能刚好之后抵达服务器。」
「我承认这个选择的风险。让执行在条件改变之后继续，会出问题；但打断应用同样会出问题。如果你的应用有可能因为一次被拒的委托而崩溃，你就有共享凭证的动机。」

决定时刻收敛了

我们的答复（0096 号帖）先记录了收敛：有了 0095 的更正，双方如今共享同一个决定时刻。访问政策在委托成立时表达，条件在资源被调用时裁决。线格式从另一个方向抵达同一个结论：条件可以是委托人的，但它消费之事实的新鲜度必须在使用那一刻可重推导——而这正是租约与它的到期时间戳存在的意义。草案从不需要被说服到这个对齐上；时间戳本来就是这个设计。

竞态没有被消解——它被点亮了

答复拒绝声称线格式能消解竞态。一笔恰好在调用结束之前或之后抵达的撤销，是一道任何协议都擦不掉的边界，而假装擦掉了比竞态本身更糟。线格式能做的是让边界变得可读：回执记录权威侧事实在何时有效、在何时被观察到；过期之后的读数按 expired 作答，而不是按新鲜重放；在应答无法及时抵达的地方，残余语义接管——字节陈述这份主张有多老，于是调用方是看着摆上台面的年龄做决定，而不是踩着一个无声的假设。那张清单没有一条消除了竞态；每一条都消除了「看不见它」的借口。

可读拒绝的最强论据

他的收尾段是一段激励分析，我们的答复把它当作本系列自第 15 篇以来一直在跑的拒绝设计的最强论据。如果拒绝是致命的——如果一次被拒的委托会让应用崩溃——那么共享凭证就成了理性捷径，衰减机制死于它自己的执法。所以拒绝被做成可读的而不是致命的：一套带可审计回执的闭集理由，让调用方降级、重试或改道，而不是崩溃。衰减机制之所以幸存，恰恰因为一次 DENY 可以被读取、被第三方重推导、被回应——数小时后的第二轮里，VOC 实验从经验侧演示的正是同一条性质。

这一轮为什么有帮助

他给了地图——三个相关时刻，一场不可避免的竞态——答复把每个元素绑到已经存在的机制上：决定时刻的到期时间戳，竞态的 effective 对 observed 回执，激励分析的闭集拒绝。什么都不用新发明；问题只需要被问得足够准，而它被问准了。数小时后的第二轮，把同一个设计带进了例外通道——那一轮在第 21 篇接续。

一句话：协议擦不掉竞态，但能把它的边界点亮——一份可读、可重推导、可回应的拒绝，就是「必须被共享的凭证」的另一条出路。