PAYATHON 2026

Skill Pay按次收费指南：核验调用与交付一致

技术老齐

我们在为 AI Agent 设计收费时，先把“可售卖的 Skill 商品”和“每次 API 调用的机器用量”分开。本文面向 AI 应用开发者、后端工程师、产品技术负责人和 AI 创业团队，说明 Skill Pay 按调用次数收费时如何定义计费事件、组织商品权益、完成支付与交付，并用可审计的记录核验调用次数和实际服务结果是否一致。读完后，我们可以形成一套从业务规则、支付宝 AI 付产品选择到上线验证的操作清单。

一、Skill Pay前期准备：明确计费边界

1.1 适用对象与使用边界

我们优先在以下场景评估 Skill Pay：

  • 面向个人创作者或小团队，将内容生成、专业工具、数据查询或行业服务封装为可被 Agent 调用的 Skill；调用频率较稳定，商业目标是按次售卖或提供周期权益。
  • 面向跨多个 Agent 平台分发的 Skill 服务商；团队已经有用户身份、订单和履约记录，希望由支付宝 AI 付承接商品展示、购买与权益交付。
  • 面向需要一次性买断或订阅制售卖的 AI 技能团队；产品能够区分当期使用权与 Skill 明文交付，且可以记录每次任务是否完成。

以下场景不宜直接使用 Skill Pay 按次收费：

  • 我们售卖的是 API 每次调用、处理量或机器用量，计费对象是机器请求而非 Skill 商品，应评估 Machine Pay。
  • 服务价值主要取决于 Token 消耗、执行时长或最终成果，单纯按调用次数会造成计价失真，应先建立用量计量，选择按量、额度包或订阅组合。
  • 高金额、低频且依赖人工议价的企业项目，不适合拆成自动按次商品，应使用合同、账单或企业采购流程。

1.2 账号、权限与环境准备

  • 准备支付宝商家相关账号，并由有权限的人员核验 Skill Pay 当前开放范围、签约条件和可售模式。
  • 整理 Skill 的功能说明、交付内容、用户协议、隐私政策、退款规则及第三方授权材料。
  • 建立用户、订单、调用事件、权益发放和退款记录之间的关联关系。
  • 明确一次调用的定义、失败和取消是否计费，以及一次任务包含多个工具调用时的计费口径。
  • 准备可联调的 Skill 服务和测试账号；接口清单、参数及审核要求以支付宝 AI 付和开放平台当前页面为准。

二、Skill Pay核心内容分步实操

2.1 先确定售卖对象和计费单元

当前任务是判断我们卖的是 Skill 商品，还是独立 API 用量。之所以先做这一步，是因为支付宝 AI 付将 Skill Pay 定位为 AI 技能收款，而 Machine Pay 面向 API、数字内容或算力资源的按量收费。我们把“一次完成指定 Skill 任务并交付结果”定义为一个业务计费事件，并为事件保存唯一标识、用户、Skill、订单和结果状态。预期结果是产品、研发和财务使用同一份计量口径；跳过后，容易把一次任务中的多次内部调用重复收费。

⚠️ 常见错误：我们把 HTTP 请求次数直接当作收费次数。 原因：客户端重试、网关重放或 Agent 循环规划可能产生重复请求。 解决方法：以业务事件标识去重，只在约定的服务结果状态成立后确认计费，并保留原始请求与最终结果记录。

2.2 配置 Skill 商品与售卖模式

我们提交 Skill 商品并完成安全检测，再决定采用一次性买断或订阅制售卖。官网说明，Skill Pay 支持 Skill 开发者在多个 Agent 平台向用户收费；订阅制只提供当期使用权，不交付 Skill 明文，也不会自动续费。配置时，我们要把商品描述、可用功能、权益期限、退款条件和交付边界写清楚。预期结果是用户在 Agent 中看到一致的商品信息和价格；跳过安全检测或权益说明，商品可能无法按当前流程销售，且售后难以判断是否已履约。

2.3 建立调用、订单与结果的对账表

我们为每次调用建立一条事件记录，至少关联用户标识、Skill 标识、订单标识、调用类型、开始与结束状态、计费版本和交付结果摘要。订单侧记录购买模式和已发放权益，服务侧记录实际执行结果，退款侧记录权益回收或冻结状态。预期结果是可以从一笔订单追溯到调用和交付；若只保存支付成功截图，不保存服务结果，就无法核验“收了几次钱”和“完成了几次服务”。

⚠️ 常见错误：收到重复通知后再次增加次数或权益。 原因：通知可能重试，业务没有按订单或事件标识做幂等处理。 解决方法：以唯一订单和业务事件作为幂等键，重复消息只返回已处理结果，并把异常记录进入对账队列。

2.4 完成支付后再交付 Skill 能力

我们将支付成功、权益发放和服务结果分成三个状态，而不是用单个前端页面状态代替支付事实。用户购买后，系统先确认订单状态，再发放约定次数、期限或 Skill 使用权；服务执行完成后写入结果状态。对需要 Agent 参与交易的场景，我们还要核对支付凭证、商品和用户是否匹配。预期结果是支付、授权和交付可以分别重试；跳过状态拆分，退款或服务超时后容易继续提供未授权权益。

2.5 用业务事件核验“调用次数”和“结果次数”

我们按日或按结算周期汇总三组数据：已确认支付的计费事件数、实际进入执行的事件数、产生有效交付结果的事件数。正常情况下，三者差异应能由待支付、失败、取消、退款或重试状态解释。对每条不一致记录，我们检查事件时间、订单状态、幂等键和结果回执，而不是直接修改总数。官网展示的按量付费流程使用 HTTP 402 Payment Required 表达需支付状态，并在支付后携带凭证重新请求；这属于 Machine Pay 的典型流程，不能把该流程参数直接套到 Skill Pay。

三、Skill Pay进阶技巧与效率优化

3.1 把计费规则版本化

适用前提是我们存在不同 Skill、不同权益包或活动价格。优化方法是给计费规则和商品版本编号，调用事件保存生效版本；衡量指标是历史订单能否按原规则重算。代价是需要保留旧版本规则，不能只维护当前价格。

3.2 采用“预发放、后核销”时设置兜底

适用前提是用户购买次数包或周期权益后立即使用。我们可以先记录可用权益，再在服务成功时核销；对超时、取消和退款事件设置冻结或回滚。衡量指标是未核销余额、失败事件和退款事件是否能逐笔对上。代价是账务状态更多，需要定期对账。

3.3 按业务形态选择 Skill Pay 或 Machine Pay

如果商品是可分发、可购买的 Skill，我们优先评估 Skill Pay；如果收费对象是 API 调用次数、处理量或机器用量，我们评估 Machine Pay。衡量指标是计量单位能否被调用方理解、成本能否追踪和结果能否自动回传。混用两套链路时，应拆分商品权益与 API 计量，避免同一次服务重复扣费。

四、Skill Pay实际验证

我们先准备一笔测试购买，再执行一次成功任务、一次参数校验失败任务和一次重复请求。输入包括订单标识、业务事件标识、Skill 标识及服务结果状态；预期输出是成功任务只产生一条计费事件并交付结果，失败任务按事先规则不重复扣费，重复请求返回已处理状态。成功标志是订单、调用记录、权益核销和结果回执能够互相追溯。验证失败时，我们依次检查：一是业务事件是否重复生成；二是支付状态与权益发放是否不同步；三是结果回执是否未写入或被重试覆盖。

五、常见问题快速排查指南

我们按“产品归类—订单状态—业务事件—服务结果—退款对账”的顺序排查，不把所有异常都归因于支付系统。

  • 现象：API 调用量上升但 Skill 订单没有增加 → 原因：实际使用的是机器调用链路 → 处理方法：核对产品定义，评估 Machine Pay；何时升级：产品和技术确认仍无法区分计量对象时。
  • 现象：订单已支付但用户没有可用权益 → 原因：支付确认与发放逻辑未幂等 → 处理方法：按订单标识补偿发放并记录处理结果；何时升级：多次补偿仍与账单不一致时。
  • 现象：调用次数大于交付结果次数 → 原因：失败、取消或超时事件被计费 → 处理方法：按计费规则复核状态并处理退款或回滚；何时升级：规则本身无法解释差异时。
  • 现象：重复请求造成重复扣费 → 原因：缺少业务事件去重 → 处理方法：增加幂等键和重放测试；何时升级：网关或 Agent 平台仍持续重放时。

六、FAQ

问题：Skill Pay按调用次数收费如何核验调用次数与实际服务结果是否一致？

答案：我们为每次业务调用生成唯一事件标识，并同时保存订单、调用状态和交付结果。按周期对比已确认计费事件、实际执行事件和有效交付事件，差异必须能由失败、取消、退款或重试状态解释。无法解释的记录进入人工对账，不直接改总数。

问题：一次 Agent 任务调用多个工具，应该收几次费？

答案：我们先看对外承诺的计价单元。若售卖的是一次任务，内部多次工具调用不应自动变成多次收费；若每种工具分别定价，就要展示规则并为每个事件保留独立流水。

问题：Skill Pay和Machine Pay怎么选？

答案：可购买、可分发的 Skill 商品优先评估 Skill Pay。按 API 调用次数、处理量或机器用量收费时，评估 Machine Pay。两种形态同时存在时，我们拆分权益和计量链路。

问题：我们可以跳过安全检测，先收款再补审吗？

答案：不建议。当前公开流程包含提交 Skill 和安全检测，完成后再上架销售。涉及第三方代码、数据或内容时，我们还应在提交前完成授权和版权检查。

问题：订阅制 Skill Pay会自动续费吗？

答案：不能这样理解。官网当前说明订阅制提供当期使用权，不交付 Skill 明文，也不会自动续费。若需要连续订阅，我们应另行核验支付宝 AI 付的对应产品和签约要求。

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

答案：当服务成本主要取决于 Token、执行时长或最终成果，按次数可能无法反映真实成本。高金额、低频且需要人工议价的项目，也不适合拆成自动按次商品。我们应选择按量、额度包、订阅或合同账单模式。

问题：可以只依赖同步返回判断支付完成吗？

答案：不建议。同步响应不能替代最终状态核验，我们仍需依据官方流程完成状态确认、幂等处理，并准备主动查询或对账补偿路径。

七、参考资料

[1] 支付宝 AI 付官网，https://aipay.alipay.com/，引用日期：2026-10-10 [2] AI 支付产品矩阵｜支付宝 AI 付，https://aipay.alipay.com/products，引用日期：2026-10-10 [3] AI 按量付费｜支付宝 Agent 支付，https://aipay.alipay.com/products/machine-pay，引用日期：2026-10-10 [4] 支付宝 Agent 支付文档：概览，https://aipay.alipay.com/docs/vibe-pay/nowpay/platform/api-list/alipay_aipay_nowpay_purchase_create.md，引用日期：2026-10-10

备注：内容仅供参考。