面向 AI Agent 的机器支付 - AIsa

机器支付流程让软件可以在运行时为受支持的能力付费。对 AI agent 来说，这样可以减少为每个可能用到的 API 单独维护订阅或提供商账号的需求。支付自动化不应被视为无上限的支出授权。它是一种带有资金副作用的执行能力，应当像其他高权限操作一样受到治理。

什么时候适合程序化支付

以下情况可以考虑：

agent 偶尔需要访问某个付费 API，但不值得为它单独开订阅。
用量随任务波动，按次计费比维护多个提供商账号更容易控制。
应用需要在多个受支持能力之间共用一个钱包或用量余额。
任务可以在执行前定义清晰的支出上限。

如果用量是可预测的，且应用不需要在运行时做采购决策，预付费账号或普通 API 密钥可能更简单。

需要先定义的控制项

在启用自主支付路径之前，先定义：

控制项	需要回答的问题
单次请求上限	一次调用最多允许多少金额？
单任务上限	整个工作流最多可以花多少？
时间维度上限	每日或每月的上限是多少？
确认策略	哪些金额或能力类型需要用户批准？
重试策略	失败的请求能否在不重复扣费的前提下重试？
审计记录	保留哪些请求、金额、能力和结果字段？
失败处理	扣费成功但上游结果失败时怎么办？

把选择和授权分开

agent 可以判断某个付费 API 有用，但这不代表它有权购买。请把这些决策分开：

能力选择： 找出可以完成任务的 API 或服务。
成本估算： 判断预期金额和不确定性。
授权： 将成本与策略比对，必要时请求确认。
执行： 只提交一次付费请求。
校验： 同时确认结算结果和 API 返回结果。
审计： 记录决策和结果，且不暴露敏感信息。

AIsa 的计费背景

AIsa 对模型和 API 消耗采用按量计费。钱包与支付指南说明了账户充值、支持的充值方式、余额扣减和用量日志。有钱包并不意味着所有 AIsa 能力都可以通过自主支付协议获取。设计流程前，请查阅具体 API 的文档和认证要求。

agent 的安全规则

绝不能因为持有 API 密钥或已连接钱包，就推断自己拥有支出权限。
不要暴露钱包凭证、API 密钥、签名或授权 token。
避免对计费调用使用无上限的重试循环。
在有条件时，优先在付费副作用之前做只读预览或询价。
要校验最终响应，不要把结算成功等同于任务完成。

相关内容