AI Agent 不只是需要一只钱包

最近读到 Christian Crowley 等六位作者在 a16z crypto 发表的 《The missing infrastructure for AI agents: 5 ways blockchains can help》^[1]。他们把 AI Agent 的身份、治理、支付、信任和用户控制放在一起讨论。我尤其认同，问题不能被缩成“让 Agent 能付款”这一件事。

文章有两句很直接的话，也是我想回应它的原因：

“The bottleneck for the agent economy is now identity, not intelligence.”

（译：Agent 经济的瓶颈，如今是身份，而不是智能。）

“Scale without verification is a liability that builds over time.”

（译：没有核验的规模化，是一笔会随着时间不断累积的负债。）

我大体认同这两个判断。当 Agent 不再只是聊天窗口里的助手，而是开始代表人和组织调用服务、花钱、交付结果时，旧互联网确实缺少一些基础设施。但我还想把重点往前挪一步。AI Agent 不只是需要一只钱包。

ArcBlock 长期在去中心化身份、Blockchain 和应用基础设施上工作。

支付是最容易看见的场景。一个 Agent 调用 API、买一份数据、完成一项服务，然后自动付款，这当然很重要。可在它付款之前，系统应该先能回答几个更基础的问题：它是谁，代表谁，谁授予了它权限，权限到什么范围，出现异常后谁能核对发生过什么。没有这些问题的答案，钱包只是一把被交给程序的钥匙。

我认同五个问题，但它们其实是一条责任链

Crowley 等六位作者把身份、治理、机器支付、可验证信任和用户控制分开讲，这样很有帮助。对我来说，在真正运行的 Agent 系统里，它们往往不是五个独立的产品类别，而是一条连续的责任链。

Agent 先要有身份，别人才能知道它是谁。它有了身份，才谈得上谁能够授权它。授权有了范围，才知道它能花多少钱、能调用哪些服务、能不能代表一个团队签发某种结果。发生了操作之后，记录才有办法被核验、对账和追溯。最后，用户才能判断自己究竟是在使用一个 Agent，还是把自己交给了一个不透明的平台。

ArcBlock 的起点和这里有天然的连续性。我们长期采用 DID，Decentralized Identifier，可以把它理解为不依赖某个平台临时账号、可持续沿用且可被验证的身份标识。核心不是给每个对象多贴一个加密标签，而是让人、设备和未来的 Agent 都能拥有这样的身份。DID Connect 是围绕身份、登录和签名交互的基础；DID Spaces 则是用户的数据空间。它们都不是为了今天的 Agent 临时拼出来的概念，而是在处理身份、授权和数据不应天然附属于某一个平台或某一次应用安装的问题。

这也是我不太喜欢“Blockchain 能不能让 Agent 付款”这种问法的原因。它把最容易演示的一步，当成了最难的一步。真正难的是委托。

小额热钱包能限制损失，却不能解释授权

今天的机器支付协议，比如 x402，解决了一件很实际的事：让服务请求和付款可以在同一条机器流程里完成。小额余额、虚拟卡或受限 wallet 也都有价值。这里的 hot wallet 指连接在在线程序上的钱包或账户，它们至少能把最坏情况下的损失压小。

但它们不自动回答：这个 Agent 为什么能花这笔钱？它受谁指派？允许它花在什么服务上？预算、时间、次数和撤销条件在哪里？如果一个团队发现异常消耗，能不能沿着证据找到是哪个授权、哪个 Agent、哪次调用出了问题？

这不是 Agent 出现后才有的问题。我们在做去中心化应用时，早就遇到过类似的矛盾：不能要求用户为每一笔自动化交易都重新拿出钱包签名，也不能把用户的主私钥长期放在在线服务上，让程序自行决定一切。前者无法自动化，后者很难谈安全边界。

因此，我们长期在思考的不是“怎样让程序代替用户拿着钱”，而是怎样把身份、委托范围、额度、规则和责任链拆开表达。DID 可以提供身份与验证关系；委托或能力模型，也就是说明一份凭据具体能做什么、不能做什么的规则，负责定义范围与约束；Verifiable Credentials，或 VC，可以作为带签名、可独立核验的证据载体。这样，Agent 即使需要使用自己的受限凭据，也不必把用户的主私钥托管给一个常驻在线服务。

我并不认为这会让风险凭空消失。它只把问题从“某个程序拿着一把钥匙”变成“谁在什么条件下交出了哪一把受限的钥匙”。后者至少可以被讨论、检查和撤回。

账本的价值，往往在付款之后才开始显现

PaymentKit 是 ArcBlock 已有的支付抽象层。支付本来就不是新问题，Agent 让它变得更重要，是因为一笔付款会拉出更多问题。

想象一个团队同时使用多种 AI 服务。不同的 Agent 在调用外部工具，员工也在使用 API key，最后账单又从另一个系统里出来。某天金额不对，你看到的通常只是几份互相独立的记录：供应商账单、信用卡流水、内部日志。到底是服务方计费出了问题、某个 key 被滥用、员工超出了权限，还是内部系统没有把授权传对，往往很难说清。

我不认为答案是把所有日志都写到 public chain。那既不必要，也不合理。我们更接近的判断是：记录应该随着信任边界分层。

Receipt、invoice、服务交付、第三方服务调用，以及谁授权、谁使用、如何消耗等信息，都可以用 VC 这类可验证数据格式表达，再按场景保存在合适的账本层。这里的 ARC 是 Agentic Realm Computer，也就是 ArcBlock 正在构建的面向人和 Agent 的运行时与计算架构。这是我们希望 ARC 逐步承接的方向，不是说完整的链侧接入、链上结算和多层流程今天已经全部交付。

这样的记录也不会自动证明一个服务做得对，更不会自动替人承担责任。它的作用更朴素：当一个 Agent 世界开始复杂到人不可能逐笔盯住时，至少让重要动作留下能被适当一方验证的证据。

链应该是证据边界，不是每个动作的目的地

a16z 文章提到，随着自动化执行变得便宜，验证会变得昂贵。我同意。人不可能靠所谓 human in the loop，也就是由人逐笔介入复核，去审查成千上万个 Agent 的每次调用。

不过，Blockchain 在这里的价值不该被说成“它产生信任”。Blockchain 可以提供持久证据、共享账本和可执行约束；正确性、服务质量、争议处理和最终责任，仍然需要系统设计和人来承担。把这两件事混在一起，反而会把讨论说得太轻松。

所以，不是每个 Agent 都必须上链。如果一个 Agent 只是在本地整理一份草稿，最简单的工具通常就是最好的工具。但当它代表用户或组织跨系统行动，涉及钱、权限、可验证的交付或多方对账时，身份、委托和记录就不该只剩在某一家平台的后台里。

这也是我从那篇文章里读到、但想补上的一句话：支付只是入口。对 Agent 更根本的基础设施，是一条可验证的委托链。它要让我们回答清楚：谁在行动，谁授权了它，它能做什么，出了问题后又能如何核对。

参考