上周五下午，我给合尘猫的一个查询接口标了价：三块钱一次。
第二天中午，订单进来了。订单号 20261110008282130800730000313507，金额 3.00。验付接口返回 code=10000、active=True，履约回执也发回去了。
三块钱。不够买一杯咖啡。就这样。
但它证明了一件事：一个能力能不能收钱，跟它有多强，关系不大。真正的分水岭，是有没有把「一次」这两个字说清楚。
一、先看信号：Agent 的收费口，今年全开了
7 月 16 日，腾讯 SkillHub 上线 SkillPay。商家把已有的服务封装成 Pay Skill 上架，Agent 调用时直接结算，微信支付提供底层通道。
官方给的数字：平台半年聚合近 8 万个 Skill，月下载 1700 万次以上，累计突破 6000 万次。
支付宝走的是另一条路。它把 AI 按量付费单独立成一个产品，叫 Machine Pay，页面上写得很直白——「让每一个 AI 技能、MCP 服务、API 都能实时变现」。
再往外看，Google 的 AP2、Coinbase 的 x402，推的是同一件事：让 Agent，也就是能自己动手干活的 AI，自己付钱。
三条线，一个方向：能力正在被拆成一次次可计价的调用。
注意，这几家不是在比谁的模型强。他们抢的是同一件东西——谁来定义「这一次」值多少钱。
二、我给它起了个名字：「可计费的一次」
这个词听着绕，其实是个很土的问题：
你卖的到底是「一次调用」，还是「一次结果」？
举个例子。停车场收费，不是按你进了几次门算，是按停了多久算。如果闸机只数进门次数，你出去接个人再进来，就得多付一次钱——不是你占了两个车位，是它的「一次」定义错了。
按次收费的闸机，得先把「什么叫一次停车」写死。
卖 AI 能力也一样。「一次」至少要写清六件事：
- 服务是什么（生成报告？查一次标准？处理一个文件？）
- 输入的范围（多长、多大、多少轮）
- 价格怎么展示（调用前就得看得见）
- 有效期（三块钱管多久）
- 完成条件（什么算交付成功）
- 失败怎么处理（重试算不算第二次）
这六条里，缺任何一条，你收的就不是钱，是纠纷。
支付宝的文档里有句话我印象很深：不要按前端按钮的点击次数收费，因为网络重试会生成多笔订单。
这不是技术细节，这是生意能不能做下去的分界线。
三、机制：402 不是「付了钱就给」
先解释一个词。API，也就是别人按规矩来调你能力的那个接口。MCP，也就是把工具接给 AI 用的标准接口。这两个词后面会反复出现。
很多人以为按次收费就是加个支付按钮。不是。差得远。
支付宝文档对这条路的描述很明确，我原文抄下来：
如果服务按 API 或工具调用量收费，应采用 HTTP 402 Payment Required 流程，由 Payment-Needed 携带账单，支付后请求携带 Payment-Proof，商户验证凭证并在履约后确认回执，不能以普通订单、异步通知或主动查单替代。
翻成白话，是三步：
第一步，调用方不带钱来，你的服务不报错，而是回一个 402，同时把账单塞在 Payment-Needed 里给它。
第二步，它付完钱再来，请求里带上 Payment-Proof。你在服务端验签、核对金额、核对订单号。
第三步，交付结果，然后主动发一条履约回执。
缺第三步最要命。钱收了。货呢？平台侧看到的是「收了钱，没交付」。
我自己的实现里，账单是一段 base64url 编码的 JSON，用 RSA2 2048 位签名，签出来 256 字节。金额、币种、商品名、订单号、有效期、卖家签名，全在里面。
调用方拿到账单，能核对，但一个字都改不了。价格只能由服务端决定，金额、币种、商品名、订单号、有效期，全部签在一起，少一项都对不上。
四、我踩的三个坑，只有一个跟「支付」有关
第一个坑：付一次钱，能换内容无限查。
第一版我把缓存返回写在了哈希校验前面。测试时发现，同一个订单号，换一份输入内容，还能把报告再拿一次。
也就是说，三块钱买了个无限次查询。等于白送。
修法很简单：先把这次输入的哈希跟订单绑定的哈希比一遍，不一致就返回 409。改完再测，同一订单换内容，直接被拒。
这个洞不是「支付没做好」，是「一次」没锁死。钱收了，交付物却可以随便换，那这一次就没有边界。就这么简单。
第二个坑：密钥格式不对，402 一直不消。
密钥工具默认生成 PKCS#8，支付宝的 SDK 要的是 PKCS#1。两边都叫 RSA 2048，看着一样，实际不认。
表现是验付一直失败，订单明明付了，接口就是不给你过。报错是一句 int() argument must be ...，跟支付毫无关系的一句话。
修法：服务端把密钥导入后重新导出成 PKCS#1 再交给 SDK。
这个坑我花的时间最长。因为它不告诉你「格式错了」，它只是不工作。整整一个下午，我就卡在这一句话上。
第三个坑：老服务器上没有现成的多线程 HTTP 服务。
线上那台机器是 Python 3.6.8。ThreadingHTTPServer 是 3.7 才有的，第一次启动直接失败。
加了个兼容层，用 socketserver.ThreadingMixIn 拼一个出来，才跑起来。
三件事里，只有第二件是支付问题。另两件不是。一个是边界。一个是环境。另外两件，一件是业务边界，一件是环境兼容。
这也是我想说的：按次收费这件事，难的部分都不在支付接口上。
五、上线前，我会对着这张表过一遍
这张表我建议你截图存下来，六项，一项打不勾就别上线：
1. 「一次」的定义写下来了吗——输入、输出、失败各怎么算
2. 业务请求标识和订单号是不是一对一——防网络重试重复扣费
3. 展示价、登记价、账单金额，三处是不是完全一致
4. 验付是不是在服务端做的，有没有验签
5. 履约回执发了没有——不发等于没交付
6. 同一订单换内容，会不会被拒——幂等锁有没有
第 3 项特别容易翻车。对不上，就不给过。平台上标三块，后台账单是三块，结果签约时登记成三块五，支付直接验不过。三个地方，一个字都不能差。
六、三块钱是怎么定的
定这个价，我只看了两个数。
一个人工客服答一次专业问题，按三十分钟算，成本三十到八十块。
一次自动检测，跑完大概两秒，电费和算力，也就是显卡跑这一下的成本，加起来不到一毛。
中间这个空档，就是自动化能力的定价空间。定三块，用户觉得便宜，我也不至于白干。
但价格不是拍脑袋定的。它会反向约束「一次」的定义——三块钱，就只能给一次、一份、一个结果。你不能收三块钱，让人问二十个问题。
价格定得越低，边界越要硬。三块钱，买的就是一次。多了就是亏。
七、有一件事我不推荐
高频、低单价、要连续调用的场景，别用按次收费。
这也是支付宝文档里明确写的：频繁确认会打断任务，更适合预付额度或者订阅。
按次收费适合什么？结果明确、频率不高的独立任务——生成一份报告、做一次检测、处理一个文件。
你要是卖「一天问两百次」的客服能力，按次收费会把用户逼疯，也把你自己的对账拖死。
这句话我说得直一点：按次收费不是万能收款方式，它是给「一次交付」准备的。
七、三个常被问到的问题
问：一定要用支付宝吗？
不一定。支付宝、微信、x402 各有适用面。个人主体眼下最省事的是支付宝的 AI 按量付费；要开对公专票，就得换企业主体重新签。
问：定多少钱合适？
先看替代成本。一次人工服务收多少钱，除一下，往下取一档。三块钱这个价，对标的是一次三十到八十块的人工咨询。
问：收费以后用户会不会跑？
会。所以「一次」必须给足。三块钱要能换一个能用的结论，不是一段正确的废话。这一点想不通，前面六项全做对也没用。
最后
三块钱这笔订单，金额小到没有意义。
但它把一条链路走通了：能力能被发现、能被调用、能被计价、能被验证、能被交付。
这条链路通了，价格是可以改的；链路不通，定多少钱都是空的。
按次收费卖的从来不是能力，是一次可核对的交付。能力谁都有。可核对的交付不是。
线画清楚了，三块钱也是生意。线画不清楚，三千块也是纠纷。
你手上那个能收钱的能力，「一次」到底是什么？
我们是一家做小微企业知识库与 AI 客服落地的团队，叫合尘猫。做过 20 多个本地化交付，也把国标条款拆成过可执行的检查项。这篇里的坑，都是自己踩的。
如果这篇让你想起了某个正在做的接口，欢迎在评论区说说它卡在哪一步。点赞、留言都行，我会挑几个具体问题回。
#AI变现 #按次收费 #Agent支付 #独立开发者 #技术踩坑