# AP2 协议详解：智能体支付如何获得授权 > 一份关于 AP2（Agent Payments Protocol，智能体支付协议）的实用指南，涵盖结账与支付 Mandate、Open 与 Closed 授权、可验证数字凭证，以及这对商家意味着什么。 - **Author**: Ayush Agarwal - **Published**: 2026-09-13 - **Category**: AI, Payments - **URL**: https://dodopayments.com/blogs/zh/ap2-protocol-agent-payments --- 一名 AI 智能体在一笔 $279.99 的订单上点击了"购买"。六周后，持卡人提出争议，称自己从未批准过这笔购买。 现在，请基于证据回答两个问题：是谁授权了这笔交易？他们在授权时究竟看到了什么？银行卡网络最初是为人在终端上刷卡而构建的，并不是为了回答"这个软件智能体是否被允许在这个购物车上花这笔钱"。 AP2 协议正是要弥合这一差距。它不负责转移资金，也不会取代你的支付处理商。它会生成一条加密的证据链，证明智能体获得了什么权限、这些权限涵盖了什么，以及每一方在授权时看到了什么。 ## 什么是 AP2 协议？ AP2 代表 Agent Payments Protocol（智能体支付协议）。它是一种用于保护智能体执行的支付交易的协议，由 Google 发布，文档位于 ap2-protocol.org，规范由 google-agentic-commerce/AP2 仓库维护。该文档网站于 2025 年 9 月发布。 AP2 是授权与证据层，而不是结算通道。它定义了 AI 智能体如何获取、携带并出示证明人类已授权购买的加密凭证，以及链路中的每个参与方如何独立验证这些凭证。 标准化工作仍在 FIDO 的 Agentic Authentication Technical Working Group 和 Payments Technical Working Group 中持续进行。现代身份验证技术栈中的许多部分，正是在这些工作组中得到强化后，才达到生产规模。 其核心原语是可验证数字凭证（Verifiable Digital Credential，VDC）：一种具备防篡改能力、经过加密签名的数字对象。AP2 规定使用 SD-JWT，即 Selective Disclosure JSON Web Token（选择性披露 JSON Web Token），来保护承载授权信息的 mandate。 其基本逻辑很简单。AP2 回答的是："这个智能体是否被允许购买这件商品？我们之后能否证明这一点？"它天然适用于[智能体商务](https://dodopayments.com/blogs/agentic-commerce)的发展趋势：由软件发起购买，而不仅仅是提供推荐。 ## 两种 Mandate：结账与支付 AP2 将授权拆分为两个对象，而不是一整块同意信息。商家需要知道买了什么；支付链路需要知道哪个支付工具获得了授权，以及授权金额是多少。受众不同，隐私需求也不同。 Checkout Mandate（结账 Mandate）记录智能体与商家协商确定的具体商品及购买详情，并与商家共享。 Payment Mandate（支付 Mandate）授权使用特定支付工具进行付款，并与 Credential Provider（凭证提供方）、Network（支付网络）和 Merchant Payment Processor（商家支付处理商）共享。 | Mandate | 创建方 | 验证方 | 证明内容 | | -------------------------------- | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | -------------------------------------- | | Checkout Mandate（结账 Mandate） | 用户根据 Shopping Agent（购物智能体）协商出的结账信息，在 Trusted Surface（可信界面）上签名 | 商家 | 用户同意了这些具体商品和购买详情 | | Payment Mandate（支付 Mandate） | 用户在 Trusted Surface（可信界面）上签名 | Credential Provider（凭证提供方）、Network（支付网络）和 Merchant Payment Processor（商家支付处理商） | 用户授权使用特定支付工具为这笔交易付款 | 这些角色对应着你已经运行或集成的基础设施： - Shopping Agent（购物智能体）：负责协商并执行购买的 AI 智能体。 - Trusted Surface（可信界面）：用户实际查看交易并签名的地方，也是人类同意的发生点。 - Merchant（商家）：卖方，负责验证 Checkout Mandate。 - Credential Provider（凭证提供方）：支付凭证的来源。 - Network（支付网络）：银行卡网络或支付网络。 - Merchant Payment Processor（商家支付处理商）：验证 Payment Credential（支付凭证）的范围是否正确覆盖该结账流程。 验证职责并非偶然重叠。商家验证 Checkout Mandate。Credential Provider 和 Network 验证 Payment Mandate。Merchant Payment Processor 验证 Payment Credential 是否正确限定在其所声称覆盖的结账流程内。 如果你之前已经[将支付接入智能体工作流](https://dodopayments.com/blogs/mcp-payments-ai-agents)，那么这种结构会让你感到熟悉。新变化在于：同意变成了可移植、可验证的凭证，而不再只是一个会话 Cookie 和一行日志。 ## Open Mandate 与 Closed Mandate 这是大多数解释最容易出错的地方。每种 Mandate 都有两个阶段：open 和 closed。它们不是两种不同的 Mandate，而是同一授权过程的两个阶段，在不同时间点记录同意信息。 Open Mandate 会在具体购物车最终确定之前，记录用户的限制条件和目标。用户授权智能体在一定边界内自主执行，例如限定金额范围和允许的收款方集合，而不是授权一个具体的商品明细购物车。 Closed Mandate 会记录对具体、最终确定的结账流程和交易金额的授权。购物车已经存在，总金额已经确定，用户明确批准的就是这一笔交易。 这一差异对应两种商务模式。"现在购买这个购物车"会直接生成 Closed Mandate；"留意这件商品，如果它在这三家卖家处降到 $200 以下就购买"则会生成一个之后由智能体执行的 Open Mandate。 由于 Open Mandate 尚未绑定到具体交易，因此必须将其限定在持有该 Mandate 的智能体上。规范要求 Open Mandate 在 "cnf" claim 中包含智能体的公钥。如果没有这一绑定，Open Mandate 就会变成任何一方都能执行的 bearer token。 同时，规范还建议将 "exp" claim 设置为在智能体完成任务所需范围内的最短有效期。有效期为三天的价格监控 Mandate，其潜在影响范围远小于有效期为一年的 Mandate。 验证逻辑中还有一个容易忽略的细节：无论交易最初采用哪种模式，验证方始终会收到 Closed Payment Mandate 和 Closed Checkout Mandate。变化的只有流程。Open Mandate 是上游约束，而不是交易发生时进行验证的对象。 如果你现在正在为自主智能体设计消费限额，这与[协商 AI 智能体的按用量计费](https://dodopayments.com/blogs/negotiate-usage-based-billing-ai-agents)以及[智能体计费](https://dodopayments.com/blogs/agentic-billing)所涉及的问题高度相似。核心难题始终不变：如何在赋予足够自主性的同时，避免允许不受限制的消费？ ## AP2 交易如何流转 下面展示的是一次使用 Closed Mandate 的购买流程：用户授权了一个具体且已经最终确定的购物车。关键在于，商家会签发经过签名的 Checkout JWT，并将两个 Mandate 都以加密方式绑定到该 JWT 上。 ```mermaid sequenceDiagram participant U as 用户 participant TS as 可信界面 participant SA as 购物智能体 participant M as 商家 participant CP as 凭证提供方 participant MPP as 商家支付处理商 U->>SA: 表达购买意图 SA->>M: 协商购物车和购买详情 M-->>SA: 商家签名的 Checkout JWT SA->>TS: 展示结账信息供人工审核 TS->>U: 显示商品、总金额和收款方 U->>TS: 批准并签名 TS-->>SA: Closed Checkout Mandate（绑定到 Checkout JWT 的哈希） TS-->>SA: Closed Payment Mandate（绑定到 Checkout JWT 的哈希） SA->>M: 提交 Checkout Mandate M->>M: 验证 Checkout Mandate M-->>SA: Checkout Receipt SA->>CP: 提交 Payment Mandate CP->>CP: 验证 Payment Mandate CP->>MPP: 转发以进行处理 MPP->>MPP: 验证凭证是否限定在该结账流程内 MPP-->>SA: 签名的 Payment Receipt MPP-->>CP: 签名的 Payment Receipt ``` 三个细节发挥了关键作用。商家 MUST 向 Shopping Agent 提供一个包含结账信息、由商家签名的 JWT。这样，商家就不是被动接收同意，而是负责生成同意所指向的规范对象。 Trusted Surface 是人类查看并签名的地方。Shopping Agent 负责协商，但不会伪造同意；这种分离正是整个安全论证的核心。随后，Receipt 会回传，因此验证并不是发出请求后就不再关注。 ## 支撑其可靠性的加密机制 AP2 使用 SD-JWT 来保护 Mandate。选择性披露非常重要，因为商家和支付链路需要同一授权中的不同部分：商家不应需要完整的支付工具上下文来验证购物车，支付网络也不应需要明细购物车来验证支付工具。 绑定模型正是协议价值所在。Closed Checkout Mandate 通过加密哈希绑定到商家签名的 Checkout JWT，而 Payment Mandate 则通过使用同一个 Checkout JWT 的哈希，绑定到特定结账流程。 这意味着你无法将某个购物车的有效授权拿来重放到另一个购物车上。只要结账信息的任何部分发生变化，哈希就不再匹配，Mandate 也就无法通过验证。 Checkout JWT MUST 使用 ECDSA 等数字签名方案进行签名，具体来说，不能使用 Ed25519 等确定性方案。原因在于彩虹表攻击：对于可预测、低熵的内容，确定性签名本身也是可预测的，攻击者可以预先计算常见结账结构的签名并进行匹配。如果你因为 Ed25519 是加密库的默认选项而选择它，那么你就不符合规范。 版本控制通过 "vct" claim 实现。每种 Mandate 类型都使用带数字版本后缀的 vct 值标识其 schema，例如 "mandate.payment.1" 或 "mandate.checkout.open.1"。实现 MUST 匹配包含后缀在内的完整字符串。这比带有 semver 风格的 API 版本控制更严格：不存在"接受 1.x 版本线中的任意版本"这种行为。 payment_amount 对象包含 ISO 4217 货币代码和以最小货币单位表示的整数金额，因此 USD 货币下的 27999 表示 $279.99。使用最小货币单位可以避免浮点数舍入问题，我们的[集成指南](https://docs.dodopayments.com/developer-resources/integration-guide)也采用相同约定。 ## Receipt 与争议证据 对商家而言，这是 AP2 真正有用的部分，但大多数介绍都没有充分强调。商家接受或拒绝 Checkout Mandate 后，MUST 返回 Checkout Receipt。Merchant Payment Processor 接受或拒绝 Payment Mandate 后，MUST 向 Shopping Agent、Credential Provider，以及可能的 Network 返回签名的 Payment Receipt。 Receipt 不是礼貌性的确认信息。Mandate 证明用户授权了某件事；Receipt 则证明某个特定参与方收到了该授权、对其进行了评估，并作出了决定。 发生争议时，Checkout Mandate、Checkout Receipt、Payment Mandate 和 Payment Receipt 会作为证据一起验证，用来证明用户和每个角色实际看到了什么。Receipt 中的 "reference" 值必须与对应 Closed Mandate 的哈希匹配，因此之后无法悄悄将 Receipt 重新关联到另一笔交易。 如今，一笔由智能体发起的争议通常只能提供服务器日志、一个会话标识符、可能还有一封邮件确认，以及一套说法。AP2 用任何一方都能独立验证的签名凭证取代了争论。这一点很重要，因为赢得拒付的关键，在于明确展示客户究竟同意了什么。 我们关于[拒付与退款的区别](https://dodopayments.com/blogs/chargeback-vs-refund)的分析说明了证据质量为何会影响结果；[MoR（名义商户）如何处理拒付](https://dodopayments.com/blogs/merchant-of-record-chargebacks)则介绍了由谁承担这项工作。 这些机制不会让争议消失，但会让证据链变得确定，而不必事后重新拼凑。 ## AP2 与 x402：处于不同层级，并非竞争关系 这两个协议经常被拿来比较，通常仿佛其中一个会击败另一个。实际上，它们在不同层级解决不同问题。 x402 是结算协议：它定义价值如何转移，通常是通过 HTTP 402 响应转移稳定币。AP2 是授权与证据协议：它定义如何证明智能体获准进行交易，并在交易后保留可验证的审计链路。 | 维度 | AP2 | x402 | | ------------ | ---------------------------------------------------- | -------------------------------------------- | | 解决的问题 | 证明智能体获准购买，并保留可验证证据 | 在不存在预先账户关系的情况下，为请求转移价值 | | 价值如何转移 | 不转移。现有支付通道和处理商仍负责结算付款 | 链上直接在付款方和收款方之间转移 | | 结算资产 | 底层支付工具使用的任何资产（银行卡、银行通道、钱包） | 通常是稳定币 | | 争议处理 | 将签名的 Mandate 和 Receipt 一起作为证据进行验证 | 结算具有最终性；争议在协议之外处理 | | 成熟度 | 早期。规范工作仍在 FIDO 工作组中持续 | 早期。正在形成的机器对机器支付模式 | | 面向对象 | 需要为智能体购买行为提供授权证明的商家和处理商 | 按请求向智能体收费的 API 和服务 | 从原理上看，它们是互补的。一个智能体可以持有 AP2 Mandate，用于约束其可支出的范围，同时通过传统支付通道结算一部分购买，通过面向机器的支付通道结算另一部分购买。 我们在[x402 协议详解](https://dodopayments.com/blogs/x402-protocol)中介绍过结算层。两者合在一起，正好对应智能体支付问题的两个部分：权限与资金转移。 两者都不会消除你现有的义务。税务、开票、退款和 MoR（名义商户）职责不会因为某个协议标准化了授权步骤而改变。 ## 商家现在应该做什么 坦诚地说：AP2 仍处于早期，采用情况尚未得到验证，没人应该在本季度围绕它重建结账流程。但无论 AP2 最终是否成功，几乎所有让你做好 AP2 准备的工作本身都是良好的工程实践。 构建清晰、可由机器调用的结账 API。如果智能体无法通过编程方式创建购物车、获取规范总金额，并获得该结账流程的稳定标识符，那么任何授权协议都帮不了你。智能体流量意味着你的结账流程应当是一个 API 界面，而不是渲染出来的页面。 保留持久化的订单和 Receipt 记录。记录客户看到的内容，而不只是你收取的金额：商品明细、总金额、货币、时间戳，以及发起请求的主体身份。AP2 将其正式化为签名 Receipt；在今天，也应保留等价的信息。 每条写入路径都要实现幂等性。智能体会重试，网络也会超时。没有幂等键，你就可能重复扣款，而智能体购买产生的重复扣款争议，从原则上就很难获胜。这是[AI 智能体计费集成](https://dodopayments.com/blogs/ai-agent-ai-billing-integration)的基本要求。 建立强有力的争议证据链。在交易发生时就收集证据，在授权上下文仍然清晰时记录，而不是八周后再从日志中重建。[风控工具](https://dodopayments.com/payments/fraud-protection)有助于预防问题，但证据管理由你负责。 制定并公开清晰的退款政策。智能体购买会带来更多"我不是想买这个"的咨询，而一项易于找到且易于执行的退款政策，可以将拒付转化为退款，成本会低很多。 在自己的产品中明确消费边界。如果你的产品允许智能体触发收费，现在就定义限制：单笔交易上限、每日上限、允许的类别和允许的收款方。AP2 的 Open Mandate 将这一理念正式化，而自行构建这些能力也能帮助你了解需要哪些约束。[SaaS 按用量计费](https://dodopayments.com/blogs/usage-based-billing-saas)和各种[AI 计费平台](https://dodopayments.com/blogs/ai-billing-platforms)中的模式可以作为有用的起点。 直截了当地说：Dodo Payments 并未实现 AP2，我们也不会暗示一条尚未承诺的产品路线图。 我们提供的是底层能力，无论哪种授权协议最终胜出，这一层都不会改变。作为一家[MoR（名义商户）](https://dodopayments.com/payments/merchant-of-record)，我们负责覆盖 190 多个国家和地区的税务合规、开票和争议处理，并支持 40 多种支付方式、80 多种货币，以及 220 多个国家和地区。定价为美国境内每笔交易 4% + 40 美分，另加国际交易 1.5% 和订阅交易 0.5%；每笔争议收费 $30，不收固定月费。完整详情请查看[定价页面](https://dodopayments.com/pricing)，[MoR（名义商户）究竟是什么](https://dodopayments.com/blogs/what-is-a-merchant-of-record)一文则介绍了这一模式。 在智能体侧，我们提供面向 AI 智能体的 [MCP server](https://docs.dodopayments.com/developer-resources/mcp-server)，让智能体能够通过结构化界面处理支付操作，并提供适用于常见工作流的[智能体技能](https://docs.dodopayments.com/developer-resources/agent-skills)。这与 AP2 是互补关系，而不是替代关系：AP2 将规定智能体是否获准购买，而 MCP server 将规定智能体如何与计费操作交互。 ## 未决问题与局限 采用情况仍不确定。一个文档于 2025 年 9 月发布、且仍在 FIDO 工作组内部持续标准化的规范，还不能算是成熟稳定的生态。支付标准依赖网络效应，而网络效应需要多年时间才能形成。 责任规则尚未解决。如果智能体执行了一个有效的 Open Mandate，并在其约束范围内买错了东西，谁来承担损失？加密机制可以证明 Mandate 有效，但无法确定在有效边界内发生错误结果时，应由用户、智能体运营方、商家还是发卡方负责。FIDO 工作组仍在推进相关工作。 Trusted Surface 的实现是一个真实的依赖条件。安全模型假设存在一个用户能够真实查看并签名的界面，但钱包应用、操作系统层或浏览器组件目前尚未统一具备这一能力。 Open Mandate 的范围界定很难做到恰到好处。规范要求使用 "cnf" claim 将其绑定到智能体公钥，并建议使用最短的 "exp" 值，但为真实购物任务选择合适的约束，这是产品设计问题，而不是加密问题。 对商家而言，最重要的是：AP2 不会改变任何税务义务、VAT 和 GST 注册、开票或 MoR（名义商户）职责。签名 Mandate 不会提交纳税申报表，也不会开具合规发票。这些义务与过去完全相同。 ## 常见问题 ### AP2 代表什么？ AP2 代表 Agent Payments Protocol（智能体支付协议）。它是由 Google 发布、用于保护智能体执行的支付交易的协议，文档位于 ap2-protocol.org，规范由 google-agentic-commerce/AP2 仓库维护。 ### AP2 中的 Open Mandate 和 Closed Mandate 有什么区别？ Open Mandate 会在具体购物车最终确定之前，记录用户的限制条件和目标，允许智能体在金额范围和允许收款方等边界内自主执行。Closed Mandate 则记录对具体、最终确定的结账流程和交易金额的授权。 ### AP2 会取代我的支付处理商吗？ 不会。AP2 是授权与证据层，用于证明智能体获准进行交易，并保留可验证的审计链路。结算仍会通过你现有的支付通道完成，你的支付处理商、税务和 MoR（名义商户）义务也不会改变。 ### AP2 与 x402 有什么不同？ x402 是结算协议，定义价值实际如何转移，通常是通过 HTTP 402 响应转移稳定币。AP2 是授权与证据协议，用于证明智能体获准进行交易，因此两者处于不同层级，并非相互竞争。 ### Dodo Payments 支持 AP2 吗？ Dodo Payments 尚未实现 AP2。Dodo Payments 作为 MoR（名义商户）运营，负责税务合规、开票和争议处理，并提供 MCP server，让 AI 智能体能够通过结构化界面与支付操作交互。 ## 最终结论 AP2 为一个不会消失的问题提供了精心设计的答案：当软件代表某个人花钱时，如何证明它获得了授权？Mandate 拆分、绑定到商家签名 Checkout JWT 的哈希、ECDSA 要求，以及基于 Receipt 的争议证据，都是经过审慎设计的选择，显然出自处理过真实支付争议的人之手。 AP2 是否会成为标准，仍然无法确定。早期支付标准的存活率并不高，而责任模型仍在 FIDO 工作组内部制定。 但发展方向是明确的。智能体每年都会发起更多购买，随着交易量增长，授权与证据问题也会变得更加棘手。无论 AP2 最终成功与否，构建清晰结账 API、持久化 Receipt 记录、具备幂等性的写入路径，并建立严格争议证据流程的商家，都将处于更有利的位置。 无论结果如何，底层基础设施都不会改变。仍然需要有人在 190 多个国家和地区收取正确税款、开具合规发票并处理拒付。如果你希望有人负责这些工作，让你专注于智能体体验，可以从我们的[开发者文档](https://docs.dodopayments.com)开始。 --- - [More AI articles](https://dodopayments.com/blogs/category/ai) - [All articles](https://dodopayments.com/blogs)