Nexus 与 AP2：凭证提供者 + 结算轨道
发布时间：2026-03 | 基于 AP2 规范、Google Cloud 博客与 Nexus 实施计划
概述
Google 的 Agent 支付协议（AP2）定义了 Agent 如何通过三层 Mandate 证据链授权和审计支付。Nexus 以 凭证提供者（Credential Provider）和结算轨道 的角色接入 AP2 — 接收 AP2 生态的 Mandate，通过链上托管完成结算，并将 PaymentMandate VC 签发回 AP2 证据链。
Nexus 兼容 AP2 协议，并正在积极适配基础设施以服务 AP2 生态商户。
速览
| 维度 | AP2 | Nexus |
|---|---|---|
| 发起方 | Google + 60 合作伙伴 (2025) | Nexus 团队 |
| 层级 | 支付授权与审计追踪 | 结算与资金托管 |
| 核心机制 | 可验证凭证 Mandate | 链上托管 + 状态机 |
| 安全模型 | 密码学证据链 | 托管锁定 + 自动退款 |
| 支付方式 | 信用卡、稳定币、银行转账 | USDC（链上） |
| 争议方式 | 基于证据的事后仲裁 | 确定性链上解决 |
| 签名算法 | JCS + ECDSA P-256 | EIP-712 + secp256k1 |
| 传输 | A2A、MCP | MCP、REST API、HTTP 402 |
AP2 的三层 Mandate 模型
AP2 通过三个可验证数字凭证（VDC）建立完整的证据链：
┌──────────────────────────────────────────────────────┐
│ 第一层：Intent Mandate │
│ "我想买一副降噪耳机，预算 300 美元以内" │
│ 签名方：用户（设备密钥） │
│ 用途：为 Agent 自主决策场景捕获授权 │
│ （人类不在场） │
├──────────────────────────────────────────────────────┤
│ 第二层：Cart Mandate │
│ "我批准这个购物车：Sony WH-1000XM6，$279.99" │
│ 签名方：用户（密码学签名） │
│ 用途：精确购买内容的不可否认证明 │
├──────────────────────────────────────────────────────┤
│ 第三层：Payment Mandate │
│ "资金已通过 Nexus 托管结算，tx 0xabc..." │
│ 签名方：凭证提供者（Nexus） │
│ 用途：向支付网络通知结算完成 │
└──────────────────────────────────────────────────────┘AP2 定义了第一层和第二层。第三层 — PaymentMandate — 正是 Nexus 接入的位置。
Nexus 如何接入 AP2
Nexus 作为 AP2 的凭证提供者：接收来自 AP2 生态的 CartMandate VC，将其翻译为内部结算格式（NUPS），通过托管管线完成结算，并签发 PaymentMandate VC 回到证据链。
AP2 Shopping Agent Nexus（凭证提供者）
│ │
│ 1. CartMandate VC │
│ （用户签名，商品 + 总额） │
├─────────────────────────────────────────→ │
│ │ 2. 验证 JCS 签名
│ │ 3. 解析校验 VC
│ │ 4. CartMandate → NUPS Quote 转换
│ │ 5. 执行托管管线
│ │ （锁定资金至智能合约）
│ │
│ 6. Checkout URL (HTTP 402) │
│ ←──────────────────────────────────────── │
│ │
│ [用户签署托管交易] │
│ │
│ │ 7. 检测链上 ESCROWED
│ │ 8. 签发 PaymentMandate VC
│ 9. PaymentMandate VC │
│ ←──────────────────────────────────────── │
│ │
│ （证据链完成： │
│ Intent → Cart → Payment） │什么改了，什么没改
| 组件 | 变更 |
|---|---|
| AP2 Adapter（新增） | 解析 CartMandate VC、验证 JCS 签名、翻译为 NUPS |
| PaymentMandate 生成器（新增） | 托管确认后签发 VC |
| 托管合约 | 零改动 — 同一个 13 态状态机 |
| 编排管线 | 零改动 — AP2 适配器接入现有管线 |
| Webhook 系统 | 零改动 |
| 现有 NUPS 商户 | 零改动、零感知 |
设计原则：边缘适配，核心不动。
为什么 AP2 需要 Nexus 结算
AP2 Mandate 提供的是事后审计能力 — 出问题时证据链可以证明谁授权了什么。但 Mandate 本身不能防止资金损失。Nexus 增加了事前资金保护：
| 能力 | 仅 AP2 | AP2 + Nexus |
|---|---|---|
| 授权证明 | CartMandate VC（密码学） | CartMandate VC（不变） |
| 资金保护 | 取决于支付处理器 | 交付前托管锁定 |
| 未交付追索 | 基于证据的争议（数天/数周） | 超时自动退款（确定性） |
| 争议证据 | Mandate 链 | Mandate 链 + 链上状态转换 |
| 结算隐私 | 取决于支付处理器 | 隐私代币（ZK 证明） |
AP2 回答"谁授权了这笔支付？" Nexus 回答"资金在交付前是否安全？"
双路径架构
Nexus 通过同一套结算基础设施支持两条并行路径 — 现有 NUPS 原生商户和 AP2 生态商户：
| 路径 A：NUPS 原生 | 路径 B：AP2 → Nexus | |
|---|---|---|
| Agent 协议 | NUPS（Nexus 原生） | AP2 |
| 授权方式 | EIP-712 群组签名 | CartMandate VC（JCS + P-256） |
| 商户发现 | skill.md / MCP 工具 | AP2 Shopping Agent |
| 报价格式 | NexusQuotePayload | CartMandate → 自动翻译 |
| 结算 | 托管（相同） | 托管（相同） |
| 证据输出 | 链上 tx + webhook | 链上 tx + PaymentMandate VC |
两条路径在编排管线处汇合。托管合约对它们一视同仁。
证据链优势
当 Nexus 结算一笔 AP2 支付时，产生的证据链比任何单一协议都更强：
- Intent Mandate（用户签名）— "我授权最多 $300 购买耳机"
- Cart Mandate（用户签名）— "我批准了这个 $279.99 的购物车"
- 链上托管记录（智能合约）— "$279.99 USDC 在区块 #N 锁定，区块 #M 释放"
- Payment Mandate（Nexus 签名）— "结算完成，交易哈希 0xabc..."
当争议发生时，仲裁者拥有用户意图、用户批准、资金托管和结算完成的密码学证明 — 覆盖交易的每一个阶段。
核心结论
Nexus 是 AP2 的凭证提供者。 接收来自 AP2 Agent 的 CartMandate VC，通过链上托管结算，并签发 PaymentMandate VC 完成三层证据链。
Mandate + 托管 = 完整保护。 AP2 提供审计级的授权证明。Nexus 提供事前的资金安全。两者共同覆盖了"谁授权的"和"资金是否受保护"。
结算核心零改动。 AP2 集成是协议边缘的适配器。托管合约、13 态状态机和 Webhook 系统保持不变 — 降低风险，保留经过验证的基础设施。
两条路径，一个结算层。 NUPS 原生商户和 AP2 生态商户都通过同一套托管管线结算。Nexus 成为服务多种 Agent 支付协议的结算轨道。