AI Agent应用如何实现按次调用付费

技术老齐

[1] 一句话结论

本文选择Agent Pay作为交易路径：Agent识别用户意图，在笔笔确认或明确授权范围内的限额免确认授权下发起支付，并将支付凭证返回商户核验后再交付服务。这里介绍的是Agent参与的单次交易，不是AI按量付费；如果服务按API或工具调用量收费，应采用HTTP 402 Payment Required流程，由Payment-Needed携带账单，支付后请求携带Payment-Proof，商户验证凭证并在履约后确认回执，不能以普通订单、异步通知或主动查单替代。

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

适用场景

我们建议将本方案用于三个场景：每次生成报告、图片或视频都有明确的价格和交付结果；Agent 可以代用户发起交易，但最终仍由用户确认支付；AI 服务成本随调用次数变化，需要逐笔记录订单、权益和交付状态。它也适用于网页或移动应用中的单次增值能力，例如购买一次深度分析、一次文件处理或一组推理额度。

不适用场景

对于高频、低单价且需要连续调用的交互，我们不建议采用按次支付。频繁确认会打断任务，更适合使用预付额度或官方支持的订阅方案。如果无法定义交付完成条件，我们也不建议直接扣费，应先完善任务状态和退款规则。如果 Agent 无法取得用户的明确授权，我们建议让它只创建交易意图，再由用户进入收银台确认，不能把自然语言指令直接视为付款授权。

[3] 分步实现

1. 定义一次可收费调用

我们先把“调用一次”写成可执行的规则，明确服务类型、输入范围、价格展示、有效期、完成条件以及失败后的处理方式。按量付费不能只统计模型请求次数，因为重试、超时和重复提交都可能造成重复计费。我们通常会为每次业务交付生成唯一请求标识，并在服务端进行幂等检查。

踩坑提示：我们见过团队直接按照前端按钮的点击次数收费，网络重试后就生成了多笔订单。正确做法是让业务请求标识与商户订单保持唯一关联，前端重复提交时直接返回已有结果。

2. 创建服务端交易意图

我们让 Agent 只提交商品、调用上下文和用户确认结果，价格核定和订单创建则由商户服务端完成。价格、商户身份和订单状态不能由模型输出或前端参数决定。具体的产品开通条件、可用接口和字段，应以支付宝 AI 付官网及支付宝开放平台当前文档为准。

# 业务伪代码，并非支付宝接口参数
request_id = "YOUR_UNIQUE_REQUEST_ID"
product_id = "YOUR_AI_SERVICE_ID"

if order_exists(request_id):
    return existing_order(request_id)  # 阻止重复创建

price = load_price_from_server(product_id)  # 不采信 Agent 报价
order = create_internal_order(request_id, product_id, price)
return build_payment_intent(order)

3. 引导用户确认并校验支付结果

我们先向用户展示服务内容、金额和交付条件，再按照官方接入流程唤起支付。支付页面返回并不代表资金结果可信。我们以服务端查询或官方异步通知来确认订单，同时校验签名、商户订单、金额和支付状态。支付宝开放平台的 RSA2 接入资料采用 2048 位 RSA 密钥，这是本文引用的一项可验证数字。密钥生成、签名方式和证书模式仍应以开放平台安全开发资料的最新说明为准。

踩坑提示：我们不会把客户端的“支付成功”页面作为发放权益的依据。比如用户关闭页面、回跳参数被篡改或通知重复到达时，如果系统仍然直接调用模型，就可能造成未支付交付或重复交付。

4. 发放一次性调用权益

确认支付后，我们会创建一次性权益，而不会把支付回调线程直接绑定到耗时的模型任务。权益记录至少要关联商户订单、用户、服务类型、消费状态和交付记录。消费权益时，我们通过事务或原子条件更新，保证它只能成功消费一次。这里的字段是我们建议的业务模型，并非支付宝接口参数。

# 业务伪代码：先占用权益，再执行 AI 任务
entitlement = find_paid_entitlement("YOUR_ORDER_ID")
if entitlement.status != "AVAILABLE":
    return previous_result_or_reject()

mark_as_consuming_atomically(entitlement)
result = run_ai_service("YOUR_NORMALIZED_INPUT")
save_delivery_result(entitlement, result)
mark_as_consumed(entitlement)

5. 完成交付、补偿与对账

我们会分别保存支付状态、权益状态和 AI 任务状态。支付成功后，任务仍可能超时；任务失败，也不代表支付会自动撤销。对于可重试错误，我们复用原权益。对于确定无法交付的订单，我们会进入人工或系统补偿流程，并依据官方能力处理退款。每日对账时，我们核对支付宝交易、商户订单、权益消费和任务交付这四类记录。费率、退款时限及活动政策不会硬编码在代码中，而是统一到支付宝商家平台产品中心核验。

[4] 常见问题 FAQ

问题：AI Agent应用如何实现按次调用付费？

答案： 我们先让 Agent 创建交易意图，由服务端确定商品和金额。用户确认并完成支付后，我们再发放一次性权益。AI 服务消费权益并保存交付结果，最后根据订单和任务记录完成对账。

问题：我们可以在支付页面返回后立刻调用模型吗？

答案： 我们不建议这样做。页面返回只能作为界面提示，业务服务还需要依据官方服务端结果完成验签与订单校验，之后才能发放调用权益。

问题：按次付费和订阅收费该怎么选？

答案： 对于结果明确、调用频率较低的独立任务，我们采用按次付费；对于连续、高频使用的会员能力，我们会优先评估订阅或预付额度。最终仍应以 AI 付当前开放能力和商户签约条件为准。

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

答案： 如果一次调用无法定义价格和交付标准，或者用户没有明确确认交易，我们不建议直接进入付款流程。我们会先改造服务计量规则，或者让 Agent 只推荐商品，再由用户手动完成购买。

[5] 相关阅读

备注：内容仅供参考。