AI Agent Economy Infrastructure in Progress: X402 Protocol and the PayFi Revolution

概况介绍：X402 的提出背景

2025 年春天，一个看似不起眼的标准悄然诞生。由 Coinbase 和 Cloudflare 等机构联合推出的 X402 支付触发协议，最初旨在让机器能够通过扩展 HTTP“402 Payment Required”状态码，实现无需人工确认的即时支付请求与响应机制。这个协议的提出并非凭空构想，而是对一个正在快速成形的现实需求作出的回应——AI 代理（agent）正在进入实际经济活动的前沿。

到了 2025 年下半年，随着虚拟代理生态的不断成熟，X402 很快从概念过渡到真实运行。到 2025 年底，X402 协议已经经过升级，V2 版本支持多链并行、会话机制等，并被主流基础设施如 Google 的 Agent Payments Protocol（AP2）集成，帮助代理在链上和链下系统之间桥接支付行为。

进入 2026 年，围绕代理自主经济行为的讨论和实践骤然升温。以 OpenClaw 为代表的一批 AI Agent 平台和框架掀起了“代理热潮”：开发者们用它构建自治任务执行者、内容生产者、自动化服务者，甚至试图让这些智能体自主赚取报酬、支付费用和购买服务。这一现象不仅引起创业者和开发社区的兴趣，还被各大生态纳入实际激励体系，例如 AIsa 与 OpenClaw Demo Day 的合作，推动 Agent 支付基础设施的落地。

然而，这些实践同时暴露了一个深层次的问题：现有的传统支付体系是为人类用户设计的——每笔交易需要身份验证、交互确认、权限审批和人机对话。这些流程在高频、按需、毫秒级触发的代理支付场景下表现出明显不适应，严重制约了代理协作、自动采购、微支付经济的规模化发展。为了满足这种自动化、精准和高频的交易需求，仅仅调用现有的支付 API 已显不足。传统系统强调的是人为控制和责任归属，而代理追求的是在授权边界内自由、安全地自动完成支付。

X402 的引入恰好切中了这一矛盾。它不是一个简单的结算工具或 API，而是一个支付触发协议，将支付能力嵌入请求流程，使机器能够在授权范围内以可验证的方式即时发起支付并完成操作。协议本身不维护账户或处理身份，而是通过一次性、与请求绑定的支付能力证明，让自动化系统能够安全、高效、无需人工介入地进行微支付。这种设计不仅弥合了传统支付体系与机器自主支付之间的鸿沟，还为正在形成的 Agent 经济提供了底层支付语义和基础设施支持。

一、技术架构

1.1 Agent 支付的基础逻辑

1.1.1 支付主体为什么从"人"转向"机器"

AI Agent 支付并非"新支付工具"，而是支付决策主体发生变化后的系统性重构问题。其关键不在于结算方式，而在于授权如何表达、执行如何约束、风险如何回溯。

在传统支付中，每一笔交易的发起都经过人的确认——点击按钮、输入密码、扫码授权。但当 AI Agent 成为服务调用的主体时，这一前提不再成立。Agent 需要在无人干预的情况下，高频、自主地完成 API 调用、数据采购、算力租赁等小额资源消费。这类交易的特征是：频次高、金额小、长尾分散、实时性要求强。

支付主体从人切换到机器，随之带来一系列新风险：Agent 可能在无明确指令下触发支付（不可预期触发）；Agent 被赋予过大权限导致资金失控（权限滥用）；出现问题时无法回溯到具体的授权来源与决策逻辑（追责困难）；交易记录缺乏结构化存证，难以进行事后审计（审计缺失）。这些风险决定了：面向 Agent 的支付系统，不能简单复用传统支付架构，而必须从授权、执行、审计三个维度进行系统性重构。

1.1.2 为什么必须拆分"授权"与"执行"

在传统支付体系中，"是否允许支付"与"如何完成支付"通常由同一系统处理。而在 AI Agent 场景下，这一方式不再成立。当前较为合理、且已在协议层面显现共识的路径，是将 Agent 支付拆解为两条相互独立但可组合的逻辑链：

• 授权链（Authorization Path）：解决"Agent 是否被允许代表用户支付"——包括授权的来源、边界、有效期和撤销机制。

• 执行链（Execution Path）：解决"一次具体支付如何完成并触发资源交付"——包括支付的发起、校验、结算和证明生成。

拆分的核心原因在于：如果 Agent 同时承担"授权来源"和"执行裁量"两种角色，系统风险将不可控。授权来源必须始终来自用户（资金所有者），而执行则可以委托给 Agent 在严格约束下完成。这种分离确保了：即使 Agent 行为异常，损失也被限定在授权边界之内；任何支付都可以回溯到一个明确的人类授权决策。

从系统设计角度，AI Agent 支付至少涉及五类角色，各自职责边界必须清晰：

• 用户（资金所有者）：提供初始授权与最终责任归属；

• AI Agent（执行主体）：在授权约束下发起支付请求；

• 商户/资源方：提供定价、校验支付并决定是否放行资源；

• 授权/信任层：表达并验证"谁在什么条件下可以支付"；

• 支付执行层：完成一次具体、可验证、可结算的支付行为。

1.1.3 一个标准化 Agent 支付闭环如何形成

一笔标准化的 AI Agent 支付遵循"授权前置、条件触发、自主执行"的原则，整个流程可以分为四个阶段：

授权期：用户向 Agent 颁发包含额度、对象及期限的受限授权（Limited Mandate），确立资金支出的合法性边界。授权声明需上链或以可验证方式存储。

请求期：Agent 向资源方发起请求，资源方返回机器可解析的支付指令（包含金额、币种、收款地址、过期时间等），明确交易标的与支付对价。

执行期：Agent 在内部校验该请求符合授权边界与风控策略后，自动完成支付并生成一次性、不可重放的支付证明。

清算期：资源方验证支付证明的真实性与唯一性，确认收款后放行资源，并记录交易以供审计。

这四个阶段构成了一个"条件支付—条件交付"的自动化闭环。其工程意义在于：将"支付意图"与"执行动作"解耦，使 Agent 在不依赖主观信任的前提下，高效完成高频、小额的资源采购。

AI Agent 支付的主要风险并不集中在转账环节，而是集中在三个方面：授权风险（Agent 是否被过度授权、授权是否可撤销可审计、是否存在语义模糊空间）；执行完整性风险（支付是否与具体资源请求强绑定、是否存在重放或并发滥用）；系统性与合规风险（是否能形成完整证据链、是否支持事后对账与合规审查）。

1.1.4 判断一套系统是否可商用的标准

一个可规模化的 AI Agent 支付系统，至少应满足以下约束条件：

安全维度：所有支付均可回溯至明确授权来源；支付与单一资源请求一一对应；支付凭证不可复用、不可转移；执行层不依赖主观信任假设；全流程事件可审计、可复现。授权必须可撤销、可限额。

成本维度：交易摩擦足够低，能够支撑高频小额场景；集成成本对开发者、商户和平台友好；不要求复杂的前置账户体系或订阅关系。

生态维度：与既有支付网络和结算体系具备兼容性；支持多链、多资产、多 Facilitator 的开放竞争格局；协议标准化程度足以支撑互操作。

合规维度：责任主体清晰——谁授权、谁执行、谁承担最终责任，均有链上或结构化记录；支持 KYC/AML、跨境制裁、KYT 等监管检查；争议处理路径明确，具备纠纷仲裁的证据基础。

是否满足这些条件，是判断不同协议优劣的核心标准，也是后续评估 x402 及其补充机制的出发点。

1.2 x402 的定位、机制与信任补充

1.2.1 x402 到底解决什么，不解决什么

x402 的核心定位是支付触发协议——它位于 HTTP API 与结算网络之间，扮演信息传递桥梁的角色。x402 不是支付系统，它解决的是一个精确的问题：如何将"支付"嵌入到"HTTP 请求—资源交付"的链路中，形成请求级付费的标准化骨架。

具体而言，x402 解决了以下问题：

• 为 HTTP 402 状态码补充机器可理解、可执行、可验证的最小信息集合；

• 在不破坏 HTTP 无状态特性的前提下，完成"请求—支付—交付"的闭环；

• 让支付成为一种请求附带的能力证明，而非前置的账户关系或订阅绑定。

同样重要的是理解 x402不解决什么：

• 不解决身份与授权的全套信任问题——它不关心"你是谁"，只关心"这次请求是否已付费"；

• 不处理所有支付网络与清结算——它不绑定特定链或支付通道，结算由外部网络完成；

• 不覆盖复杂商业关系——它不适合需要长期客户关系管理或复杂计费策略的场景；

• 不解决监管合规与争议仲裁——这些需要由上层业务系统或补充协议承担。

这种克制的定位，使 x402 避免了"设计过度、落地困难"的陷阱。它承认自己不是通用支付系统，接受外部结算网络的存在，不追求覆盖所有商业关系。也正因如此，它更强调"面向机器"——如果交互对象是人类用户，完全可以通过页面跳转、二维码或钱包弹窗解决支付问题；只有在调用方是程序时，协议级表达才显得必要。

与既有支付模型的差异也值得简要对比：Web2 支付通常发生在调用之前（订阅/预充值），Web3 支付由用户主动发起交易，x402 则把支付嵌入请求流程、由服务端触发。Web2 维护大量账户状态，Web3 把状态放在链上，x402 尝试把状态压缩到单次请求中。从自动化角度看，x402 的优势非常明显——它不需要交互式授权，也不要求持有长期私钥，只要 Client 能执行支付并附带证明，调用就可以完成。

1.2.2 从 HTTP 402 到请求级支付

HTTP 402（Payment Required）最早在 RFC 2616 中被保留，但并未定义任何可执行语义。HTTP 设计之初刻意回避支付机制，把它留给了更高层的系统处理。历史上也有过尝试——LSAT（Lightning Service Authentication Token）由 Lightning Labs 在 2019 年提出，将 HTTP 402 与 Lightning 发票绑定，通过支付发票换取 Bearer Token。LSAT 证明了 402 的可用性，但暴露了几个问题：支付完成后系统退化为会话型 Token；服务端需要维护 Token 与权限映射；支付与请求解耦，难以做到"一次请求一次证明"。

x402 明确放弃了"支付换身份"的路径，而是把支付结果本身作为一次性能力证明。其核心设计约束是：不引入会话、不维护用户账户、不要求服务端记住"谁已经付过钱"。在这种约束下，支付被重新定义为请求附带的能力证明——只要证明可验证、不可伪造、可绑定请求，服务端就可以在完全无状态的前提下放行。

一次完整的 x402 支付执行路径如下：

a. Client/Agent 发起 HTTP 请求，访问需要付费的资源端点；

b. 服务端返回 402 响应，附带机器可解析的支付要求（金额、币种、收款地址、网络、过期时间、证明类型等），这些字段让 Client 可以在无需人工介入的情况下完成决策；

c. Agent 在授权边界内完成支付，生成支付证明；

d. Agent 携带支付证明重新发起请求；

e. 服务端校验证明的真实性与唯一性，通过后放行资源并记录审计。

关键在于：支付不是前置步骤，而是请求失败后的分支路径。这一设计使 x402 天然适配无状态的 HTTP 架构。

x402 的协议演进也值得关注。早期实验实现面临互操作性问题——支付指令格式各异、证明验证逻辑高度定制、Facilitator 与 Server 强耦合。V2 版本通过标准化支付指令格式、引入独立的 Facilitator 角色、将结算层抽象为可替换后端，解决了这些碎片化问题。V2 的真实工程意义在于证明了：支付可以作为协议状态，而不是业务前置条件。这对 Agent 自动调用 API、跨组织无账户关系的服务访问、按次即时结算等场景尤为重要——在这些场景中，引入账户体系本身就是一种摩擦。

工程实践中，x402 无法"优雅地解决"所有边界情况，例如支付成功但请求最终失败、Client 重放请求、Facilitator 短暂不可用。类似问题在 Lightning、Rollup bridge、Webhook 体系中早已存在，最终都被交由实现层处理。x402 选择不在协议层假装这些复杂性不存在。

1.2.3 x402 为什么需要身份/信任补充层

x402 解决了"付费动作如何嵌入请求"，但它有一个天然短板：不解决"谁是可信的 Agent""谁授权了它""如何撤销授权"这些身份与信任问题。 x402 关心的是"这次请求是否已付费"，而不是"你是谁"或"你是否被授权"。

在简单场景下，这种设计是足够的——Agent 有钱就能付，付了就能用。但在规模化商业场景中，仅靠"能付钱"远远不够。商户需要知道对手方是否可信、是否有恶意历史；用户需要确保 Agent 不会超出授权边界；监管需要能够追溯交易的完整身份链条。

因此，x402 需要补充以下能力：

• 身份注册与验证：Agent 需要有链上可查的身份标识，商户和 Facilitator 可以据此判断是否接受请求；

• 授权边界的结构化表达：不仅是"有钱"，还需要明确"谁授权、对什么资源、在什么条件下、有效期多久"；

• 执行代理的职责界定：在 Agent 与商户之间，需要一个可信的中间执行层（Facilitator），承担身份校验、证明生成和风控职责；

• 可追责与可审计的证据基础：交易记录需要链上锚定，支持事后纠纷仲裁。

这些能力正是 ERC-8004 等机制试图补充的领域。

1.2.4 ERC-8004 等机制带来了什么补充

ERC-8004，全称"Trustless Agents"（无信任代理），是以太坊于 2025 年 8 月提出、2026 年 1 月正式上线主网的标准。它不修改以太坊核心，而是通过三个链上注册表来扩展 Agent 间的协议能力：

• IdentityRegistry（身份注册表）：为 Agent 提供链上身份 NFT 标识，支持身份有效性查询、黑名单与冻结机制；

• ReputationRegistry（声誉注册表）：基于历史交易表现为 Agent 提供多维度聚合评分，评分规则透明、确定性更新；

• ValidationRegistry（验证注册表）：存储执行证明（Merkle 证明、交易哈希、时间戳等），确保交易记录不可篡改、可供审计与纠纷仲裁。

ERC-8004 与 x402 的结合，构建了一个"身份证明+执行证明"的二元信任结构：

身份证明侧（ERC-8004 负责）：解决"这个 Agent 是谁、是否被授权、可信度如何、历史表现怎样"。授权链在引入 ERC-8004 后得到显著强化——授权声明不仅包含金额、商户白名单、有效期等传统约束，还可以集成声誉阈值（只有评分达标的 Agent 才能执行支付）、身份白名单检查、异常行为检测等机制。

执行证明侧（x402+Facilitator 负责）：解决"这笔交易是否真实发生、执行过程是否合规、结果是否可验证"。执行链的核心目标——原子性、可验证性、一次性、可审计性——通过密码学签名、链上交易和 Merkle 树等手段实现。

在这一融合架构中，Facilitator 的角色从可选的支付路由方升级为系统级的执行代理，承担三重职责：

第一，身份验证枢纽。 Facilitator 在接收 Agent 支付请求时，首先查询 ERC-8004 IdentityRegistry 验证 Agent 身份 NFT 是否有效，检查是否被列入黑名单或冻结，并查询 ReputationRegistry 评估声誉评分是否达到授权声明中设定的阈值。对于声誉较低的 Agent，系统可要求额外审核或增加担保。

第二，执行证明生成方。 通过身份验证后，Facilitator 承担将 Agent 的离链支付签名转化为链上交易的关键任务——包括智能合约交互、必要时垫付 Gas 费用、处理交易重试以确保最终执行的原子性。更重要的是，Facilitator 在此过程中生成可验证的执行证明（包含 Merkle 路径、交易时间戳、Nonce 等），并上传至 ERC-8004 的 ValidationRegistry，确保交易历史不可篡改。

第三，风险控制与合规锚点。 Facilitator 是系统中唯一能够在执行期进行实时干预的参与方——动态风险评分（是否超出累计限额、Agent 是否有异常行为、是否触发 AML/CFT 规则）、条件执行的严格检查、以及在特定条件下暂停或冻结交易的权限。所有执行决策与交易日志并行记录，确保透明性。

市场允许多个 Facilitator 共存并竞争，前提是都必须遵守同一套 ERC-8004 验证规范和合规标准，从而保障系统的去中心化韧性与互操作性。如果某个 Facilitator 的审计记录显示系统性偏差或不当行为，其将面临交易量下降甚至被排除出生态的风险，形成经济与声誉制衡。

引入 ERC-8004 后，原有四阶段支付流程升级为"双证明"模式——在授权期、请求期、执行期、清算期的每个阶段，都对"身份证明"与"执行证明"进行持续的链上可验证关联。x402 原有的三类风险架构也得到强化：授权风险增加了声誉分数门槛与异常行为检测；执行风险增加了 Merkle 证明的标准化验证（支持 ZK、TEE 等多种验证模式）；系统风险增加了跨链验证机制与链上黑名单同步。

需要指出的是，x402 与 Google AP2 并非竞争关系，而是解决同一问题的不同层面——一个解决"如何执行一次支付"，一个解决"是否被允许执行支付"。二者在支付执行与授权方面互为补充，构成完整的支付体系基础。

1.2.5 这套体系的边界与局限

尽管 x402+ERC-8004 的组合构建了一个相对完整的"身份+执行"双层信任体系，但在实际落地中仍然存在明确的边界与局限：

依赖前提方面：商户侧需要改造以支持 402 响应和支付证明校验，这对存量商户构成集成门槛；依赖稳定币及链上结算网络的可得性与稳定性；链上链下证明的可信度桥接仍是开放问题。

尚未覆盖的领域：监管合规在不同法域存在显著差异，协议层无法统一解决；复杂退款、拒付、争议仲裁等机制尚未标准化；涉及多方分润、阶梯计价、捆绑销售等复杂商业关系时，当前框架表达力不足；隐私保护方面，链上交易的透明性与商业隐私需求之间存在张力。

Facilitator 的中心化倾向：虽然协议设计允许多 Facilitator 竞争，但实践中可能出现少数 Facilitator 主导市场的局面——这与 Infura、Alchemy 在基础设施层的集中化趋势类似。x402 对此的处理是诚实标注信任边界，而非假装不存在信任假设。

适用场景的优先级：当前框架最适合的场景是高频、小额、按次计费的 API 和资源调用——如 Agent 自动采购数据、调用模型推理、租用算力等。对于需要长期客户关系、复杂计费或高价值单笔交易的场景，x402 的适配性有限，需要更多上层业务逻辑的补充。

从工程演进的角度看，x402+ERC-8004 提供的是一个最小可用的 Agent 支付骨架——它解决了"支付如何嵌入请求""身份如何验证""执行如何审计"这些基础问题，为上层商业应用提供了可组合的协议基础。但从骨架到完整的商业化支付体系，仍需要在合规、争议处理、商业关系建模等维度持续建设。

二、商业前景/应用场景的抽象概括：PayFi 基础设施与微支付

2.1API 经济的重构：从账户驱动到请求驱动

在传统 API 经济中，订阅制与预充值模式构成了主要的商业基础，其核心在于通过账户体系对未来调用行为进行预先定价与集中结算。然而，这一模式隐含着对调用频率与规模的稳定预期，与 AI Agent 所呈现出的高频、离散、按需调用特征存在结构性不匹配。随着调用行为被拆解为大量原子化请求，传统基于账户余额的计费方式不仅难以精确反映资源使用情况，也在客观上增加了接入与管理成本。

x402 所引入的请求级支付机制，通过将支付嵌入 HTTP 请求流程，使每一次调用均可独立完成定价与结算，从而实现“请求—支付—重试”的闭环。这一机制使 API 从“持续性服务关系”转变为“即时可获取能力”，弱化了账户在交易中的核心地位，并将计费逻辑从周期维度压缩至单次请求层级。由此，API 经济开始由“账户驱动”向“请求驱动”转型，服务调用与支付行为在系统层面实现了更高程度的耦合。

2.2 资源市场的演进：即时结算与信用解耦

在算力与去中心化基础设施（DePIN）场景中，资源供给长期依赖于平台化调度与预付费机制，其背后本质是一种以信用关系为基础的资源分配模式。资源使用方通常需要提前锁定预算或建立信用额度，而资源提供方则需承担一定的履约与回款风险。这种结构在面对短周期、动态化的任务需求时，往往表现出效率不足与灵活性受限的问题。

请求级支付机制通过将资源调用与支付行为进行强绑定，使“使用即结算”成为可实现的系统特征。在这一框架下，资源的获取不再依赖长期合约或信用背书，而是基于即时支付完成价值交换。这种从“先使用后结算”向“边使用边结算”的转变，在本质上实现了对信用关系的部分替代，使资源市场能够在更低信任成本下运行，并推动基础设施供给从中心化平台向更具流动性的市场化形态演进。

2.3 内容与数据服务：微支付驱动的价值重估

内容与数据产业的既有变现模式主要依赖广告与订阅，两者分别对应流量规模与用户粘性的不同路径。然而，这些模式均以“用户持续关系”为前提，与 AI Agent 在信息获取过程中所呈现的“单次访问”特征存在偏离。Agent 更倾向于在多个数据源之间进行即时选择，其需求往往聚焦于特定信息单元，而非长期服务绑定。

在此背景下，请求级支付所支持的微支付机制，为内容与数据服务提供了一种更加细粒度的定价方式。数据访问行为得以从整体订阅中剥离，转化为可独立计价与结算的最小单元，从而使长尾内容具备直接变现能力。与此同时，数据不再仅作为平台内部资源存在，而逐渐演化为可被调用、交易与组合的标准化要素，其经济价值开始通过支付行为在系统中被持续刻画与显性化。

2.4 PayFi 机制：支付行为的金融属性内生化

在上述应用演进的基础上，支付行为本身的属性也在发生变化。传统金融体系中，支付主要承担价值转移功能，其金融属性依附于账户结构与中介机构；而在请求级支付框架下，每一次交易均天然包含交易对象、价格、时间与执行结果等结构化信息，并以可验证形式被记录。这使支付不再仅是交易的结果表达，而逐渐成为金融信息生成的基础过程。

高频、小额且与具体行为强绑定的支付数据，为信用评估与风险定价提供了新的数据来源，使支付体系本身具备了生成金融信用的能力。在这一意义上，“Payment is Finance”不再仅是一种概念性表述，而体现为一种可操作的系统特征：支付既是价值交换的实现机制，也是信用体系的底层输入。由此，金融不再完全建立在账户之上，而开始部分建立在持续发生的支付行为之上。

三、项目实践——基于 Tron 的 x402 高频支付原型

3.1 Why Tron

在实际落地中，x402 对支付网络有很高要求：一笔支付必须够快、够轻、够便宜。否则，一次请求还没处理完，就先被确认时间和手续费拖慢了，“按次付费”这套模式就很难真正跑起来。

从这个角度看，Tron 比较适合 x402 的实践部署。因为对 Agent 来说，支付不是一个单独的动作，而是任务流程中的一环。真正重要的，不只是钱能不能转过去，而是整个流程能不能顺畅完成：服务端返回 402、客户端自动支付、再次发起请求、服务端验证后放行资源。只有这个闭环能在很短时间内稳定运行，Agent 才能高频调用付费服务。Tron 在速度、成本和并发能力上的特点，正好更符合这种需求。 图 1 Tron 对 x402 高频支付闭环的适配逻辑

3.2 从 ERC-8004 身份到 x402 执行证明

“身份”和“支付”不是两套分开的功能，而是 Agent 完成一次商业行为时前后相连的两个步骤。先要解决“这个 Agent 是谁、有没有权限、最多能花多少钱”，再解决“这一次请求有没有付钱、服务能不能继续提供”。前者主要由 ERC-8004 来处理，后者主要由 x402 来完成，所以它们不是简单并排放在一起，而是组成了一条从身份确认到资源放行的完整流程。

在整个支付流程中，ERC-8004 负责给 Agent 确定身份、绑定权限和预算范围，说清楚“它是谁、代表谁、能做到什么程度”；x402 负责在具体请求中触发支付、附带支付证明，并让服务端判断这次请求是否已经完成付款。两者结合后，支付就不再只是一次单纯的转账，而变成了一种可以验证身份、限制权限、记录过程的自动化商业行为。

Agent 会先带着自己的身份和预算去访问服务；如果这个服务要收费，服务端就返回价格和支付要求；然后客户端或中间的 Facilitator 代为完成支付；支付完成后，系统把付款结果作为证明附加到请求里；服务端验证通过后，再继续开放 API、数据或算力资源，同时把这次过程记录下来，方便后续审计。这样一来，原本分散在身份认证、权限控制、支付和审计中的几个环节，就被串成了一条完整、清晰、可追踪的执行链路。

图 2 执行路径：ERC-8004 身份层 + x402 支付层 + Tron 结算层

3.3 Bank of AI：ERC-8004 身份标准 + x402 支付协议的一站式工具箱

Bank of AI 作为全球首个深度集成“ERC-8004 身份标准与 x402 支付协议”的一站式工具箱。其核心意义在于成为开发者可直接调用的统一能力栈，涵盖身份注册、Agent 授权、预算控制、402 自动支付、Facilitator 协调、账单归集、风险审计与合规留痕等关键环节。对于开发者来说无需再分别拼装钱包、认证机制、预算管理系统和支付中间件，而是可以直接获得一个面向 Agent 商业化部署的统一入口。

Bank of AI 提供的并不只是一个支付功能，而更像是 Agent 的一层金融基础设施。它把身份、预算、支付和合规这些原本分散的能力整合起来，为 Agent 的商业执行提供底层支持。

3.4 Agent 能力层 × Agent 金融层

如果把 Agent 系统看成一个“干活的能力层”，负责做任务规划、调用工具和执行流程，那么 Bank of AI 扮演的就是它上面的“金融层”和“商业层”。它补上的，正是 Agent 在真正落地时常常缺少的几项关键能力，比如支付、预算控制、风险管理、结算和审计。借助这一层封装，一个原本仅具备任务执行能力的 Agent，将进一步获得预算内自主支付、风险约束、账单留痕以及责任可追溯等商业化能力。能力层负责“把事情做成”，而 Bank of AI 负责“让这些行为能够被计费、被结算、被约束、被审计”。

过去，大多数 Agent 只能调用免费的工具，或者必须依赖人提前把账号、订阅和支付关系都配置好。但在 Bank of AI 这样的体系下，Agent 可以在执行任务时自己发现哪些服务需要付费，判断价格是否在预算之内，自动完成小额支付，然后继续把后面的流程跑下去，同时把整个过程沉淀成可复核的账单、信用和审计记录。

从技术角度看，这相当于给 Agent 补上了一套金融和合规基础设施；从商业角度看，它说明 Agent 可能不再只是“听指令办事的软件”，而是开始具备一定的经营属性，比如有自己的预算边界、有成本约束、也能衡量投入产出。这样，Agent 参与数字经济活动的方式，也会从单纯调用功能，逐步走向能够交易、能够担责、能够形成商业闭环的程序化主体。

图 3 Agent× Bank of AI 的组合想象：能力层与金融层的耦合

3.5 竞品分析：L402/LSAT 协议

在协议层支付的探索中，除 x402 这类以稳定币为中心的方案外，另一个关键实践是由 Lightning Labs 推出的 L402（及其前身 LSAT）标准。该标准基于比特币闪电网络，同样旨在激活沉睡已久的 HTTP 402 Payment Required 状态码，为 API 服务提供一种原生的按次付费机制。与 x402 试图构建的链无关支付触发层不同，L402 从设计之初就与闪电网络生态深度绑定。其技术实现与安全假设均带有鲜明的“比特币原生”特征。

L402（Lightning HTTP 402 Protocol）的核心思想可以概括为：通过支付一张闪电网络发票（Invoice），换取一个可验证的、附带访问权限的“收据”（Token），并将该收据作为后续请求的通行证。其“付费换令牌，持令牌访问”的核心逻辑，可分解为“挑战-支付-认证”的闭环。

图 4 L402 交互时序图

基于其技术特性，L402/LSAT 在以下场景中表现出较强的适配性：

• AI Agent 调用微支付 API：这是 L402 最核心的应用场景。Agent 可自主完成“402 挑战-支付-重试”循环，无需人工干预。

• 内容微支付：为单篇文章、单个视频或单次数据查询提供无需注册的付费方案。

• 算力/带宽按时或按量结算：用户可通过支付获取一个有时长或流量限制的 L402 令牌。

然而，其设计也决定了它在某些场景下的局限性：

• 不适合长期客户关系管理：L402 的匿名模式不利于需要识别用户、提供个性化服务的业务。

• 复杂计费策略支持有限：原生支持能力弱于传统的订阅或阶梯计费系统。

• 企业级应用的合规障碍：强依赖比特币和闪电网络，使其在要求法币或稳定币核算的企业环境中难以落地。

尽管 L402 已拥有一个初步但活跃的生态，主要围绕 Lightning Labs 的核心产品展开。但它的采用仍局限于闪电网络和比特币的核心开发者社区。其较高的技术门槛与对比特币的强依赖，限制了其在大规模商业场景的普及。

表 1 L402 与 X402 对比

总结而言，L402 更像一个将会话式认证与链上微支付结合的方案，它通过一次支付为客户端“购买”了一段访问时间或次数。而 x402 则更纯粹地贯彻了 HTTP 无状态哲学，将每一次 API 调用都视为一次独立的、需即时清算的原子交换。

四、金融领域合规

4.1 反洗钱（AML）与反恐怖融资（CFT）的结构性挑战

在传统交易中，金融机构需要在交易的各个环节尽到 KYC、AML 与 CFT 的责任，在开户阶段需要通过身份证验证、背景调查等方式确认客户真实身份，并且在后续的交易中还要持续监控，对可疑交易和用户身份信息变更等情况进行识别和风险评估，配合监管的调查。传统金融体系中的 AML/KYC 机制，本质上依赖于三项前提：

• 明确的金融机构主体；

• 稳定、可识别的客户身份；

• 以账户为中心的交易监控框架。

而在区块链应用层，这三项前提均被系统性削弱。

首先，从身份维度看，x402 所支持的链上支付更接近“凭证式”而非“账户式”交易。用户通过地址、智能代理或程序化身份参与经济活动，其行为可被追踪，但其法律主体身份并不天然可识别。即便在应用层引入 KYC，身份验证往往发生在“入口环节”（如钱包或应用注册阶段），而非持续贯穿于整个交易生命周期。这导致 AML 从“持续尽调（CDD）”退化为“一次性校验”，降低了对复杂洗钱路径的识别能力。

其次，从合规责任的分配来看，区块链应用层在 AML/CFT 上呈现出明显的责任碎片化问题。传统金融体系中很多功能是强绑定的，比如银行经手了用户入口、资金托管、支付执行全流程，所以自然承担了 AML/CFT 的责任。

但在 x402 协议所支持的应用生态中，一笔价值转移往往并非由单一主体完成，而是被拆分为多个功能环节：

• 应用负责触发支付逻辑；

• 钱包负责私钥、签名与授权；

• 协议负责撮合规则或结算；

• 链负责最终状态确认。

没有一个主体完整地控制一笔交易，功能的模块化解耦虽然可以提高可组合性、降低单点风险、提高效率，但也拆散了责任结构。由此产生的核心问题在于：AML/CFT 义务难以在功能层面被清晰锚定到具体主体。

在此背景下，监管难以沿用传统 AML/CFT 框架中“以机构为中心”的执法逻辑，不仅削弱了监管规则的可执行性，也为不同主体通过结构设计规避合规义务提供了空间。这促使监管逻辑不得不从“谁在做”转向“做了什么”，即以功能和行为为导向的监管。是否触发 AML/CFT 义务，主要取决于某一组件是否实际参与了价值转移、交易撮合或用户身份控制，而非其是否自我定位为金融中介。然而，这种转向在现实中仍面临落地障碍：应用层组件高度可替换、跨司法辖区部署，以及开源与去中心化治理结构，使得基于功能的责任界定在执行层面成本高昂。

另外，从自动化与智能代理视角来看，x402 所强调的机器可读支付与程序化交易，对传统 AML/CFT 以人的意图、行为动机为核心的可疑交易识别机制构成了冲击。支付不再比如由单一自然人基于明确主观意图发起，而是可能由 AIAgent 或预设的策略中满足特定条件是自动触发，因此除了识别高风险的用户，还要对嵌于算法逻辑、策略参数或跨交易组合模式进行监管。

因此，x402 应用层的 AML/CFT 挑战并不是单纯因为合规缺失，而是因为其技术架构与当前监管逻辑之间的错位。应用层 AML/CFT 的核心问题不再是“是否履行合规义务”，而是如何在不显著削弱去中心化系统效率与隐私假设的前提下，重新设计合规的执行方式。这也在一定程度上解释了为何当前监管与行业实践正逐步从以全面身份披露为核心的模式，转向基于风险分级、行为特征分析以及跨平台协同监测的方向演进，以适应自动化与智能代理广泛参与的交易环境。

五、法律监管

5.1 AI Agent 的法律定位

AI Agent 并不具备独立法律人格，其法律地位更接近于合同法与电子商务法中的“电子代理人”（Electronic Agent），即一种由自然人或法人预先设定规则并自动执行交易行为的技术工具，而非具有权利能力与行为能力的法律主体。

这一定位在多个法域中已有明确制度基础。例如，《联合国国际合同使用电子通信公约》

第 12 条明确承认自动化系统可以“在没有人为干预的情况下形成合同”，并被法律所承认。美国《统一电子交易法》（UETA）亦规定，电子代理行为的法律效果归属于其背后的使用者，而非代理本身。

因此，核心法律问题并不是 AI 是否可以成为法律主体，而是 AI 的行为应当归属于谁，以及当 AI 的操作超出预设授权时，即构成越权代理时，应如何解释和处理。在这一框架下，一旦 AI Agent 越权——例如擅自提高支付金额、向未授权对象转账，或触发用户未同意的交易——法律争议通常会集中在合同效力、授权范围、责任归属和救济路径上。

因此，合规工作的重点在于将“越权”风险尽量控制在执行前，而非事后补救。稳妥做法包括：将授权设计为受限授权，明确金额上限、白名单对象、时间窗口、交易类型及高风险动作的人工确认；同时保留可审计日志、异常预警和事后争议处理机制，确保每一步操作都能追溯到“谁授权、授权到哪里、系统如何执行”。通过这种方式，可以在最大程度上降低 AI 行为引发的法律风险。此外，服务协议和用户界面也应明确提示 AI 的辅助性质，说明哪些操作需要用户再次确认，以及异常情况的处理流程。自动化系统不能被用来规避法律义务，因此信息披露至关重要。

5.2 消费者保护与机器瞬时交易的冲突

传统金融支付系统（如信用卡网络或 PayPal）的核心基石之一是完善的消费者保护机制，包括退款、拒付和争议仲裁。这些机制在设计上容许“反悔”和“纠错”。然而，x402 协议及 Agent 支付的工程初衷，恰恰是追求机器对机器（M2M）之间“瞬时、无状态且不可逆的确定性结算” 。

这种技术架构与现行消费者保护法规产生了剧烈的摩擦。在实际应用中，如果发生不可预见的风险——例如 AI Agent 产生“幻觉”导致过度采购了无用的算力，或者 Agent 成功支付了 x402 凭证但对方 API 节点宕机未能交付数据——用户的资金损失在当前的基础设施下缺乏标准的救济路径 。

在去中心化且极高频的微支付场景中，要求传统金融机构的人工客服介入进行纠纷仲裁，在流程和成本上完全不可行。因此，为了满足监管对消费者权益的底线要求，行业未来的合规路径必须走向“代码级救济”：即在智能合约层引入机器原生的保护机制，例如“基于预言机验证的条件释放/延迟结算”，或结合 ERC-8004 建立服务商的链上信誉惩罚与自动化退款协议，从而在不牺牲 M2M 结算效率的前提下，填补消费者保护的制度缺失。

或者可以依托区块链原生的经济学模型来解决潜在争端：引入一套自洽的验证者与仲裁者获利模型，通过经济博弈来维护系统的公正性。在这个生态中，参与方有两者和一个智能合约代码机制：

争议发起方与响应方（Agents）：在 x402 支付完成后，若购买算力的 Agent 发现 API 持续报错或数据包验证失败，可通过智能合约发起争议（Dispute），并提交链下执行日志的哈希值作为证据。

质押验证者（Staked Validators）：由全网具备多签权限的第三方节点充当。要成为验证者，节点必须预先在协议中超额质押特定资产（如稳定币或生态治理代币）。

动态抽签机制：为了防止节点串谋，当争议触发时，智能合约会通过可验证随机函数（VRF）从质押池中随机抽取一组验证者组成“临时仲裁委员会”，通过运行共识算法对双方提供的日志进行机器层面的复核与投票。

验证者为系统贡献了算力与信用，其获利主要来源于系统内设计的三重资金池：

违约方罚金：争议发起前，双方均需在担保合约中锁定一笔保证金。一旦仲裁委员会裁定某一方违约（如服务方确实未提供 API，或请求方恶意发起无理纠纷），败诉方的保证金将被没收，按比例直接分配给参与本次正确裁决的验证者。

协议抽水与仲裁金库：在网络中，Facilitator 可以从全网数以亿计的 x402 成功微支付中，提取极小比例（例如 0.01%）作为“网络安全税”，定期注入公共仲裁金库。验证者只要保持节点在线并维持高信誉分，即可定期获得金库的基础收益分配。

争议发起费：为了防止系统被无效的维权请求进行粉尘攻击，发起争议需要支付一笔微小的“仲裁诉讼费”，这笔费用将直接作为 Gas 费和劳动补偿支付给当次执行验证逻辑的节点，满足了统计学上不可能完全没有未解决争议的事实。

5.3 算法授权的金融法律效力与“意图”定性

传统金融支付的授权机制建立在“强交互”与“明确同意”的基础之上（如输入密码、生物识别或签署纸质/电子协议）。然而，在 AI Agent 支付场景中，用户的初始授权往往是基于自然语言的模糊“意图”（例如：“帮我寻找并购买性价比最高的算力资源以完成本次模型训练”）。这种非结构化的自然语言指令，在经过大模型转化为底层机器可执行的 x402 支付动作时，其在金融法规眼中是否构成具有完全法律约束力的“支付指令”？

这引出了一个极具争议的法律灰色地带：因算法理解偏差导致的“非授权交易（Unauthorized Transaction）”界定。如果 Agent 误解了用户的意图，或者由于大模型的“幻觉”超额调用了无用服务并完成扣款，这笔资金流失在法律上该被视为“用户的代理人失误（需用户自担损失）”，还是“系统缺陷导致的非授权扣款（需平台或服务商赔付）”？现行的电子签名法规或支付服务指令并未对“基于算法黑盒衍生的支付意图”给出明确的法律定性。

为解决这一合规阻碍，行业不仅需要法律界对“智能代理授权”进行重新定义，在工程层面上也必须将模糊意图“具象化”。这也正是 AP2（Agent Payments Protocol）等授权层协议在系统架构中不可或缺的原因。AP2 的核心设计思想，正是将“用户对 Agent 的支付授权”从隐式逻辑中抽离，转化为结构化、可验证的授权声明 。通过在声明中锚定严格的金额与频次限制、对象与场景限制 ，并生成不可篡改的可验证授权凭证 。只有当非结构化的自然语言意图被转化为这种可追溯、可审计的密码学契约后，“算法授权”才能在未来的 PayFi 体系中获得真正被监管认可的法律效力

5.4 内容微支付应用场景下的版权合规

X402 协议的重要应用场景之一是内容微支付，即对数字内容或服务进行小额、即时、按使用量支付的机制。生成式人工智能大模型训练数据、数字内容消费、在线服务工具以及社交与创作平台构成了内容微支付的典型应用场景。在生成式人工智能领域，大模型训练依赖海量数据，当模型使用特定受版权保护的内容时，可通过微支付机制向内容权利人支付相应的版权费或许可费。在数字内容消费领域，音乐、图片、短视频和文章等内容可以按次或按时长计费，用户在完成小额支付后即可即时访问或下载相关内容。在在线服务或工具场景中，API 调用、软件功能或数据接口的使用通常按调用次数收费，广泛适用于云计算平台和数据分析工具等服务。与此同时，在社交或创作平台中，用户也可以通过微支付方式对他人创作的表情包、短视频片段或数字艺术作品进行打赏或直接付费，从而形成以小额、高频交易为特征的内容价值流通机制。

尽管上述内容微支付应用场景在技术上具有可行性，但其实际运行需要以明确的法律前置条件为基础。无论是生成式人工智能大模型训练数据的使用，还是数字内容消费、在线服务调用与创作者内容打赏，这些场景均涉及对内容、数据或技术成果的使用与交易，其合法性须以现行版权法、合同法及相关判例所确立的权利边界为前提。因此，有必要在技术方案之外，系统梳理并分析这些应用场景所依赖的法律前置条件。由于后三种场景法律规则相对明晰，本章重点落在生成式人工智能大模型训练数据的版权规则上。

目前生成式人工智能大模型训练数据的版权规则正在利益冲突和碰撞中逐渐建立。一方面，部分观点坚持传统版权法框架，认为训练过程中的复制行为原则上受控制，但可通过法定许可、合理报酬或补偿机制实现利益平衡；另一方面，也有观点主张对合理使用制度进行扩张，将模型训练乃至内容生成纳入豁免范围，以回应技术发展带来的大规模数据使用需求。

在美国，在发生了纽约时报诉微软和 OpenAI 等几十场关于生成式人工智能数据训练的版权诉讼之后，美国版权局于 2025 年发布了《著作权与人工智能》报告，对“将受版权保护作品用于训练生成式 AI 是否构成合理使用”进行了详尽技术与法律分析，指出 AI 训练使用受版权保护作品并不当然构成美国版权法上的合理使用，应依照传统“四要件测试”分情形判断。整体上看，美国版权局不支持大模型训练自动构成合理使用的产业主张，认为商业模型需要引入许可制度，并呼吁国会立法，明确 AI 训练的合理使用例外或许可框架，并提出了若干可能的立法路径，包括：（1）设立针对特定 AI 训练行为的有限法定例外；（2）引入强制许可或扩展性集体管理许可制度；（3）建立兼具退出权（opt-out）与标准化报酬机制的混合模式。

英国则采取了更为激进的立场，在 Getty Images v. Stability AI 判决中，Stability AI 试图将其行为类比为受美国法保护的“转化性使用”，但英国法院明确拒绝了这一移植。法院裁定，Stability AI 为训练目的而复制 Getty Images 受版权保护图片库的行为，本身就构成了未经授权的复制行为，侵犯了原告的复制权。判决否定了“技术必要性”可作为侵权抗辩的理由，明确指出商业实体不能以构建模型需要为由，无偿攫取他人的知识产权成果。这一定性使得 AI 公司在英国法下面临“从源头开始”即需获得授权的压力。并且，英国法院认为，即使无法从模型中直接提取出完整原图，但若受保护作品的实质部分以某种形式被“存储”或“表示”在模型参数中，该行为仍可能构成法律意义上的复制。目前来看，由于较强的版权保护趋势，对于商业模型的训练，在美国及英国适用 x402 协议进行内容微支付日后可能获得法律支持。

欧盟对人工智能训练中使用版权作品的合法性判断，主要依据《数字单一市场版权指令》中的“文本与数据挖掘例外”条款。该条款分为两类：第一类是第 3 条科研例外，允许为科学研究目的进行文本与数据挖掘，著作权人无权排除此例外。第二类是第 4 条一般例外，允许为任何目的对合法获取的作品进行文本与数据挖掘，但为著作权人保留了以合理方式声明排除此项例外的权利。由于大多数 AI 研发者是商业机构，通常无法适用第 3 条的科研例外，因此其合法性高度依赖著作权人是否行使其“保留权”。2024 年通过并生效的欧盟《人工智能法案》承认《数字单一市场版权指令》第 4 条规定的权利保留条款。欧盟在平衡 AI 发展与版权保护时，倾向于严格尊重著作权人控制其作品使用的意愿，对合理使用的认定较为审慎。

中国大陆地区现有研究大体提出了两种解决方案：一是通过合理使用等豁免规则予以合法化，此方面的研究成果已经比较丰富。二是通过解释、界定复制权的办法予以合法化，此种方案目前尚属于少数意见。整体上倾向于为生成式人工智能的数据训练找到一条切实可行的合法路径。

5.5 数据安全与隐私合规

可以把 AI 支付理解为一条“先授权、再执行、最后结算”的链路，其合规性直接取决于授权行为是否符合全球主流数据隐私法规对“同意”的核心要求。简单来说，真正的合规关键就在“用户有没有清楚地同意，以及这份同意能不能被随时控制和追溯”。亦即，用户必须明确知道自己授权了什么，如支付额度、对象、期限等；同时也要能撤回，并留下完整记录。此外，AI 支付本质上处理的是大量个人数据，因此必须遵循“少收集、严保护”的原则——只拿完成支付所必需的信息，对敏感数据单独征求同意，并通过加密、分级管理等方式保障安全。尤其在跨境场景下，不同国家对数据存储和传输的要求差异很大，企业必须选择适当的合规路径，否则很容易出现“技术上可行、法律上卡住”的局面。

在新模式下，合规问题会进一步集中在 Facilitator 身上——谁在处理数据、处理到什么程度、是否履行反洗钱和审计义务，都需要被清晰界定。同时，由于 AI 能够“自主决策”的特性，监管也越来越关注算法本身：比如为什么一笔支付被拒、是否对某些人群存在不公平判断，都需要能解释、可审计。因此，真正可落地的路径，是建立一套分级应对机制：小额简单交易尽量轻量合规，高风险场景则全面加强审核与数据保护，并用技术手段把合规嵌入系统之中。此外，还需持续跟踪各国政策变化，AI 支付才能在创新和监管之间找到一个现实可行的平衡点。

六、总结与展望

如果把今天的互联网比作一个巨大的市场，那么 AI 代理就是市场中最新涌入的“顾客”和“摊主”——它们能检索信息、调用工具、编写代码、规划行程，甚至替你下单购物。但长久以来，这个市场缺了一样东西：“支付能力”。AI 代理没有银行卡，无法注册账户，更不会手动输入验证码。传统支付系统要求的身份验证、账户体系、人工参与，对它们而言是一道无法逾越的高墙。

这正是 x402 等协议出现的根本原因。它们做了一件看似简单却极具颠覆性的事——把支付直接写进互联网的底层对话语言里。从此，支付不再需要“人”在中间点头确认，而是变成了一段代码可以自动触发的指令。区块链恰好提供了这种能力——可编程、无需许可、自动执行。稳定币则让价值像数据一样，在全球范围内低成本、高效率地流动。

于是，一个全新的经济形态正在萌芽：“智能体经济”。在这个经济体中，AI 代理既是消费者（购买数据、算力、API 服务），也是生产者（出售自己的分析结果、执行能力），还可以彼此交易。区块链不再是高高在上的金融工具，而默默下沉为整个 AI 经济的底层结算层。未来很多应用看起来并不属于加密世界，但它们的每一次价值交换，背后都跑在区块链上。

当然，这场变革不会轰轰烈烈地一夜到来。短期内，AI 代理与数字服务之间的“机器对机器”支付会率先爆发——比如代理按次付费调用天气 API、购买一篇学术论文、租用几分钟的 GPU 算力。而面向普通消费者的零售场景，仍会长期依赖 Visa、PayPal 等传统方式。区块链将在绝大多数用户看不见的地方安静工作。

有意思的是，x402 最容易被低估的影，不在商业领域，而在软件开发领域。今天的 AI 模型已经足够聪明，能独立完成大量任务。真正的瓶颈是什么？是访问权限。是昂贵的订阅套餐、繁琐的 API 密钥管理、那些你为了一两次使用而不得不整月付费的捆绑服务。x402 用“按需付费的微支付”取代了“预付订阅”，用户可以给代理设定一个月度预算，让它像花零用钱一样自主采购。因此可能大幅降低入门级软件开发工作的成本。

放眼更远的未来，问题不再是“区块链会不会被用上”，而是“在哪里、以什么方式被用上”。链上结算不会彻底取代传统支付系统，而是与之共存互补。从 API 微支付起步，逐步向更高价值的商业场景延伸，区块链将悄然重塑软件的构建、定价与使用方式。

一言以蔽之，AI 正在从“工具”进化为“经济主体”，x402 协议把支付嵌入互联网的毛细血管，让 AI 可以自主购买、交易、协作——它不是又一个空中楼阁，而是未来智能体经济的基础设施。

特别鸣谢

感谢白 B.AI 生态在本文研究与写作过程中提供的支持与帮助，包括相关资料交流、观点讨论与信息参考。其下业务分支 BANK OF AI 与 AINFT 亦在相关议题沟通中提供了有价值的参考。