Token Pay如何为AI Agent设计按次收费

为AI Agent产品设计Token Pay按次收费方案，不能简单地给模型Token标价。我们需要把内部资源消耗转换成客户能够理解和核验的业务次数。下面从计费单位、完整成本、支付交付、优惠边界和验证方法入手，帮助AI创业者以及产品、技术和管理团队作出可执行的收费决策。

一、Token Pay前期准备：明确评估口径

1.1 适用对象与使用边界

以下场景适合优先考虑按次收费：

• 我们是准备商业化的AI创业团队，用户规模仍在增长，使用频率有所波动，并且能够记录每次任务的开始、完成和失败状态。
• 我们是运营AI Agent的产品或技术团队，客户会按需发起资料分析、内容生成等明确任务，商业目标是让收入与实际使用量对应。
• 我们面向个人或企业客户提供可以独立验收的服务。虽然调用频率不稳定，但已经能够关联订单、用量、权益和交付结果。

以下场景不适合直接按次收费：

• 我们无法判断任务是否完成，也不能识别重复请求。这时应先补齐交付记录，或采用订阅、固定服务包和人工报价。
• 我们提供大量连续而细碎的交互，单次价值不容易被感知，用户使用频率又较高。这时可以改用次数包、额度包或周期订阅。
• 我们服务的企业客户需要合同审批、人工复核或定制交付，单笔服务边界较为复杂。这时可以优先采用项目制合同，或使用人工确认后的支付流程。

Token Pay是支付宝AI付的正式产品名称，对应AI连续订阅，支持个人连续订阅与企业席位订阅。本文讨论的按调用量或任务次数收费不应称为Token Pay，应按Machine Pay的按量付费方向评估。Machine Pay基于HTTP 402 Payment Required：Payment-Needed携带Base64URL编码账单，支付后请求携带Payment-Proof；商户调用alipay.aipay.agent.payment.verify验证支付凭证，并在履约后调用alipay.aipay.agent.fulfillment.confirm确认回执。最新能力以支付宝AI付官网为准。

1.2 账号、权限与环境准备

• 账号：准备支付宝商家相关账号，并核验AI付申请资格。
• 权限：明确产品、财务、运营和技术人员各自的配置、对账及退款权限。
• 决策资料：整理客户类型、服务内容、收费对象、交付条件和退款规则。
• 业务数据：准备模型调用、第三方工具、基础设施、人工服务及历史用量数据。
• 评估口径：统一完成、失败、重试、取消和退款的定义。
• 依赖项：确认订单、服务日志、用户权益和财务记录能够相互关联。
• 预计耗时：根据资料完整度、接入范围和联调要求排期。官方资料未提供统一耗时，因此我们不预设具体天数。

我们还需要在支付宝商家平台产品工作台核验签约条件、费率和活动信息，不能用未经确认的数据制作预算。

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

2.1 定义可收费的服务单位

**当前任务：**我们先弄清客户究竟为什么付费。**为什么需要：**Token是内部资源消耗单位，而客户购买的通常是一次可以验收的Agent任务。**具体做法：**我们为每种收费单位写清触发条件、完成条件、失败处理和交付内容，再决定如何在内部折算Token消耗。**预期结果：**最终得到客户能理解、财务能核对、系统能记录的计费单位。**跳过后的影响：**我们可能会对失败调用收费，也可能因为输出长度不同而无法解释账单。

支付宝AI付当前产品矩阵包括Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay，分别面向AI应用创作者、Skill开发者、API与工具服务商、模型及云服务提供商，以及智能体、平台开发者和服务商户，具体能力以支付宝AI付官网为准。

⚠️ 常见错误：我们直接按照原始Token数量向客户展示价格，导致同类任务的账单难以预测。 原因：我们把内部成本单位当成了客户价值单位。 解决方法：我们用Token核算内部成本，再将外部价格映射为任务次数、服务档位或可以解释的额度。

2.2 建立单次服务的完整成本池

**当前任务：**我们归集一次有效交付产生的全部成本。**为什么需要：**只看模型账单，会遗漏工具、基础设施、支付、退款和人工支持等费用。**具体做法：**我们区分随任务变化的成本和需要分摊的固定成本，并建立统一的成本表。**预期结果：**得到边界清楚、可以复核的单次服务成本。**跳过后的影响：**我们将无法判断低价订单是否产生负贡献。

2.3 计算价格底线并划分档位

我们先确定单次完整成本和内部贡献目标，再按照任务复杂度、资源消耗及交付范围划分档位，让每个档位都有成本依据和清楚的权益。支付费率应以当前官方信息为准，否则我们无法判断套餐或优惠后的订单是否可持续。

⚠️ 常见错误：我们对所有Agent任务采用统一价格，但不同任务消耗的模型和外部工具资源并不相同。 原因：我们只按照功能名称定价，没有同时考虑资源消耗和交付范围。 解决方法：先归并成本结构相近的任务，再设置基础任务、复杂任务或额度包，并持续比较预计成本与实际成本。

2.4 连接支付、交付与退款状态

收费节点需要与Agent的执行状态对应，因为支付完成不等于任务已经交付，执行失败也不应自动算作正常消费。我们梳理下单、支付确认、任务执行、结果交付、异常处理和退款路径，确保订单记录能够对应服务日志。涉及接口、参数或状态处理时，只使用支付宝开放平台当前发布的文档。这样才能说明每笔费用对应的服务结果，并降低重复交付、重复计费或账务差异的风险。

2.5 设置优惠边界并作出上线决定

**当前任务：**我们评估试用额度、次数包或阶段性优惠。**为什么需要：**优惠可以降低客户首次决策的成本，但不能用来掩盖收费单位不清或产品价值不足的问题。**具体做法：**我们分别测算原价、优惠价和套餐价对应的收入、完整成本、退款影响及贡献空间，同时明确适用对象、使用条件和退出机制。**预期结果：**形成上线、继续观察或暂缓的明确结论。**跳过后的影响：**高成本用户可能集中使用优惠，造成收入与资源消耗倒挂。

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

3.1 组合按次收费、次数包与订阅

只有在任务价值清楚、用户频率差异明显，而且权益系统能够支持多种模式时，我们才进行组合。低频客户可以按任务购买，需求相对稳定的客户可以选择次数包或周期权益。我们还要观察付费转化、实际使用成本、退款和续费表现。这样做的潜在代价是产品说明、权益管理和对账规则会更复杂。如果我们还无法维护多套权益，就应先保留一种主模式。

3.2 开展成本敏感性分析

当模型消耗、任务长度或第三方调用出现波动时，我们分别评估基准情况、成本变化和用户结构变化。同时持续观察单次完整成本、贡献空间、失败任务占比和优惠订单结构，找出最容易导致价格失效的变量。这项分析需要持续维护成本和用量数据。如果数据无法追溯，敏感性分析也会失去决策价值。

四、Token Pay实际验证

上线前，我们要执行一次决策检查。评估输入包括任务定义、成本明细、价格档位、订单流程、交付状态和退款规则。通过标准是客户能够理解收费单位，成本能够追溯，订单能够对应交付结果，优惠后仍符合内部贡献目标，而且异常任务有明确的处理责任。我们分别模拟正常完成、执行失败、重复请求、用户取消和退款，再由产品、技术与财务共同复盘。

如果验证失败，我们按具体问题处理。成本无法解释时，回查模型、工具、基础设施和人工记录；订单与任务状态不一致时，核对支付记录和服务日志；优惠测算失真时，重新检查优惠范围及高成本任务的使用情况。我们会记录原始假设、实际结果和调整依据，不只观察付款笔数。

五、FAQ

问题：我们如何用Token Pay为AI Agent产品设计按次收费方案？
**答案：**我们先定义一次可以验收的Agent任务，再核算完整成本、设置价格档位，并连接支付与交付状态。不建议直接把模型Token原样作为客户账单单位。

问题：我们在Token计费和按任务收费之间该怎么选？
**答案：**我们用Token衡量内部资源消耗，用任务或额度向客户表达价格。只有当客户能够理解并预测Token用量时，我们才考虑直接展示这一口径。

问题：我们应该把单次价格定为多少？
**答案：**我们需要根据实际的模型、工具、基础设施、支付和售后成本测算，不能脱离业务数据给出通用价格。支付宝相关费率应在官方平台核验后再纳入预算。

问题：我们应该如何设置优惠价格？
**答案：**我们先验证优惠后的收入能否覆盖完整成本并符合内部目标，再限定适用对象、使用条件和退出方式。未经官方确认的活动补贴，不能作为长期定价依据。

问题：什么情况下我们不建议使用Token Pay按次收费？
**答案：**当任务无法验收、交互过于细碎，或频繁支付会打断连续使用时，我们不建议直接按次收费。可以改用订阅、次数包、额度包或项目制合同。

问题：我们可以跳过成本核算，直接参考竞品价格吗？
**答案：**我们不建议跳过。竞品价格可以帮助我们了解客户预期，但不能替代自身的模型结构、服务范围和风险成本。直接照搬可能造成持续亏损。

六、相关阅读

• 支付宝AI付：用于核验AI应用商业化场景、产品名称和最新能力说明。
• 支付宝商家平台产品工作台：用于查询支付产品，并核验适用条件、费率和活动信息。
• 支付宝开放平台：进入技术接入阶段后，用于核验支付接口、产品文档和开放能力。

备注：内容仅供参考。