AP2 协议深度解析：当 AI Agent 要刷你的信用卡，规则该怎么定？

billhan2016
26 阅读11分钟

AP2 协议深度解析：当 AI Agent 要刷你的信用卡，规则该怎么定？

导语

2025 年 9 月的一个清晨，你对 AI 助手说了一句："帮我买一台 3000 元以内的空气净化器，要适合 30 平米的房间。"

Agent 立刻开始工作——在京东、天猫、苏宁三个平台比价，筛选出 5 款候选产品，综合评分和价格后选定了一台 2680 元的型号。然后，它准备用你绑定的信用卡下单。

问题来了：

  • 银行怎么知道这笔消费是你本人授权的？ 没有密码，没有人脸识别，只是一个 AI 程序发起的请求。
  • 如果 Agent "理解错了"你的意图，买了一台 5000 元的工业级净化器，谁负责？
  • 如果这笔交易出了纠纷，你说没授权过，商家说 Agent 下了单——证据在哪里？

这三个问题，就是 AP2（Agent Payments Protocol） 要解决的核心难题。

2025 年 9 月 17 日，Google Cloud 联合 Mastercard、PayPal、American Express、Visa 等 60+ 家机构，正式发布了 AP2 协议——一个为 AI Agent 支付场景量身定制的开放标准。

本文是系列第三篇，将深入 AP2 的技术内核。

官方规范文档：ap2-protocol.org/specificati…

一、AP2 要解决什么问题？

1.1 现有支付体系的"假设"

当前全球支付体系建立在一个根本性假设之上：每一笔交易的背后，都有一个人类在直接操作。

  • 刷信用卡 → 人输入密码或签名
  • 在线支付 → 人点击"确认付款"按钮
  • 移动支付 → 人扫脸或按指纹

所有的安全机制（密码、生物识别、3D Secure）都是为"验证人"而设计的。

但当 AI Agent 代替人类发起支付时，这套假设彻底崩塌：

  • Agent 没有指纹，不能扫脸
  • Agent 不会"点击"按钮
  • Agent 的行为是基于概率推理的，可能存在"幻觉"

1.2 三大核心问题

AP2 协议围绕三个核心问题展开设计：

核心问题具体挑战后果
授权（Authorization）如何证明用户确实同意了 Agent 的这笔消费？无法证明 → 银行拒绝交易
真实性（Authenticity）如何确保 Agent 的购买行为反映了用户的真实意图，而非 AI 幻觉？意图偏差 → 买错东西、超预算
问责（Accountability）交易出错时，责任归谁？用户？Agent 开发者？商家？责任不清 → 争议无法解决

AP2 的核心设计思想：用可验证的加密凭证来替代传统的密码/签名，为每一笔 Agent 交易建立不可否认的审计链。

二、基于角色的架构

2.1 六大核心角色

AP2 采用角色分离架构，每个参与方有明确的职责边界：

graph TB
    User["<b>用户（User）</b><br/>任务发起者<br/>资金权限的最终来源"]
    SA["<b>购物代理（Shopping Agent）</b><br/>与用户交互的 AI<br/>理解需求、发现商品、协商购物车"]
    CP["<b>凭证提供商（Credential Provider）</b><br/>管理支付凭证（数字钱包）<br/>处理代币化、获取支付同意"]
    ME["<b>商家端点（Merchant Endpoint）</b><br/>卖方的 Web/MCP/AI 接口<br/>展示商品、确认购物车"]
    MPE["<b>支付处理端点</b><br/>构建交易授权消息<br/>发送至支付网络"]
    NI["<b>网络与发行方</b><br/>支付网络（Visa/Mastercard）<br/>+ 发卡行"]

    User -->|"授权任务"| SA
    SA <-->|"A2A 协议<br/>协商购物车"| ME
    SA -->|"请求支付凭证"| CP
    CP -->|"获取用户同意"| User
    ME -->|"发起支付"| MPE
    MPE -->|"交易授权"| NI

    style User fill:#fff,stroke:#333,stroke-width:2px,color:#333
    style SA fill:#fff,stroke:#333,stroke-width:2px,color:#333
    style CP fill:#fff,stroke:#333,stroke-width:2px,color:#333
    style ME fill:#fff,stroke:#333,stroke-width:2px,color:#333
    style MPE fill:#fff,stroke:#333,stroke-width:2px,color:#333
    style NI fill:#fff,stroke:#333,stroke-width:2px,color:#333

2.2 角色职责详解

角色核心职责安全约束
用户发起任务、审批购物车、签署授权凭证持有设备硬件密钥，是唯一的签名主体
购物代理理解用户需求、与商家协商、呈现方案不能直接接触支付凭证和 PCI 数据
凭证提供商管理用户的信用卡/钱包、处理代币化专门的安全实体，隔离支付敏感数据
商家端点展示商品、签署购物车、确认交付确保商品和价格信息的准确性
支付处理端点构建交易授权消息（可以是商家或 PSP）负责与支付网络的交互
网络与发行方处理交易授权、风控、清算获取 Agent 交易的可视性信息

关键设计：购物代理（Agent）被明确隔离在支付凭证之外。 Agent 可以帮你选商品、谈价格，但它永远不会触碰你的信用卡号或银行密码。这通过角色分离和凭证提供商的独立地位来保证。

三、核心技术：可验证数字凭证（VDC）

3.1 VDC 是什么？

可验证数字凭证（Verifiable Digital Credential，VDC） 是 AP2 协议的技术核心——一种防篡改、可移植、经过加密签名的数据对象。

简单来说：VDC 就是 Agent 交易的"电子合同"，每一笔消费都有一份经过加密签名的凭证，证明"谁授权了什么"。

3.2 三种 VDC 类型

AP2 定义了三种 VDC，分别适用于不同的交易场景：

graph LR
    subgraph "用户在场"
        CM["<b>购物车授权</b><br/>Cart Mandate<br/>用户看到最终购物车<br/>并用硬件密钥签名确认"]
    end
    subgraph "用户不在场"
        IM["<b>意图授权</b><br/>Intent Mandate<br/>用户提前设定条件<br/>Agent 异步执行"]
    end
    subgraph "支付网络"
        PM["<b>支付授权</b><br/>Payment Mandate<br/>向银行/卡组织提供<br/>Agent 交易的可视性"]
    end

    CM --> PM
    IM --> PM

    style CM fill:#fff,stroke:#333,stroke-width:2px,color:#333
    style IM fill:#fff,stroke:#333,stroke-width:2px,color:#333
    style PM fill:#fff,stroke:#333,stroke-width:2px,color:#333
类型一：购物车授权（Cart Mandate）

适用场景：用户在场交易——用户能实时查看并确认购物车内容。

字段说明
商品明细具体的商品名称、数量、单价
总金额最终的交易金额
商家信息商家签名的购物车数据
支付方式用户选定的支付方式（信用卡、银行转账等）
风险载荷设备信息、地理位置等风控数据
用户签名用户通过设备硬件密钥的加密签名

关键流程：

  1. Agent 与商家协商完最终购物车
  2. 商家对购物车内容进行签名（防止事后篡改价格）
  3. Agent 将签名后的购物车展示给用户
  4. 用户在自己的设备上用硬件密钥签名确认
  5. 签名后的 Cart Mandate 传递给凭证提供商处理支付

核心价值：不可否认性。 用户的硬件密钥签名是防篡改的——它能证明"这个人，在这个时间，批准了这个具体的购物车"。

类型二：意图授权（Intent Mandate）

适用场景：用户不在场交易——用户提前授权，Agent 在条件满足时自主执行。

这是 AP2 最具创新性的设计。

字段说明
支付方式类别授权使用的支付方式范围（如"任意信用卡"或"仅 Visa 卡"）
购物意图产品类别、预算上限、品牌偏好等
Agent 回放Agent 用自然语言复述它对用户指令的理解
用户签名用户确认 Agent 的理解无误后签名

关键流程：

  1. 用户设定条件任务："当 AirPods Pro 降到 1500 以下时帮我买一副"
  2. Agent 复述理解："我理解您的意思是：当 AirPods Pro 3 的价格降到 1500 元以下时，自动为您购买一副，使用您的 Visa 信用卡支付"
  3. 用户确认 Agent 的复述无误，并签名授权
  4. Agent 持续监控价格，满足条件时自动执行
  5. 如果 Agent 无法确定具体商品（如出现多个版本），可强制要求用户回话确认

Agent 回放的意义： 这是一个巧妙的设计——让 Agent "复述"它的理解，然后用户签字确认。这样一来，如果 Agent 后来买错了东西，可以回溯检查是 Agent 理解错了（Agent 服务商的责任），还是用户确认了错误的理解（用户的责任）。

类型三：支付授权（Payment Mandate）

适用场景：向支付网络（银行/卡组织）提供 Agent 交易的可视性。

字段说明
Agent 参与信号标识这是一笔由 Agent 发起的交易
交易模式用户在场（Cart Mandate）还是不在场（Intent Mandate）
关联的上游 VDC指向对应的购物车授权或意图授权

核心价值： 让支付网络和发卡行"看见" Agent 交易。传统的交易消息中没有"这是 Agent 发起的"这个信号，导致银行的风控系统无法区分正常的 Agent 交易和盗刷。Payment Mandate 填补了这个空白。

3.3 三种 VDC 的对比

维度Cart MandateIntent MandatePayment Mandate
签名者用户 + 商家用户 + AgentAgent + 凭证提供商
用户状态在场（实时确认）不在场（事先授权）不直接参与
绑定内容具体的商品和价格抽象的意图和条件交易元数据
适用场景电商下单、订票自动补货、条件触发购买所有 Agent 交易
风险级别低（用户逐笔确认）中（依赖 Agent 判断）-

四、完整交易流程

4.1 用户在场交易

sequenceDiagram
    participant U as 用户
    participant SA as 购物代理
    participant ME as 商家 Agent
    participant CP as 凭证提供商
    participant NI as 支付网络

    U->>SA: "帮我买一台降噪耳机，3000以内"
    SA->>ME: [A2A] 搜索商品、比价
    ME-->>SA: 返回商品列表
    SA->>SA: 智能选品，生成最优方案
    SA->>ME: 确定商品，请求生成购物车
    ME-->>SA: 返回商家签名的购物车

    SA->>U: 展示最终方案和购物车
    U->>U: 查看确认，硬件密钥签名
    U-->>SA: 签名后的 Cart Mandate

    SA->>CP: 提交 Cart Mandate + 请求支付
    CP->>U: 确认使用哪张卡（可选）
    U-->>CP: 确认
    CP->>NI: 提交 Payment Mandate + 交易请求
    NI-->>CP: 交易授权成功
    CP-->>SA: 支付完成
    SA-->>U: "已为您购买 Sony WH-1000XM5，实付 2680 元"

4.2 用户不在场交易

sequenceDiagram
    participant U as 用户
    participant SA as 购物代理
    participant ME as 商家 Agent
    participant CP as 凭证提供商

    U->>SA: "AirPods Pro 降到1500以下时帮我买"
    SA->>U: "我理解：当 AirPods Pro 3 价格<1500元时，<br/>自动购买，使用 Visa 信用卡支付。对吗？"
    U->>U: 确认无误，硬件密钥签名
    U-->>SA: 签名后的 Intent Mandate

    Note over SA: 持续监控价格...（可能数天）

    SA->>ME: [A2A] 检测到价格 ¥1,480
    ME-->>SA: 确认库存和价格
    SA->>ME: 确定购买
    ME-->>SA: 返回商家签名的购物车
    SA->>CP: 提交 Intent Mandate + Cart + 请求支付
    CP->>CP: 验证 Intent Mandate 签名<br/>验证购物车是否符合意图范围
    CP-->>SA: 支付完成
    SA->>U: 推送通知："已为您购买 AirPods Pro 3，¥1,480"

关键区别： 在不在场交易中，如果商家提供的商品信息模糊（比如同时有 AirPods Pro 3 和 AirPods Pro 2），Agent 无法确定用户想要哪一款时，协议允许强制回话——将交易模式切换为"在场交易"，要求用户回来确认。

五、信任流设计

5.1 短期信任：允许列表

在 AP2 生态的早期阶段，信任通过人工管理的允许列表建立：

  • 购物代理只与受信任的凭证提供商交互（白名单）
  • 凭证提供商只接受经过审核的购物代理的请求
  • 商家只对接经过认证的 Agent 平台

5.2 长期信任：基于标准的动态信任

随着生态成熟，AP2 计划利用 A2A 和 MCP 中的身份断言方法，结合已有标准建立动态信任：

技术用途
HTTPS / TLS传输层加密
DNS 所有权验证确认 Agent 归属的组织
mTLS（双向 TLS）双方相互验证身份
API Key 交换基于密钥的接入控制
Agent Card 签名验证 Agent 身份的真实性

六、争议解决框架

6.1 传统支付争议 vs Agent 支付争议

传统信用卡争议通常只有两种情况：持卡人说"我没消费过"（盗刷），或"商品不对"（商家问题）。

但 Agent 支付引入了新的争议维度：

争议类型描述可能的责任方
Agent 误解意图Agent 买错了商品Agent 服务商
Agent 超出授权Agent 消费超出预算限制Agent 服务商
商家不履约商家没有按照购物车交付商家
用户否认授权用户声称未授权（实际已签名）用户
账户被盗攻击者控制了用户的 Agent视安全责任而定

6.2 基于 VDC 的证据链

AP2 的争议解决依赖 VDC 形成的加密证据链：

用户签名的 Intent/Cart Mandate
    ↓ 证明用户授权了什么
Agent 回放的自然语言理解
    ↓ 证明 Agent 理解的是什么
商家签名的购物车
    ↓ 证明商家承诺了什么
支付授权记录
    ↓ 证明最终执行了什么

仲裁逻辑：

  • 如果用户签名的 Mandate 中明确包含了争议商品 → 用户已授权，用户承担责任
  • 如果 Agent 的回放与用户的原始指令不符 → Agent 理解错误，Agent 服务商承担责任
  • 如果商家交付的商品与签名购物车不符 → 商家未履约，商家承担责任
  • 如果用户的签名密钥被盗用 → 账户安全问题，视具体情况分配责任

七、版本路线图与生态现状

7.1 版本演进

版本时间核心内容
V0.12025.09"拉"支付（信用卡）+ 用户在场 + 基于 A2A 的参考实现
V1.x计划中"推"支付 + 订阅 + 用户不在场 + 基于 MCP 的实现
长期远期多商家交易拓扑 + 买卖方 Agent 实时谈判

7.2 与 A2A、x402 的关系

AP2 被明确设计为 A2A 和 MCP 的扩展，而非独立的协议：

关系说明
AP2 + A2A购物代理通过 A2A 协议与商家 Agent 通信和协商，AP2 处理支付授权
AP2 + MCP购物代理通过 MCP 接入商家的产品目录和库存系统
AP2 vs x402AP2 面向传统支付（信用卡/银行），x402 面向 Crypto 支付（稳定币）；两者互补

八、写在最后

AP2 协议的出现，本质上是在回答一个根本性问题：在 AI 代替人类做决策的时代，信任的基础设施该怎么建？

传统支付体系用密码和签名建立信任：你输入密码 = 你同意这笔交易。这个模型简单、有效，但无法应对 Agent 场景。

AP2 的答案是 "可验证的意图"：不依赖密码，而是通过加密签名的数字凭证，把用户的授权、Agent 的理解、商家的承诺全部"锁"进一条不可篡改的证据链中。每一笔交易都有完整的审计轨迹，每一个参与方的责任都有据可查。

这套设计哲学超越了支付本身——它为 AI 代理人类行事的所有场景，提供了一个"可验证意图"的范式。 未来，签合同、做投资、管理资产，都可能采用类似的授权机制。

下一篇，我们将深入 x402 协议——一个完全不同的支付哲学：不需要授权、不需要账户、不需要签名，只需要一个 HTTP 请求和一笔链上转账。

关注公众号「coft」，获取更多 AI 时代的深度洞察和技术实战干货。

avatar
文章
阅读
粉丝