摘要

  • 修订 05 要求在调用外部适配器之前，用同一笔原子事务记录“已进入提供方”，并把额度从预留转为已消耗。
  • 越过这条边界后，超时只能说明结果未知，不能证明未进入；只有权威状态证明入口从未被跨越，额度才可释放。
  • 撤销和紧急冻结必须在排序上先于入口才能阻止本次行动；入口先发生，就只能阻止后续行动，不能改写已经可能发生的效果。

退款按钮制造出的第二份权力

设想一个被授权采购有限耗材的智能体。它为一笔 800 单位的订单预留额度，向供应商发出请求，却没等到响应。本地界面把它标成失败，于是退回 800。几分钟后，供应商完成原订单；智能体也已经用恢复的额度下了第二单。

问题不在签名真假，而在系统把“没有看见结果”误当成“没有进入外部系统”。《Bounded Capability Receipts and Durable Spend Control for Agent Actions》把签名凭证与实时额度状态分开。凭证可以绑定签发者、主体、范围、单位、金额、持有者证明、有效期和上级能力；它不能让多个进程、重试和副本自动共享同一个余额事实。因此，草案要求所有能够动用同一能力的执行者依赖同一个原子状态域。

余额公式很朴素：总额减已消耗，再减已预留。真正的制度问题是，预留在何时变成消耗。

修订 05 把扣减搬到入口

修订 04 采用“预留—执行—提交”顺序：进入提供方前记录入口开始，之后在结果提交时把预留转为消耗。修订 05 改称“预留—准入—核对”，并把状态转移与外部入口合并。

就在调用适配器之前，同一笔事务必须验证预留所有者和截止时间，重查能力与当前许可状态，重查直接撤销和需要继承的级联撤销；若启用紧急准入域，还要确认域仍为活动状态且时代编号未变。随后，这笔事务同时写入 provider_entered、减少预留、增加消耗。只有成功完成后，外部适配器才可以运行。

后续结果提交不再扣第二次。它只把 provider_entered 关闭为已执行或不确定。于是账面权力与现实风险在同一时刻变化：从组织无法再证明“外部效果绝无可能”的那一刻起，额度就不再可用。

未知结果不是未进入证明

草案刻意区分 indeterminate 与 not_entered。前者表示入口可能已经跨越，但没有足够证据确认成功或失败；额度继续算作已消耗。调用方超时后不得换一个操作编号重试，而应查询和核对原操作。

恢复额度需要更强证据。权威状态必须显示操作仍停留在预留阶段，且没有写入提供方入口。经过身份验证的预留所有者才可释放预留，并把状态结束为 not_entered。即便如此，原操作编号和行动绑定仍作为防重放墓碑保留。额度恢复的是未使用容量，不是把同一请求洗成一项新请求。

这种不对称会牺牲一部分可用性，却避免把不确定性变成重复后果。两次付款、两次发货、两次删除或两次密钥轮换，不会因为后来修正一张表而自动消失。

冻结也必须赢得先后顺序

修订 05 增加了可选的准入控制域。预留时保存一个单调递增的时代编号，入口事务再重查。如果冻结先完成，入口被拒绝，可在证明未进入后释放额度；如果入口先完成，冻结只能阻止后来的准入，不能退款或改写本次结果。

撤销也是如此。预留不会把旧授权永久固化；入口必须重查当前撤销状态。但晚于入口的撤销也不能证明提供方没有接受请求。

边界必须保持克制。Datatracker 将修订 05 列为 2026 年 9 月 6 日更新的活跃个人 Internet-Draft，IESG 状态为 I-D Exists，没有正式 IETF 背书。草案正文写的是 Experimental 意向，而摘要页目前没有列出预期 RFC 状态。它不是标准、认证、部署或互操作证明。

JSON 规范化、Ed25519、互联网时间格式和规范性关键词可以帮助复现被签对象，却不能证明适配器把入口设在了提供方真正不可逆的位置。签名声明、当前状态、外部准入和观察结果仍是四层不同事实。

来源