摘要

  • 9月28日公布的首版 AAuth Budgets 草案，建议由资源服务按每张授权令牌执行消费上限；这不是自动覆盖某个人全部智能体任务的总上限。
  • 多张令牌同时有效时，用户侧服务器须把已承诺额度合并预留；真实消耗尚未查明，不能先按零元释放额度。

最危险的超额，未必发生在某张令牌突破限制时。设想两项代理任务同时使用同一推理服务，各拿到上限为10个计费单位的授权令牌。这只是说明机制的假设数字，不是事故。服务为每张令牌精确止损，最后仍可能产生20个单位的费用。如果用户原本只允许总共10个单位，问题出在上游把同一段余量批准了两次。服务的单张限额可以完全正确，用户的总体承诺却已经错误。

Dick Hardt于2026年9月28日提交的 AAuth Budgets 首版 Internet-Draft，正面处理这种权责分离。作者将它标为“探索性草案”；“Standards Track”只是拟议方向。IETF Datatracker目前显示草案存在，尚未定义 RFC stream。这不是工作组共识、正式标准，也不证明广泛部署。草案依附于另一份 AAuth 协议草案：代理请求额度，资源服务声明计费单位与可提供额度，用户侧服务器以及可能参与的访问服务器可以缩小请求，最终获准数额随授权令牌送到资源端。资源端计量和强制执行；用户的总天花板留在用户侧服务器，不向单张令牌披露。

资源端的“硬上限”不是账单出来后推一条提醒。草案要求，同一张令牌已经承诺的消耗，加上正在处理请求的预留金额，任何时候都不能超过获准额度。生成式服务往往到输出完成后才知道真实费用，所以收费请求开始前，必须先有有限的最高成本：可来自请求指定的输出上限，也可来自已说明的默认规则。资源端先预留这笔最大值，再结算实际费用，把差额退回可用余额。这样会出现一种看似保守的拒绝：请求的最高可能价格超过余量，即使最终实际价格或许能装得下，也要先拒绝；代理可降低上限重试。它换来的是消费发生前的约束，而不是事后颜色警报。

草案还要求资源端保存归属于个人的用量账，但这本账不等于资源端知道个人的私人总限额，更不能凭猜测再造一个拒绝规则。多张令牌的总额由签发它们的用户侧服务器负责。草案把并发风险写成算式：同时存续的 n 张令牌，每张额度 X，在有效期内形成最高 nX 的授权敞口。这是权限设计的条件性后果，不能写成已经发生的损失。下游代理也不会自动从上游令牌划出“子预算”；它拿到的新令牌仍须另行获批、纳入同一总额。

更难处理的是失联后的“未知”。代理可能崩溃、丢弃令牌，或者刷新授权后不再出示旧令牌。签发方知道当初给了多少，却未必知道用掉多少。草案要求，在真实数值到达前，先把整笔尚未报告的分配视作已经花掉。另一次挑战带回的单令牌消费记录，只是当时的快照；令牌仍有效，就还能继续消费。资源的用量查询若注明统计已完整覆盖到 as_of 时点，签发方才能把此前已到期的分配核销。资源确认已记录撤销，可以提前结束风险；若不支持撤销或结果不可知，不能立即腾出额度。已经在途的请求仍可能做完。“停止”按钮既不自动追回消费，也不自动释放所有预留。

额度与行为权限也须分开。预算约束花费多少，不约束可以做什么：低价但不可逆的动作仍需恰当的 scope。若同一人在资源端拥有几个付费账户，令牌里的预算本身也不能决定记到哪个账户。草案提出 AAuth-Budget 响应头，向代理报告本次成本与令牌剩余额度，便于调整下一次请求；它默认不签名，是节奏提示而非授权依据。用量响应可以签名，但只是推荐，不是强制；签名能固定资源“报告了什么”，不能证明计量诚实或账单必然正确。草案中的实施状态来自提供者自述，本文没有独立验证。由代理提供商自行承担推理费用、且不走用户侧服务器的常见模式，亦不在本扩展范围内。

所以，新闻增量并不是又出现一个“给智能体设预算”的口号，而是总额究竟由谁保管、何时才可释放。只看每张令牌的绿色余额，无法回答同时活着的其他令牌、已预留金额、最新完整计量时点和撤销是否真正生效。

来源