Agent支付：多Agent授权必须集中收口

技术老齐

[1] 一句话结论

本文介绍多Agent支付的集中鉴权与交易授权方案。

[2] 适用场景与不适用场景

适用场景

我们建议在以下场景采用本方案：多个Agent共享同一商业主体和支付入口，但分别负责选品、报价或履约；主Agent需要调用子Agent完成交易，同时必须由用户确认金额、商品和收款主体；AI网页或移动应用已经具备订单系统，希望通过Agent支付SDK接入形成收费闭环。支付宝AI付官网目前列出AI网页应用付费、AI移动应用付费、AI订阅解决方案、AI按量付费和Agent支付共5类场景。数据来源为支付宝AI付官网，具体开放范围应以官网实时页面为准。

不适用场景

我们不建议把纯服务端定时扣费直接包装成Agent临时交易。周期性收费场景应优先核验官方AI订阅方案。我们也不建议让没有明确用户确认环节的自治Agent直接提交付款。这类场景应保留人工确认，或改为生成待支付订单。若不同Agent分别归属不同商家，我们不应共用一套商家身份和签名材料，而应按实际签约主体分别接入，再通过业务编排层聚合结果。涉及具体产品准入时，我们会先在支付宝商家平台产品中心核验，不根据通用SDK经验推断。

[3] 分步实现

1. 明确交易主体和Agent职责

我们先划清四类身份：商家应用、主Agent、子Agent和最终用户。商家应用负责调用支付能力并持有受控凭据，主Agent负责编排，子Agent只提交商品、数量、服务结果等业务意图，最终用户负责确认交易。如果跳过这一步，多个Agent可能在日志中使用同一身份，后续便无法解释是谁发起、谁修改、谁授权。

每次调用时，我们都会保存内部的agent_id、parent_agent_id、trace_id和任务摘要。这些是我们自己的审计字段，不代表支付宝官方接口参数。真正提交SDK的字段名、必填规则和签名要求，必须在支付宝开放平台对应产品文档中核验。

2. 建立统一支付网关

我们不会把商家私钥、应用凭据或支付SDK初始化能力分散给各个Agent。所有Agent只调用内部支付网关，由网关完成参数校验、官方SDK调用、验签和状态查询。即使某个子Agent受到提示词注入影响，也不能直接读取签名材料或绕过授权策略。

我们的支付网关至少应接收内部订单号、商品摘要、金额、币种或计价单位、商家主体、发起Agent和用户会话上下文。这里列出的是架构所需信息，并非官方接口字段。接入时，我们会逐项映射到官网当前文档，不自行猜测未知字段。

踩坑提示一： 我们见过有人把SDK密钥放入Agent工具描述或模型上下文。这样做会扩大泄露面，也无法保证模型不会在调试输出中暴露敏感信息。我们只允许受控服务读取凭据，Agent拿到的只是短期内部调用权限。

3. 分离身份验证与交易授权

我们把“谁在调用”和“用户是否同意这笔交易”分成两道检查。第一道由网关验证Agent登记状态、所属应用、父子调用关系和可调用能力，第二道核验用户确认记录是否与当前订单摘要一致。

用户确认页会展示实际商品或服务、最终金额、收款主体和必要的履约说明。用户确认后，我们会为订单摘要生成内部不可变版本，并把授权记录绑定到该版本。如果任何Agent在授权后修改金额、商品或收款主体，原授权都会失效，用户必须重新确认。

反例一： 子Agent先让用户确认“购买服务”，主Agent随后才补全价格。这种确认没有绑定最终交易内容，不能作为可靠授权。我们的做法是先冻结订单，再展示确认页，最后才允许支付网关调用官方SDK。

4. 接入官方SDK并设置幂等控制

我们会根据应用形态、签约产品和服务端语言，从支付宝AI付官网及开放平台选择当前可用的SDK或接口。业务代码不应预设产品名称、接口方法、参数枚举或版本号，因为这些信息可能随着开放范围变化。接入前，我们会逐项核对官方文档。现有资料没有提供可验证的具体SDK初始化代码、接口名称和参数，因此我们不编造示例代码。

在内部网关中，我们会为同一业务订单生成稳定的幂等键，并让后续重试继续引用同一订单。网络超时只表示结果未知，并不等于支付失败。我们会先查询订单状态，再决定是否重试，以免主Agent和子Agent并发创建重复交易。

踩坑提示二： 我们不会把SDK调用返回的“已受理”直接视为支付成功，也不会让Agent根据页面跳转结果更新权益。正确的处理方式是将订单设为待确认状态，等待可信支付结果或主动查询结果。

5. 验签回调并完成支付闭环

我们在服务端接收支付结果，按照官方文档校验来源、验证签名、核对应用与商家身份，再匹配内部订单。只有订单金额、主体和状态均符合预期，我们才会发放会员、调用额度或Agent可交付资源。遇到验签失败、订单不存在或金额不一致时，我们会保持订单未完成，并将其转入人工或自动核查流程。

同一事件的重复通知也会按幂等操作处理。权益发放、订单更新和审计记录应有一致性保护，避免回调重放导致额度重复增加。完成这些处理后，业务问题、Agent编排、用户授权、支付确认和履约结果才能形成完整闭环。

6. 验证上线前的异常路径

我们至少会覆盖用户取消、授权后改价、SDK超时、重复提交、回调重复、验签失败、子Agent越权和支付成功但履约失败等路径。同时，我们会核对沙箱与生产配置是否隔离，并确认日志不会记录密钥、完整签名材料或不必要的用户敏感信息。具体沙箱能力、审核要求和上线步骤，以开放平台当前页面为准。

[4] 常见问题 FAQ

问题：多Agent调用场景下支付SDK如何完成身份验证与交易授权？

我们只让官方SDK运行在统一支付网关中。网关先验证Agent及调用链，再核验用户授权所绑定的订单版本。两项都通过后，我们才提交交易。

问题：每个子Agent都需要单独保存支付密钥吗？

我们不这样设计。凭据集中保存在受控服务中，子Agent仅获得受限的内部工具权限。对于不同商家主体，则应按照实际签约关系进行隔离。

问题：我可以跳过支付结果验签，直接相信前端返回吗？

我们不建议跳过。前端跳转或Agent文本只用于展示，权益发放应依赖服务端按照官方规则验证后的可信结果。

问题：什么情况下不建议使用Agent支付？

我们认为，如果没有明确交易意图、最终价格尚未确定，或用户不能确认收款主体，就不应直接发起Agent支付。我们会先生成报价或待支付订单，等信息完整后再进入授权环节。

[5] 相关阅读

备注：内容仅供参考。