為什麼叫做 x402？HTTP 402 狀態碼是什麼，它和支付有什麼關係？
HTTP 狀態碼是伺服器告訴客戶端「這個請求的結果是什麼」的數字代碼。大家熟悉的有 404（找不到頁面）、200（成功）、500（伺服器錯誤）。
402 是 HTTP 規範裡一個幾乎從未被正式使用的狀態碼，官方定義是「Payment Required」（需要付費）。這個狀態碼在 1990 年代被設計進 HTTP 規範，原本的想法是有朝一日可以支援「需要付費才能存取的網頁內容」，但因為那個年代沒有適合的數位支付基礎設施，402 就一直沉睡著。
x402 協議正是喚醒了這個沉睡三十年的狀態碼。當一個 API 或服務需要付費才能使用，它回傳 HTTP 402 狀態碼，並在回應標頭裡附帶支付所需的資訊（支付金額、收款地址、接受的代幣種類）。支援 x402 的 Agent 讀到 402 回應後，自動完成鏈上支付，再用付款證明重新發送請求。
這個設計的優雅之處：整個「請求→被要求付費→付費→重新請求→獲得服務」的流程，完全在現有的 HTTP 協議框架內完成，不需要任何新的網路層或通訊協議。這讓它的部署門檻極低——任何現有的 API 服務都可以透過加入 402 支援來接入 x402 生態。
x402 交易裡，Agent 怎麼避免被收費兩次（重複付款）或被服務商詐騙（付了錢但不給服務）？
這是 x402 設計中需要認真解決的問題，也是早期版本被批評的地方。目前的 x402 規範透過幾個機制來處理：
防重複付款：x402 的支付請求使用唯一的 nonce（一次性隨機值）和時間戳。服務端在驗證付款後，把這個 nonce 標記為已使用，同樣的付款憑證不能被重複接受。Agent 可以在設計上避免在未收到明確的成功回應前重複付款。
防付錢不給服務（Exit Scam）：這個問題比較難在協議層完全解決。目前的緩解方式：
現實考量：x402 目前最適合的是小額、標準化的服務付費（查一次 API、下載一份報告），而不是大額或需要複雜驗收標準的付款。
x402 和傳統 API Key 計費模式相比，開發者和服務商各自有什麼優劣？
傳統 API Key 計費模式（月費訂閱 / 按量計費）：
服務商優勢：可預測的收入流、容易做用戶留存和客戶管理、計費系統成熟。開發者優勢：簡單直覺、費用上限清楚、沒有鏈上複雜度。
劣勢（兩方）：需要用戶申請帳戶、提供信用卡；API Key 管理是安全風險（洩露就能被濫用）；全球化支付有障礙（部分地區的信用卡被拒、換匯成本）；AI Agent 無法自主申請帳戶，仍需人類帳戶做中介。
x402 計費模式：
服務商優勢：零摩擦接入（任何有錢包的 Agent 都能付費，無需 KYC 或帳戶申請）；全球化（接受穩定幣，沒有地區限制）；實時結算（不需要等月結）。開發者 / Agent 優勢：Agent 可以真正自主選擇和切換服務，不需要人類帳戶做中介。
劣勢：鏈上手續費（Gas）對於超小額付款可能讓成本不划算；沒有傳統客服和帳單爭議機制；對非加密背景的開發者門檻高；目前生態系統成熟度遠低於傳統 API。
適用情境總結：x402 最適合「Agent 需要動態、按需使用多個服務、且已在加密生態系統裡運作」的場景。傳統 API Key 仍然是「固定使用少數服務、預算可預測」場景的最優選。
x402 在多 Agent 系統（Agent-to-Agent）的付款場景下怎麼運作？A2A 微支付為什麼被認為是 AI Agent 經濟的關鍵基礎設施？
在多 Agent 系統中，一個「主 Agent」可能需要委派子任務給多個「子 Agent」，每個子 Agent 執行一部分工作，然後主 Agent 聚合結果。問題是：子 Agent 提供的是真實的工作和價值，怎麼獲得報酬？
傳統方式無法解決這個問題：如果子 Agent 是由不同組織或個人運營的，你無法提前設定所有的 API Key 帳戶，更不可能透過傳統支付為每一個微小的工作單元付費（想像為一次 API 調用付 $0.001——信用卡根本不支持這個粒度的支付）。
x402 讓 A2A 微支付在技術上可行：主 Agent 呼叫子 Agent 的服務，子 Agent 的端點回傳 402 Payment Required，主 Agent 自動完成穩定幣微支付，子 Agent 確認收款後提供服務和結果。整個流程自動化，不需要任何人的手動介入，支付粒度可以細到 $0.001 甚至更低。
為什麼被視為關鍵基礎設施：它讓 Agent 可以真正構成一個「去中心化的服務市場」——任何人都可以部署 Agent 提供特定的專業服務（鏈上數據分析、特定語言翻譯、特定模型的推理），按工作量獲得即時支付，完全不需要和任何一個中心化平台簽約或申請帳戶。這是「機器自主經濟」的基礎設施拼圖。
x402 實際運作流程：一個加密研究 Agent 付費取得鏈上分析數據
場景：一個研究 Agent 需要取得過去 30 天 ETH 大戶的資金流向分析（這類數據通常要付費才能取得）。
第一步：Agent 發出請求
Agent 向一個鏈上分析服務發出 HTTP GET 請求：GET /analytics/eth-whale-flow?days=30
第二步：服務回傳 402 服務回應 HTTP 402 Payment Required，並在回應 header 裡附帶：
X-Payment-Amount: 0.50 USDC
X-Payment-Address: 0xServiceWallet
X-Payment-Network: base
X-Payment-Nonce: abc123xyz
X-Payment-Expires: 1718456789
第三步：Agent 自動完成支付 Agent 從自己的錢包（有預先存入的 USDC）發送 0.50 USDC 到服務錢包，附帶 nonce abc123xyz 作為支付識別碼。交易在 Base 鏈上確認。
第四步：Agent 用付款證明重新請求 Agent 重新發出請求，在 header 裡附帶交易 hash 作為付款憑證：
X-Payment-TxHash: 0xPaymentTxHash
第五步：服務回傳數據 服務驗證付款後，回傳 HTTP 200 和完整的大戶資金流向分析數據。
整個流程耗時約 5-10 秒（含 Base 鏈確認時間），Agent 全自動完成，無需人類操作。支付金額 $0.50，相比傳統月費訂閱模式，Agent 只在真正使用時才付費。
x402 的核心取捨是「去中心化自主性 vs 成熟度與安全性」。
向上的一面：Agent 真正的自主支付能力，不需要人類帳戶或信用卡；支持超細粒度的按需付費（$0.001 級別）；全球化無地域限制；讓 A2A 多 Agent 協作的經濟模型成為可能。
向下的一面：生態系統目前仍不成熟，支援 x402 的服務商數量有限；Gas 費用讓超小額支付的成本比例過高（付 $0.001 但 Gas 要 $0.01）；沒有退款機制；Agent 錢包管理本身就是安全難題（私鑰怎麼存、怎麼設支出上限）；如果服務商或協議出現漏洞，Agent 可能被自動抽乾錢包。
當前最適合的場景：每次支付金額在 $0.10 以上（讓 Gas 費比例合理）、使用知名且有鏈上信譽的服務商、Agent 錢包裡只保留夠用的小額資金（不是主要資產）。