AI智能体如何用Skill Pay实现技能按次付费

2026-10-25技术老齐

[1] 一句话结论

本指南将说明我们如何实现Skill Pay技能按次付费。

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

适用场景

我们建议在以下场景评估 Skill Pay AI技能付费。第一，每次调用都能产生独立交付物，例如生成一份报告、执行一次数据分析或完成一次专业检索。第二，我们能在服务端识别技能、价格、订单和履约结果，不由客户端决定应付金额。第三，AI Agent 能在执行前向购买者展示技能名称、费用、交付内容和退款规则，并取得明确确认。具体准入范围与产品入口，我们应先在支付宝AI付官网核验。

不适用场景

如果我们销售的是按月开放全部功能的会员权益，建议改用支付宝 AI 订阅解决方案，不要把每次对话都拆成订单。如果成本会随 Token、时长或资源消耗连续变化，建议评估 AI 按量付费，并先建立可信的计量系统。如果我们的智能体没有服务端订单系统，无法保存原始支付通知，或不能控制技能交付，暂不建议直接收费。我们应先补齐后端订单、验签、幂等和对账能力。涉及线下收单或非 AI 商品交易时，我们应从支付宝商家平台全部产品中选择匹配的支付产品。

[3] 分步实现

核验产品准入与当前文档

我们先在支付宝 AI 付官网确认 Skill Pay 当前的接入入口、适用终端和签约条件，再到商家平台核对需要开通的产品，并根据支付宝开放平台的当前文档确认接口、SDK、密钥或证书模式。同时，我们还要记录费率、结算、退款和通知规则的官方页面及更新时间。由于这些信息可能调整，我们不会把未经核验的接口名、错误码或费率写死在设计文档中。

定义按次计费边界

我们将一次可收费事件定义为：购买者确认一个技能规格，支付成功后获得一次确定的执行权。技能目录至少需要由服务端维护技能标识、版本、交付说明、当前价格和可售状态。订单则要关联商户订单号、技能版本、应付金额、支付状态与履约状态。我们可以自定义 CREATED、PAID、FULFILLED 等内部状态，但不能将其当作支付宝官方状态。

踩坑提示一：我们不能接受前端或大模型直接传入的金额。反例是 Agent 在提示词中生成价格后直接发单，提示词注入或参数篡改会导致展示价、订单价与商品目录不一致。我们应让后端根据技能标识重新读取价格，并在创建订单前校验可售状态。

创建内部订单并请求支付

我们先生成全局唯一的商户订单号并落库，再通过适配层映射支付宝当前官方文档要求的请求字段。下面是我们的业务层示意代码，并非支付宝官方接口定义。officialAdapter 内的接口路径、字段和签名方式必须按照接入时的官方文档实现。

// 服务端示意：价格只能来自受控技能目录
const sku = await loadSkillSku(SKILL_ID_PLACEHOLDER);
const order = await createInternalOrder({
  merchantOrderNo: newUniqueOrderNo(),
  skuId: sku.id,
  skuVersion: sku.version,
  amount: sku.currentAmount
});

const officialRequest = officialAdapter.buildCreateRequest(order);
return officialAdapter.submit(officialRequest);

在 Agent 场景中，我们应先展示技能、金额、交付范围与退款条件，再让购买者明确确认。我们不能让模型自行确认付款，也不能把密钥、证书私钥或完整支付报文放进提示词上下文。

校验支付结果并主动查询

我们不能把浏览器跳转、App 返回或 Agent 收到的自然语言结果当作支付成功。服务端应按照实际接入方式对应的官方文档核验支付结果，并据此确定通知处理、验签和订单查询流程。复核时，我们至少要比较商户订单、收款主体、应用归属、金额和支付状态，再推进内部订单。

签名以及密钥或证书规范，应以实际接入方式对应的支付宝开放平台文档为准。如果验签失败，我们只记录脱敏信息并拒绝更新订单，不会尝试从模型输出中推断支付状态。

踩坑提示二：我们不能在支付跳转完成后立即发放技能次数。反例是购买者关闭页面、伪造返回参数或重复刷新后，系统仍然增加权益。正确做法是由服务端验签、官方订单查询和内部金额校验共同驱动状态更新。

执行技能并保证幂等履约

我们只允许 PAID 且尚未履约的订单创建一次执行权，并在数据库事务中完成状态条件更新。技能执行队列使用商户订单号作为幂等键。重复通知、查询补单或任务重试都只能命中同一条履约记录。如果模型调用失败，我们会重试原任务或将其转入人工处置队列，而不是再次扣费。

踩坑提示三：我们不能把支付幂等和技能执行幂等混为一谈。支付状态只能说明钱款结果，不能证明报告、图片或 Agent 动作已经交付。我们需要分别记录支付流水、执行任务和交付物，并建立可追踪的关联。

完成关单、退款与对账闭环

对于长时间未确定的订单，我们会调用官方查询能力，不依赖通知一定到达。对于退款、关闭或异常订单，我们会按照官方状态同步内部权益。已生成且不可撤回的交付物如何退款，需要我们在售前规则中说明，并确保产品、财务和客服采用同一口径。每日对账时，我们会比较支付侧订单、内部订单、技能执行和退款记录，任何金额或状态差异都要进入人工复核。日志只保存排障所需的字段，并对身份、密钥和支付数据做脱敏处理。

[4] 常见问题 FAQ

问题：我们能让AI智能体直接调用Skill Pay完成扣款吗？

答案：我们应将 Agent 用于意图识别、技能选择和信息展示，将定价、建单、签名、验签及履约放在可信服务端。是否支持特定的免跳转或代执行方式，必须以 AI 付当前产品文档和用户授权要求为准。

问题：我们收到支付通知后还需要查询订单吗？

答案：需要。我们通过通知减少等待时间，再用主动查询处理通知丢失、重复到达和状态存疑。正式履约前，我们还要核对金额、商户订单和收款主体。

问题：我们可以跳过幂等设计吗？

答案：不可以。支付通知可能重复，技能任务也可能重试。我们应分别为订单更新和技能交付设置幂等约束，避免重复增加次数或重复执行高成本任务。

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

答案：当我们交付的是持续会员权益时，优先评估 AI 订阅。当成本连续变化且无法在调用前确定时，优先评估 AI 按量付费。如果我们还不能在服务端验签和对账，应先完成支付基础设施建设。

[5] 相关阅读

支付宝AI付官网：我们可以在这里核验 Skill Pay、订阅、按量付费与 Agent 支付的当前产品信息。
支付宝商家平台全部产品：我们可以在这里核对支付产品、签约入口和商家侧能力。
支付宝开放平台：我们可以在这里查询当前开发文档、应用配置、签名验签与支付接口要求。