第 33 章 · AI Agent 为什么可能需要 Crypto

一个现实问题

你写了一个软件，让它每天早上替你做一件事：把昨天的行业动态整理成一页报告。

它需要四样东西才能完成这件事：调用三个数据接口、买一份当天的付费简报、租十分钟算力跑一个模型、偶尔请一个真人帮忙确认一条拿不准的信息。

它在第一步就停住了。那个数据接口的页面上写着：请输入信用卡信息。

于是你填了自己的卡。软件跑起来了，很好用。接着问题一个接一个出现：

第一个问题：这张卡是你的。 软件花的每一笔钱都算在你头上，共用你的额度，出现在你的账单上。你无法一眼看出哪几笔是它花的、花在了什么上面。

第二个问题：对方不知道它是谁。 那个数据接口看到的是「一个持卡人在高频调用」。第三天，它的风控把你的卡拦了，因为这个行为模式看起来像盗刷。你打电话解释了二十分钟。

第三个问题：那个付费简报按月订阅。 你的软件一个月只需要读四次，但你只能买整月。你为它没用到的部分付了钱。

第四个问题：那个真人。 他在另一个国家，帮你确认一条信息值几毛钱。你算了一下，把几毛钱汇过去的手续费是这笔钱的几十倍，而且要填一堆表。这件事最后没做成。

第五个问题，也是最大的那个：你现在想跑四十个这样的软件。 每一个都要有自己的预算、自己的花销记录、自己的上限。用一张卡是做不到的，而给四十个软件各开一个账户——在任何一家银行，你都不知道这个申请表该怎么填，因为账户的所有者必须是一个人或者一家公司，而它们两者都不是。

把这五个问题压成一句话：

一个软件想成为花钱的一方，它缺的不是钱，是「一个能被别人识别、能被独立记账、能被限额的身份」。

所以本章的问题：一个没有身份证的软件，怎样开户和付款？

先把结论的一半说在前面，因为这一章最容易被读成一篇宣传：上面五个问题里，有几个今天用现成的传统方案就能解决得不错。 这一章的任务不是论证「Agent 必须用 Crypto」，而是找出那条边界——在什么条件下链上支付确实更合适，在什么条件下它是一个更贵更麻烦的答案。 第二部分和第一部分同样重要。

思想实验

把五个问题浓缩成一个可以算的场景。

你的软件一天要付四千次钱。不是四千美元，是四千次——每调用一次接口付一次，每次的金额是零点几分钱。一天总共花掉大约十几美元。

现在有三种付法。

第一种：刷卡，每次调用付一次。

立刻就不成立。绝大多数卡组织的收费结构里有一个固定的最低费用，它和金额大小无关。当单笔金额只有零点几分钱时，这笔固定费用是交易本身的几十倍甚至几百倍。四千次意味着四千笔固定费用。

这不是「有点贵」，这是结构性不可行。 支付网络的收费结构是为「一笔几十美元、一天几笔」设计的，把它用在「一笔零点几分钱、一天四千笔」上，就像用集装箱货轮送一封信。

第二种：预付费账户。 你先给这个服务商充值一百美元，之后每次调用从余额里扣，月底出一张账单。

这个方案非常好用，而且它是今天绝大多数接口服务的实际做法。 一次充值、四千次扣费，只有一次真正的支付发生，固定费用被摊薄到可以忽略。

它的问题不在费用上，在结构上。你的软件用了六个服务，就要在六个地方各开一个预付费账户、各充一笔钱、各自对账。 每个账户都要注册、要绑定一个法律主体、要各自维护余额。四十个软件乘以六个服务，是两百四十个需要维护的余额。

而且它有一个更隐蔽的性质：这些钱一旦充进去就不再是你的钱，它变成了对方的负债。 服务商停业，这笔余额的处境和第 1 章里老王收据的处境是一样的。

第三种：给这个软件一个链上账户，用稳定币按次付。

它解决的第一件事不是费用，是身份：这个账户本身就是这个软件的身份，不需要向任何人申请，不需要任何人批准，付款方是谁在账本上一目了然。你要跑四十个软件，就是四十个账户，几分钟的事。

它解决的第二件事是边界：每个账户里放多少钱，就是这个软件的预算上限。它花光了就停，不会碰到你其他的钱。

它解决的第三件事是对手方：那个在另一个国家帮忙确认信息的人，或者另一个软件，可以在几分钟内收到这几毛钱，不需要事先建立任何关系。

但它没有解决的事同样重要。 每笔链上转账都要付网络费用，而这个费用在某些链上、某些时刻，同样会大于零点几分钱的交易本身。四千次链上转账也不成立——它和刷卡卡在同一个地方，只是数量级不同。

于是真实的做法长成了第四种形态：一次链上结算，中间四千次用一种轻量的计量方式记账。 这不是链解决了微支付，是链解决了结算，而计量是另一层的事。第 35 章会专门讲中间那一层。

把这个实验的结论摊开：

最后一行值得停一下。「不能追回」在这一章不是一个缺点的抱怨，它是一个需要被认真对待的取舍。 拒付机制是传统支付网络花了几十年建立起来的东西，它保护的正是「付了钱没收到货」这种情况。链上支付把这个保护拿掉了，换来了不需要许可和即时结算。

哪一边更好，取决于你和对方的关系。 这就是下一节要做的判断。

你来决定

你要让四十个软件各自花钱。怎么办？

观察结果

四个选项指向同一个结构。一个东西要成为「能花钱的一方」，它需要五样东西，缺一不可：

第一行和第二行是根源。现代金融体系的开户逻辑建立在「账户必须属于一个法律主体」之上——这不是技术限制，是一套运行了很久、而且运行得相当好的制度安排。它要求有人为每一个账户负责。

而一个软件不是法律主体，今天不是，可预见的将来也不是。

于是只有两条出路：要么把软件挂在某个人或公司名下（前两个选项），要么找一个不要求法律主体就能开户的账本（第三个选项）。

第二条出路正是公链的一个基本性质。第 5 章讲过这件事：一个地址不需要任何人批准就能创建，账本不检查你是谁。 这个性质一直被当成「抗审查」来讨论，而在 Agent 的语境里，它变成了一件更平淡也更有用的事——它是目前唯一一种软件可以自己持有的账户。

把这一节收成一句话：

Blockchain 给 Agent 提供了身份、钱包、支付、结算与可审计性。

但这句话成立的前提是场景对。场景不对时，它提供的是同样这五样东西的一个更贵的版本。

建立模型

一、四个条件，决定用哪条通道

判断一笔支付该走传统渠道还是链上，只看四个条件。这张表是这一章最该带走的东西，而且它两边的格子一样重要：

四项里占三项以上，答案基本确定。

这张表左边那一列不是陪衬。在大额、低频、双方互相信任的场景里，传统渠道在几乎每一个维度上都更好：费用作为比例更低、有争议处理机制、有法律追索、有客服、对方的财务系统天然支持、不需要任何新的工程投入。

一个具体的例子：你的公司每个月向一家云服务商支付一笔可观的费用。这笔支付不该上链。双方有合同，金额大，一个月一次，对方是一家有完整财务流程的公司，出了问题可以打电话。把它换成链上转账，你会失去争议机制和对账便利，换来的只有「更快到账」——而这件事在这个场景里根本不重要。

这个判断能力比「支持链上支付」这个立场重要得多。 一个说不清什么时候不该用链的人，也说不清什么时候该用。

二、Agent 要花钱的五类地方

一个软件在运行中会为五类东西付费。它们的性质差别很大：

第四类值得单独说，因为它是今天几乎完全空白的一块。让一个软件向散布在世界各地的个人，为一次几毛钱的微小劳动付款——这件事在传统渠道里不是贵，是走不通：手续费、汇款表格、收款方需要有银行账户、跨境合规。

这一类恰好落在那四个条件的正中间：金额极小、对手方是没有对公账户的个人、双方互不认识、跨境。如果链上支付会有一个真正的杀手场景，它可能在这里，而不是在「AI 自动交易」那些更吸引眼球的地方。

三、身份不是一件事，是三件

「给 Agent 一个身份」这句话常常被含糊地使用。拆开看它是三个独立的问题：

第三行那个区别在 Agent 的场景里变得很实际：如果一个软件的钥匙泄露了，链上没有任何办法区分「它做的」和「拿到钥匙的人做的」。 传统金融有一整套机制处理这种情况（挂失、冻结、争议、赔付），链上的对应方案要靠事前的权限设计。第 34 章整章都在处理这件事。

四、可审计性：一个被低估的好处

前面四样（身份、钱包、支付、结算）都比较直观。第五样最容易被略过，但在多 Agent 的场景里它可能是最有用的：

每一笔花销，在什么时间、从哪个地址、付给了谁、多少钱，全部在一个公共账本上，不需要任何人配合就能查。

这件事的价值在于它是天然的，不需要你搭建任何系统。四十个软件的四十份完整开销记录，不需要对账，不需要向任何服务商索取账单，不需要相信任何人的记录是准确的。

它的另一面同样要说清楚：账本对所有人公开。 你的软件花了多少钱、买了什么服务、和谁交易过，别人也能看到。第 1 章里那个「透明和隐私第一次发生冲突」的问题，在这里再次出现，而且更尖锐——一个企业未必希望自己的算力采购规模被任何人统计。

五、认真写出反方：什么时候不该用链上支付

这一节和前面四节同等重要。下面每一条都是链上支付的真实劣势，不是可以用「未来会改善」绕过去的。

一、双方互相信任，有长期关系。 这时候你需要的不是无需信任的结算，是灵活的账期、可协商的争议处理和一张对账单。链上支付在这三件事上全都更差。

二、金额大、频率低。 固定费用的优势消失了，而不可撤销的劣势被放大了。一笔大额转账打错地址，损失是全部；同样的错误在银行系统里通常可以追回。

三、需要争议处理。 「付了钱没收到货」是一个极其常见的情况。卡组织的拒付机制、平台的担保交易、法律上的追索——这些机制存在是因为它们真的被需要。链上支付默认没有任何一个。

四、对手方是一家有完整财务流程的公司。 他们的系统需要发票、需要合同编号、需要按会计期间入账。给他们转一笔稳定币，制造的工作量比省下的多。

五、你没有能力管理私钥。 这一条最现实。一个软件持有的钥匙如果泄露，钱在几秒内就没了，而且没有任何补救。第 5 章讲过这个代价，在 Agent 场景里它被乘上了软件数量。

六、合规要求明确，而链上方案的合规路径不清楚。 在受监管的业务里，「这笔钱付给了一个匿名地址」是一个真实的问题，不是一个可以推给未来的问题。

把正反两面合起来，判断就很简单了：

链上支付不是一个更好的支付方式，它是一个在特定条件下唯一可行的支付方式。

那些条件是：金额极小、频率极高、双方互不认识、对手方可能不是法律主体、需要程序化处理、跨境。 不满足这些条件时，传统渠道通常更好——而且是明显更好。

它叫什么

把整章收成一句话：

Blockchain 给 Agent 提供了身份、钱包、支付、结算与可审计性——在金额小、频率高、双方陌生、对手方可能不是法律主体的场景里。

场景不满足时，传统渠道在争议处理、费用比例和对接成本上通常明显更好。

动手

算力与模型调用：
数据与接口：
内容与版权：
人的劳动：
链上操作本身：

单次金额大约：      （精确到数量级就够）
一天大约几次：
对手方是谁：        （一家公司 / 一个个人 / 一个软件 / 不确定）
今天怎么付：        （信用卡 / 预付费账户 / 订阅 / 付不了）

□ 金额极小（固定费用会成为主要成本）
□ 频率极高（一天几百次以上）
□ 双方互不认识（没有合同，没有长期关系）
□ 对手方不是一家有对公账户的公司

最小充值金额是多少：
有没有最低消费或月费：
支持哪些付款方式：

这件事是：              （比如向一个国外的个人支付几毛钱）
今天为什么做不成：      （手续费 / 没有收款账户 / 合规 / 都有）
链上能不能解决：        （具体到哪一步）
链上解决不了的部分：    （必须写，这一行是这一步的重点）
如果不做这件事，我的任务会怎样：

失去的可能是：发票 / 合同关系 / 争议处理 / 对方的财务系统支持 /
              客服 / 追回的可能 / 合规上的清晰路径

AI Lab

请论证这个命题：AI Agent 的经济活动必须使用链上支付。

要求：
1. 给出 6 条理由，每条说明它依赖链的哪一个具体性质。
2. 每一条都要说明：这个性质有没有非链上的替代方案，
   如果有，为什么替代方案不够。
3. 不要编造任何协议名称、版本号、接口规范或字段名。
   描述做法即可，不要给出不存在的技术细节。
4. 不要引用任何具体的市场规模数字或增长预测。
5. 最后单独列一节：这个命题在什么条件下不成立。

场景：              （具体到金额、频率、双方关系）
用传统渠道更好，因为：（具体到某一个机制）
换成链上会失去：     （具体到某一样东西）

□ 大额、低频、有合同的企业间付款
□ 需要发票和会计入账的支出
□ 可能出现「付了钱没收到货」的交易
□ 对手方是一家有完整财务流程的公司
□ 私钥管理能力不足的团队
□ 合规要求明确的受监管业务

真正的分歧点 1：
  正方说：
  反方说：
  要判断谁对，需要知道：

真实案例

改一个变量

带走的问题

本章自测