摘要

  • Sankalp Gilda 10 月 27 日个人 Internet-Draft 的第 01 版，新增“累计额度下的消耗”记录：已花金额、未结算许可的预留金额、本次请求和决策点所读余额版本都要入账。
  • 工具回复丢失，不等于钱没有花出去。相同请求重试不重复占额；另一笔请求若读到预留之前的旧状态，可能把同一额度授权两次。

消失的是回复，不是那笔占额

让 AI 代理替人调用一次付费工具，工具没有回话。运营系统这时最容易做的一件错事，是把没有回复当成没有执行，立刻把那笔钱放回可用额度。Sankalp Gilda 新版代理审计记录草案的处理办法更谨慎：金额继续预留，直到同一请求的后续记录显示工具究竟产生了什么效果。

10 月 27 日公告与IETF Datatracker确认这是一份个人 Internet-Draft。文中没有真实付款事故。前一版也没有这次新增的第 5.9 节。新闻点不是“机器也要记账”这种空话，而是具体到下一次授权时，余额里必须保留哪些尚未兑现的承诺。

累计限额不能靠逐笔检查守住。一笔付款看起来小，前面几笔尚未结算的许可却可能已经占满天花板。新版要求 consumption-state 写出限额文件摘要、币种、限额、已消耗、已预留、本次请求、待结算请求清单和 stateRevision。最后一项尤其重要：它指出决策系统当时读的是哪一版余额。余额刚更新过，也可能漏掉一笔更早获准但尚未回执的付款；只写“数据新鲜”不足以说明它算对了账。

同一请求重发，和另一笔钱不是一回事

草案给了一个很直观的算例：限额 50,000 便士，已经花掉 30,000；先前一笔获准的 12,000 便士还在预留区。如果只是同一请求因回复丢失而重试，系统根据相同请求摘要认出它，合计仍为 42,000，不能把这 12,000 再算一次。若来了另一笔独立的 12,000，合计就到 54,000，应当拒绝。这里的金额是草案示例，不是现实交易数据。

预留金额如何退出，也写得很死。后续记录显示同一请求的效果确已发生，就从“预留”转为“已花”；后续记录显示效果为 none，才释放额度。没有回复，不能替代任何一种结算证据。这可能让一次实际未执行的调用暂时占着钱，但能防止一个结果未明的调用把自己的额度借给下一笔。

再看旧状态。第一笔 12,000 已经获准并预留，第二个决策点却读到预留之前的 stateRevision。它眼里的余额很宽松，记录格式也可能完全正确，但它没有看到已经作出的承诺。草案要求持有同一限额下多条记录的审查者按状态版本对照：后来的许可应持续列出此前未结算的许可，直到它转为已花或有“未发生”的结算记录。漏掉预留，便露出双花窗口；无凭无据释放预留，也露出缺口。

更有意思的是，一条记录即使写着“超限仍许可”，格式仍然有效。若审计系统把这类记录当成坏数据拒收，真正的坏决定反而从档案里消失。记录要能说出授权失败，而不是只收藏成功案例。签名能固定已写下的字节；草案自己也提醒，档案内部自洽不能证明外部世界确实如此。

谁能把余额说清楚

授权文件规定上限，决策点读状态并放行，工具产生效果，观察者描述效果，保管者交出记录。每个人掌握的不是同一块事实。跨记录核对能够追问“第二笔决策看见第一笔预留了吗”，但前提是审查者拿到了有关记录。由同一运营者决定写什么、留什么、交什么，数字再精密也可能只照亮被呈上的那一叠纸。

因此，所谓代理“花钱不越权”，不能只靠一次成功响应或一张绿色勾号。它要能说清：哪份文件给了额度，哪版余额承载了决策，哪笔预留尚未结算，什么观察结果允许释放。回复没了，只是核账工作的开头。

原始文件