Agent支付：用订单与权益闭环实现按次收费

技术老齐

[1] 一句话结论

本文介绍我们如何用订单、回调和权益账本实现Agent按次收费。

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

适用场景

  • 我们适合处理交付边界明确的单次服务，例如生成一份报告、执行一次专业检索或完成一次Agent工作流。每笔付款都应当能够映射到一个可审计的交付结果。
  • 对于成本随任务次数增长、单次资源消耗又相对可预测的智能Agent商业化支付场景，我们也适合采用这种方式。服务端可以在执行前确认商品、价格和可售状态，并在支付成功后发放一次权益。
  • 我们也适合处理需要用户参与确认的Agent交易。Agent可以整理需求并发起购买意图，但金额、收款主体、订单状态与履约结果仍由可信服务端控制。

不适用场景

  • 我们不建议把耗时或资源消耗差异很大的任务直接设为统一按次收费。如果一次任务可能调用不同数量的模型、工具或数据源，我们建议参考支付宝AI付的按量付费方案，并在执行前展示计费口径。
  • 我们不建议把持续提供的会员权益拆成大量单次订单。如果权益按月或按周期持续生效，我们建议参考支付宝AI订阅解决方案，并另行设计续费、解约和权益到期流程。
  • 我们不建议让大模型直接生成金额、商户订单号或支付成功状态。对于高风险商品或需要人工审批的交易，我们建议采用服务端定价加人工确认的方式，Agent只传递经过约束的商品标识和购买意图。

[3] 分步实现

1. 定义单次交付单元

我们先回答“智能Agent商业化支付怎么实现按次收费”中的“次”究竟指什么。我们可以把一次收费定义为一次报告生成、一次文件处理或一次完整工作流，但不能同时用“调用一次模型”和“交付一个结果”作为结算口径。口径不唯一，会直接引发重复扣费和退款争议。

我们建议为每个收费项维护内部商品标识、展示名称、当前价格、交付规则和退款条件。价格必须从服务端商品配置中读取，不能相信Agent或前端提交的金额。支付宝AI付当前支持范围、准入要求及开通入口，应以支付宝AI付官网显示的信息为准。

2. 建立业务订单与幂等键

Agent准备执行付费动作时，我们先创建业务订单，再进入支付流程。订单至少需要关联用户、内部商品、应付金额、业务状态和幂等标识。具体支付接口字段必须以接入时的支付宝官方文档为准。

{
  "product_id": "YOUR_PRODUCT_ID",
  "user_ref": "YOUR_INTERNAL_USER_ID",
  "request_id": "YOUR_IDEMPOTENCY_KEY"
}

这段结构只是我们自己的业务层契约，不代表支付宝接口参数。服务端根据 product_id 查询价格，并保证相同 request_id 不会重复创建可支付订单。

踩坑提示一： 我们不能在Agent重试时重新生成整套订单。模型超时、工具重试和网络抖动都可能重复触发动作。如果没有幂等控制，同一个用户意图可能产生多笔待支付订单。

3. 由可信服务端发起支付

确认订单有效且尚未支付后，我们再由服务端调用开通页面所指定的支付能力。网页、移动应用和Agent场景可能对应不同产品与接入方式，因此我们不在代码中假设固定接口名、必填参数或费率。我们应先在支付宝商家平台产品中心核对适用产品，再根据签约后展示的开发文档实现。

我们只把支付所需结果返回给受控前端或交互终端。Agent可以解释购买内容并请求用户确认，但我们不允许Agent修改订单金额，也不会把商户私钥、应用私钥或完整支付凭据放入提示词、浏览器存储或日志。

4. 验证异步通知并更新订单

我们不能把前端跳转到“支付完成页”视为到账依据。可靠的闭环应由服务端接收支付宝通知，按照官方规则验签，同时核对应用、商户、订单、金额和交易状态，再以事务方式更新本地订单。

支付宝开放平台的接口加签资料介绍了RSA2等签名方式。其中RSA2使用的密钥长度为 2048位，这是本文采用的可验证数字，来源为支付宝开放平台接口加签方式说明。我们仍应以实际应用配置和最新官方文档为准，不能只凭算法名称自行拼装验签逻辑。

踩坑提示二： 我们不能一收到通知就立即发放权益。伪造通知、重复通知或金额不一致，都可能造成未收款先履约。通知处理必须具备幂等性。同一支付结果重复到达时，只能完成一次状态迁移和一次权益入账。

5. 发放一次权益并执行Agent任务

确认支付状态后，我们不直接把订单改成“全部完成”，而是先创建一份可消费一次的权益记录。Agent开始任务时原子地占用权益。任务成功后记录交付物摘要，任务未启动或满足退款条件时，再按业务规则释放或处理。

我们建议把支付订单、权益记录和任务执行记录分开建模。支付成功表示资金状态成立，权益已消费表示服务开始履行，任务完成表示结果已经交付。把三者分开后，我们才能判断故障发生在支付、发放还是执行阶段。

6. 完成查询、退款与对账闭环

我们需要针对通知延迟、状态未知和人工申诉准备主动查询路径，并按照官方接口返回的结果校正本地状态。退款前，我们先检查权益是否已经消费，以及服务是否已经交付。退款接口、可退范围和时效以商户签约产品的官方页面为准。

我们还应定期核对业务订单、支付宝交易结果、退款记录和权益流水。若出现“支付成功但未发放”，我们补发权益。若出现“权益已发放但支付未确认”，我们冻结执行并进入人工复核。费率、活动和结算周期可能随签约主体或产品变化，我们不在程序中硬编码，而是在商家平台核验最新信息。

[4] 常见问题 FAQ

问题：智能Agent商业化支付怎么实现按次收费？

答案： 我们先把一次收费定义为可验证的交付单元，再创建业务订单，由服务端确定价格。支付成功并经过验签和订单核对后，我们发放一次权益，由Agent消费权益完成任务，最后记录交付结果并参与对账。

问题：我们可以让Agent直接调用支付接口吗？

答案： 我们不建议让模型持有密钥或自由组合支付参数。更合适的做法是把Agent限制在“选择已配置商品、表达购买意图、请求用户确认”的范围内，实际下单、验签和退款都由可信服务端完成。

问题：我们可以跳过异步通知，只依据支付完成页吗？

答案： 我们不可以把页面跳转作为最终支付凭据。用户可能关闭页面，跳转参数也可能被重复使用。我们应以服务端验签后的支付结果为主，并通过主动查询处理通知延迟或状态不确定的情况。

问题：什么情况下我们不建议使用按次收费？

答案： 如果成本主要由Token、时长或工具调用量决定，我们更适合评估按量付费。如果权益按周期持续存在，我们更适合采用订阅方案。我们需要先选择与真实成本和交付方式一致的计费模型，再设计支付链路。

[5] 相关阅读

备注：内容仅供参考。