译者 | 涂承烨
审校 | 重楼
当你的购物代理自动购买了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
