譯者 | 涂承燁

審校 | 重樓

當你的購物代理自動購買了499美元的專業版套餐，而不是49美元的基礎版—責任應由誰承擔：用戶、代理開發者還是商家？這種信任鴻溝是目前支付渠道上代理主導結算的主要障礙。Google的代理支付協議（AP2）通過一個開放、可互操作的代理發起支付規范解決了這一問題，它定義了一種可加密驗證的通用語言，使得任何兼容的代理都能與全球任何兼容的商戶進行交易。

Google的代理支付協議（AP2）是一個開放的、供應商中立的規范，用于執行由AI代理發起的支付，并提供用戶意圖的加密可審計證明。AP2擴展了現有的開放協議—代理到代理（A2A）和模型上下文協議（MCP）—來定義代理、商戶和支付處理器如何在“意圖→購物車→支付”流程中交換可驗證的證據。其目標是在不分裂支付生態系統的情況下，彌合代理主導商務中的信任鴻溝。

https://github.com/google-agentic-commerce/AP2

為什么代理需要支付協議？

目前的支付渠道假設是由人類在可信的界面上點擊“購買”。當自主或半自主代理發起結算時，商戶和發卡機構面臨三個未解決的問題：（1）用戶的授權是否真正被委托（授權）；（2）請求是否反映了用戶意圖和批準的真實性（真實性）以及（3）如果出現問題，責任應由誰承擔（問責制）。AP2通過規范數據、加密和消息傳遞，以在提供商和支付類型之間一致地回答這些問題。

AP2如何建立信任？

AP2使用可驗證憑證（VCs）——防篡改、經加密簽名的數字對象——在交易中傳遞證據。該協議標準化了三種授權類型：

• 意圖授權（人不在場）：捕獲代理可以交易的條件（例如，品牌/類別、價格上限、時間窗口），并由用戶簽名。
• 購物車授權（人在場）：將用戶的明確批準與商戶簽名的購物車（商品、金額、貨幣）綁定，產生“所見即所付”的不可否認證明。
• 支付授權：向網絡/發卡機構傳達AI代理的參與情況，包括模式（人在場與不在場）和風險相關上下文。這些VCs形成了一條審計線索，明確將用戶授權與最終的扣款請求聯系起來。

核心角色和信任邊界是什么？

AP2定義了基于角色的架構，以分離關注點并最小化數據暴露：

• 用戶：將任務委托給代理。
• 用戶/購物代理（用戶交互的界面）：解釋任務、協商購物車并收集批準。
• 憑證提供者（例如，錢包）：持有支付方式并簽發特定于支付方式的憑證。
• 商戶端點：暴露目錄/報價并為購物車簽名。
• 商戶支付處理器：構建網絡授權對象。
• 網絡與發卡機構：評估并授權支付。

人在場與不在場：線上有何變化？

AP2定義了清晰、可測試的流程：

• 人在場：商戶簽署最終購物車；用戶在可信UI中批準它，生成簽名的購物車授權。處理器提交網絡授權以及支付授權。如果需要，增強驗證（例如，3DS）在可信界面上進行。
• 人不在場：用戶預先授權意圖授權（例如，“價格低于100美元時購買”）；代理稍后在條件滿足時將其轉換為購物車授權，或者商戶可以強制重新確認。

AP2如何與A2A和MCP組合使用？

AP2被指定為A2A（用于代理間消息傳遞）的擴展，并與MCP（用于工具訪問）互操作，因此開發者可以重用已有的發現、協商和執行能力。AP2專門處理支付層—標準化授權對象、簽名和問責信號—而將協作和工具調用留給A2A/MCP。

支持哪些支付方式？

該協議是支付方式無關的。初始重點涵蓋常見的基于拉取的支付工具（信用卡/借記卡），并計劃支持實時推送轉賬（例如，UPI、PIX）和數字資產。對于web3路徑，Google與合作伙伴發布了A2A x402擴展，以實施代理發起的加密支付，使x402與AP2的授權結構對齊。

對開發者來說，這看起來如何？

Google已發布一個公共倉庫（Apache-2.0），包含參考文檔、Python類型和可運行示例：

示例：演示人在場卡片流程、x402變體和Android數字支付憑證，展示如何簽發/驗證授權并從代理協商轉到網絡授權。

類型包：核心協議對象可在src/ap2/types下獲取以供集成。

框架選擇：雖然示例使用Google的ADK和Gemini 2.5 Flash，但AP2是框架無關的；任何代理棧都可以生成/驗證授權并使用該協議。

AP2如何解決隱私和安全問題？

AP2的角色分離確保敏感數據（例如，主賬號PAN、令牌）保留在憑證提供者處，無需流經通用代理界面。授權使用可驗證身份簽名，并可以嵌入風險信號而不會向對方暴露完整憑證。這與現有控制（例如，增強驗證）一致，并向網絡提供明確的代理參與標記，以支持風險和爭議邏輯。

生態系統準備情況如何？

Google引用與60多個組織的合作，涵蓋網絡、發卡機構、網關和技術供應商（例如，美國運通、萬事達卡、PayPal、Coinbase、Intuit、ServiceNow、銀聯國際、Worldpay、Adyen）。目標是通過在跨平臺上對齊通用授權語義和問責信號來避免一次性集成。

實現說明和邊緣情況

• 確定性優于推斷：商戶接收用戶批準（購物車）或預先授權（意圖）的加密證據，而不是模型生成的摘要。
• 爭議：憑證鏈作為網絡/發卡機構的證據材料；問責可以根據哪個授權被簽署以及由誰簽署來分配。
• 挑戰：發卡機構或商戶可以觸發增強驗證；AP2要求挑戰在可信界面上完成并與授權路徑鏈接。
• 多代理：當多個代理參與時（例如，旅游元搜索+航空公司+酒店），A2A協調任務；AP2確保每個購物車在支付提交前由商戶簽名和用戶授權。

下一步是什么？

AP2團隊計劃公開演進規范，并繼續添加參考實現，包括跨網絡和web3的更深度集成，以及與標準機構在VC格式和身份原語上的對齊。開發者今天即可開始，通過運行示例場景、集成授權類型，并針對其代理/商戶棧驗證流程。

總結

AP2為代理生態系統提供了一種具體的、基于加密的方法來證明用戶授權，將其與商戶簽名的購物車綁定，并向發卡機構提供可審計的記錄—而無需將開發者鎖定在單一棧或支付方式中。如果代理將代表我們購買物品，這正是支付系統所需的證據路徑。

譯者介紹

涂承燁，51CTO社區編輯，具有18年以上的開發、項目管理、咨詢設計等經驗，獲得系統架構師設計師、信息系統項目管理師、信息系統監理師、PMP，CSPM-2等認證。

原文標題：Google AI Introduces Agent Payments Protocol (AP2): An Open Protocol for Interoperable AI Agent Checkout Across Merchants and Wallets，作者：Asif Razzaq