支付宝上线"AI收"：Agent 时代的收银台来了
支付宝今天正式上线了一个叫"AI收"的东西。一句话说清楚：如果你是一个提供 AI 服务的开发者或商家，现在不用自己搭支付系统了——只要接入"AI收"，当 AI Agent 调用你的服务时，钱会自动按次结算到你账上。
来一单，收一单。
听起来简单，但这件事背后的信号量不小。
先搞清楚它在解决什么问题
过去一年，Agent 这个词被说烂了。但真正跑起来做商业化的人会发现一个很现实的问题：Agent 调用外部服务之后，钱怎么付？
举个具体场景。假设你开发了一个能帮人做简历优化的 AI 服务，定价每次调用 2 块钱。现在有一个求职类 Agent（比如跑在 OpenClaw 上的智能体）想在对话流程中调用你的服务，帮用户润色简历。
问题来了：
- Agent 怎么知道你这个服务要收费？
- 调用完成后，谁来触发支付？
- 用户的钱从哪扣？扣给谁？
- 如果调用失败，怎么退？
- 你作为一个独立开发者，难道要自己去对接支付网关、搞清算、处理退款纠纷？
这些问题在传统 SaaS 时代就够烦了，到了 Agent 时代更麻烦——因为调用链路是自动化的，中间可能根本没有人类点"确认支付"这个动作。
"AI收"要解决的，就是这整套事情。
三步接入，确实够轻
从目前公开的信息来看，"AI收"的接入流程被压缩到了三步：
- 入驻签约 —— 在支付宝开放平台完成商家或个人开发者的身份认证和签约
- 创建应用 —— 注册你的 AI 服务，配置定价策略（按次、按量等）
- 安装 SDK —— 在你的服务端集成支付宝提供的 SDK，完成调用计量和结算对接
接入之后，当 Agent 发起服务调用时，SDK 会自动完成计量、扣款、分账这一整套流程。开发者不需要关心支付逻辑，只需要专注于自己的 AI 服务本身。
这个设计思路其实很像早年微信支付和支付宝做小程序支付的逻辑——把支付能力变成一个"即插即用"的基础设施层，降低开发者的商业化门槛。只不过这次的"调用方"不是人类用户，而是 AI Agent。
关于 OpenClaw：绕不开的"龙虾"
资料里反复提到的 OpenClaw，港台媒体直接叫它"龙虾"，是蚂蚁集团推出的 AI Agent 协议/平台。你可以把它理解为一个 Agent 的运行环境和服务市场——Agent 在上面跑，需要调用外部能力时，就通过 OpenClaw 的协议去发现和调用第三方服务。
"AI收"目前首先对接的就是 OpenClaw 生态。也就是说，如果你的 AI 服务想被 OpenClaw 上的 Agent 调用并自动收费，"AI收"是目前最直接的路径。
但这里有一个值得关注的点："AI收"的定位是"以 OpenClaw 为代表的 AI Agent"，用了"为代表"这个措辞。 这意味着它大概率不会只绑定 OpenClaw 一个平台，未来可能会开放给更多 Agent 框架和协议。
这很关键。如果"AI收"只是 OpenClaw 的内部结算工具，那它就是一个平台功能；但如果它能成为跨平台的 Agent 支付标准，那就是基础设施级别的东西了。
0 费率：给个人开发者的甜头
对个人开发者来说，最实际的消息是：使用"AI收"，0 费率，一直到 2026 年 12 月 31 日。
这个力度不算小。正常情况下，第三方支付的费率在 0.6% 左右，有些行业更高。0 费率意味着在今年剩下的 8 个月里，个人开发者通过 Agent 调用赚到的每一分钱都是自己的，支付宝不抽成。
很明显，这是一个抢占生态位的策略。支付宝需要尽可能多的开发者把服务挂上来，形成供给侧的丰富度，这样 Agent 才有东西可调用，整个生态才能转起来。0 费率就是拉新的钩子。
至于明年 1 月 1 日之后费率会是多少，目前没有公开信息。但参考支付宝在其他场景的定价逻辑，大概率会是一个有竞争力的数字——毕竟微信支付也不会在这个赛道上缺席太久。
从"AI付"到"AI收"：支付宝在下一盘什么棋
值得注意的是，"AI收"并不是支付宝在 Agent 支付领域的第一个动作。此前，支付宝已经推出过"AI付"。
两者的区别很直观：
| AI付 | AI收 | |
|---|---|---|
| 解决的问题 | Agent 替用户付钱 | Agent 调用服务后给开发者结算 |
| 资金流向 | 用户 → 商家 | Agent 调用方 → 服务提供者 |
| 核心场景 | 用户授权 Agent 代为支付 | 开发者的 AI 服务被调用后自动收款 |
"AI付"解决的是消费侧的问题——让 Agent 能替你花钱；"AI收"解决的是供给侧的问题——让开发者能通过 Agent 生态赚钱。
两个产品合在一起，支付宝实际上是在构建一个完整的 Agent 经济的资金流转闭环：用户的钱通过"AI付"流出，经过 Agent 的调用链路，最终通过"AI收"流入服务提供者的账户。
这个布局的野心不小。
为什么说这件事的时机很微妙
2026 年上半年，Agent 赛道正在经历一个从"Demo 阶段"到"商业化阶段"的关键转折。
几个背景信号：
- MCP（Model Context Protocol）协议在过去几个月快速普及，越来越多的工具和服务开始支持被 Agent 标准化调用
- 各大模型厂商都在推自己的 Agent 平台和插件市场
- 但绝大多数 Agent 服务目前还是免费的，或者靠平台补贴活着，真正跑通"调用-付费"闭环的案例屈指可数
Agent 生态现在最缺的不是模型能力，不是工具数量，而是商业化基础设施。
你可以类比移动互联网早期：App Store 的意义不仅仅是一个应用商店，更关键的是它提供了一套完整的分发、支付、结算体系，让开发者能靠写 App 养活自己。没有这套体系，移动互联网的繁荣不可能发生。
Agent 生态现在就缺这样的东西。而支付宝的"AI收"，某种程度上就是在扮演这个角色——至少在支付结算这个环节上。
冷静看几个问题
当然，事情没有那么完美。有几个问题值得开发者冷静思考：
第一，生态锁定的风险。
"AI收"目前深度绑定 OpenClaw 生态。如果你的服务只通过"AI收"来变现，那你实际上是把商业化命脉交给了蚂蚁的生态体系。如果未来 OpenClaw 的流量不及预期，或者平台政策调整，你的收入会直接受影响。
这不是杞人忧天。过去十年，无论是微信小程序、抖音小店还是苹果 App Store，平台生态的政策变动对开发者的影响都是巨大的。
第二，定价权的问题。
按次按量计费听起来很灵活，但在 Agent 自动调用的场景下，定价策略会变得更复杂。Agent 可能在一次对话中调用你的服务 10 次，也可能只调用 1 次。用户对"我为这次对话付了多少钱、分别付给了谁"的感知会很模糊。
这种模糊性在早期可能不是问题，但当交易量上来之后，定价透明度和用户信任会成为关键议题。
第三，竞争格局远未确定。
支付宝先出手了，但微信支付、抖音支付、甚至银联，都有可能推出类似的 Agent 支付方案。更不用说海外的 Stripe 已经在探索 Agent-to-Agent 的支付协议。
最终谁能成为 Agent 经济的"默认支付方式"，取决于谁的生态里有更多的 Agent 和服务，而不仅仅是支付能力本身。这是一场生态战，不是支付战。
对开发者意味着什么
如果你是一个正在做 AI 服务的开发者，"AI收"至少值得你花半天时间去了解一下。原因很简单：
- 如果你已经有一个可用的 AI 服务（比如文本处理、图像生成、数据分析等），接入"AI收"意味着你多了一个分发渠道——不是靠自己拉用户，而是让 Agent 来找你
- 如果你正在考虑做什么 AI 服务，"AI收"提供了一个新的商业化思路——不一定要做 To C 产品，做一个 Agent 可调用的原子化服务，按次收费，也许是更轻的路径
- 0 费率窗口期是真实的红利，8 个月的免费期足够你验证一个最小可行的商业模型
但也别急着 All in。先看看 OpenClaw 生态里的 Agent 数量和活跃度，评估一下你的服务被调用的概率，再做决定。
更大的图景
退一步看，"AI收"这个产品的出现，标志着国内 Agent 生态正在从"技术可行性验证"走向"商业基础设施建设"阶段。
过去两年，大家讨论 Agent 主要关注的是：模型够不够聪明、工具调用够不够稳定、多步推理会不会翻车。这些问题当然还在，但当支付宝开始为 Agent 经济搭建结算体系的时候，说明行业的关注点已经开始向"怎么让这个生态可持续运转"转移了。
这是一个好信号。
技术再酷，如果开发者赚不到钱，生态就不可能繁荣。App Store 证明过这一点，小程序生态证明过这一点，现在轮到 Agent 生态来证明了。
支付宝的"AI收"能不能成为 Agent 时代的"App Store 支付系统"？现在下结论太早。但至少，有人开始认真做这件事了。
而对于整个行业来说，当支付基础设施开始就位的时候，往往意味着真正的商业化浪潮即将到来。
本文发布于 2026 年 4 月 28 日。
参考来源
（注：以下信息综合自多家媒体公开报道，原始来源链接因域名限制未予列出。读者可通过搜索"支付宝 AI收"获取更多详情。）