谷歌的代理支付协议(AP2)
谷歌的代理支付协议(AP2)是一个新宣布的开放标准,旨在实现由AI代理代表用户发起的安全、可信交易。AP2与超过60个支付和技术组织(包括主要支付网络、银行、金融科技公司和Web3公司)合作开发,建立了"代理支付"的通用语言 —— 即自主代理(如AI助手或基于LLM的代理)可以为用户执行的购买和金融交易。AP2的创建源于一个根本性转变:传统上,在线支付系统假设有人类直接点击"购买",但AI代理按用户指令行动的兴起打破了这一假设。AP2解决了AI驱动商务中授权、真实性和问责制的挑战,同时与现有支付基础设施保持兼容。本报告检视了AP2的技术架构、目的和用例、与AI代理和支付提供商的集成、安全性和合规性考虑、与现有协议的比较、对Web3/去中心化系统的影响,以及行业采用/路线图。
技术架构:AP2如何工作
AP2的核心引入了一个密码学安全的交易框架,基 于可验证数字凭证(VDCs)—— 本质上是防篡改的签名数据对象,作为用户授权内容的数字"合约"。在AP2术语中,这些合约被称为授权书,它们为每笔交易形成可审计的证据链。AP2架构中有三种主要的授权书类型:
- 意图授权书: 捕获用户对购买的初始指令或条件,特别是在*"无人在场"场景中(代理将在用户不在线时稍后行动)。它定义了用户给予代理的授权范围* —— 例如,"如果音乐会门票降到200美元以下,最多买2张"。这个授权书由用户预先加密签名,作为在特定限制内同意的可验证证明。
- 购物车授权书: 代表用户已批准的最终交易详情,用于*"有人在场"*场景或结账时刻。它包括确切的商品或服务、价格和购买的其他细节。当代理准备完成交易时(例如填满购物车后),商家首先对购物车内容进行加密签名(保证订单详情和价格),然后用户(通过其设备或代理界面)签署创建购物车授权书。这确保了所见即所付,准确锁定向用户呈现的最终订单。
- 支付授权书: 发送给支付网络(如卡网络或银行)的单独凭证,表明AI代理参与了交易。支付授权书包含元数据,如用户在授权期间是否在场,并作为风险管理系统的标志。通过向收单银行和发卡银行提供用户意图的密码学可验证证据,这个授权书帮助它们评估上下文(例如,区分代理发起的购买与典型欺诈)并相应地管理合规或责任。
所有授权书都实现为由相关方密钥(用户、商家等)签名的可验证凭证,为每个代理主导的交易产生不可否认的审计跟踪。实际上,AP2使用基于角色的架构来保护 敏感信息 —— 例如,代理可能处理意图授权书而从不看到原始支付详情,这些详情只在需要时以受控方式披露,保护隐私。用户意图 → 商家承诺 → 支付授权的密码学链建立了各方之间的信任,确保交易反映用户的真实指令,并且代理和商家都遵守了这些指令。
交易流程: 为说明AP2如何端到端工作,考虑一个有人参与的简单购买场景:
- 用户请求: 用户要求其AI代理购买特定商品或服务(如"为我订购这双鞋,我的尺码")。
- 购物车构建: 代理与商家系统通信(使用标准API或通过代理对代理交互)为指定商品按给定价格组装购物车。
- 商家保证: 在向用户展示购物车之前,商家端对购物车详情(商品、数量、价格等)进行加密签名。这一步创建了商家签名报价,保证确切条款(防止任何隐藏更改或价格操控)。
- 用户批准: 代理向用户显示最终购物车。用户确认购买,此批准触发用户端的两个加密签名:一个在购物车授权书上(接受商家的购物车现状)和一个在支付授权书上(通过选定的支付提供商授权支付)。这些签名授权书然后分别与商家和支付网络共享。
- 执行: 有了购物车授权书和支付授权书,商家和支付提供商继续安全执行交易。例如,商家向支付网络(卡网络、银行等)提交支付请求以及用户批准证明,支付网络可以验证支付授权书。结果是完成的购买交易,带有密码学审计跟踪将用户意图与最终支付联系起来。
这个流程展示了AP2如何在AI驱动购买的每一步都建立信任。商家有用户同意以什么价格购买什么的密码学证明,发卡行/银行有用户授权该支付的证明,即使AI代理促成了这个过程。在争议或错误的情况下,签名授权书作为明确证据,帮助确定问责(例如,如果代理偏离指令或如果费用不是用户批准的)。实质上,AP2的架构确保可验证的用户意图 —— 而不是对代理行为的信任 —— 是交易的基础,大大减少了模糊性。
AP2的目的和用例
为什么需要AP2: AP2的主要目的是解决当AI代理可以代表用户花钱时出现的新兴信任和安全问题。谷歌及其合作伙伴确定了当自主代理在循环中时,今天的支付基础设施无法充分回答的几个关键问题:
- 授权: 如何证明用户实际给了代理进行特定购买的权限?(换句话说,确保代理不是在没有用户知情同意的情况下购买东西。)
- 真实性: 商家如何知道代理的购买请求是真实的,反映了用户的真实意图,而不是错误或AI幻觉?
- 问责制: 如果通过代理发生欺诈或错误交易,谁负责 —— 用户、商家、支付提供商,还是AI代理的创造者?
没有解决方案,这些不确定性围绕代理主导的商务创造了"信任危机"。AP2的使命是通过建立安全代理交易的统一协议来提供解决方案。通过引入标准化的授权书和意图证明,AP2防止了分散的生态系统,避免每个公司发明自己的临时代理支付方法。相反,任何符合要求的AI代理都可以在一套通用规则和验证下 与任何符合要求的商家/支付提供商交互。这种一致性不仅避免了用户和商家的困惑,还为金融机构提供了管理代理发起支付风险的明确方式,而不是处理专有方法的拼接。简而言之,AP2的目的是成为让"代理经济"在不破坏支付生态系统的情况下增长的基础信任层。
预期用例: 通过解决上述问题,AP2为超越人类手动点击购买可能性的新商务体验和用例打开了大门。AP2支持的一些代理启用商务示例包括:
- 更智能的购物: 客户可以指示其代理,"我想要这件绿色冬季夹克,我愿意支付比当前价格高20%"。有了编码这些条件的意图授权书,代理将持续监控零售商网站或数据库。一旦夹克有绿色可选(并在价格阈值内),代理自动执行购买带有安全的签名交易 —— 捕获否则会错过的销售。从用户的初始请求到自动结账的整个交互都由AP2授权书管理,确保代理只购买授权的确切内容。
- 个性化优惠: 用户告诉其代理他们正在寻找来自特定商家的特定产品(比如新自行车)用于即将到来的旅行。代理可以与商家自己的AI代理分享这种兴趣(在意图授权书的边界内),包括相关上下文如旅行日期。商家代理知道用户的意图和上下文,可以回应定制套餐或折扣 —— 例如,"自行车+头盔+旅行架15%折扣,48小时内有效"。使用AP2,用户的代理可以安全地接受并完成这个定制优惠,将简单查询转变为商家更有价值的销售。
- 协调任务: 用户计划复杂任务(如周末旅行)完全委托它:"为这些日期预订航班和酒店,总预算700美元"。代理可以与多个服务提供商的代理交互 —— 航空公司、酒店、旅行平台 —— 找到符合预算的组合。一旦确定了合适的航班-酒店套餐,代理使用AP2执行一次性多个预订,每个都经过加密签名(例如,为航空公司和酒店分别发出购物车授权书,都在用户的意图授权书下授权)。AP2确保这个协调交易的所有部分都按批准发生,甚至允许同时执行,这样门票和预订一起预订,没有一部分中途失败的风险。
这些场景只说明了AP2预期用例的一小部分。更广泛地说,AP2的灵活设计支持传统电商流程和全新的商务模式。例如,AP2可以促进类似订阅的服务(代理通过在满足条件时购买来保持你的必需品库存)、事件驱动购买(在触发事件发生瞬间购买门票或商品)、群体代理谈判(多个用户的代理汇集授权书来讨价还价群体交易),以及许多其他新兴模式。在每种情况下,共同点是AP2提供信任框架 —— 明确的用户授权和密码学可审计性 —— 允许这些代理驱动的交易安全发生。通过处理信任和验证层,AP2让开发者和企业专注于创新新的AI商务体验,而无需从头重新发明支付安全。
与代理、LLMs和支付提供商的集成
AP2明确设计为与AI代理框架和现有支付系统无缝集成,充当两者之间的桥梁。谷歌将AP2定位为其代理对代理(A2A)协议和模型上下文协议(MCP)标准的扩展。换句话说,如果A2A为代理通信任务提供通用语言,MCP标准化AI模型如何整合上下文/工具,那么AP2在 顶部添加了交易层用于商务。这些协议是互补的:A2A处理代理对代理通信(允许比如购物代理与商家代理对话),而AP2在这些交互中处理代理对商家支付授权。因为AP2是开放和非专有的,它意味着与框架无关:开发者可以将其与谷歌自己的代理开发工具包(ADK)或任何AI代理库一起使用,同样它可以与包括LLMs在内的各种AI模型工作。例如,基于LLM的代理可以通过生成和交换所需的授权书负载(由AP2规范指导)而不是仅仅自由形式文本来使用AP2。通过强制执行结构化协议,AP2帮助将AI代理的高级意图(可能来自LLM的推理)转换为具体的安全交易。
在支付方面,AP2是与传统支付提供商和标准协调构建的,而不是作为撕裂和替换系统。该协议是支付方法无关的,意味着它可以支持各种支付轨道 —— 从信用/借记卡网络到银行转账和数字钱包 —— 作为转移资金的底层方法。在其初始版本中,AP2强调与卡支付的兼容性,因为这些在在线商务中最常见。AP2支付授权书设计为插入现有的卡处理流程:它为支付网络(如Visa、万事达、美国运通)和发卡银行提供额外数据,表明AI代理参与以及用户是否在场,从而补充现有的欺诈检测和授权检查。本质上,AP2不处理支付本身;它用用户意图的密码学证明增强支付请求。这允许支付提供商以适当的谨慎或速度处理代理发起的交易(例如,如果发卡行看到有效的AP2授权书证明用户预先批准了它,可能会批准看起来不寻常的购买)。值得注意的是,谷歌和合作伙伴计划发展AP2以支持"推送"支付方法 —— 如实时银行转账(如印度的UPI或巴西的PIX系统)—— 以及其他新兴数字支付类型。这表明AP2的集成将扩展到卡之外,与全球现代支付趋势保持一致。
对于商家和支付处理商,集成AP2将意味着支持额外的协议消息(授权书)和验证签名。许多大型支付平台已经参与塑造AP2,所以我们可以期待它们会构建对它的支持。例如,像Adyen、Worldpay、PayPal、Stripe(没有明确提及但可能感兴趣)等公司可能会将AP2整合到其结账API或SDK中,允许代理以标准化方式发起支付。因为AP2是GitHub上带有参考实现的开放规范,支付提供商和技术平台可以立即开始实验。谷歌还提到了一个AI代理市场,第三方代理可以在其中列出 —— 这些代理预期支持AP2的任何交易能力。实际上,构建AI销售助手或采购代理的企业可以将其列在这个市场上,感谢AP2,该代理可以可靠地执行购买或订单。
最后,AP2的集成故事受益于其广泛的行业支持。通过与主要金融机构和技术公司共同开发协议,谷歌确保AP2与现有行业规则和合规要求保持一致。与支付网络(如万事达、银联)、发卡行(如美国运通)、金融科技公司(如Revolut、PayPal)、电商玩家(如Etsy)甚至身份/安全提供商(如Okta、Cloudflare)的合作表明AP2正在设计为以最小摩擦嵌入现实世界系统。这些利益相关者在KYC(了解你的客户法规)、欺诈预防和数据隐私等领域带来了专业知识,帮助AP2开箱即用地解决这些需求。总之,AP2构建为代理友好和支付提供商友好:它扩展现有AI代理协议来处理交易,并在现有支付网络之上分层以利用其基础设施,同时添加必要的信任保证。