閱讀時長 4 分鐘
x402 與 AP2 解析：AI 代理付款協定如何分工
超過 100 家支付服務提供商與科技公司 已經齊力支持 AP2。Coinbase 的 x402 已 在 Base 上處理超過 1.19 億筆交易。如果你正在為 AI 代理打造支付基礎架構，這兩個協定是你必須理解的對象。
x402 是 Coinbase 開發的 HTTP 付款基礎原語。當伺服器回傳 HTTP 402 狀態碼（「需要付款」）時，代理會讀取回應中內嵌的付款指示，簽署一筆穩定幣交易，附上付款證明後重新發送請求。不需要使用者工作階段，也不需要登入流程。結算在鏈上數秒內即可完成。
AP2（Agent Payments Protocol，代理付款協定）是 Google 為代理發起商務所制定的開放標準。它負責的是工作階段層級的信任與授權：在代理能夠花費任何款項之前，使用者必須先簽發一份以密碼學方式簽署的 Mandate（付款委託），以證明其意圖。AP2 包含一個 x402 擴充功能，由 Coinbase、以太坊基金會與 MetaMask 共同開發，讓 x402 成為 AP2 中的加密貨幣／穩定幣支付方式。
兩者並非競爭關係。它們解決的是同一問題的不同層面。
x402 是什麼，如何運作
x402 是一套用於機器對機器 API 呼叫的付款協定。其設計刻意保持精簡。它重新啟用了 HTTP 402 狀態碼——這個狀態碼早在 1991 年就存在於規格中，但直到現在才被標準化。
流程如下：
- 代理呼叫某個 API 端點。
- 伺服器回傳 HTTP 402，並附帶付款酬載：金額、幣別、收款地址、可接受的穩定幣、網路。
- 代理的錢包簽署一筆符合這些條件的穩定幣交易。
- 代理重新發送原始請求，並在標頭中附上付款證明。
- 伺服器驗證證明後履行請求。
無需登入、無需信用卡、無需 OAuth 權杖。付款本身就是憑證。
截至 2026 年 3 月，x402 協定費用為零，年化交易量約 6 億美元（涵蓋 Base 與 Solana）。Coinbase 隨後在 Google、Stripe 與 Visa 的支持下，將 x402 移交給 Linux Foundation。這項舉措在營運層面意義重大：治理如今是中立的，協定風險也低於由單一企業贊助時的情況。
如果你的 API 直接服務代理，而你想要計量式、無摩擦的付款，不想自行建置訂閱制或工作階段管理層，x402 就是你要的機制。它不管理跨工作階段的信任、不驗證使用者意圖，也不知道目前行動的代理是否獲得最終使用者授權。這些刻意被排除在範圍之外。
AP2 是什麼，如何運作
Google 的 AP2 發表 將 Coinbase、Mastercard、PayPal、American Express、Revolut、Shopee、Salesforce、Worldpay、Adyen、Etsy、JCB 與 UnionPay 納入其 60 多家創始合作夥伴之中。短短六週內，這個聯盟便已 突破 100 家合作夥伴。規格書已公開，請參閱 此處。
AP2 的核心概念是 Mandate（付款委託）：一份以密碼學方式簽署的數位合約，記錄使用者已授權代理執行的事項，任何交易都必須先有它才能發起。Mandate 可以指定消費上限、核可商家、有效時間窗口與付款方式。沒有有效的 Mandate，代理便無法依 AP2 發起付款。
信任模型的運作方式如下：
- 使用者或企業設定 Mandate：範圍、上限、到期時間。
- Mandate 經簽署後發給代理。
- 代理在發起付款時出示 Mandate。
- 付款服務商在處理前，以密碼學方式驗證 Mandate。
AP2 可跨傳統支付軌道（卡片、銀行轉帳）運作，並透過 AP2 x402 擴充功能支援穩定幣與鏈上結算。這個擴充功能正是兩個協定直接交會之處。
AP2 是大規模代理商務的授權與信任層。如果你正在建置供代理購買商品或服務、呼叫付費 API，或代表使用者執行定期付款的基礎架構，你就需要 Mandate 框架。x402 付款可以在這個框架內作為結算方式運作。
x402 與 AP2 如何搭配
理解兩者關係最清楚的方式，是透過協定堆疊來看。
AP2 運作於工作階段與授權層：它回答「這個代理是否被允許花費？代表誰？在什麼限制下？」x402 運作於呼叫層：它回答「代理此刻如何為這一次特定的 API 呼叫付款？」
AP2 x402 擴充功能將兩者融合。當一個在 AP2 Mandate 下運作的代理需要以穩定幣支付某次 API 呼叫時，x402 機制負責逐次呼叫的結算。Mandate 為 AP2 提供授權脈絡，x402 負責結算的執行機制。
兩個協定都不是執行層。它們定義介面、訊息格式與驗證邏輯，規範付款請求的樣貌以及有效回應必須包含的內容。實際執行交易需要協定之下的工作：保管金鑰、以可稽核的軌跡簽署、篩查收款地址、派發資金。這一切都發生在位於兩個協定之下的錢包基礎架構中。
沒有與具備正確基礎架構的情境對比
設想一個 AI 代理，已獲企業授權呼叫某個資料 API 並按查詢次數付費。此代理在 AP2 Mandate 下運作，並為每次呼叫發出一筆 x402 付款。
若沒有足夠的錢包基礎架構： 代理產生付款證明並送出。你的後端收到一筆已簽署的穩定幣交易請求。如果你的提領流程沒有自動化簽署、可設定的核可門檻與即時 KYT 篩查，你就得在人工審核（會完全破壞延遲模型）與盲目執行（構成合規與詐欺風險）之間做選擇。
若底層有 WaaS 管線： 請求進入 CoinSend，由它將交易路由到 CoinSign，在派發前完成 RSA/HMAC-SHA256 授權。CoinGet 的自動 KYT 會在資金移動前篩查收款地址。簽署、篩查與派發全都發生在基礎架構層、位於協定層之下，且不會破壞 x402 所設計的次秒級延遲模型。
這就是執行層的差別。x402 與 AP2 描述介面；CoinGet、CoinSend 與 CoinSign 則是底層管線。
CoinsDo WaaS 採非託管模式：私鑰由營運方持有，而非 CoinsDo。CoinSign 的 RSA/HMAC-SHA256 簽章為每筆交易提供無法偽造的授權軌跡。平台支援代理部署錢包的應用場景，涵蓋 ETH/ERC-20、TRX/TRC-20、BNB/BEP-20、Polygon、Solana 及多條其他區塊鏈，並依客戶需求的鏈整合以約一個月的週期推出。
如果你的代理跨鏈運作，這樣的涵蓋範圍就很重要。x402 起源於 Base 與 Solana；AP2 在框架層級與鏈無關。你的基礎架構必須涵蓋你的代理實際會使用的鏈。
想進一步了解這在 WaaS 情境中如何運作，請 參閱此處
至於這些協定所衍生的基礎架構決策（金鑰託管、核可流程、合規自動化與鏈涵蓋範圍），請 參閱此處
常見問題
我需要同時實作 x402 與 AP2 嗎？
不一定，也不是同時。如果你的使用情境是 API 變現——代理按次付費且不需要工作階段層級的授權——單用 x402 可能就足夠。如果你在打造代理對商家的商務，且使用者意圖與消費上限必須能跨多筆交易以密碼學方式驗證，AP2 提供你 Mandate 框架。至於任何具規模的穩定幣結算代理商務，你最終很可能兩者都要實作：AP2 負責信任與授權，x402（透過 AP2 x402 擴充功能）負責結算機制。
錢包基礎架構在堆疊中位於何處？
在區塊鏈之上、協定之下。x402 與 AP2 定義訊息格式與驗證邏輯；它們不保管金鑰、不簽署交易、也不篩查交易對手。這些工作屬於錢包層：充值地址產生、交易簽署、KYT 篩查與自動派發。兩個協定都沒有規範這一層的樣貌，你得自行準備。
x402 現在夠穩定，可以直接建構在上面嗎？
在 Stripe、Google 與 Visa 的支持下移交給 Linux Foundation，是協定穩定性的強烈訊號。x402 GitHub 與 Base 上超過 1.19 億筆交易的實績，都顯示核心機制已度過實驗階段。治理模式如今是中立的。不過，隨著 AP2 本身日趨成熟，你應預期 AP2 x402 擴充功能會持續演進，因此建構時請依循規格，而不是綁定特定廠商的實作。
AP2 Mandate 如何防止代理未經授權的支出？
Mandate 是以密碼學方式簽署的，而不只是以權杖把關。代理必須出示有效的 Mandate 才能發起任何符合 AP2 的付款，且付款服務商會在處理前驗證其密碼學簽章。消費上限、商家限制與到期窗口都內嵌在 Mandate 本身，而非在應用層強制執行。即使代理被入侵，也無法在 Mandate 範圍之外支出，因為服務商端的驗證會拒絕任何超出授權參數的交易。
