)
谷歌的代理支付协议（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代理协议来处理交易，并在现有支付网络之上分层以利用其基础设施，同时添加必要的信任保证。
安全性、合规性和互操作性考虑
安全性和信任是AP2设计的核心。协议使用密码学（对授权书的数字签名）确保代理交易中的每个关键操作都是可验证和可追踪的。这种不可否认性是至关重要的：用户和商家都不能后来否认被授权和同意的内容，因为授权书作为安全记录。直接好处是在欺诈预防和争议解决方面 —— 使用AP2，如果恶意或有缺陷的代理尝试未授权购买，缺乏有效用户签名授权书将是明显的，交易可以被拒绝或撤销。相反，如果用户声称"我从未批准这次购买"，但存在带有其密码学签名的购物车授权书，商家和发卡行有强有力的证据支持费用。这种问责的清晰度回答了支付行业的主要合规关切。
授权和隐私： AP2强制执行代理主导交易的明确授权步骤，这与强客户认证等监管趋势保持一致。融入AP2的用户控制原则意味着代理不能花费资金，除非用户（或用户委托的人）提供了可验证的指令。即使在完全自主场景中，用户也通过意图授权书预定义规则。这种方法可以被视为类似于给代理特定交易的授权委托书，但以数字签名、细粒度的方式。从隐私角度来看，AP2注意数据共享：协议使用基于角色的数据架构来确保敏感信息（如支付凭证或个人详情）只与绝对需要它的各方共享。例如，代理可能向商家发送包含商品和价格信息的购物车授权书，但用户的实际卡号可能只通过支付授权书与支付处理商共享，而不与代理或商家共享。这最小化了数据的不必要暴露，有助于遵守隐私法和处理支付数据的PCI-DSS规则。
合规性和标准： 因为AP2是在既定金融实体的输入下开发的，它被设计为满足或补充支付中的现有合规标准。该协议不绕过通常的支付授权流程 —— 相反，它用额外的证据和标志增强它们。这意味着AP2交易仍然可以利用欺诈检测系统、3-D安全检查或任何需要的监管检查，AP2的授权书作为额外的认证因素或上下文线索。例如，银行可以将支付授权书视为类似于客户在交易上的数字签名，可能简化 用户同意要求的合规性。此外，AP2的设计者明确提到与"行业规则和标准协调"工作。我们可以推断，随着AP2的发展，它可能被带到正式的标准机构（如W3C、EMVCo或ISO）以确保它与全球金融标准保持一致。谷歌已表示承诺通过标准组织开放、协作地发展AP2。这个开放过程将有助于解决任何监管关切并实现广泛接受，类似于之前的支付标准（EMV芯片卡、3-D安全等）如何经历行业范围的合作。
互操作性： 避免分散是AP2的关键目标。为此，协议是公开发布的，任何人都可以实现或集成。它不与谷歌云服务绑定 —— 实际上，AP2是开源（Apache-2许可），规范加上参考代码在公共GitHub存储库中。这鼓励互操作性，因为多个供应商可以采用AP2，他们的系统仍然可以协同工作。已经，互操作性原则被强调：AP2是现有开放协议（A2A、MCP）的扩展，是非专有的，意味着它促进了实现的竞争生态系统，而不是单一供应商解决方案。实际上，公司A构建的AI代理可以与公司B的商家系统发起交易，如果两者都遵循AP2 —— 双方都不锁定到一个平台。
一个可能的关切是确保一致的采用：如果一些主要玩家选择不同的协议或封闭方法，分散仍可能发生。然而，鉴于AP2背后的广泛联盟，它似乎准备成为事实标准。许多身份和安全专注公司（例如Okta、Cloudflare、Ping Identity）在AP2生态系统中的包含*图：超过60家跨金融、技术和加密的公司正在AP2上合作（合作伙伴的部分列表）。*表明互操作性和安全性正在共同解决。这些合作伙伴可以帮助将AP2集成到身份验证工作流程和欺诈预防工具中，确保AP2交易可以在系统间信任。
从技术角度来看，AP2使用广泛接受的密码学技术（可能基于JSON-LD或JWT的可验证凭证、公 钥签名等）使其与现有安全基础设施兼容。组织可以使用其现有的PKI（公钥基础设施）来管理签名授权书的密钥。AP2似乎也预期与去中心化身份系统的集成：谷歌提到AP2创造了在代理授权的去中心化身份等领域创新的机会。这意味着未来，AP2可以利用DID（去中心化标识符）标准或去中心化标识符验证，以可信方式识别代理和用户。这种方法将通过不依赖任何单一身份提供商进一步增强互操作性。总之，AP2通过密码学和明确问责强调安全性，旨在通过设计准备合规，并通过其开放标准性质和广泛行业支持促进互操作性。
与现有协议的比较
AP2是一个新颖的协议，解决了现有支付和代理框架未涵盖的空白：使自主代理能够以安全、标准化的方式执行支付。在代理通信协议方面，AP2建立在先前的工作之上，如代理对代理（A2A）协议。A2A（2025年早期开源）允许不同的AI代理互相交谈，无论其底层框架如何。然而，A2A本身没有定义代理应该如何进行交易或支付 —— 它更多是关于任务谈判和数据交换。AP2通过添加任何代理在对话导致购买时可以使用的交易层来扩展这个景观。实质上，AP2可以被视为A2A和MCP的补充，而不是重叠：A2A涵盖通信和协作方面，MCP涵盖使用外部工具/API，AP2涵盖支付和商务。它们一起形成了未来"代理经济"的标准栈。这种模块化方法有些类似于互联网协议：例如，用于数据通信的HTTP和用于安全的SSL/TLS —— 这里A2A可能像代理的HTTP ，AP2是商务顶部的安全交易层。
当将AP2与传统支付协议和标准比较时，既有相似之处也有差异。传统在线支付（信用卡结账、PayPal交易等）通常涉及如HTTPS的安全传输协议，以及如PCI DSS的处理卡数据标准，加上可能的3-D安全的额外用户认证。这些假设用户驱动的流程（用户点击并可能输入一次性代码）。相比之下，AP2引入了第三方（代理）参与流程的方式，而不破坏安全性。可以将AP2的授权书概念与OAuth风格的委托授权的扩展进行比较，但应用于支付。在OAuth中，用户可以通过令牌授予应用程序对账户的有限访问；类似地在AP2中，用户通过授权书在某些条件下授予代理花费的权力。关键差异是AP2的"令牌"（授权书）是金融交易的特定签名指令，比现有支付授权更细粒度。
另一个比较点是AP2如何与现有电商结账流程相关。例如，许多电商网站使用如W3C支付请求API或平台特定SDK的协议来简化支付。这些主要标准化浏览器或应用程序如何从用户收集支付信息，而AP2标准化代理如何向商家和支付处理商证明用户意图。AP2专注于可验证意图和不可否认性，使其区别于更简单的支付API。它在支付网络之上添加了额外的信任层。可以说AP2不是替换支付网络（Visa、ACH、区块链等），而是增强它们。协议明确支持所有类型的支付方法（甚至加密），所以它更多是关于标准化代理与这些系统的交互，而不是从头创建新的支付轨道。
在安全和认证协议领域，AP2与EMV芯片卡中的数字签名或数字合约中的公证等事物有一些精神共同点。例如，EMV芯片卡交易生成密码图来证明卡在场；AP2生成密码学证明证明用户的代理被授权。两者都旨在防止欺诈，但AP2的范围 是代理-用户关系和代理-商家消息传递，现有支付标准没有解决这个问题。另一个新兴的比较是与加密中的账户抽象（如ERC-4337），用户可以授权预编程的钱包操作。加密钱包可以设置为允许某些自动交易（如通过智能合约自动支付订阅），但这些通常局限于一个区块链环境。另一方面，AP2旨在跨平台 —— 它可以利用区块链进行一些支付（通过其扩展），但也与传统银行合作。
在主流支付行业中，还没有AP2的直接"竞争者"协议 —— 它似乎是AI代理支付开放标准的第一次协调努力。专有尝试可能出现（或可能已经在个别公司内部进行），但AP2的广泛支持使其在成为该标准方面具有优势。值得注意的是，IBM和其他公司有**代理通信协议（ACP）**和类似的代理互操作性举措，但这些没有以AP2那样全面的方式涵盖支付方面。如果有的话，AP2可能与这些努力集成或利用（例如，IBM的代理框架可以为任何商务任务实现AP2）。
总之，AP2通过针对AI和支付的独特交叉点来区分自己：旧的支付协议假设人类用户，AP2假设AI中介并填补由此产生的信任空白。它扩展而不是与现有支付流程冲突，并补充现有代理协议如A2A。展望未来，人们可能会看到AP2与既定标准一起使用 —— 例如，AP2购物车授权书可能与传统支付网关API调用协同工作，或者AP2支付授权书可能附加到银行业的ISO 8583消息。AP2的开放性也意味着如果出现任何替代方法，AP2可以通过社区合作潜在地吸收或与它们对齐。在这个阶段，AP2正在设定以前不存在的基线，有效地在AI和支付堆栈中开拓新的协议层。
对Web3和去中心化系统的影响
从一开始，AP2就被设计为包容Web3和基于加密货币的支付。该协议认识到未来商务将跨越传统法币渠道和去中心化区块链网络。如前所述，AP2支持从信用卡和银行转账到稳定币和加密货币的支付类型。实际上，与AP2的发布一起，谷歌宣布了一个名为A2A x402的加密支付特定扩展。这个扩展与像Coinbase、以太坊基金会和MetaMask等加密行业玩家合作开发，是"代理基础加密支付的生产就绪解决方案"。名称"x402"是对HTTP 402"需要支付"状态代码的致敬，该代码从未在Web上广泛使用 —— AP2的加密扩展有效地复活了HTTP 402的精神，用于想要在链上相互收费或支付的去中心化代理。实际上，x402扩展将AP2的授权书概念适应区块链交易。例如，代理可以持有来自用户的签名意图授权书，然后在满足条件时执行链上支付（比如发送稳定币），将授权书证明附加到该链上交易。这将AP2的链下信任框架与区块链的无信任性质相结合，给出两个世界的最佳：*链下各方（用户、商家）*可以信任的链上支付由用户授权。
AP2和Web3之间的协同作用在合作者列表中是明显的。加密交易所（Coinbase）、区块链基金会（以太坊基金会）、加密钱包（MetaMask）和Web3初创公司（如Sui的Mysten Labs、闪电网络的Lightspark）参与了AP2的开发。他们的参与表明AP2被视为去中心化金融的补充而不是竞争。通过创建AI代理与加密支付交互的标准方式，AP2可以推动加密在AI驱动应用中的更多使用。例如，AI代理可能使用AP2在用信用卡或用稳定币支付之间无缝切换，取决于用户偏好或商家接受度。A2A x402扩展专门允许代理通过链上手段货币化或支付服务，这在未来的去中心化市场中可能至关重要。它暗示代理可能作为区块链上的自主经济行为者运行（一些人称为DACs或DAOs的概念），能够处理服务所需的支付（如向另一个代理支付信息的小费）。AP2可以为这种交易提供通用语言，确保即使在去中心化网络上，代理也有其行为的可证明授权书。
在竞争方面，人们可能会问：纯去中心化解决方案是否使AP2不必要，反之亦然？AP2很可能在分层方法中与Web3解决方案共存。去中心化金融提供无信任执行（智能合约等），但它本身不解决"AI是否有人类的权限做这件事？"的问题。AP2解决了这个非常重要的人类对AI信任链接，即使支付本身在链上，这仍然很重要。而不是与区块链协议竞争，AP2可以被视为将它们与链下世界桥接。例如，智能合约可能只有在包含对有效AP2授权书签名的引用时才接受某个交易 —— 这可以实现为结合链下意图证明和链上执行。相反，如果有加密原生代理框架（一些区块链项目探索用加密资金运营的自主代理），它们可能开发自己的授权方法。然而，AP2的广泛行业支持可能引导即使那些项目采用或与AP2集成以保持一致性。
另一个角度是去中心化身份和凭证。AP2使用可验证凭证非常符合Web3的身份方法（如W3C标准化的DIDs和VCs）。这意味着AP2可以插入去中心化身份系统 —— 例如，用户的DID可用于签名AP2授权书，商家可以对区块链或身份中心验证。探索代理授权的去中心化身份的提及强化了AP2可能利用Web3身份创新以去中心化方式验证代理和用户身份，而不是仅依赖中心化权威。这是协同点，因为AP2和Web3都旨在给用户更多控制和其行动的密码学证明。
潜在冲突可能只有在设想完全去中心化的商务生态系统没有大型中介角色的情况下才会出现 —— 在那种情况下，AP2（最初由谷歌和合作伙伴推动）可能太中心化或由传统玩家治理？重要的是注意AP2是开源的，旨在标准化，所以它不是谷歌专有的。这使它对重视开放协议的Web3社区更可接受。如果AP2被广泛采用，它可能减少对代理单独Web3特定支付协议的需求，从而统一努力。另一方面，一些区块链项目可能更喜欢纯链上授权机制（如多签钱包或链上托管逻辑）用于代理交易，特别是在没有任何中心化权威的无信任环境中。这些可以被视为替代方法，但它们可能仍然是小众，除非它们可以与链下系统交互。AP2通过涵盖两个世界，实际上可能通过使加密成为AI代理可以无缝使用的另一种支付方法来加速Web3采用。确实，一位合作伙伴注意到*"稳定币为[用于]传统基础设施的代理系统提供了明显的扩展挑战解决方案"，强调加密可以在处理规模或跨境场景中补充AP2。同时，Coinbase的工程负责人评论说，将x402加密扩展带入AP2"是有意义的 —— 这是代理的天然游乐场...很高兴看到代理相互支付与AI社区产生共鸣"*。这暗示AI代理通过加密网络交易的愿景不仅仅是理论想法，而是预期结果，AP2作为催化剂。
总之，AP2与Web3高度相关：它将加密支付作为一等公民纳入，并与去中心化身份和凭证标准保持一致。而不是与去中心化支付协议正面竞争，AP2可能与它们互操作 —— 提供授权层，而去中心化系统处理价值转移。随着传统金融和加密之间的界限模糊（稳定币、CBDCs等），像AP2这样的统一协议可以作为AI代理与任何形式的货币（中心化或去中心化）之间的通用适配器。
行业采用、合作伙伴关系和路线图
AP2最大的优势之一是即使在这个早期阶段背后的广泛行业支持。谷歌云宣布它*"与超过60个组织的多元化群体合作"开发AP2。这些包括主要信用卡网络（如万事达、美国运通、JCB、银联）、领先的金融科技和支付处理商（PayPal、Worldpay、Adyen、Checkout.com、Stripe的竞争对手）、电商和在线市场（Etsy、Shopify（通过Stripe等合作伙伴）、Lazada、Zalora）、企业技术公司（Salesforce、ServiceNow、Oracle可能通过合作伙伴、Dell、Red Hat）、身份和安全公司（Okta、Ping Identity、Cloudflare）、咨询公司（德勤、埃森哲）和加密/Web3组织（Coinbase、以太坊基金会、MetaMask、Mysten Labs、Lightspark）等。如此广泛的参与者阵容是行业兴趣和可能采用的强烈指标。许多这些合作伙伴已经公开表达支持。例如，Adyen的联合CEO强调对代理商务"通用规则手册"的需求，并将AP2视为其支持商家新支付构建块使命的自然延伸。美国运通的EVP表示AP2对"下一代数字支付"*很重要，信任和问责是首要的。如前所述，Coinbase的团队对将加密支付集成到AP2中感到兴奋。这种支持合唱表明行业中许多人将AP2视为AI驱动支付的可能标准，他们渴望塑造它以确保满足其要求。
从采用立场来看，AP2目前处于规范和早期实现阶段（2025年9月宣布）。完整的技术规范、文档和一些参考实现（如Python等 语言）在项目的GitHub上可供开发者实验。谷歌还表示AP2将被整合到其代理产品和服务中。一个值得注意的例子是前面提到的AI代理市场：这是一个第三方AI代理可以提供给用户的平台（可能是谷歌生成AI生态系统的一部分）。谷歌说许多构建代理的合作伙伴将使它们在市场中可用，"由AP2启用的新的可交易体验"。这暗示随着市场启动或增长，AP2将成为任何需要执行交易的代理的支柱，无论是从谷歌云市场自主购买软件还是代理为用户购买商品/服务。自主采购（一个代理代表公司从另一个代理购买）和自动许可证扩展等企业用例已被特别提及为AP2可能很快促进的领域。
在路线图方面，AP2文档和谷歌的宣布给出了一些明确指示：
- 近期： 继续协议的开放开发与社区输入。GitHub存储库将通过额外的参考实现和改进更新，随着现实世界测试的进行。我们可以期待库/SDK出现，使将AP2集成到代理应用程序中更容易。此外，合作伙伴公司可能进行初始试点项目或概念验证。鉴于许多大型支付公司参与，他们可能在受控环境中试用AP2（例如，在小用户测试版中的AP2启用结账选项）。
- 标准和治理： 谷歌已表达将AP2转移到开放治理模型的承诺，可能通过标准机构。这可能意味着向Linux基金会（如A2A协议所做）等组织提交AP2或形成联盟来维护它。Linux基金会、W3C甚至ISO/TC68（金融服务）等机构可能是正式化AP2的考虑。开放治理将向行业保证AP2不在单一公司控制下，将保持中性和包容性。
- 功能扩展： 技术上，路线图包括扩展对更多支付类型和用例的支持。如规范中所述，在卡之后，焦点将转移到**"推送"支付如银行汇款和本地实时支付方案，以及数字货币**。这意味着AP2将概述意图/购物车/支付授权书如何工作，比如直接银行转账或加密钱包转账，其中流程与卡拉取略有不同。A2A x402扩展是加密的一种扩展；类似地，我们可能看到开放银行API的扩展或B2B发票场景的扩展。
- 安全和合规增强： 随着真实交易开始通过AP2流动，将受到监管机构和安全研究人员的审查。开放过程可能会迭代使授权书更加稳健（例如，确保授权书格式标准化，可能使用W3C可验证凭证格式等）。与身份解决方案的集成（可能利用生物识别用于用户签名授权书，或将授权书链接到数字身份钱包）可能是路线图的一部分以增强信任。
- 生态系统工具： 一个新兴生态系统是可能的。已经，初创公司注意到空白 —— 例如，Vellum.ai分析提到一个名为Autumn的初创公司构建"AI计费基础设施"，本质上是Stripe之上的工具来处理AI服务的复杂定价。随着AP2获得牵引力，我们可以期待更多工具如代理专注的支付网关、授权书管理仪表板、代理身份验证服务等出现。谷歌的参与意味着AP2也可以集成到其云产品中 —— 想象Dialogflow或Vertex AI代理工具中的AP2支持，使代理处理交易成为一键（在谷歌云中管理所有必要的密钥和证书）。
总的来说，AP2的轨迹让人想起其他主要行业标准：有强大赞助商（谷歌）的初始启动、广泛行业联盟、开源参考代码，然后是迭代改进和在真实产品中的逐步采用。AP2邀请所有玩家"与我们一起构建这个未来"的事实强调路线图是关于合作的。如果势头继续，AP2可能在几年内变得像今天OAuth或OpenID Connect在其领域中一样普遍 —— 一个看不见但关键的层，实现跨服务的功能。
AP2（代理/代理支付协议）代表着朝着AI代理可以像人类一样可靠和安全地交易的未来迈出的重要一步。技术上，它引入了可验证授权书和凭证的巧妙机制，在代理主导的交易中注入信任，确保用户意图明确且可执行。其开放、可扩展的架构允许它与新兴的AI代理框架和既定的金融基础设施集成。通过解决授权、真实性和问责制的核心关切，AP2为AI驱动的商务蓬勃发展奠定了基础，而不牺牲安全性或用户控制。
AP2的引入可以被视为奠定新基础 —— 就像早期互联网协议启用网络一样 —— 为一些人称为"代理经济"的东西。它为无数创新铺平了道路：个人购物代理、自动交易发现机器人、自主供应链代理等，所有这些都在共同信任框架下运营。重要的是，AP2的包容性设计（拥抱从信用卡到加密的一切）将其定位在传统金融和Web3的交叉点，可能通过共同的代理中介协议桥接这些世界。
到目前为止，行业反应非常积极，广泛联盟表明AP2可能成为广泛采用的标准。AP2的成功将取决于持续合作和现实世界测试，但鉴于它解决的明确需求，其前景强劲。在更广泛的意义上，AP2例证了技术如何发展：一种新能力（AI代理）出现，破坏了旧假设，解决方案是开发一个新的开放标准来适应这种能力。通过现在投资开放的安全优先协议，谷歌及其合作伙伴有效地构建了下一个商务时代所需的信任架构。正如俗话说，"预测未来的最好方法是构建它" —— AP2是对AI代理为我们无缝处理交易的未来的押注，它正在积极构建使那个未来可行所需的信任和规则。
来 源：
- 谷歌云博客 – "用新的代理支付协议（AP2）为AI商务提供动力" (2025年9月16日)
- AP2 GitHub文档 – "代理支付协议规范和概述"
- Vellum AI博客 – "谷歌的AP2：AI代理支付的新协议" (分析)
- Medium文章 – "谷歌代理支付协议（AP2）" (Tahir总结，2025年9月)
- AP2合作伙伴引用（谷歌云博客）
- A2A x402扩展 (AP2加密支付扩展) – GitHub README
