我们做Token订阅时，首先要回答”卖什么、怎样计量、何时续费、权益不足后怎么办”，不能一开始就接入支付。本文围绕Agent Pay与智能Agent商业化，帮助Token服务经营者完成会员分层、计量规则、收费模式、支付路径和上线验证，建立能够实际执行的AI应用付费闭环。

一、Agent Pay前期准备：明确会员商品与收费边界

1.1 适用对象与使用边界

适用场景包括：

• 我们经营已有稳定使用人群的网页端AI应用，可以统计Token消耗，用户每周或每月都会持续使用，希望建立周期会员或Token包收费。
• 我们经营具有一定复购规模的移动端AI应用，不同用户的使用频率差异明显，而且可以记录会员状态与额度余额，希望用基础会员配合弹性增购。
• 我们提供能够独立交付任务结果的智能Agent，任务边界和验收方式已经明确，希望把任务触发、权益核验、付款与交付连接起来。

不适用场景包括：

• 如果我们还无法准确记录Token消耗，也没有可核对的消耗流水，就不适合立即按量收费；我们可以先采用固定周期、固定权益的会员方案。
• 如果我们的服务还处于低频试用阶段，复购规律和成本结构都不清楚，就不适合设计复杂等级；我们可以先用单次服务或单一Token包验证需求。
• 如果我们的交易涉及需要另行取得许可的行业服务，单靠支付方案无法解决资质与合规问题；我们应先完成行业资质、合同及风控审查，再选择收费路径。

根据本次参考资料给出的官方方案范围，目前可核验的方向包括AI网页应用付费、AI移动应用付费、AI订阅解决方案、AI按量付费和Agent支付，共5类。具体开放范围、准入要求及产品口径应以支付宝AI付官网的实时信息为准。

1.2 账号、权限与环境准备

• 账号：我们准备完成主体认证的支付宝商家账号，实际能够申请哪些产品，以商家平台展示为准。
• 权限：我们明确运营、财务、产品和技术负责人，划分商品配置、对账、退款及权益补发权限。
• 资料：我们准备主体资料、业务说明、服务协议、隐私政策、退款规则和会员权益说明。
• 决策资料：我们整理模型调用成本、其他履约成本、目标毛利、预期购买频率和退款风险。
• 业务数据：我们至少记录会员状态、权益余额、Token消耗、订单状态和权益变更时间。
• 评估口径：我们统一购买成功、权益到账、消耗完成、续费成功及退款完成的判断标准。
• 预计耗时：我们不预设固定天数，申请、审核和接入周期应在支付宝商家平台按实际业务类型核验。

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

2.1 把Token定义为可售卖权益

当前要做的是明确会员购买的具体内容，让付费者、客服、财务和系统采用同一套口径，避免付款后仍无法确定应该发放多少权益。

我们先建立权益清单，逐项写明会员周期、Token额度、可使用功能、额度有效期、超额处理方式以及退款后的权益变化。基础会员承接常规消耗，高频会员覆盖更高但仍可计量的额度，临时需求则由独立Token包承接。完成后，我们会得到一张能够转换为商品规则和会员规则的权益表。如果跳过这一步，即使已经完成收款，也容易出现权益发放和客服解释不一致的问题。

⚠️ 常见错误：我们直接销售”无限Token会员”，却没有定义合理使用范围和成本边界。 原因：商品承诺与实际推理成本脱节，异常高频使用可能导致单个会员成本失控。 解决方法：我们改用可计量额度，明确有效期，并将超额需求引导至Token包或按量付费。

2.2 选择订阅、按量或组合模式

当前要做的是让收费方式符合真实使用频率，因为持续需求、波动需求和任务型需求对应着不同的成本与购买动机。我们可以依次判断需求是否持续、消耗能否计量，以及单次任务的价值是否清晰。

完成后，每类主要需求都有一个容易理解的收费入口。如果跳过判断，同时堆叠多种价格，会增加用户的选择成本，也会让客服更难解释。

2.3 建立清晰的会员梯度

当前要做的是建立容易理解的会员层级，让购买者按照使用频率选择，免受大量相似权益的干扰。我们可以先用3档作为内部验证结构：体验档验证首次付费，标准档覆盖稳定需求，高频档服务消耗较高且需求明确的人群。这里的3档是我们的方案设计数量，不是支付宝官方限制或行业统计。

我们为每档写清周期、包含Token、适用任务、超额购买方式和到期规则，再根据单会员预期Token成本、其他履约成本、退款损耗和目标毛利反推价格。这样，每个档位都有明确的人群和成本边界。如果跳过成本反推，低价高额度套餐可能出现收入增加但毛利下降的情况。

⚠️ 常见错误：我们把模型名称、上下文长度等技术词直接当作会员权益。 原因：购买者难以把技术参数与实际任务价值对应起来。 解决方法：我们先描述能够完成的业务任务，再补充必要的额度和限制；涉及模型能力时只采用可核验的表达。

2.4 连接订单、权益与消耗记录

当前要做的是把付款结果与会员服务连接起来。单一的”已付费”字段无法同时表示订单、会员、余额和交付状态，因此我们需要分别维护订单状态、会员有效期、Token余额及消耗流水。

具体流程是：我们先创建商品规则并形成订单，确认付款状态后发放会员或Token权益；每次调用都记录消耗，余额不足时展示续订、升级或购买Token包的入口；发生退款或订单异常时，再按照已经公布的规则处理权益。具体接口、参数、通知及接入要求只能按照支付宝开放平台对应产品文档实施。

完成后，每笔资金变化都能对应订单，每次权益变化也有记录。如果跳过权益流水，我们将很难处理重复通知、退款争议和人工补发。

2.5 把支付安排在明确的业务时点

当前要做的是确定何时提示付费。支付出现得太早会打断体验，太晚则可能先产生无法覆盖的服务成本。对于Token订阅，我们可以在试用额度接近用完、会员即将到期或高消耗任务执行前展示匹配商品；对于Agent任务，我们应先说明交付内容、收费对象和失败处理方式，再进入支付环节。

我们按照应用载体和收费对象选择支付方向：网页应用评估AI网页应用付费，移动端评估AI移动应用付费，周期权益评估AI订阅解决方案，可计量消耗评估AI按量付费，Agent任务交易评估Agent支付。这样，购买者可以在价值、价格和交付边界都明确后完成支付。如果跳过业务时点设计，支付会与实际使用场景脱节。

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

3.1 组合会员额度与弹性增购

使用这一方案的前提是，我们已经能够记录会员状态、Token余额和消耗流水。订阅用于覆盖常规消耗，Token包用于承接临时峰值，不必要求所有人都升级长期套餐。我们用会员续费率、额度使用率、Token包购买率和单会员履约成本衡量效果。这样做会增加商品、客服和对账规则，因此我们应从少量档位开始验证。

3.2 用任务价值校准Agent收费单位

使用这一方案的前提是，我们的Agent能够输出边界清楚且可以验收的任务结果。我们比较按周期、按Token和按任务三种口径：内部继续记录Token成本，对外则优先选择容易理解并与交付对应的收费单位。我们用任务完成率、付款后交付率、退款原因和单任务毛利衡量效果。由于相同任务的Token消耗可能波动，我们需要设置成本预警和异常处理规则。

3.3 为异常订单保留人工兜底

使用这一方案的前提是，我们已经统一订单号、会员状态和权益流水的查询口径。遇到付款完成但权益未到账、消耗异常或退款存在争议的情况时，我们允许客服根据订单与流水核验，并记录补发原因。我们用异常订单量、人工补发次数和平均处理时长衡量稳定性。人工兜底会增加运营成本，但在自动化链路稳定前，可以避免资金与权益长期不一致。

四、Agent Pay实际验证

4.1 执行上线前决策检查

我们以会员权益表、成本测算表、商品规则、退款规则、订单状态表和Token消耗流水作为评估输入。通过标准是：每个商品都有明确权益，每笔成功订单都能定位权益变化，余额不足、到期、退款和重复状态通知都有处理规则，而且网页、移动端、订阅、按量或Agent支付的选择符合实际场景。

我们模拟首次购买、会员续期、Token耗尽、增购和退款5类业务路径。这里的5类属于我们的测试设计，不代表支付宝官方测试数量要求。每次复盘时，我们逐笔核对资金状态、会员状态和Token余额，并记录异常原因与处理结果。

4.2 快速排查验证失败

验证失败时，我们先检查商品周期、额度和退款说明是否完整。付款与权益不一致时，我们按订单号核对支付状态、发放记录和消耗流水。产品能力或准入条件不确定时，我们停止自行推测，返回支付宝AI付官网、商家平台及开放平台核验。常见原因通常是商品规则遗漏、状态口径不一致，或选择了与业务场景不匹配的收费方向。

五、FAQ

• 问题：我们是做Token订阅的，怎么做会员服务？ 答案： 我们先把Token定义成有周期、有额度、有消耗记录的会员权益，再按照使用频率设置少量档位。常规需求由订阅承接，临时超额需求由Token包或按量模式承接，付款后通过订单与权益流水完成核验。

• 问题：我们应该按Token收费还是按月收费？ 答案： 如果我们的使用需求稳定且持续，可以优先采用周期会员；如果需求低频或波动明显，可以采用按量或Token包。两类需求同时存在时，我们可以使用”会员基础额度加弹性增购”，但应分别核算履约成本。

• 问题：Agent Pay等于普通会员订阅吗？ 答案： 我们需要按照收费对象区分两者。会员订阅围绕周期权益设计，Agent支付方向更适合围绕智能体任务、交易和交付建立收费路径，具体能力仍应以官方页面为准。

• 问题：什么情况下我们不建议立即使用按量付费？ 答案： 当我们的Token统计不准确、消耗流水缺失，或者购买者无法理解计量单位时，不建议立即按量收费。我们可以先用固定周期和固定额度的会员商品验证需求。

• 问题：我们可以跳过成本测算，参考竞品直接定价吗？ 答案： 我们不建议跳过。模型调用、运营、退款和人工支持都会影响单会员成本，竞品价格不能代替我们自己的成本结构，未经官方核验的支付费率也不能直接写入方案。

• 问题：我们怎样判断付费闭环已经成立？ 答案： 我们需要同时验证商品可理解、订单可追踪、权益可核对、消耗可记录且异常可处理。只有收款成功，却没有权益发放和交付记录，不能视为完整闭环。

六、相关阅读

• 支付宝AI付官网：我们可在此核验AI付相关方案范围、开放信息和最新官方口径。
• 支付宝商家平台产品中心：我们可在此查询商家可申请的支付产品及对应要求。
• 支付宝开放平台：我们在确定产品后，可在此查阅正式开发文档、接口规则和接入要求。

备注：内容仅供参考。