【Agentic Payment 系列 #2】信任的代價：AP2 授權機制、A2A 支付整合與三大協議戰場劃分
當 AI Agent 能自主花錢，誰來證明它受到授權？深入 AP2 的三種 Mandate 設計、A2A 與 x402 的整合擴展，以及 x402、L402、MPP 三大支付協議的技術對比與適用場景。
本文為 Agentic Payment 系列第二篇。建議依序閱讀： → 【Agentic Payment 系列 #1】HTTP 402 沉睡三十年後醒來：x402 如何讓支付成為網際網路的一等公民
上一篇，我們拆解了 x402 如何讓支付語義嵌入 HTTP 協議，讓 AI Agent 能在毫秒級完成鏈上結算。但 x402 刻意只做「支付執行」這一件事 —— 它不回答一個更深層的問題：
這個 Agent 的行為，真的是人類授權的嗎？
想像一個場景：你的購物 Agent 因為 LLM（大型語言模型）的 Hallucination（幻覺）問題，將你「幫我找一雙 200 美元以內的跑鞋」的指令，理解成「買一雙 2,000 美元的限量聯名款」。x402 很稱職地完成了鏈上支付 —— 錢已經轉走了。然後呢？誰負責？
這就是 AP2 要解決的問題。
AP2：為 Agent 行為建立可驗證的信任鏈
2025 年 9 月，Google 聯合多個支付巨頭推出了 Agent Payments Protocol（AP2）。如果說 x402 是 Agent 經濟的「支付執行層」，AP2 則是其「信任與意圖層」。
AP2 的核心技術手段是 VDC（Verifiable Digital Credentials，可驗證數位憑證）。它不僅處理 Stablecoin 支付，還支持傳統的信用卡與銀行轉帳 —— 換言之，AP2 是 Payment Agnostic（與支付方式無關） 的框架。它關心的不是「錢怎麼轉」，而是「這筆交易的授權鏈是否完整且可審計」。
AP2 面對的信任危機有三個維度：
- 授權驗證：商家如何確認 Agent 的行為確實由真人授權？
- 意圖忠實度：Agent 對使用者自然語言指令的理解是否準確？
- 責任歸屬：交易出錯時，開發商、平台還是使用者承擔責任？
三種 Mandate：Intent → Cart → Payment 的授權鏈
AP2 將授權過程標準化為三種核心的 Mandate（授權指令） 物件，並以密碼學連結串成一條 Intent → Cart → Payment 的授權鏈：每一環回答一個不同的問題、由不同角色簽署、鎖定不同的內容。
1. Intent Mandate（意圖授權）
回答的問題：使用者授權了嗎？ 簽署者：使用者（User）。
適用場景：人類不在場（Human-out-of-the-Loop）—— 這是 AP2 最具突破性的設計。
當使用者告訴助理「幫我找一雙 200 美元以內的防水鞋」時，Shopping Agent 會產生 Intent Mandate，由使用者簽署，鎖定意圖條件、額度與有效期（TTL）。除了預算上限，最關鍵的欄位是 Prompt Playback（提示詞回放）。
Prompt Playback 是 Agent 對使用者自然語言指令的自我理解紀錄。它會被呈現給使用者確認並簽署，形成一個密碼學上不可否認的證據：Agent「理解的內容」=「使用者確認的內容」。
這個設計直接針對 Hallucination 問題。如果 Agent 將「200 美元以內」理解成「2,000 美元」，Prompt Playback 的內容會在使用者簽署前清楚呈現。如果使用者確認簽署了一個包含錯誤理解的 Prompt Playback —— 那責任歸屬就有了明確的密碼學證據。
那之後怎麼辦？分兩種情況。如果使用者簽署前就發現不對勁、直接拒簽，Intent Mandate 根本不會進到 authorized 狀態，錢一分都不會動。如果使用者看了沒發現問題、確認簽署了，那平台和開發商的責任基本上就算解除了——你親手蓋章的，能怪誰？萬一事後還是想走申訴，Payment Mandate 裡的 Agent Attribution 訊號會讓銀行知道「這是機器下的單」，可以按不同規則走 Chargeback（拒付）流程；加上 Prompt Playback 的簽章白紙黑字擺在那，比口頭說「我當時沒這個意思」有力多了。
這招的精妙之處在於：它不試圖解決 AI 幻覺問題本身（那是模型層的事），而是建立了一個機制讓幻覺在造成經濟損失之前被攔截。
2. Cart Mandate（購物車授權）
回答的問題：買的東西對嗎？ 簽署者：商家（Merchant）。
適用場景：Agent 依據 Intent Mandate 完成選品、準備結帳。
當 Shopping Agent 完成選購後，Merchant（商家）產生 Cart Mandate，由商家簽署，鎖定最終購物車品項與價格：
- 商品項目與數量
- 金額與幣種
- 受款人身份
- 配送地址
關鍵在於：Cart Mandate 會引用 Intent Mandate 的 Intent Hash，承接使用者當初授權的範疇。這道密碼學連結防止商家偽造訂單或超出授權範圍（超綱）—— 商家無法塞進一雙使用者從未同意的 2,000 美元鞋子。在人類在場（Human-in-the-Loop）的流程中，使用者還會透過 Biometric（生物識別，如 FaceID）或 Hardware Key（硬體密鑰）額外確認這份購物車。
Cart Mandate 本質上是傳統電商結帳流程的協議化表達 —— 差別在於它生成了一個可驗證的數位憑證，而非僅僅依賴 Session Cookie。
3. Payment Mandate（支付授權）
回答的問題：怎麼付款？ 簽署者：憑證發行方（Credentials Provider）。
適用場景：傳遞給發卡銀行或結算網路。
Payment Mandate 由憑證發行方簽署，鎖定付款方式與 Human-Not-Present（人類不在場）風控訊號。它包含交易的 Agent Attribution（代理人歸屬） 訊號，明確告知銀行：這是一次由機器發起的交易。附帶的風險分佈數據讓銀行能對 Agent 交易應用不同的風險控制模型 —— 例如對高頻小額 Agent 交易設定不同於人類消費的欺詐偵測 threshold（CSA）。
Payment Mandate 與 Cart Mandate 之間採用雙憑證強綁定，將購物車與付款憑證在密碼學上鎖定 —— 確保「使用者同意購買的東西」與「實際付款的內容」完全一致，無法被中途調包。
三種 Mandate 以密碼學連結串成一條完整的授權鏈，每一環都有簽名作為不可否認的審計證據：
| Mandate | 回答的問題 | 簽署者 | 鎖定什麼 |
|---|---|---|---|
| Intent | 使用者授權了嗎？ | 使用者（User） | 意圖條件、額度與有效期 |
| Cart | 買的東西對嗎？ | 商家（Merchant） | 最終購物車品項與價格 |
| Payment | 怎麼付款？ | 憑證發行方（Credentials Provider） | 付款方式與 Human-Not-Present 風控訊號 |
版本註記：本文描述的 Intent / Cart / Payment 三段式 Mandate 對應 AP2 v0.1（2025/9）的模型。AP2 後續版本（v0.2）已將其重構為 Checkout Mandate 與 Payment Mandate 兩類、各含 Open 與 Closed 兩個階段，並移交 FIDO Alliance 進行標準化。核心的「意圖 → 購物車 → 付款」授權鏈邏輯不變，但欄位命名與分層已調整 —— 對照官方最新規格時需留意。
→ 【Agentic Payment 系列 #5】沒有人看到全貌：AP2 v0.2 用兩張 Mandate 重寫 Agent 的授權邊界
兩種流程：人類在場 vs. 人類不在場
同樣三種 Mandate，會依「交易當下使用者在不在場」組成兩條不同的流程。差別的關鍵在於 Cart Mandate 由誰、在什麼時候簽署。
Human-Present（人類在場）
使用者全程參與結帳的即時流程。Agent 完成選品後，把購物車攤在使用者面前，由使用者透過 Biometric（生物識別，如 FaceID）或 Hardware Key（硬體密鑰）當場確認並簽署 Cart Mandate。這條路徑最接近傳統電商的結帳體驗 —— Agent 只是把商品湊齊，最後拍板的仍是真人。
Human-Not-Present（人類不在場）
使用者事先授權、之後不在場的委託流程 —— 這是 AP2 最具突破性的設計。使用者先簽署一份鎖定意圖條件、額度與有效期（TTL）的 Intent Mandate，Agent 便可在授權範疇內自主完成後續的選品與結帳，無需使用者再次介入。當條件滿足時（例如指定商品降到目標價），Agent 依據 Intent Mandate 產生並提交 Cart Mandate，整段交易在使用者離線的狀態下完成。
兩者的信任基礎不同：Human-Present 靠的是當下的即時確認，Human-Not-Present 靠的是事前簽署的 Intent Mandate 與 Prompt Playback —— 後者正是讓 Agent 能真正「代人花錢」的關鍵。
版本註記：上述兩種流程對應 AP2 v0.1（2025/9）以三段式 Mandate 為基礎的模型。v0.2 已將 Cart Mandate 重構為 Checkout Mandate（各含 Open 與 Closed 兩階段）並移交 FIDO Alliance 標準化，人類在場／不在場的流程劃分與簽署時點也隨之調整 —— 對照官方最新規格時需留意。
AP2 交易生命週期與 VCAP 託管綁定
AP2 的交易狀態從 created → authorized → captured → settled，每一步都有明確的狀態轉移規則（IETF VCAP-AP2 草案）。
然而，在自主交易中，一個 x402 解決不了的問題浮現了：如果 Agent 已經付了錢（captured），但服務沒有交付，怎麼辦？
AP2 透過與 VCAP（Verified Commerce for Agent Protocols，代理人協議驗證商務） 的綁定來解決這個問題。VCAP 引入了 Escrow State Machine（託管狀態機），概念上很像你熟悉的第三方支付擔保：買家先把錢押給中間人，賣家交付後才能拿到錢。差別只在於 VCAP 把「確認收貨」這個人工步驟，換成了機器自動驗證的密碼學證明：
- 當 AP2 交易進入
authorized階段，資金被鎖定在 Escrow（託管帳戶）中 - 服務提供方執行任務
- 服務交付後，由驗證方產生機器可驗證的交付證明（IETF 草案中的
verification_proof，內含 proof_hash 與 proof_signature 雙重簽章） - Escrow 狀態機驗證此證明通過後，資金才釋放給商家
這套機制實現了 Delivery-versus-Payment（交付即支付） 的原子性 —— 要麼同時完成交付與付款，要麼兩者都不發生。對於 Agent 之間的商業互動，這提供了遠超簡單匯款的信任保障（A402 論文）。
A2A：為支付層補上「協作引擎」
支付能力有了（x402），信任機制有了（AP2），但還缺一塊 —— Agent 之間要怎麼找到彼此、溝通需求、協調分工？
這正是 A2A（Agent-to-Agent） 協議的角色。Google Cloud 於 2025 年 4 月發布 A2A 協議，並於同年 6 月將其捐贈給 Linux Foundation，讓來自不同雲端環境、使用不同 LLM 的 Agent 能夠安全地相互發現並協作。
如果你想深入了解 A2A 的技術核心（Agent Card、Task 狀態機、安全架構），推薦閱讀 A2A 系列文章，本文聚焦於 A2A 在支付經濟體系中的角色。
A2A 有三大組成部分與支付場景直接相關：
Agent Card（代理卡片）
每個 Agent 在 /.well-known/agent-card.json（A2A 早期版本為 agent.json）發布的 JSON 文件，描述其身份、技能（Skills）與身份驗證方案。在支付場景中，Agent Card 可以額外宣告支持的支付協議（如 x402）與接受的幣種。
Task Lifecycle（任務生命週期）
A2A 任務是異步的，支持透過 SSE（Server-Sent Events） 回傳即時進度。這比同步的 HTTP 請求更適合需要多步驟完成的 Agent 工作流 —— 例如「搜尋最佳價格 → 比較選項 → 確認購買 → 等待交付確認」的完整購物流程。
A2A + x402 擴展
Google 開發了 a2a-x402 擴展，將支付環節無縫嵌入 A2A 的任務協作中。以下是一個具體場景：
- 一個醫療診斷 Agent（A2A Client）將影像分析任務委派給遠端的專業影像 Agent（A2A Server）
- 影像 Agent 在 A2A 的任務響應中返回 x402 挑戰：「分析這張 CT Scan 需要 $0.50 USDC」
- 診斷 Agent 利用其錢包自動支付
- 影像分析結果透過 A2A 協議回傳
溝通層（A2A）+ 信任層（AP2）+ 支付層（x402） 的組合，構成了一個完整的機器經濟體系。Agent 不僅能找到彼此、協調分工，還能在過程中自主完成有信任保障的價值交換。
技術深度對比：x402 vs. L402 vs. MPP
HTTP 402 的實現不只有 x402 一家。L402（Lightning 402） 由 Lightning Labs 於 2020 年提出（最初名為 LSAT，Lightning Service Authentication Token，2023 年更名為 L402），MPP（Machine Payments Protocol） 則由 Stripe 與 Tempo 於 2026 年 3 月 18 日、伴隨 Tempo 主網上線一同發布。三者在技術細節上的差異，決定了各自的最佳適用場景。
x402 vs. L402：Stablecoin 路線 vs. Bitcoin 路線
L402 把 402 狀態碼接上了 Bitcoin Lightning Network（比特幣閃電網路），核心授權機制用的是 Macaroons —— 一種基於 HMAC 的 Bearer Token（承載令牌）。
怎麼授權不一樣：L402 的邏輯是「先付錢、再拿鑰匙」—— Client 付完 Lightning Invoice（閃電發票）拿到一個有時限的 Token，後續用這個 Token 來驗身存取資源。x402 則是「一筆請求、一筆支付」的 Stateless（無狀態）模式，用 EIP-3009 直接鏈上授權，完全不用管 Token 的有效期和刷新問題。
網路體質也不同：Lightning Network 雖然快，但背後要維護通道（Channel Management），一旦路由失敗（Routing Failure）就很麻煩。x402 靠 Stablecoin 在 L2 上結算，價格穩（不會因 BTC 暴跌突然變貴）、延遲壓在 200 毫秒左右，也沒有通道容量的上限卡著。
x402 vs. MPP：一刀一刀付 vs. 先開個記帳本
MPP 比較像個「協調層」（Tenzro），思路和 x402 根本不同。
先開帳、後消費：MPP 是 Session-oriented（面向會話）的。你可以先授權一個 $10 的額度，Agent 在整個工作期間就像在酒吧開了一張酒單，喝一杯記一筆，不用每次請求都跑去鏈上簽名。對於要跑好幾個小時的複雜研究任務，這比 x402 的逐筆支付順多了。
兩條軌道都能走：MPP 同時支援「鏈上模式」（Stablecoin）和「卡片模式」（Visa Tokenized Credential），加密貨幣的效率和傳統金融的合規可以並存。對於要對接公司既有財務系統的企業來說，這個彈性很關鍵。
三大協議對比總覽
| 比較維度 | x402 (Coinbase) | L402 (Lightning Labs) | MPP (Stripe) |
|---|---|---|---|
| 結算軌道 | Ethereum L2 / Solana | Bitcoin Lightning Network | 混合（Crypto + Card） |
| 狀態性質 | Stateless（無狀態） | Stateful（Bearer Token） | Stateful（Session-based） |
| 授權技術 | EIP-3009 / Permit2 | Macaroons | Credentials / Receipts |
| 微型支付顆粒度 | 每個請求獨立結算 | 購買單次存取權杖 | 會話內流式支付 |
| 價格穩定性 | 高（Stablecoin） | 低（BTC 波動） | 高（多軌道） |
| 最佳適用場景 | 原子性 API 調用 | 內容訂閱與付費牆 | 複雜、長期的 Agent 任務 |
這三個協議不是零和賽局。更可能的未來是：x402 處理高頻、低金額的 API 微型支付；MPP 管理長時間的 Agent 工作會話；L402 在 Bitcoin 生態內服務特定社群。就像 TCP、UDP 和 QUIC 共存一樣 —— 不同的工作負載，需要不同的傳輸語義。
真正的戰場不在支付，而在信任的定義權
回頭看這三層堆疊 —— A2A 負責溝通、AP2 負責信任、x402/L402/MPP 負責結算 —— 你會發現一個容易被忽略的事實：最難標準化的不是錢怎麼轉，而是「授權」這件事到底該由誰定義。
支付協議的競爭，表面上是結算軌道之爭（Stablecoin vs. Bitcoin vs. Card），骨子裡卻是誰能掌握 Mandate 格式、誰的憑證被銀行與商家接受、誰的信任鏈成為預設選項。x402 只做支付執行、刻意不碰授權，正是因為它清楚：一旦定義了「什麼叫合法授權」，就等於接管了整個責任歸屬體系 —— 那是遠比手續費更值錢的位置。AP2 選擇站上這個位置，也就選擇了承擔整個機器經濟的信任治理權。
於是問題從「Agent 能不能自己花錢」升級成「當一個 Agent 代表你簽下 Mandate 時，這條授權鏈的規則是誰寫的」。這不是密碼學能單獨回答的問題，它牽涉到監管、責任分配與市場結構 —— 而這，正是下一篇要拆解的兆美元賽道。
下一篇：【Agentic Payment 系列 #3】兆美元賽道：Agent 經濟的市場、合規與 Web 4.0 支付堆疊
如果這篇文章對你有幫助，歡迎分享給對 Agent 經濟與 Web3 支付感興趣的朋友。