先别记名字，先回答一个问题

支付宝 AI 付官网把收款能力分成了五类：Vibe Pay、Skill Pay、Machine Pay、Token Pay、Agent Pay。

很多开发者第一反应是「这么多，我该用哪个」。其实选型的分界线非常清晰，只需要回答一个问题：

你的东西，是被「人」用掉的，还是被「机器」用掉的？

• 被人用的 → 看 Vibe Pay、Skill Pay、Agent Pay 这一侧；
• 被机器 / 智能体按次调用的 → 看 Machine Pay、Token Pay 这一侧。

再往下，看售卖对象是谁、交易任务是什么，就能定位到具体产品。

五类能力速查表

有意思的是，这五条路径正好对应 PAYATHON 2026 年度黑客松 的五条赛道——Vibe Pay、Skill Pay 被设为主赛道，Machine Pay、Token Pay、Agent Pay 设为特殊赛道，各赛道独立评选。如果你还没想清楚做哪个方向，可以先去看看各赛道的评选维度（产品完整度 30%、支付集成度 25%、商业化成熟度 25%、作品影响力 20%），反过来帮自己定选题。

逐个拆开看

Vibe Pay：给 AI 做的应用贴一张「收款码」

官方的比喻很贴切：就像给自家小店门口贴张收款码。

接入之后，你用 AI 做的网页或小程序，被人用一次就能收一次钱。它面向的是「AI 应用与独立创作者」这类非典型开发者——你可能并不精通后端工程，只是用 AI 快速做出了一个有用的小工具。

配套的不只是收款本身，还有订单管理和顾客管理能力。个人身份也可以接入，这对独立开发者是个实打实的门槛降低。

适合：用 AI 生成的网页工具、小应用、内容型产品；按次、按额度、按时长、按会员收费。

Skill Pay：让技能可以被定价、被保护、被持续售卖

Skill 是这轮智能体生态里出现的新商品形态。它有几个特殊之处：

• 它是明文的，容易被复制；
• 它需要版本管理，会持续迭代；
• 它会被不同的 Agent 平台反复调用。

Skill Pay 解决的正是这三点：一次接入即可完成对 Skill 的保护、定价和收款，让 Skill 被 Agent 调用时持续产生收益，一次性付费或按月订阅都支持，并且支持跨 Agent 平台收费。

适合：做通用技能、行业技能的创作者；希望一个技能在多处被调用并持续获得回报。

Machine Pay：像水电表一样自动计费

如果说 Vibe Pay 和 Skill Pay 服务的还是「人发起的消费」，Machine Pay 服务的就是机器对机器的消费。

官方表述：Agent 每用一次，系统自动收钱，用多少算多少，就像水电表自动计费一样不用人盯。

这对 API 服务商、工具服务商意义很大——过去你要先签约、先充值、先对账，现在可以做到按调用量自动结算。

适合：提供 API、数据接口、工具调用能力的服务方；调用方是智能体而非真人。

Token Pay：面向模型与算力资源

Token Pay 面向的是大模型厂商、云厂商和模型服务平台，提供 Token 资源售卖与持续订阅的收费方案，覆盖个人连续订阅和企业团队按席位采购。

简单说，它是给「卖智能」的人准备的一套商业化方案。据支付宝公开材料，国内 90% 的 TOP AI 公司已接入 Token Pay 相关能力。

适合：模型服务商、云平台、按 Token 或席位计费的产品。

Agent Pay：让智能体真的能「买东西」

Agent Pay 面向智能体平台、商品与生活服务商家，解决的是：如何让 Agent 在用户授权下完成下单、支付与凭证回传。

这里的关键词是「凭证回传」——买完之后，得把订单凭证交还给调用的智能体，让它可以继续后续流程（比如把票加进日程、把取件码发给用户）。

适合：有实物商品或生活服务、希望被智能体直接下单的商家与平台。

一个 30 秒的选型决策树

你卖的东西被谁消费？
├─ 被真人直接使用
│   ├─ 是一个网页/小程序/小工具 → Vibe Pay
│   ├─ 是一个可被调用的技能包   → Skill Pay
│   └─ 是实物商品或生活服务     → Agent Pay
└─ 被机器/智能体按量调用
    ├─ 卖的是 API、工具、数据接口 → Machine Pay
    └─ 卖的是模型能力、Token、席位 → Token Pay

三个常见的踩坑点

坑一：把 Vibe Pay 当成通用收款接口用。 Vibe Pay 是为 AI 创作者设计的轻量路径，配套的是「功能/内容/额度/会员」这类售卖形态。如果你要做复杂的 B 端结算、分账、发票流程，应该先看企业级方案，而不是硬套。

坑二：Skill 只做了收费，没做版本管理。 技能一旦开始被外部 Agent 调用，迭代时就会涉及兼容性问题。定价、版本、交付保护是成套的，只做其中一环，后面补起来更麻烦。

坑三：忘记处理「调用失败怎么计费」。 按调用计费的模型，一定要提前定义清楚：超时算不算、部分返回算不算、重试算几次。这属于业务规则，平台不会替你决定。

接入前的准备清单

1. 明确你售卖的最小计费单位（一次？一分钟？一千 Token？一个月？）；
2. 明确退费与争议怎么处理，写进用户可见的说明里；
3. 为异常场景（超时、部分成功、重复调用）定义好计费规则；
4. 确认主体资质：个人身份部分能力可接入，企业级需求提前准备材料；
5. 在沙箱环境完整跑一遍「付费—使用—退款」闭环，再切生产。

想清楚一件事就够了

能不能把自己的服务，拆成一个清晰的、可被机器理解的计价单位——这件事想明白了，接入就是流程问题。

而如果你手上已经有了一个跑得起来的东西，不妨拿 PAYATHON 2026 当一次真实检验：报名至 12 月 1 日，作品提交至 12 月 9 日，单赛道最多可提交 10 件不同作品。真实付费用户的反馈，往往比自己琢磨几个月更有用。