x402 利用 HTTP 402 Payment Required 响应建立网络请求与支付之间的联系,使 AI Agent 能够按照服务端提供的支付条件完成交易。
x402B 则在这一基础上引入托管合约、交付状态和争议处理机制,让付款授权、资金锁定、商品或服务交付以及最终结算成为可以分别管理的环节。Boson Protocol 已于 2026 年 6 月 8 日将 x402B 部署至 Base 主网,但其应用范围、兼容性和实际保障效果仍需要结合具体实现判断。
x402B 是 Boson Protocol 面向 x402 支付协议开发的链上托管扩展方案。 它通过智能合约管理交易资金,使付款与最终资金释放能够分阶段完成。
x402 主要解决自动支付问题,x402B 进一步处理支付后的交付风险。 当 AI Agent 购买的服务无法即时交付时,托管机制可以提供额外保障。
非托管 Escrow 是 x402B 的核心机制。 买方资金进入链上托管合约,而不是在付款授权完成后直接全部转入卖方账户。
交付确认和争议解决决定资金如何释放。 根据具体交易规则,资金可能在兑换确认、争议期结束或争议裁决后分配。
x402B 为 Agent Commerce 提供新的交易基础设施。 它适用于需要异步交付、交易保障和自动化结算的 AI Agent 商业场景,但不能消除所有履约风险。
x402B 可以理解为在 x402 支付流程中加入链上交易保障机制的一种实现方案。x402 的核心思想是将支付要求嵌入 HTTP 请求与响应过程。当客户端请求付费资源时,服务端可以返回 HTTP 402 状态码,并提供可接受的支付方式。客户端完成相应授权后重新发起请求,服务端验证支付条件,再决定是否提供资源。这种模式能够减少传统账户注册、订阅管理和人工付款操作对自动化服务的依赖。
对于即时交付的 API 调用,这种支付模式通常比较直接。例如,AI Agent 请求一次模型推理服务,按照接口报价完成支付后,即可获得对应结果。但如果交易涉及定制内容、长期计算任务、数字许可证或需要等待交付的商品,付款和实际履约之间可能存在时间差。在直接支付模式下,资金一旦完成最终结算,买方通常无法仅凭原始支付协议要求卖方退还资金。
x402B 针对这一问题引入 Escrow 支付方案。卖方可以在 HTTP 402 响应中提供托管交易条件,买方签署相应授权后,资金被锁定在智能合约中,后续根据交付和争议状态决定释放方式。它不是替代整个 x402 协议的新支付网络,而是利用 x402 支持不同支付方案的设计,扩展其中的交易结算能力。
AI Agent 可以按照预设任务自主调用服务、比较报价和提交支付请求,但自动完成付款并不意味着能够自动判断交易是否履约。对于一次即时返回结果的 API 请求,支付和服务交付之间的时间差可能很短;对于需要数分钟生成的研究报告、数小时完成的计算任务,甚至跨境商品采购,付款和交付之间则可能存在较长间隔。
这种时间差会带来交易对手风险。例如,一个 AI Agent 向陌生服务提供商支付 100 USDC,购买一份定制数据报告。如果资金直接结算至卖方地址,而卖方最终未能交付内容,买方就需要依赖额外的退款流程、平台规则或法律途径解决问题。对于没有成熟信用记录的自动化服务提供商,传统的信誉机制可能不足以覆盖所有风险。
链上托管通过改变资金释放顺序降低部分风险。买方可以先将资金锁定在智能合约中,卖方按照约定提供商品或服务,随后再依据交付确认、争议期或其他结算条件完成资金分配。这样,支付授权不再必然等于卖方立即获得全部资金。不过,托管并不意味着交易一定成功,也不能自动证明链下商品的质量,实际保障程度仍取决于交付验证和争议解决机制。
x402B 将 HTTP 支付交互与链上托管状态结合起来,使 AI Agent 能够通过标准化请求完成从购买到结算的多个步骤。典型流程包括请求资源、获取报价、签署授权、锁定资金、执行交付和最终结算。

买方 AI Agent 向服务端请求资源。卖方根据请求生成交易报价,并在 HTTP 402 响应中提供托管支付条件,其中可以包含价格、支持的代币、托管合约地址以及卖方签名的交易承诺。买方验证条件后签署元交易授权,随后通过 Facilitator 或其他受支持的方式将交易提交至区块链。智能合约完成资金锁定,并记录相应交易状态。
资金锁定后,卖方可以提供资源或交付凭证,后续操作由交易状态和可执行动作决定。x402B 的设计使用 nextActions 描述当前允许执行的步骤,例如确认交付、发起争议或完成结算。根据具体实现,资金可以在交付确认、争议窗口结束或争议解决后释放。该机制将一次性的支付过程扩展为可追踪的交易生命周期。
Escrow 是一种在交易条件满足之前暂时保管资金的机制。在传统商业活动中,托管通常由银行、支付机构或第三方平台提供;在 x402B 中,资金由智能合约按照预设规则管理。买方完成授权后,稳定币被锁定在链上托管合约中,卖方不能仅凭收到付款请求就立即取得这笔资金。
x402B 使用 Boson Protocol 的托管基础设施管理交易承诺和结算状态。买卖双方按照约定完成交易操作,智能合约依据交付确认、争议状态和时间限制执行资金分配。这种机制的主要价值是减少对单一支付平台或交易对手的资金保管依赖,同时让交易记录与资金释放条件能够在链上验证。
但非托管不等于完全没有风险。智能合约漏洞、错误的交易参数、不合理的争议窗口以及交付证明不足,都可能影响最终结果。特别是链下商品和服务的实际质量无法仅凭区块链状态自动判断。因此,x402B 提供的是一套可编程交易保障机制,而不是对所有交易结果的无条件担保。
在 AI Agent 自动交易中,付款与交付可能发生在不同时间。为了处理这种情况,x402B 将交付状态纳入交易生命周期。例如,买方购买一项数字服务后,卖方可以通过指定渠道提供内容或交付凭证,买方再按照协议要求完成确认。对于某些商品或服务,交付还可能涉及兑换凭证、订单状态更新或其他验证步骤。
如果买方认为卖方没有履约,可以在符合规则的时间窗口内发起争议。Boson Protocol 的设计支持争议解决者(Dispute Resolver)参与处理,具体机制可能包括双方协商、第三方裁决或按照预先设定的超时规则结算。最终资金分配取决于交易状态、相关签名和适用的争议处理条件,而不是简单由买方或卖方单方面决定。
需要注意的是,争议解决并不意味着每笔交易都会由完全自动化的智能合约判断商品质量。对于链下交付,仍可能需要外部证据、人工裁决或可信验证机制。x402B 的优势在于能够将争议结果与链上资金执行连接起来,但判断交易是否真正履约,仍然可能依赖链下信息。
x402 与 x402B 的差异,主要体现在资金结算方式和交易生命周期的管理上。x402 的 exact 支付方案更适合付款后立即提供资源的场景,而 x402B 的 escrow 方案则适合付款与交付之间存在时间差、需要交易保障的场景。
| 对比维度 | x402 的 exact 方案 | Boson x402B |
|---|---|---|
| 核心目标 | 完成网络原生支付 | 支付与交付保障 |
| 资金流向 | 验证后向卖方结算 | 先锁定在托管合约 |
| 交付方式 | 通常适合即时交付 | 支持异步交付 |
| 争议处理 | 不提供统一的内置托管争议流程 | 支持托管争议机制 |
| 资金释放 | 完成支付结算 | 根据交付与争议状态释放 |
| 适用场景 | API 调用、即时数据服务 | 定制服务、数字商品、复杂采购 |
| 主要风险 | 付款后无法获得预期服务 | 合约、交付验证与争议机制风险 |
这种比较并不意味着 x402 本身只能用于简单交易,也不意味着所有使用 x402 的服务都缺少退款或争议处理能力。开发者可以通过其他应用层机制实现交易保障。x402B 的区别在于将托管支付作为一种可集成的支付方案,使相关规则与链上资金状态直接关联。
此外,x402B 并不要求所有现有 x402 客户端自动支持托管交易。只有具备相应支付方案处理能力的客户端,才能正确识别和执行 escrow 流程。服务端可以同时提供直接支付和托管支付选项,让不同客户端根据自身能力选择。
x402B 并非依靠单一智能合约完成全部交易,而是结合链下签名、稳定币授权、链上合约和交易中继等组件。EIP-712 提供结构化数据签名方式,使买卖双方能够对报价、交易授权和其他参数进行签署。与直接签署不透明数据相比,结构化签名能够让兼容钱包更清晰地展示部分交易内容,但用户仍需要检查实际授权范围。
在支付资产方面,x402B 可以使用 USDC 等受支持的稳定币完成资金锁定。其技术方案涉及 EIP-3009、EIP-2612、Permit2 和普通代币授权等不同路径,具体采用哪种方式取决于资产、网络和集成条件。稳定币在这里承担计价和结算媒介的角色,而托管合约负责管理资金释放条件,两者解决的是不同问题。
Facilitator 则主要承担交易提交与执行辅助功能。买方可以先完成签名,再由 Facilitator 将相应交易提交至区块链,从而在特定实现中获得免自行支付 Gas 的操作体验。不过,Gasless 不代表链上交易没有成本,而是费用由其他参与方承担。x402B 还设计了直接链上操作路径,以降低 Facilitator 不可用时对交易继续执行的影响。
数字内容和专业服务采购。AI Agent 可能需要购买行业报告、定制数据、软件许可证或第三方研究服务。这些商品通常无法像简单 API 请求一样立即完成交付,部分服务还需要根据用户需求生成内容。通过 x402B,买方可以在支付时锁定资金,卖方按照约定交付后再进入结算流程。
Agent-to-Agent Commerce,即 AI Agent 之间的自动化商业交易。例如,一个负责市场研究的 Agent 可以向另一个数据分析 Agent 采购计算服务,后者再调用其他模型或数据源完成任务。多个独立服务提供者之间可能缺乏长期合作关系,因此标准化的交易承诺、托管资金和争议处理机制能够降低部分交易对手风险。
自动化电商和实物商品采购。AI Agent 可以负责查找商品、比较报价、提交订单和授权付款,而商品交付仍然依赖商户、物流和其他现实世界环节。Boson Protocol 已展示结合 Facet 商店、USDC 和 x402B 托管的购买流程。这类案例说明,自动化支付可以与实际商品交易结合,但测试环境中的演示并不等同于大规模商业采用。
x402B 首先需要解决交付验证问题。对于 API 返回的数据,服务端是否成功响应可能相对容易检查;但对于定制研究、设计作品或实体商品,判断交付是否符合约定往往涉及主观标准。即使资金托管和结算全部发生在链上,协议也不能仅凭转账记录判断商品是否存在质量问题。
其次是资金占用与交易成本。托管机制提高了交易保障程度,但也可能延长资金释放周期。对于低价值、高频率的 API 请求,直接支付可能更加简单;如果每笔交易都需要维护托管状态、交付确认和争议窗口,额外的流程与执行成本可能抵消部分效率优势。因此,x402B 未必适合所有 AI Agent 支付场景。
最后是兼容性与采用规模。x402B 的托管支付方案需要客户端、服务端和相关中继组件共同支持,不能假设所有 x402 应用都已具备这些能力。其长期发展还取决于智能合约安全、争议解决者的可靠性、支付资产流动性、开发者集成成本及实际交易需求。现有技术实现和商业案例可以验证部分可行性,但仍不足以证明这种模式将成为所有 Agent Commerce 交易的统一标准。
Agent Commerce 的发展正在推动支付基础设施从简单的资金转移向完整交易管理扩展。当 AI Agent 只需要购买即时返回结果的 API 服务时,自动支付能力可能已经足够。但当 Agent 开始购买定制服务、协调多个供应商或参与现实商品交易时,支付授权、履约确认、退款和争议解决就需要成为相互衔接的环节。
x402B 提供了一种将这些环节连接起来的技术路径。通过 HTTP 支付请求、链上托管、结构化签名和可执行的交易状态,AI Agent 可以在减少人工参与的同时,获得一定程度的交易保障。这种模式也有助于形成更加标准化的自动化采购流程,使不同开发者和服务提供商能够围绕共同的支付与结算接口构建应用。
不过,Agent Commerce 的成熟不仅取决于支付技术,还需要身份认证、交易授权、服务质量评价、争议治理和合规框架共同发展。x402B 解决的是其中与资金托管和结算相关的一部分问题,其实际价值最终仍需要通过真实交易规模、履约成功率、资金安全性和开发者采用情况验证。
x402B 是 Boson Protocol 在 x402 支付体系基础上开发的链上托管扩展方案。与主要面向即时支付的直接结算方式相比,x402B 将资金锁定、商品或服务交付、争议处理和最终结算纳入同一交易流程,为 AI Agent 购买非即时交付服务提供了额外的交易保障。
它的核心价值并不是让 AI Agent 更快付款,而是让自动付款能够与交易履约建立更明确的联系。随着 AI Agent 逐渐参与复杂的数字服务采购和商业交易,非托管 Escrow 有望成为 Agent Commerce 的重要基础设施之一,但其安全性、适用范围和商业成熟度仍需要持续验证。
x402B 是 Boson Protocol 开发的 x402 支付扩展方案,通过非托管链上托管合约管理交易资金,并支持交付确认和争议解决。
不是完全相同的概念。x402 是网络原生支付协议,x402B 是在其支付交互框架下增加托管交易能力的具体扩展实现,并非所有 x402 客户端都自动支持。
不一定。在支持交易中继的场景中,Facilitator 可以代为提交交易并承担 Gas,买方无需自行持有用于支付 Gas 的原生代币。但链上执行成本仍然存在。
不能。链上托管可以降低部分付款后不交付的风险,但无法消除智能合约漏洞、虚假交付证明、争议裁决错误等问题。
不是。USDC 是已有集成案例中使用的稳定币,具体支持哪些资产取决于相应网络、代币授权机制和服务端配置。
更适合付款与交付之间存在时间差,或者买卖双方需要额外履约保障的交易,例如定制数字服务、软件采购、异步计算任务和部分商品交易。
* 投资有风险,入市须谨慎。本文不作为 Gate 提供的投资理财建议或其他任何类型的建议。
* 在未提及 Gate 的情况下,复制、传播或抄袭本文将违反《版权法》,Gate 有权追究其法律责任。





