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 有權追究其法律責任。





