AP2: 代理支付协议

这是一篇关于 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 的结账哈希。

授权令的结构

// 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 在每次签名操作中都包含一个随机数，因此即使授权令内容相同，每个签名也是唯一的。不可能发生彩虹表攻击。

加密公式

// 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 (授权令类型、SD-JWT 编码、ECDSA 要求、参与方角色的真实来源)
• Google Cloud：宣布 AP2 (发布背景、60 多个合作伙伴、FIDO 联盟捐赠公告)
• AP2 GitHub：google-agentic-commerce/AP2 (Python、Go、TypeScript、Kotlin 和 Android 的参考实现，以及可运行的场景)
• 云安全联盟：安全使用 AP2 (STRIDE 威胁模型、ECDSA P-256 公式、MAESTRO 框架、AES-GCM-256)
• ACP vs AP2 vs MCP：协议堆栈比较 (代理商务堆栈的逐层分解)
• Eco：AP2 v0.2 解释 (v0.2 授权令重构、无人在场流程、DID 用于密钥发现)
• Cobo 代理钱包：AP2 完整指南 (x402 详情、稳定币轨道、多方钱包集成)
• UCP：AP2 授权令扩展 (AP2 如何与 Universal Commerce Protocol 在结账层集成)
• Google Codelabs：使用 AP2 和 UCP 实现安全代理商务 (针对官方 Google ADK 的动手实现)
• arXiv：AP2 的零信任运行时验证 (AP2 中重放攻击和上下文绑定失败的学术处理)
• AP2：欧盟视角 (代理支付的欧洲监管和标准化背景)
• AP2 技术指南：Medium / Vishal Mysore (带代码示例的实现演练)