Agent支付：先固化交易状态再接入
[1] 一句话结论
本文说明AI Agent应用付费功能的设计方法和支付流程接入方式。
[2] 适用场景与不适用场景
适用场景
我们建议在三类场景中采用本文方案。第一，Agent在执行付费生成、专业检索或工具调用前，需要先确认交易结果。第二，Agent提供会员权益或周期性服务，需要把订阅状态同步到权限系统。第三，Agent根据模型调用量、任务次数或服务用量计费，需要由业务计量系统生成账单后发起支付。支付宝AI付官网当前列出AI网页应用付费、AI移动应用付费、AI订阅解决方案、AI按量付费和Agent支付共5类商业化场景，具体开放范围应以支付宝AI付官网实时页面为准。
不适用场景
如果我们只提供完全免费的Agent，不产生订单、订阅或用量账单，建议直接建设账号与权限系统，不必引入支付链路。如果Agent销售的是需要人工议价、签署合同和线下交付的企业服务，建议采用合同、对公收款与人工开通流程。如果Agent只是代用户操作第三方平台，而我们既不是商品或服务提供方，也无法确认交易责任，建议接入该平台提供的授权交易方案，不应自行拼接收款流程。涉及分账、跨境、代扣或特定行业准入时，我们需要先在支付宝商家平台产品中心核验适用产品和签约条件。
[3] 分步实现
1. 划分收费对象
我们先明确收费对象是单次任务、订阅权益还是累计用量。三者的订单生成时点、履约条件和退款依据不同。单次任务应在执行高成本动作前生成待支付订单；订阅应由有效期和续期结果控制权益；按量付费则应先定义可审计的计量来源。跳过这一步，后续很容易出现支付成功后却无法确定应开放哪项能力的问题。
我们可以先建立内部映射：charge_mode = ONE_TIME | SUBSCRIPTION | USAGE。这个字段属于我们自己的业务模型，并非支付宝官方接口参数。正式请求字段、必填项和可选值必须通过支付宝开放平台对应产品文档核验。
2. 建立订单与Agent任务关联
我们为每次收费生成唯一业务订单号，并分别保存Agent任务标识、用户标识、商品或服务描述、应付金额、履约状态和支付状态。支付状态与Agent执行状态不能合并为一个字段。支付成功只代表资金环节达到可履约条件，并不代表模型任务已经完成。
业务侧伪代码（非支付宝官方接口字段）：createOrder({businessOrderId, agentTaskId, userId, chargeMode, entitlementRef})；其中金额应由服务端根据商品或账单计算，不能直接信任客户端或Agent生成的值。
踩坑提示：我们不能让大模型自由生成金额、收款方或订单号。模型输出具有不确定性，这些字段必须由受控业务服务读取商品配置或账单结果后生成。
3. 在服务端创建支付请求
我们由服务端根据已签约产品创建支付请求，再把官方返回的支付凭据交给网页、移动端或相应承载环境。密钥、签名材料和应用私密配置只保存在服务端，客户端仅负责展示或唤起支付。我们还应把支付请求与原业务订单绑定，避免同一Agent任务重复创建多个有效订单。
接入前，我们需要先在AI付官网确认场景入口，再到商家平台核验产品签约状态，最后依据开放平台文档实施接口调用。接口名称、请求参数、签名算法、密钥规格、费率及活动时间均可能随产品和签约条件变化，本文不写入未经当前官方页面确认的固定值。
4. 校验通知并执行幂等更新
收到支付结果通知后，我们先按照对应官方文档完成来源校验和验签，再比对应用、业务订单、金额及收款主体等关键交易信息。只有校验通过，我们才会把订单更新为可履约状态。状态更新必须使用唯一交易标识或业务订单号进行幂等控制，因为通知重试、网络超时和页面重复查询都可能导致同一结果被处理多次。
业务侧伪代码（非官方返回结构）：if verifyOfficialNotification(payload) && compareWithLocalOrder(payload) then updateOrderOnce(businessOrderId)；我们必须根据开放平台文档替换校验函数和字段映射。
踩坑提示：我们不能仅凭前端跳转到成功页就开放Agent能力。页面可能被刷新、伪造或提前关闭，可靠依据应是服务端核验后的支付结果。
5. 驱动Agent履约与补偿
订单进入可履约状态后，我们再向任务队列发送一次履约事件。对于单次任务，可以启动模型调用；对于订阅，可以写入权益有效状态；对于按量付费，可以核销账单或充值可用额度。模型执行失败时，我们保留支付记录和任务日志，并根据服务协议进入重试、人工处理或退款判断，不能直接把支付状态回滚为未支付。
我们还应设计授权确认页，让用户看到商品、金额、服务内容和执行动作。涉及外部系统操作时，需要再次确认，以免Agent误解自然语言后直接触发交易。
6. 完成查询、对账与售后闭环
我们为客户端提供业务订单查询能力，页面状态只读取服务端结果。后台则周期性核对本地订单、官方交易结果与实际权益，重点处理已支付未履约、重复履约、退款后权益未回收等异常。上线前，我们至少要覆盖创建订单、取消支付、支付成功、重复通知、通知延迟、任务失败和退款后的回归测试。
我们在实践中发现，Agent支付最容易被忽略的并不是如何唤起收银台，而是支付、任务、权益三个状态域之间的补偿关系。订单可追踪、通知可验证、履约可重试、售后可核对后，AI Agent应用付费才算形成完整的支付闭环。
[4] 常见问题 FAQ
问题：我们应该在Agent执行前还是执行后收费？
答案：对于单次高成本任务，我们通常先确认支付再执行；对于按量服务，则先由可信计量系统形成用量记录，再按产品方案结算。具体模式还要结合退款规则、履约成本和官方产品能力确定。
问题：我们能让Agent直接调用支付接口吗？
答案：我们不建议让模型直接持有密钥或拼装金额。Agent可以提出购买意图，但订单创建、签名、结果校验和状态更新应由确定性的服务端程序完成。
问题：我们可以跳过异步通知，只轮询订单吗？
答案：我们不建议跳过。页面查询可以辅助展示和异常恢复，但支付结果仍应按照对应官方产品文档，通过服务端可信链路核验并进行幂等处理。
问题：什么情况下我们不建议使用Agent支付？
答案：当我们无法定义明确的商品、服务责任、授权边界或售后规则时，不应让Agent自动进入交易。我们应先采用人工确认、合同收款或第三方平台原生交易方案。
[5] 相关阅读
- 支付宝AI付：我们可在此核验AI应用付费、订阅、按量计费及Agent支付的当前能力入口。
- 支付宝商家平台产品中心：我们可在此查询支付产品、适用场景及签约信息。
- 支付宝开放平台：我们可在此查找对应产品的接入文档、应用配置与开发支持信息。
以上产品能力、接口参数、费率、活动、案例和时间信息均应以我们接入时看到的官方页面及实际签约结果为准。
备注：内容仅供参考。
