只设预算，不足以约束 AI 智能体支付

为 AI 智能体设置消费限额，看起来是一种负责任的自动化方式。

但它远远不够，而且容易制造危险的安全错觉。

每日预算只能回答一个问题：一个周期内最多允许流出多少价值？它无法回答谁可以收款、哪个服务可以发起付款要求、允许使用什么资产、审批后的报价是否发生变化，以及请求超时究竟代表付款失败还是响应丢失。

一台始终没有超出预算的智能体，仍然可能向错误的收款人支付一百次。

如果自主系统能够花钱，它需要的不只是钱包和一个数字，而是一套把业务意图绑定到签名者最终授权交易的支付策略。

限额控制数量，却不说明用途

假设一个研究智能体每天最多可以消费 10 USDC。这个规则看起来相当保守，但如果它是唯一控制措施，就可能允许：

• 向运营人员从未批准的服务支付 10 USDC
• 因重试循环重复支付 100 次，每次 0.10 USDC
• 在错误网络上向格式相同的地址付款
• 为一项有效服务付款，但收款人在预览与执行之间已经改变
• 为一项 POST 请求付款，但请求正文并不是用户审核过的内容
• 第一次请求超时后重新授权，而前一笔转账其实已经成功。

所有这些结果都可能没有超过每日限额。

因此，预算是会计边界，不是完整的授权边界。它能够限制总体风险敞口，却无法说明为什么允许某一笔付款。

其他安全系统早已体现了同样的区别。数据库角色不会只用可执行查询的数量定义，云身份也不会因为配置了月度账单提醒就自动变得安全。资金权限同样需要明确作用域。

把购买表示成结构化权限

智能体付款权限应该表示成结构化意图，而不是“模型可以使用这个钱包”。这项意图至少需要绑定：

这就是“把钱交给软件”和“向软件分配一项可能需要花钱的明确任务”之间的区别。

模型可以判断自己需要购买天气记录、市场数据集或推理结果，但它不应该成为最终授权者，不能独自决定任何声称提供该资源的地址都有权收款。

分离四个信任边界

把四种职责分开以后，智能体支付会更容易理解和验证。

1. 智能体运行时负责请求

运行时选择资源并提出购买请求。它只持有受限且能够撤销的凭据，并且只能访问自己的付款尝试。

它不应该持有组织管理密钥，不能修改自己的限额、批准自己的例外、登记替代钱包，也不能调用通用签名方法。

即使模型本身行为正常，这种隔离仍然必要。运行时会处理不受信任的工具输出、远程内容和提示词。依赖项入侵或提示词注入不应因此继承资金库的完整权限。

2. 控制平面负责决策

控制平面把拟议购买与生效策略和当前预算进行比较，并决定拒绝、自动批准，或暂停等待人工判断。

决策应该使用经过归一化的结构化数据，而不是自然语言描述：资源来源、收款人、网络、资产、准确金额、智能体身份和请求身份。对于包含写入内容的请求，还应绑定 HTTP 方法与请求正文摘要。

3. 人工审批负责处理例外

一次审批应该只授权一项已经锁定的意图，而不是永久放宽支付策略。

如果审核后的收款人、网络、资产、方法、请求正文或金额发生变化，旧审批就不应继续有效。新请求必须被拒绝，或重新等待人工判断。

只显示“是否允许此智能体支付 2 USDC？”的审批界面，隐藏了审核人员真正需要的信息。界面应说明将购买什么、资源来自哪里、谁会收款、使用哪条网络和哪种资产，以及这一操作能否安全重试。

4. 签名者负责验证

持有钱包密钥的进程不能仅仅因为与智能体运行时属于同一家公司，就默认信任它。

更安全的做法是只接受控制平面签发的短期执行授权，并验证付款载荷是否与每一项授权字段完全一致。执行授权应绑定智能体、钱包、环境、网络、资产、收款人、金额、随机数和有效时间。重放、过期授权、未知签发密钥以及字段不一致都必须默认拒绝。

签名接口与密钥存储同样重要。即使私钥放在 AWS KMS 中，如果外部仍然可以调用通用的 sign(anything) 端点，就只是把无限制能力搬到了网络接口后面。受限签名者只应开放与付款有关的特定操作。

执行时使用的策略必须不可变

可变策略会制造一个很难回答的审计问题：十分钟前发生的付款，究竟由哪一版规则授权？

应该为策略文档建立版本，并让每一个已激活版本保持不可变。新增允许列表或修改限额时创建新版本，而不是原地覆盖旧策略。每一项付款意图都记录决策时使用的策略版本。

一份精简策略可以写成：

const policy = {
  allowedOrigins: ['https://data.example.com'],
  allowedPayTo: ['0x1234567890abcdef1234567890abcdef12345678'],
  automaticPaymentThresholdAtomic: '250000', // 0.25 USDC
  perPaymentLimitAtomic: '1000000', // 1 USDC
}

这份文档把请求分成三种结果：

• 超过单笔硬上限的请求直接拒绝，人工审批不能悄悄绕过硬限制
• 未超过硬上限，但不在自动允许范围内或超过自动付款阈值的请求等待审批
• 资源来源、收款人、金额、网络、资产和预算全部通过时，请求才可以自动继续。

每日预算仍然重要。应该同时设置组织预算和智能体预算，避免一个运行时消耗整个组织的可用额度。预算还必须在签名前以原子方式预留，否则并发请求可能同时看到相同的剩余额度，最终合计超过限制。

但是，只有策略能够解释为什么允许这笔支出，预算只能证明当时还有容量。

报价改变后，预览与审批仍应有效约束付款

x402 这样的 HTTP 原生支付协议，可以让资源服务器返回付款要求，并让客户端带上付款凭据重试原始请求。它解决了一个重要的协议问题：价格、付款载荷、验证步骤、结算步骤和资源响应如何组成一次 HTTP 交换。

但它不会替每一个组织决定智能体应该购买什么。

从首次预览到正式执行之间，资源服务器可能返回一项更新后的付款要求。安全客户端应该把它与已批准意图进行比较。如果策略明确允许，更低金额或许可以接受。不同的收款人、来源、网络、资产、请求正文或更高最高金额，则代表另一项购买。

字段绑定审批的复杂性在这里发挥价值。智能体不能拿“购买 example.com 的一份报告”这项审批，去授权一个上传了不同数据或向另一个地址付款的修改后请求。

超时表示结果不确定，不表示可以重新付款

最危险的重试发生在签名之后。

设想下面的过程：

1. 支付策略允许一项购买
2. 签名者授权完全匹配的付款
3. 客户端发送付费请求
4. 客户端在收到资源或结算响应之前超时。

付款可能失败，也可能已经成功。

立即创建新意图可能造成重复扣款，而且两笔付款都符合允许列表与单笔限额。正确状态不是 failed，而是在证据确定结果之前保持 settlement_unknown。

恢复流程需要稳定身份：

• 同一次购买尝试始终复用一个任务级幂等键
• 持久保存原始付款意图编号
• 审批后恢复原意图，而不是创建新意图
• 超时后查询并对账原始付款
• 永远不要把“没有收到响应”解释成“没有发生转账”。

自主系统往往会积极重试，因为这种行为对普通软件任务很有帮助。支付工具则必须用明确的不确定状态替代这种乐观假设。

审计记录必须能够还原决策

运营人员调查一笔智能体付款时，应该能够回答：

• 哪一个智能体和任务发起了请求？
• 哪一个策略版本执行了判断？
• 绑定了哪个来源、方法、网址和请求正文摘要？
• 批准了哪个收款人、网络、资产和金额？
• 预留了多少组织预算与智能体预算？
• 付款是自动通过还是人工批准，由谁批准？
• 哪一项执行授权和哪个签名者完成了签名？
• 资源请求返回了什么结果？
• 链上交易引用和结算状态是什么？

不能为了让记录看起来完整，就把钱包私钥、完整付款签名、原始执行授权或敏感响应正文写入日志。审计能力来自稳定标识符与摘要，而不是把秘密复制到日志中。

智能体支付的最低控制模型

启用自动付款前，至少应该具备：

• 一台专用支付智能体及能够撤销的运行时凭据
• 一个只用于明确目的和环境的钱包
• 包含准确来源与收款人的不可变策略版本
• 针对付款要求执行网络与资产验证
• 单笔硬上限、智能体每日预算和组织每日预算
• 不高于单笔硬上限的自动付款阈值
• 对未知对象或超过自动阈值的请求进行人工审批
• 把审批绑定到准确 HTTP 请求和付款字段
• 由客户控制且不提供通用签名接口的签名者
• 短期且只能使用一次的执行授权
• 重试过程中保持稳定的幂等键与意图编号
• 明确的结算不确定状态与对账路径。

最初应把自动付款阈值设为零，在人工审批下完成第一笔付款。验证完整记录后，只加入一个已知来源和收款人。提高自主程度的方法应该是缩小已知安全路径，而不是向模型提供权限更大的凭据。

为什么我们要构建这一层

StableOps 智能体支付围绕上述边界设计。智能体运行时只获得受限的 Agent Key。不可变策略和两层预算共同约束每一项意图。未知对象或超过自动阈值的购买需要等待审批。短期执行授权允许客户自行部署的签名者完成签名，而钱包密钥或 KMS 权限始终保留在客户环境中。

我们的目标不是让每一笔付款都自动执行，而是清楚定义哪些付款可以自动进行、哪些需要审核、哪些必须禁止，并在网络超时、报价改变和进程重启时继续守住这条边界。

智能体预算告诉你它最多可以花多少。

支付策略决定这项购买是否应该存在。