第 35 章 · Machine Payment 会不会成为新的互联网协议

一个现实问题

你的软件向一个接口发了一个请求。对方回了一个状态码：402，需要付款。

然后它卡住了。

这件事值得停下来想一想，因为它很奇怪。互联网上的软件遇到别的情况时都知道该怎么办：404 说明这个东西不存在，那就换一个地方找；401 说明需要登录，那就带上凭证重试；403 说明没有权限，那就放弃；429 说明请求太快了，那就等一会儿再来。

这些状态码之所以有用，是因为它们后面都跟着一套所有人都同意的后续动作。软件不需要理解语义，它只需要照着做。

只有 402 是个例外。 它在 HTTP 的规范里被预留了几十年，含义是「需要付款」，但它后面什么都没有。收到它之后，一个软件不知道：

要付多少钱？
付给谁？
用什么付？
付完之后怎么证明自己付过了？
如果服务没提供，能不能拿回来？

这五个问题，人类可以通过打开一个网页、看一眼价格、掏出信用卡、填一堆表来解决。软件不能，因为这五步里没有一步是标准化的。

于是过去几十年，互联网用两种方式绕开了这个问题。第一种是广告——内容免费，成本由广告主承担。第二种是账户——你先注册、先充值、先建立一段关系，之后的消费从关系里扣。

这两种方式都很成功，也都有一个共同的前提：付费的一方是人，而且这段关系会持续一段时间。

当付费的一方变成一个软件、而且它可能只用这一个接口一次时，两种方式都开始别扭。广告对它没有意义；注册一个账户去消费几分钱，摩擦远大于交易本身。

所以本章的问题：机器之间怎样为一次 API 调用付款？

这一章要讲的是问题本身和目前的通常做法。它不会给出任何协议的字段名、版本号或者接口签名——这个领域的规范还在快速变化，任何具体的技术细节写下来很快就会过期，而一个记错了的细节比不知道更糟。需要具体规范时，去读它的官方文档，如何跟上最新的 Crypto 知识那一页讲过怎么追一手源。

思想实验

你的软件一天要调用一万次某个接口。每次调用的合理定价大约是零点几分钱，一天总共十几块钱。

关键的附加条件：你的软件和这个服务商之前没有任何关系，而且可能只在今天用它。

现在有四种收费方式。

第一种：订阅。 服务商说：一个月多少钱，随便用。

对一个一天用一万次的软件，这可能很划算。但它要求你先做一个判断：我会不会一直用它。 而你的软件今天才第一次遇到这个接口。如果它只用一天，订阅就是为二十九天没用的部分付钱。

更根本的问题是订阅需要先建立关系：注册、绑定支付方式、同意条款。这几步对人来说是几分钟，对一个需要在几百个接口之间动态选择的软件来说，是一道必须有人参与的门。

第二种：预付费账户。 先充一笔钱，之后按调用次数扣，余额不足就补。

第 33 章讲过，这是今天绝大多数按量计费服务的实际做法，而且它很好用。成千上万次小额消费被合并成一次真实支付，固定费用被摊薄到可以忽略。

它的代价也讲过了：服务商数量乘以 Agent 数量，就是要维护的账户数量。 而且它同样要求先建立关系——你不能在遇到 402 的那一刻，立刻开始使用一个你还没注册的服务。

第三种：每次调用都发起一次链上支付。

它解决了关系的问题：不需要注册，不需要账户，付款方就是一个地址。

但它在费用上撞墙了。每一笔链上转账都要付网络费用，而这个费用在高频小额场景下，和交易本身可能是一个数量级甚至更大。一万次链上转账，网络费用可能远超十几块钱的服务费本身。

这和第一章里刷卡的失败方式是同一个：都是把一套为「大额低频」设计的结算机制，用在了「小额高频」上。

第四种：先建立一个额度，中间用轻量的方式计数，定期结算一次。

这是四种里唯一可行的形态，而且它其实是前面几种的混合：一次开通（像账户），中间计数（像计量），定期结算（像账单）。

区别在于「开通」这一步可以是无需许可的——不是注册一个账户，而是在链上放一笔钱或者做一次授权，几秒钟完成，不需要对方批准。

把四种放进一张表：

最后一行是这张表最诚实的一行。前两种是现实，第四种是方向。 而这一章要判断的正是：第四种会不会真的成为一层标准。

在此之前先注意一件事。第四种里的「计量」和「结算」是两件不同的事：

计量解决「你用了多少」，结算解决「钱怎么过去」。

微支付真正难的一直是计量，不是结算。把两者分开之后，结算可以走任何一条便宜的通道。

你来决定

你在设计一个给软件用的接口服务。你怎么收钱？

观察结果

四个选项指向同一件事：一次机器付款要成立，必须有六个问题被标准化地回答。

HTTP 把前面所有的事都标准化了，唯独没有标准化钱。

这不是一个疏忽。402 这个状态码被预留下来，说明当年的设计者想到了这件事。它空着几十年，原因不在协议层，在于当时不存在一种适合互联网的钱：跨境的、小额可行的、不需要事先建立关系的、机器可以自己操作的。

四十年里，钱的那一侧一直是别人的地盘：银行、卡组织、支付机构。它们各自有自己的接口、自己的开户要求、自己的地域覆盖。你可以在协议里写「需要付款」，但你无法在协议里写「怎么付款」，因为没有一种付款方式是所有人都能用的。

而第 13 章讲的那种东西，第一次让这句话有了可能：一种在互联网上原生存在、任何人都可以持有、不需要开户、转移和结算都在公开网络上完成的钱。

所以这一章的核心判断可以写成一句话：

HTTP 负责传信息，机器经济还需要一层负责传钱的协议。

这一层空了几十年，不是因为没人想做，是因为直到最近才有了一种可以被写进协议的钱。

但「有可能」和「会发生」是两件事。下一节要处理的就是这个差距。

建立模型

一、三层：报价、支付、计量

把一次机器付款拆开，它有三层，而且这三层可以分别演进：

第三层是真正的难点，而且它的难不在技术上。

考虑一个最简单的情况：服务商说你这个月调用了 10312 次。你怎么验证？ 你可以自己也记一份，但当两份记录不一致时，谁说了算？在今天的模式里答案很明确：服务商说了算，因为钱在他们那里，账也在他们那里。

这在公司之间是可以接受的——有合同，有长期关系，有声誉约束。在一个软件和一个陌生服务商之间，这个前提不成立。

这也解释了为什么「每次都付款」这个看起来笨的做法有它的道理：它把计量问题消灭了。每一次调用对应一次支付，不存在事后对账的空间。可惜它的成本不允许。

所以现实的方案都在这两端之间找平衡：付款的颗粒度越粗，成本越低，需要的信任越多。

二、四种收费模型，按「需要多少信任」排序

这张表的顺序是有意义的：越往下，摩擦越小，需要的信任越多。

一个很有用的推论：判断一个机器支付方案是否合理，看它要求的信任和它的场景是否匹配。 一个面向陌生对手方的方案，如果要求先充值一大笔，那它没有解决它声称要解决的问题。

第二行值得单独说。「攒一批结一次」是这四种里最适合机器场景的一种：每一批的金额小到即使对方赖账也无所谓，而批次足够密到风险敞口始终很小。它把「完全不信任」和「完全信任」之间的空间切成了很多小份。

三、三种成本，决定颗粒度

为什么不能每次都付？因为一次支付有三种成本，而它们的性质不同：

网络成本：  发起一次链上转账要付的费用
时间成本：  从发起到可以确认的等待时间
复杂度成本：双方各要做多少步、存多少状态

颗粒度的选择就是在这三种成本和信任之间做取舍。 一个具体的判断方法：

如果一次支付的三种成本加起来，超过这次交易金额的某个比例，那就不该在这个颗粒度上支付。

这个比例是多少，取决于你的场景。但有一条是清楚的：当单次交易只有零点几分钱时，几乎任何链上操作都会超过它。 所以在这个量级，答案必然是「不要每次都上链」——不管链变得多便宜，因为服务的单价也会随之下探。

四、协议成为标准，靠的不是技术

这是这一章最重要的一节，因为它决定了开头那个问题的答案。

HTTP 成为标准，不是因为它是当时技术上最好的方案。 一个标准能够普及，历史上通常需要同时满足几个条件：

第二行和第四行是主要障碍，而且它们都不是技术问题。

第二行说的是双边采纳困境：一条支付通道只有在足够多的服务愿意收的时候才有价值，而服务愿意收，通常需要已经有足够多的人用它付。这是一个典型的鸡生蛋问题，第 30 章讲过它的一般形态。

第四行更难。现状不是「没有方案」，是「有一个运行得相当好的方案」。 要替代一个够用的东西，新方案不能只是稍好，它必须在某个维度上好一个数量级，或者能做到旧方案根本做不到的事。

所以真正值得盯的信号不是「又发布了一个协议」，而是三件具体的事：

1. 有多少真实的服务开始接受它？（供给侧，最重要）
2. 它们为什么接受？（拿到了新客户？还是降低了成本？）
3. 有没有出现「不用它就做不成」的场景？

第三件事是最强的信号。 一个新的支付层要普及，多半不是因为它更好，而是因为出现了一类交易在旧方式下根本无法发生——第 33 章里那个「几毛钱汇不出去的人」就是这种场景的样子。

五、这一层会长成什么样

把上面的判断合起来，一个比较可能的形态是：

不是一个统一的新协议取代一切，而是在现有的 HTTP 之上多出一层可选的约定。 支持它的服务在拒绝请求时附上机器可读的付款信息；不支持的服务继续用账户和订阅，两者长期共存。

结算走哪条通道是可替换的。 稳定币是一个自然的候选，因为它同时满足「互联网原生」「无需开户」「可编程」三个条件，但协议本身不该被绑死在任何一条通道上。

计量那一层会先在少数高价值场景标准化，而不是全面铺开。最可能的起点是那些今天根本收不到钱的交易。

而最不可能发生的是：一个技术上最完善的协议因为设计优秀而被普遍采纳。 这在支付领域从来没有发生过。

它叫什么

把整章收成一句话：

HTTP 负责传信息，机器经济还需要一层负责传钱的协议。

这一层的技术难点在计量而不在结算，采纳难点在供给侧而不在需求侧。判断它的进展，看有多少真实服务开始收，而不是看发布了多少规范。

动手

服务名：
计费方式：        （按次 / 按量 / 订阅 / 混合）
标价：
最小充值额：
有没有月费或最低消费：
免费额度：
超出之后怎么算：   （阶梯？翻倍？限速？）

标价成本：             （每次多少钱）
摊销成本：             （月费或最低消费 ÷ 你的实际调用次数）
沉淀成本：             （充值余额里你用不完的部分）
接入成本：             （注册、绑定、读文档花的时间，折算一个数）

一次调用的真实成本 = 以上四项之和 ÷ 调用次数

在每天 ___ 次以下，按次更便宜
在每天 ___ 次以上，订阅更便宜
交叉点在：___

支持信用卡吗：
支持预付费账户吗：
支持任何形式的链上支付吗：
开户需要什么：      （邮箱？公司信息？实名？）
一个软件能自己完成开户吗：

这类调用方是：      （谁，什么场景）
他们的用量大概是：
他们为什么不会成为客户：（价格太高？开不了户？只用一次？）
如果能按次收他们的钱，这块市场大概有多大：
服务商为什么还没做：

支持它我要多花：    （工程投入、财务处理、合规成本）
支持它我能多赚：    （那块今天收不到的钱，估个数）
我最担心的是：
什么条件成立我一定会做：

AI Lab

请比较目前用于机器之间支付的几种协议方案或思路。

对每一种，说明：
1. 它要解决六个问题里的哪几个：报价、付给谁、用什么通道、
   什么时候算完成、怎么证明付过、出问题怎么办。
2. 它在计量这一层是怎么做的。
3. 它目前的成熟度：是一个想法、一份提案、还是已经有真实
   服务在用。
4. 有哪些真实的服务已经接受它——请给出可以核对的例子，
   如果你不确定，明确说「我不确定」。

硬性要求：
- 凡是你给出的规范名称、版本号、状态码或字段名，都要标注
  它来自哪一份文档。不确定的，写「不确定，需要核对官方规范」。
- 不要把提案说成标准。
- 最后单独列一节：这几种方案共同没有解决的问题是什么。

它说的            | 我查到的           | 对不对
版本号            |                    |
状态码            |                    |
字段名            |                    |
接口的调用方式     |                    |

你说的这些方案里，服务商为什么愿意接入？
请对每一种，回答：接入它，服务商是多赚钱了还是多花钱了？
如果是多花钱，那么它靠什么说服服务商？

真实案例

接入一次要多久？        （超过一周，普及会很慢）
有没有「否则做不成」的场景？（这是最强的信号）
有没有一个密集的小圈子先跑通？（比如某一类服务之间）

改一个变量

带走的问题

本章自测