AP2 协议深度解析：当 AI Agent 要刷你的信用卡，规则该怎么定？
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 要解决什么问题？
1.1 现有支付体系的"假设"
当前全球支付体系建立在一个根本性假设之上：每一笔交易的背后，都有一个人类在直接操作。
- 刷信用卡 → 人输入密码或签名
- 在线支付 → 人点击"确认付款"按钮
- 移动支付 → 人扫脸或按指纹
所有的安全机制（密码、生物识别、3D Secure）都是为"验证人"而设计的。
但当 AI Agent 代替人类发起支付时，这套假设彻底崩塌：
- Agent 没有指纹，不能扫脸
- Agent 不会"点击"按钮
- Agent 的行为是基于概率推理的，可能存在"幻觉"
1.2 三大核心问题
AP2 协议围绕三个核心问题展开设计：
| 核心问题 | 具体挑战 | 后果 |
|---|---|---|
| 授权（Authorization） | 如何证明用户确实同意了 Agent 的这笔消费？ | 无法证明 → 银行拒绝交易 |
| 真实性（Authenticity） | 如何确保 Agent 的购买行为反映了用户的真实意图，而非 AI 幻觉？ | 意图偏差 → 买错东西、超预算 |
| 问责（Accountability） | 交易出错时，责任归谁？用户？Agent 开发者？商家？ | 责任不清 → 争议无法解决 |
AP2 的核心设计思想：用可验证的加密凭证来替代传统的密码/签名，为每一笔 Agent 交易建立不可否认的审计链。
二、基于角色的架构
2.1 六大核心角色
AP2 采用角色分离架构，每个参与方有明确的职责边界：
2.2 角色职责详解
| 角色 | 核心职责 | 安全约束 |
|---|---|---|
| 用户 | 发起任务、审批购物车、签署授权凭证 | 持有设备硬件密钥，是唯一的签名主体 |
| 购物代理 | 理解用户需求、与商家协商、呈现方案 | 不能直接接触支付凭证和 PCI 数据 |
| 凭证提供商 | 管理用户的信用卡/钱包、处理代币化 | 专门的安全实体，隔离支付敏感数据 |
| 商家端点 | 展示商品、签署购物车、确认交付 | 确保商品和价格信息的准确性 |
| 支付处理端点 | 构建交易授权消息（可以是商家或 PSP） | 负责与支付网络的交互 |
| 网络与发行方 | 处理交易授权、风控、清算 | 获取 Agent 交易的可视性信息 |
关键设计：购物代理（Agent）被明确隔离在支付凭证之外。 Agent 可以帮你选商品、谈价格，但它永远不会触碰你的信用卡号或银行密码。这通过角色分离和凭证提供商的独立地位来保证。
三、核心技术：可验证数字凭证（VDC）
3.1 VDC 是什么？
可验证数字凭证（Verifiable Digital Credential，VDC） 是 AP2 协议的技术核心——一种防篡改、可移植、经过加密签名的数据对象。
简单来说：VDC 就是 Agent 交易的"电子合同"，每一笔消费都有一份经过加密签名的凭证，证明"谁授权了什么"。
3.2 三种 VDC 类型
AP2 定义了三种 VDC，分别适用于不同的交易场景：
类型一：购物车授权（Cart Mandate）
适用场景：用户在场交易——用户能实时查看并确认购物车内容。
| 字段 | 说明 |
|---|---|
| 商品明细 | 具体的商品名称、数量、单价 |
| 总金额 | 最终的交易金额 |
| 商家信息 | 商家签名的购物车数据 |
| 支付方式 | 用户选定的支付方式（信用卡、银行转账等） |
| 风险载荷 | 设备信息、地理位置等风控数据 |
| 用户签名 | 用户通过设备硬件密钥的加密签名 |
关键流程：
- Agent 与商家协商完最终购物车
- 商家对购物车内容进行签名（防止事后篡改价格）
- Agent 将签名后的购物车展示给用户
- 用户在自己的设备上用硬件密钥签名确认
- 签名后的 Cart Mandate 传递给凭证提供商处理支付
核心价值：不可否认性。 用户的硬件密钥签名是防篡改的——它能证明"这个人，在这个时间，批准了这个具体的购物车"。
类型二：意图授权（Intent Mandate）
适用场景：用户不在场交易——用户提前授权，Agent 在条件满足时自主执行。
这是 AP2 最具创新性的设计。
| 字段 | 说明 |
|---|---|
| 支付方式类别 | 授权使用的支付方式范围（如"任意信用卡"或"仅 Visa 卡"） |
| 购物意图 | 产品类别、预算上限、品牌偏好等 |
| Agent 回放 | Agent 用自然语言复述它对用户指令的理解 |
| 用户签名 | 用户确认 Agent 的理解无误后签名 |
关键流程：
- 用户设定条件任务："当 AirPods Pro 降到 1500 以下时帮我买一副"
- Agent 复述理解："我理解您的意思是：当 AirPods Pro 3 的价格降到 1500 元以下时，自动为您购买一副，使用您的 Visa 信用卡支付"
- 用户确认 Agent 的复述无误，并签名授权
- Agent 持续监控价格，满足条件时自动执行
- 如果 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 Mandate | Intent Mandate | Payment Mandate |
|---|---|---|---|
| 签名者 | 用户 + 商家 | 用户 + Agent | Agent + 凭证提供商 |
| 用户状态 | 在场（实时确认） | 不在场（事先授权） | 不直接参与 |
| 绑定内容 | 具体的商品和价格 | 抽象的意图和条件 | 交易元数据 |
| 适用场景 | 电商下单、订票 | 自动补货、条件触发购买 | 所有 Agent 交易 |
| 风险级别 | 低（用户逐笔确认） | 中（依赖 Agent 判断） | - |
四、完整交易流程
4.1 用户在场交易
4.2 用户不在场交易
关键区别： 在不在场交易中，如果商家提供的商品信息模糊（比如同时有 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.1 | 2025.09 | "拉"支付（信用卡）+ 用户在场 + 基于 A2A 的参考实现 |
| V1.x | 计划中 | "推"支付 + 订阅 + 用户不在场 + 基于 MCP 的实现 |
| 长期 | 远期 | 多商家交易拓扑 + 买卖方 Agent 实时谈判 |
7.2 与 A2A、x402 的关系
AP2 被明确设计为 A2A 和 MCP 的扩展，而非独立的协议：
| 关系 | 说明 |
|---|---|
| AP2 + A2A | 购物代理通过 A2A 协议与商家 Agent 通信和协商，AP2 处理支付授权 |
| AP2 + MCP | 购物代理通过 MCP 接入商家的产品目录和库存系统 |
| AP2 vs x402 | AP2 面向传统支付（信用卡/银行），x402 面向 Crypto 支付（稳定币）；两者互补 |
八、写在最后
AP2 协议的出现，本质上是在回答一个根本性问题：在 AI 代替人类做决策的时代，信任的基础设施该怎么建？
传统支付体系用密码和签名建立信任：你输入密码 = 你同意这笔交易。这个模型简单、有效，但无法应对 Agent 场景。
AP2 的答案是 "可验证的意图"：不依赖密码，而是通过加密签名的数字凭证，把用户的授权、Agent 的理解、商家的承诺全部"锁"进一条不可篡改的证据链中。每一笔交易都有完整的审计轨迹，每一个参与方的责任都有据可查。
这套设计哲学超越了支付本身——它为 AI 代理人类行事的所有场景，提供了一个"可验证意图"的范式。 未来，签合同、做投资、管理资产，都可能采用类似的授权机制。
下一篇，我们将深入 x402 协议——一个完全不同的支付哲学：不需要授权、不需要账户、不需要签名，只需要一个 HTTP 请求和一笔链上转账。
关注公众号「coft」，获取更多 AI 时代的深度洞察和技术实战干货。
浙公网安备 33010602011771号