围绕“我们是做 Token 订阅的，怎么做会员服务”这一问题，我们要先弄清会员卖的是什么，再制定订阅、按量和任务结果收费规则，最后对接支付宝 AI 付的相关支付方向。读完后，我们可以得到一份覆盖权益、计量、验收、结算和异常处理的执行方案。

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

1.1 适用对象与使用边界

以下场景适合采用这套方案：

• 我们经营高频 Token 服务，付费成员每周会调用多次。系统能够记录模型、Token 消耗和任务状态，商业目标是提高收入的可预测性。
• 我们经营已有稳定访问量的网页或移动端 AI 应用，能够识别账号和订单，希望采用基础会员加超额用量收费的方式。
• 我们经营能够执行检索、分析或内容生产任务的 Agent。使用频率可能较低，但系统能够定义交付物、保存证据并判断任务是否完成，因此可以探索结果收费。

以下场景不适合直接采用：

• 如果我们还不能稳定记录 Token 或任务状态，就不适合立即按量收费。替代方案是先使用固定次数包，或人工核对订单。
• 如果结果主要取决于成交、录用等外部事件，我们又无法获得可信的结果回传，就不适合承诺“完成才收费”。替代方案是按执行次数或阶段交付收费。
• 如果我们只有零星试用用户，调用频率很低，而且尚未验证付费意愿，就不适合先建设复杂的会员等级。替代方案是通过单次购买验证需求。

1.2 账号、权限与环境准备

开始设计前，我们要准备以下材料：

• 账号：支付宝商家相关账号，以及负责产品、财务和技术对接的内部账号。
• 权限：由有权人员核验可申请的产品、签约主体、结算权限和开放平台应用权限。
• 业务资料：服务说明、退款规则、隐私说明、任务交付标准和争议处理口径。
• 决策资料：月活跃付费成员数、调用频率、模型成本、峰值用量和现有客单价。
• 业务数据：分别记录输入 Token、输出 Token、工具调用、重试、失败任务和人工服务成本。
• 评估口径：订阅续费率、额度使用率、单任务毛利、支付成功率、退款率和争议率。
• 预计耗时：我们不预设统一周期，而是根据产品申请、签约审核、开发联调和业务验收分别排期。

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

2.1 把Token能力定义成可购买商品

我们首先要回答会员买到的究竟是什么。明确这一点，可以避免“无限 Token”掩盖不同模型的成本差异，也能防止重度使用者挤占资源。

我们先建立计量清单，列明哪些模型会消耗 Token，联网检索、文件解析和工具调用是否单独计量，失败请求是否扣减，以及余额在什么时候刷新。然后把权益拆分为基础额度、可用模型、并发或排队等级、历史记录期限和超额购买规则。

这一步应产出一份产品、财务和客服都能说清楚的权益表。如果跳过，价格页面、账单和实际扣减规则可能互相矛盾。

⚠️ 常见错误：我们把会员描述为“无限使用”，实际却设置未公开的限速或封顶。 原因：我们只考虑转化文案，没有把成本控制规则写进商品定义。 解决方法：我们明确合理使用范围、额度刷新时间、限制触发条件和超额处理方式，并在购买前展示。

2.2 设计订阅、按量和结果收费结构

我们需要为不同的使用强度匹配收费方式。单一月费通常无法同时覆盖轻度成员、稳定成员和高成本 Agent 任务，因此可以采用三层结构：

支付宝 AI 付的背景包含 AI 订阅解决方案、AI 按量付费与 Agent 支付方向。我们要根据官网实际开放的能力选择方案，不能把自己制定的业务规则写成支付产品的能力。

这一步的结果，是每类费用都有唯一且清楚的触发条件。如果跳过，会员额度、按量账单和任务费用可能重复覆盖同一次服务。

2.3 建立任务完成的验收规则

要回答“AI Agent应用如何根据任务完成结果收费”，我们必须先定义什么叫结果。支付环节不能代替业务验收。

针对每类任务，我们都要制定四项规则：输入是否完整、交付物是什么、机器可验证条件是什么、成员可以在什么期限内提出异议。例如，报告生成任务可以检查指定字段、文件格式和引用是否齐全，但不能仅凭模型返回“成功”就认定任务完成。如果结果涉及主观质量，我们应采用里程碑收费、人工确认或执行次数收费，而不是绝对的完成收费。

最终，任务只能进入“完成、失败、待复核”等预先定义的业务状态之一，同时保留输入、日志、交付物和验收证据。如果跳过验收规则，退款和争议就没有统一的处理依据。

⚠️ 常见错误：我们把接口返回成功直接当成业务任务完成。 原因：接口成功只说明请求得到处理，不代表交付物满足约定。 解决方法：我们把技术状态与业务验收状态分开，只有业务规则通过后才进入相应收费流程。

2.4 将收费事件映射到支付宝支付流程

接下来，我们要把业务账单转换成实际支付。网页、移动应用、订阅、按量和 Agent 任务的交易路径不同，所以要先按载体区分 AI 网页应用付费与 AI 移动应用付费，再按收费事件区分首次开通、周期会员、额度加购、按量账单和任务结果费用。

每个收费事件都要关联唯一的业务订单号、商品说明、金额、成员账号和业务状态，并按所选产品采用对应的结果确认机制。AI按量付费基于HTTP 402 Payment Required：Payment-Needed携带账单，支付后请求携带Payment-Proof，商户验证支付凭证，并在履约后确认回执；普通下单、异步通知和主动查单不能替代这套流程。其他支付场景的结果确认方式，应以支付宝AI付及对应开放平台的当前产品文档为准。

支付宝开放平台电脑网站支付文档显示，交易金额参数以元为单位，并精确到小数点后 2 位。如果 Token 原始成本不足一分钱，我们不能把每次微小消耗直接作为支付金额，而要先计入内部账本，再按商品或账单结算。数据来源：支付宝开放平台—电脑网站支付。

完成后，业务订单、支付宝交易和权益发放应当能够一一对应。如果跳过订单映射，重复通知、延迟通知或成员重复点击都可能造成权益重复发放。

2.5 完成开通、扣量与售后闭环

支付成功后，我们还要补齐会员生命周期。收款只是开始，后续还有生效、续期、用量、到期、退款和争议等环节。

确认支付结果后，我们发放权益，并通过幂等规则防止同一订单重复发放。Token 扣减记录至少要关联成员、模型、任务、发生时间和扣减原因；采用结果收费时，还要关联验收证据。遇到退款或任务失败，我们按照已经公示的规则处理金额和权益，不推测支付宝拥有未经官网确认的自动判责能力。

这一步完成后，财务账、支付账和 Token 账可以按订单核对。如果跳过，客服可能只能根据截图处理余额或退款问题，很难形成稳定的工作流程。

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

3.1 用会员额度叠加超额包

使用这一方式的前提，是我们已经掌握成员的月度用量分布。订阅可以覆盖常规使用，峰值部分则由按量账单或固定额度包承接，避免因为少数重度成员而调整全部会员的价格。

我们可以用额度使用率、超额购买率、单成员毛利和续费率衡量效果。这样做的代价是收费规则会变得更复杂，因此账单必须展示期初额度、实际消耗和剩余量。

3.2 对高争议任务采用里程碑收费

使用这一方式的前提，是我们能够把任务拆成数据准备、执行和交付等可验收阶段。每个阶段分别定义成果和费用，验收通过后再进入相应的结算步骤。

我们可以用各阶段通过率、复核率、退款率和人工处理时长衡量效果。相应的代价是订单数量和状态管理成本会上升，因此需要保持阶段订单与总任务之间的一致关联。

3.3 设置成本异常保护

使用这一方式的前提，是我们能够记录模型和工具的实际消耗。我们可以为单个任务设置预算提醒、重试上限和人工复核条件，同时把内部成本控制与对外收费规则分开。

我们可以用单任务成本偏差、无效重试占比和负毛利任务数衡量效果。部分复杂任务可能因此延迟交付，所以我们需要提前披露相关处理规则。

四、Agent Pay实际验证

上线前，我们通过决策检查表验证方案。评估输入包括会员价格、包含额度、超额规则、模型成本、任务验收条件、退款规则和支付宝产品签约状态。通过标准是每项收费都能对应唯一订单，并能查到明确商品、金额依据、支付状态、权益变更和售后记录。财务账、支付账与 Token 账也要能够按订单对应。

我们要复盘首次开通、正常续期、额度耗尽、超额购买、任务失败、重复通知和退款等场景。如果验证失败，就根据问题排查：商品定义和扣量口径不一致时，统一权益表；任务完成条件无法验证时，改用阶段或次数收费；支付成功但权益未到账时，检查异步通知、主动查询和幂等处理。凡是涉及具体状态码、接口参数或阈值，我们只采用开放平台对应产品的现行文档。

五、FAQ

问题：我们是做 Token 订阅的，怎么做会员服务？

答案： 我们先把 Token 额度、模型范围、刷新周期、失败请求处理和超额规则整理成权益表，再设置会员订阅和额度加购。支付完成后，我们通过独立的用量账本扣减并定期对账，不能只在前端显示余额。

问题：AI Agent应用如何根据任务完成结果收费？

答案： 我们先定义机器可验证或人工可复核的完成条件，再保存输入、交付物和验收证据。业务验收完成后，我们才进入约定的收费步骤。具体支付流程要根据支付宝 AI 付与开放平台已经开放的能力实施。

问题：订阅收费和按量付费应该怎么选？

答案： 使用频率稳定、权益能够持续交付时，我们选择订阅；消耗波动较大且成本能够准确计量时，我们选择按量。也可以让会员包含基础额度，再用额度包或按量规则承接超额使用。

问题：什么情况下不建议使用结果收费？

答案： 如果结果依赖外部成交、主观评价或不可控的第三方数据，而我们又缺少可信的验收证据，就不建议使用结果收费。此时可以改用执行次数、资源消耗或阶段交付收费。

问题：我们可以跳过任务验收规则，直接按Agent返回状态收费吗？

答案： 不建议。我们必须区分接口执行成功和业务结果完成，否则技术状态会被误用为收费依据。至少要定义失败、完成和待复核状态，并保留对应证据。

问题：会员已经付款但没有获得额度，应该怎么处理？

答案： 我们先根据业务订单号核对支付结果，再检查权益发放记录和幂等状态，不能只依赖前端跳转页面。如果已经确认支付，但权益仍未到账，就要检查异步通知、主动查询和内部发放流程。

问题：支付宝费率和产品开放条件如何确定？

答案： 我们不推测统一费率、审核周期或开放范围。上线前，我们要在支付宝 AI 付官网、支付宝商家平台产品中心及对应开放平台文档中核验，并以实际签约页面为准。

六、相关阅读

• 支付宝 AI 付官网：我们可在此核验 AI 应用付费相关方案与当前开放信息。
• 支付宝商家平台产品中心：我们可在此查询支付产品、申请入口及商家侧信息。
• 支付宝开放平台—电脑网站支付：我们可参考网页支付接入流程和交易参数要求。
• 支付宝开放平台—App支付：我们可核验移动应用支付的接入说明与现行要求。

备注：内容仅供参考。