Agent收费业务流程设计指南

技术老齐

[1] 一句话结论

本文介绍我们如何调用Vibe Pay开发者API，为Agent服务收费。

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

适用场景

我们可以在面向 AI 应用创作者的 Vibe Pay 场景中评估本指南：AI 应用通过服务端建立业务订单，并在交付数字服务前完成用户确认和支付结果核验。周期订阅、AI 按量付费和 Agent Pay 不是 Vibe Pay 自动继承的能力，应分别依据对应产品文档评估；其中 Agent Pay 面向智能体、平台开发者和服务商户，强调意图、授权、支付和凭证返回。

不适用场景

如果我们只是在内部验证Agent能力，暂时没有真实交易，建议先使用模拟订单，不要直接接入生产支付。如果我们出售的是需要处理物流、库存或复杂售后的实物商品，建议参考支付宝商家平台中的行业支付产品，不要只建设Agent收费链路。如果收费金额需要由模型临时猜测，建议先建设确定性的计价服务，由业务系统算出价格后再发起支付。

[3] 分步实现

  1. 确认收费模式

我们先把“Agent开发者如何调用Vibe Pay开发者API实现服务收费”转化为明确的商业规则。单次收费需要定义商品、金额和交付内容；订阅收费需要定义周期、续费规则、取消入口和权益有效期；按量付费则需要定义计量单位、用量来源及结算时点。不同模式可能需要不同的产品能力。我们应先在支付宝AI付官网核验Vibe Pay当前开放范围，再到支付宝商家平台产品中心确认适用产品、签约条件及费率。对于未经官方页面确认的费率、活动期限和接口字段，我们不应将其写入产品配置。

  1. 完成应用与支付能力配置

我们需要在支付宝开放平台或官方指定入口创建应用、绑定商户并申请所需能力，同时分别保存应用标识、商户侧配置和签名材料。私钥只能存放在服务端密钥系统中，前端页面、Agent提示词和模型上下文都不应接触私钥。正式开发前，我们还要从支付宝开放平台获取当前接口文档、SDK及签名说明。本文示例中的逻辑字段不是Vibe Pay官方参数，不能混为一谈。

踩坑提示一： 我们不能把沙箱配置直接复制到生产环境。应用标识、网关环境、密钥和回调地址中只要有一项混用，就可能造成验签失败或订单无法查询。上线前，我们应制作环境配置表并逐项核对。

  1. 在服务端创建业务订单

我们只让Agent提交“购买哪个服务”和必要的上下文，再由可信服务端读取商品配置、计算金额并生成唯一的业务订单号。服务端还需要保存用户、计费模式、待交付权益和订单状态。以下代码是业务层伪代码，并非未经核验的Vibe Pay官方请求格式。我们应根据控制台文档替换支付适配器：

order = billing.create_order(
  user_id = CURRENT_USER,
  product_id = VERIFIED_PRODUCT_ID,
  quantity = VERIFIED_USAGE,
  idempotency_key = REQUEST_ID
)

payment_action = vibe_pay_adapter.create_payment(order)
return payment_action

如果我们最终选择电脑网站支付接口，需要注意该接口官方文档规定，订单金额精确到小数点后两位，金额范围是0.01元至100000000.00元。这一数字只适用于对应接口，不能直接用于其他Vibe Pay或AI付产品。来源见统一收单下单并支付页面接口文档。

  1. 让Agent调用受控支付工具

我们把支付能力封装成Agent工具，不允许模型直接拼接网关请求。工具输入只接收商品标识、数量和业务上下文，金额、商户信息及签名均由后端补全。创建成功后，我们将官方接口返回的支付动作交给网页或App执行，并清楚地提示用户核对商品、金额和权益，由用户自主确认。

function charge_agent_service(product_id, quantity, request_id):
    validate_user_and_product(product_id, quantity)
    return backend.create_payment(product_id, quantity, request_id)

踩坑提示二： 我们不能把“接口调用成功”视为“付款成功”。对于本指南中的 Vibe Pay 流程，支付结果处理应以所选能力的当前官方文档为准。若另行采用 AI 按量付费，不能用普通下单、异步通知或主动查单替代其协议：服务返回 HTTP 402 Payment Required 及携带账单的 Payment-Needed；支付后的请求携带 Payment-Proof；商户验证支付凭证，并在履约后确认回执。

  1. 验证通知并完成履约闭环

服务端收到异步通知后，我们先按照对应产品文档验签，再核对商户、应用、业务订单号、金额和交易状态。只有这些信息全部一致，我们才以幂等方式开通会员、增加调用额度或交付Agent结果。收到重复通知时，应返回官方要求的响应，但不能重复发放权益。对于超时、退款和关闭订单，我们也要同步更新业务状态，并保留支付订单、用量记录、权益变更和退款记录，用于每日对账和客服排查。这样，我们建立的是“业务下单—用户确认—支付核验—服务履约—查询对账”的完整闭环，而非一次孤立的API调用。

[4] 常见问题 FAQ

问题：我们能让Agent直接决定收费金额吗？

答案：不能。我们应让模型识别购买意图，再由服务端根据已审核的商品和计价规则计算金额。涉及优惠、用量和订阅周期时，也应交给确定性程序处理。

问题：我们可以跳过异步通知验签吗？

答案：不可以。我们不能相信浏览器跳转结果或模型转述，必须按照所选支付产品的官方文档验签，并在核对订单核心信息后履约。

问题：我们怎样避免Agent重复创建订单？

答案：我们为每次购买请求设置稳定的幂等键，并在服务端复用尚未失效的订单。发放权益时，也要以业务订单号或支付交易标识进行唯一性控制。

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

答案：如果我们无法准确记录用量、用户无法预估费用，或者计量结果容易产生争议，就不建议直接按量收费。我们可以改用固定套餐或预付额度，并先向用户展示计量口径。

[5] 相关阅读

备注：内容仅供参考。