这是一篇关于 AP2 v0.2 的技术深度解析，它是自主代理支付背后的加密授权令系统。我在构建了一个真实的 Camunda 8 演示后写了这篇文章，并且根据 ap2-protocol.org 上的规范验证了每一个说法，而不是新闻报道。大多数发布周期的文章使用了当前规范已经替换的术语。我会在重要的地方指出这一点。
## 它解决的问题
> **“你会把你的信用卡给一个 AI 吗？”** 这是我为《Agents, Orchestrated》第 03 集着手回答的问题。能够妥善回答这个问题的协议就是 AP2。
一个能花钱的代理与一个能回答问题的代理有着根本的区别。当一个代理调用搜索 API 出错时，你会得到一个糟糕的结果。当它调用支付 API 出错时，你就会损失金钱。
传统的答案是：在支付时需要人工在场。点击“批准”。输入一次性密码。这很好，直到代理需要在你睡觉时，在凌晨 2 点 FIFA 门票价格下降的那一刻购买门票。
AP2 解决了一个具体问题：**人类如何以一种加密受限、链中各方可审计、且无需回传任何中央机构即可强制执行的方式，将消费权限委托给代理？**
答案是授权令。这就是整个协议。
## AP2 是什么：关键事实
**AP2 = 代理支付协议。** 谷歌的代理发起支付开放标准，于 2025 年 9 月 16 日发布，拥有 60 多个启动合作伙伴，包括 Mastercard、PayPal、American Express、Coinbase 和 Salesforce。
| 事实 | 详情 |
| --- | --- |
| 当前版本 | v0.2，2026 年 4 月发布 (GitHub: google-agentic-commerce/AP2) |
| 启动合作伙伴 | 60+ (Mastercard, PayPal, AmEx, Coinbase, Salesforce) |
| 标准化 | FIDO 联盟 (谷歌将 AP2 捐赠给代理认证与支付技术工作组) |
| 参考实现 | 5 种语言：Python, Go, TypeScript, Kotlin, Android |
需要提前了解的关键点：
- AP2 是 **A2A 协议**（Agent-to-Agent，谷歌的代理点对点消息标准）的扩展。它在 A2A 的传输层之上增加了支付授权令语义。
- 它与 **Universal Commerce Protocol (UCP)** 集成，作为商务/结账层。
- 它支持 **x402 / 稳定币 (USDC)** 作为一流的支付轨道，而不是事后才考虑的。这对于交易价值低于卡片交换费（0.50 美元到 0.80 美元）的微交易至关重要。
- 规范的真实来源是 **ap2-protocol.org**，而不是新闻报道。大多数 2025 年 9 月的文章使用了过时的术语。我会在重要的地方指出这一点。
## AP2 在堆栈中的位置
这是我希望有人在第一天就为我清楚地画出来的东西。代理商务堆栈有五个不同的层：不同的协议、不同的组织、解决不同的问题。
| 层 | 协议 | 作用 | 管理者 |
| --- | --- | --- | --- |
| 1 | MCP | 模型上下文协议。发现和工具：LLM 如何发现和调用外部能力 | Anthropic |
| 2 | A2A | 代理间协议。传输：通过 AgentCard 发现实现代理角色间的点对点 HTTP 消息传递 | Google |
| 3 | **AP2 (你在这里)** | 支付授权：加密签名的授权令链、SD-JWT、ECDSA P-256、W3C 可验证凭证 | Google / FIDO |
| 4 | ACP / UCP | 结账 HTTP 端点、购物车组装、订单履行语义 | 开放规范 |
| 5 | 卡片、FedNow、x402 | 结算轨道：Mastercard、Visa、UPI、Pix、USDC 稳定币 | 网络 |
> MCP 定义了代理可以读取和调用的内容。ACP 定义了代理如何购买。AP2 定义了用户的意图和商家的费用如何通过加密方式被见证。
这些层是组合的。你使用 MCP 给代理提供工具。这些工具调用 A2A 端点与其他代理通信。AP2 提供随这些消息传输的签名授权凭证。ACP/UCP 定义了商家暴露的结账 API。支付轨道结算资金。
*图 1：五层代理商务堆栈。AP2 位于第 3 层，在传输和结算之间，提供加密授权链。*
## 四方参与者
AP2 定义了四个命名角色。每笔交易都涉及其中部分或全部角色：
| 角色 | 作用 | 真实世界示例 |
| --- | --- | --- |
| Shopping Agent | 监控价格、做出决策、在授权令约束内代表用户行事 | Claude Sonnet、Gemini 购物代理、任何 LLM 代理 |
| Merchant Agent | 暴露 AP2 兼容的购物车端点、验证 Checkout Mandate、履行订单 | TicketVault、任何符合 ACP 标准的商家后端 |
| Credentials Provider | 验证两个授权令、向 Shopping Agent 颁发支付凭证 | Mastercard Agent Pay、PayPal、Visa |
| Payment Processor | 根据资金工具结算交易 | 卡网络、FedNow、Coinbase (x402) |
**可信表面**是一个特殊概念：用户签署授权令的 AP2 兼容客户端（钱包或应用程序）。可以将其视为用户的数字签名授权机构。它持有用户的 ECDSA 私钥，并在 Shopping Agent 自主行动之前生成开放授权令。
## 授权令系统：核心机制
**术语说明：** 许多文章仍然使用发布周期的三授权令框架（意图授权令、购物车授权令、支付授权令）。v0.2 规范将其重构为两种授权令类型，每种类型有两个阶段。旧的框架已过时；请使用 v0.2 术语。
### 两种授权令类型
| 授权令 | 共享对象 | 捕获内容 |
| --- | --- | --- |
| Checkout Mandate | 商家代理 | 购买权限、商品范围、价格上限、商家白名单、存活时间 (TTL) |
| Payment Mandate | 凭证提供商 / 网络 | 收费权限、资金工具令牌、金额上限、类别限制 |
### 开放与封闭阶段
开放与封闭的区别是无人值守支付的全部机制。
| | 开放阶段 | 封闭阶段 |
| --- | --- | --- |
| 创建时机 | 授权令设置时，人工在场 | 购买时，人工不在场 |
| 签署者 | 用户钱包密钥 (ECDSA) | 代理密钥 (ECDSA) |
| 内容 | 约束、范围、存活时间 (TTL)、白名单 | 特定购物车 / 确切金额、结账哈希 |
| 目的 | 长期授权 | 交易特定证明 |
#### 具体示例：FIFA 门票场景
Checkout Mandate，开放阶段：“我授权我的代理在 TicketVault 购买最多 2 张 3 类 FIFA 门票，每张最高 1,500 美元，24 小时内过期。”
Checkout Mandate，封闭阶段：“我正在购买 2 张 3 类门票，每张 1,350 美元，总计 2,700 美元，checkout_hash: `0xABC...`”
封闭的 Payment Mandate 只能在 Checkout Mandate 封闭后创建。它必须包含来自封闭 Checkout Mandate 的 `checkout_hash`。规范强制执行这种顺序依赖性。
*图 2：授权令生命周期。开放授权令在设置时由用户签署。封闭授权令在购买时由代理签署。Payment Mandate 需要来自封闭 Checkout Mandate 的结账哈希。*
### 授权令的结构
```jsonc
// Simplified mandate JSON (encoded as SD-JWT in practice)
{
"id": "mandate_7A3F2026",
"type": "checkout.open",
"vct": "mandate.checkout.1", // schema version, must match exactly
"user_did": "did:key:z6Mk...", // DID of user's wallet key
"agent_did": "did:key:z6Mk...", // DID of shopping agent
"constraints": {
"item_scope": "event-tickets",
"max_unit_price": 1500,
"max_quantity": 2,
"currency": "USD",
"merchant_allowlist": ["ticketvault.com"],
"ttl": "2026-07-12T00:00:00Z"
},
"signature": "ECDSA_P256_sig_by_user_key..." // MUST be ECDSA, NOT Ed25519
}
```
## 加密技术：为什么这是一个协议，而不仅仅是数据库记录
许多“代理支付”解决方案只是数据库记录：用户勾选一个框，应用程序写入 `authorized=true`，代理读取它。当你有多方不互相信任时，这种方式就会失效。
AP2 授权令是使用 **ECDSA P-256** 签名的 **SD-JWTs（选择性披露 JSON Web 令牌）**。规范明确规定：*Checkout JWT 必须使用 ECDSA 签名，并且不得使用 Ed25519。*
### 为什么是 ECDSA，而不是 Ed25519？
这一点很微妙，值得理解。Ed25519 是确定性的：给定相同的消息和私钥，它总是生成相同的签名。这意味着两个相同的授权令会生成相同的签名哈希。攻击者如果随着时间收集签名，可以针对授权令中嵌入的 `checkout_hash` 声明构建彩虹表。ECDSA 在每次签名操作中都包含一个随机数，因此即使授权令内容相同，每个签名也是唯一的。不可能发生彩虹表攻击。
### 加密公式
```text
// From the CSA security framework for AP2
Sig_U(M) = ECDSA.Sign(K_U, Hash(M))
// Verification: any party can run this independently
Verify(M, Sig, PubKey_U) → boolean
// No API call to any central server required
// The credential is self-contained proof
```
### 五项加密保证
1. **防篡改：** 签署后对授权令的任何修改都会破坏 ECDSA 签名。商家或凭证提供商将拒绝它。
2. **不可否认性：** 用户不能否认签署了开放授权令。他们的私钥是签名授权机构。
3. **可移植性：** 链中的每一方都使用用户的公钥（通过 DID）独立验证。没有中央机构。无需回传。
4. **范围强制执行：** 封闭授权令必须满足开放授权令中的所有约束，否则验证将失败。代理不能超出用户预先授权的范围。
5. **选择性披露：** SD-JWT 允许验证 Checkout Mandate 的商家查看商品和价格字段，而无需查看资金工具令牌。字段根据各方选择性地披露。
敏感负载字段（如资金工具令牌）在嵌入 JWT 之前使用 **AES-GCM-256** 加密。对于高价值交易，规范建议使用硬件支持的密钥签名（TPM/HSM）。
AP2 使用**去中心化标识符 (DIDs)** 进行颁发者密钥发现：没有证书颁发机构，没有需要信任的 PKI 层次结构。验证纯粹是加密的。
## 威胁模型
AP2 使用 STRIDE 作为其威胁模型，并由 MAESTRO 框架扩展用于多代理生态系统。了解这一点很重要，因为它准确地展示了 AP2 旨在对抗什么。
| 威胁 (STRIDE) | 攻击 | AP2 缓解措施 |
| --- | --- | --- |
| 欺骗 | 伪造授权令签名，声称虚假授权 | 基于 DID 的 PKI 验证，HSM 支持的密钥 |
| 篡改 | 传输中更改授权令内容（更改价格、范围） | 任何修改都会破坏 ECDSA 签名，TLS 1.3 |
| 否认 | “我从未授权此购买” | 开放授权令上的不可否认 ECDSA 签名加上审计日志 |
| 信息泄露 | 支付工具暴露给商家 | 敏感字段上的 AES-GCM-256，SD-JWT 选择性披露 |
| 权限提升 | 代理超出授权令范围（购买未经授权的物品） | 开放授权令约束在封闭授权令中进行加密验证 |
| 幻觉欺诈 | LLM 因模型错误购买错误物品 | 所有购买都锚定到签名的用户意图，而不是概率模型输出 |
| 代理胁迫 | 商家诱骗代理在授权令之外购买 | 基于 DID 的商家验证加上开放授权令中的 merchant_allowlist |
MAESTRO 将此扩展到新兴的多代理威胁：模型投毒、工作流劫持、生态系统串通。对于高价值交易，规范建议在授权令封闭之前需要多代理共识。
## 流程：人工在场和无人在场
### 人工在场流程
更简单的情况。支付发生时用户在键盘前。可信表面在封闭授权令之前向用户呈现特定购物车以供签名。
1. Shopping Agent 通过 ACP 端点在商家处组装购物车
2. 代理将购物车和开放授权令呈现给**可信表面**（用户的钱包或应用程序）
3. 用户审查并签署，生成**封闭的 Checkout Mandate**（用户签名，特定购物车）
4. 用户签署**封闭的 Payment Mandate**（引用 Checkout 哈希）
5. 代理将两个封闭授权令呈现给**凭证提供商**
6. 凭证提供商验证并颁发支付凭证
7. 代理使用凭证在商家处完成结账。随后进行结算。
### 无人在场流程（v0.2 的旗舰功能）
这是代理商务中最重要的。用户提前设置了约束；当触发条件满足时，代理自主行动，可能在数小时或数天之后。
**第 0 步是关键。** 设置阶段是人工在场的时候。之后，代理完全自主行动。加密技术强制执行边界，而不是人工批准每笔交易。
**设置（人工在场，一次性）：** 用户签署一个开放的 Checkout Mandate（约束、TTL、商家范围）和一个开放的 Payment Mandate（工具、金额上限）。两者都由 Shopping Agent / 可信表面存储。
*……时间流逝。用户入睡。凌晨 2 点价格下降。触发条件满足……*
1. Shopping Agent 检测到触发条件（价格达到或低于目标）
2. 代理查询商家并接收一个 **Cart Mandate**（商家签名，特定 SKU 和价格）
3. 代理验证购物车满足所有开放 Checkout Mandate 约束（价格达到或低于上限，商家在白名单中，TTL 未过期）
4. 代理签署**封闭的 Checkout Mandate**（代理密钥，特定购物车，checkout_hash）
5. 代理将封闭的 Checkout Mandate 呈现给商家，商家验证开放（用户）和封闭（代理）签名
6. 代理签署**封闭的 Payment Mandate**（引用步骤 4 中的 checkout_hash）
7. 代理将两个授权令呈现给**凭证提供商**，凭证提供商验证整个链
8. 凭证提供商颁发**支付凭证**
9. 代理使用凭证在商家处完成结账。结算发生；审计追踪完成。
*图 3：无人在场流程。四方参与，两种授权令类型，九个编号步骤。整个链条通过加密方式链接。*
## 它如何连接到商家：它不是 MCP
我早期一直在问的问题是：授权令到底是如何从我的代理传到 TicketVault 的？
答案是：通过 **A2A HTTP 调用**，而不是 MCP。
MCP 是工具和上下文层。它是 Claude（或任何 LLM）如何访问 `search_inventory` 或 `create_mandate` 作为可调用工具的方式。LLM 使用这些工具所做的事情（Shopping Agent 和 Merchant Agent 之间的消息）是 A2A。授权令凭证是有效载荷，而不是 MCP 工具结果。
> **MCP 定义了代理可以读取和调用的内容。** 授权令作为证据工件随 A2A 调用一起传输，而不是由 MCP 本身生成。
在真实的 AP2 部署中，到 TicketVault 的流程将是：
1. Shopping Agent 将签名的 Checkout Mandate (SD-JWT) POST 到 TicketVault 的 AP2 商家 A2A 端点
2. TicketVault 的商家代理验证：签名验证，然后约束检查，然后结账哈希匹配
3. TicketVault 返回一个 Checkout 收据（商家签名）
4. Shopping Agent 将该收据和 Payment Mandate 带到凭证提供商的 A2A 端点
在我们的演示中，我们通过一个 Node.js BFF 模拟了这一点：Camunda worker 扮演分布式代理角色，SSE 替换了它们之间的 A2A 调用。机制是真实的；分布式是模拟的。这是为了演示而进行的诚实简化。
## 支付轨道：刻意采用多轨道
AP2 不在卡片轨道和加密货币之间选择赢家。它为所有这些定义了扩展点：
| 轨道 | 在 AP2 中如何工作 | 最适合 |
| --- | --- | --- |
| 卡网络 | Mastercard Agent Pay、Visa：由凭证提供商颁发的令牌化卡凭证 | 高价值消费者购买、现有银行关系 |
| 实时支付 | FedNow、UPI、Pix：银行转账凭证 | 高价值 B2B、实时银行转账占主导的市场 |
| x402 / USDC | 代理直接持有智能钱包，Base/Ethereum 上的 USDC，即时结算 | 微交易、API 到 API 支付、无交换费下限 |
x402 对于微交易特别有趣。传统的卡片交换费每笔交易成本为 0.50 美元到 0.80 美元，无论金额大小。代理为 API 调用支付 0.01 美元时，无法经济地使用卡片轨道。x402 加上稳定币解决了这个问题：代理持有 USDC，直接在链上支付，并且可以使用可编程托管进行多步骤承诺。
截至 2026 年 4 月，有三个已命名的公共 AP2 部署：PayPal 的钱包加上 Google Cloud 对话式商务代理、PayPal 内部的 Mastercard Agent Pay 试点，以及用于加密支付的 A2A x402 扩展。
## 我们的演示如何映射到真实的 AP2
我为《Agents, Orchestrated》第 03 集构建了一个 Camunda 8 + AP2 形状的演示。以下是诚实的映射：
| 我们的演示 (Camunda 8 BFF) | 真实的 AP2 |
| --- | --- |
| `mandateService.js` 创建并签署授权令 JSON (ES256) | 可信表面加上 Shopping Agent 持有带有真实 DID 密钥管理的正确用户签名开放授权令 |
| Camunda DMN 消费策略 (人在回路、上限、速度) | 嵌入在开放授权令约束中，加上凭证提供商的策略引擎 |
| SSE 事件驱动 TicketVault 商家网站 | Shopping Agent 将 Checkout Mandate POST 到 Merchant Agent 的 A2A 端点（标准 HTTP） |
| `merchant.completeCheckout` Camunda worker | 独立的 Merchant Agent 二进制文件，验证授权令并执行 ACP 结账 |
| `credentials.issueToken` Camunda worker | 凭证提供商代理，验证授权令对并颁发支付凭证 |
| Zeebe 用户任务 `task_desk_approval` (人在回路) | AP2 不规定人在回路升级；Camunda 在协议之上增加了此治理功能 |
Camunda 层是我们添加 AP2 本身不强制要求的治理功能的地方：DMN 消费策略、达到 95% 上限时的人在回路升级、完整的流程审计追踪。AP2 是授权协议。Camunda 是其之上的治理协调器。
## v0.2 增加了什么 (2026 年 4 月)
头条功能是**无人在场支付**：代理可以使用开放/封闭授权令对，无需交互式同意提示即可执行预授权交易。
- 从三种授权令类型（意图/购物车/支付）重构为两种（Checkout/支付），并具有开放和封闭阶段
- 将 SD-JWT 正式化为授权令编码标准
- 在规范中明确添加了 ECDSA 必须 / Ed25519 不得使用的区别
- 引入了对 x402 / 稳定币轨道作为一流支付类型的官方支持
- Python、Go、TypeScript、Kotlin 和 Android 的参考实现
- 通过代理认证与支付技术工作组进行 FIDO 联盟标准化
## 一段话版本
AP2 是谷歌的代理发起支付开放协议。它很好地解决了一个问题：人类如何以一种交易链中各方都可以独立验证、无需互相信任或回传中央机构的方式，将受限的消费权限委托给代理？它通过一个双授权令系统来实现这一点，包括一个 **Checkout Mandate**（代理到商家）和一个 **Payment Mandate**（代理到凭证提供商），其中每个授权令都有一个开放阶段（用户预先签署约束）和一个封闭阶段（代理签署特定交易）。凭证是使用 ECDSA P-256 签名的 SD-JWT，使其具有防篡改和可移植性。AP2 位于 A2A 传输协议和 ACP/UCP 结账层之间的授权层。它不是 MCP，也不是支付网关。它适用于卡片轨道、实时支付和稳定币。v0.2 的旗舰场景是无人在场：代理在用户睡觉时自主行动，受用户预先设置的加密约束的限制。
*自主性是基本要求。护城河是代理周围的一切。*
## 参考资料
- [AP2 规范：ap2-protocol.org](https://ap2-protocol.org/ap2/specification/) (授权令类型、SD-JWT 编码、ECDSA 要求、参与方角色的真实来源)
- [Google Cloud：宣布 AP2](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) (发布背景、60 多个合作伙伴、FIDO 联盟捐赠公告)
- [AP2 GitHub：google-agentic-commerce/AP2](https://github.com/google-agentic-commerce/AP2) (Python、Go、TypeScript、Kotlin 和 Android 的参考实现，以及可运行的场景)
- [云安全联盟：安全使用 AP2](https://cloudsecurityalliance.org/blog/2025/10/06/secure-use-of-the-agent-payments-protocol-ap2-a-framework-for-trustworthy-ai-driven-transactions) (STRIDE 威胁模型、ECDSA P-256 公式、MAESTRO 框架、AES-GCM-256)
- [ACP vs AP2 vs MCP：协议堆栈比较](https://www.leadgen-economy.com/blog/acp-ap2-mcp-agentic-commerce-protocol-stack-comparison/) (代理商务堆栈的逐层分解)
- [Eco：AP2 v0.2 解释](https://eco.com/support/en/articles/15192002-ap2-protocol-explained-google-s-agentic-commerce-standard-2026) (v0.2 授权令重构、无人在场流程、DID 用于密钥发现)
- [Cobo 代理钱包：AP2 完整指南](https://www.cobo.com/post/ap2-protocol-complete-guide-to-agent-payments-for-web3-developers-2026) (x402 详情、稳定币轨道、多方钱包集成)
- [UCP：AP2 授权令扩展](http://ucp.dev/2026-01-23/specification/ap2-mandates/) (AP2 如何与 Universal Commerce Protocol 在结账层集成)
- [Google Codelabs：使用 AP2 和 UCP 实现安全代理商务](https://codelabs.developers.google.com/next26/adk-agent-commerce) (针对官方 Google ADK 的动手实现)
- [arXiv：AP2 的零信任运行时验证](https://arxiv.org/pdf/2602.06345) (AP2 中重放攻击和上下文绑定失败的学术处理)
- [AP2：欧盟视角](https://agentpaymentsprotocol.eu/) (代理支付的欧洲监管和标准化背景)
- [AP2 技术指南：Medium / Vishal Mysore](https://medium.com/@visrow/google-agent-payments-protocol-ap2-technical-guide-implementation-73ee772fe349) (带代码示例的实现演练)