AP2 执行流程详解
本文档说明 Agent Payments Protocol (AP2) 在一次交易中的端到端执行流程 ：参与方如何分工、凭证如何流转、以及在 A2A（Agent-to-Agent） 扩展下消息与工件（Artifact）如何承载协议数据。
数据对象的完整字段表、W3C 关系与 A2A MUST/MAY 条文 写在同目录 ap2_data_flow_and_w3c.md，本文专注流程与步骤，避免重复展开字段。
1. 先建立正确预期：什么是「执行流程」
AP2 的「执行」不是单点 API 调用，而是一套多角色协作过程：
- 用 可验证数字凭证（VDC） 把「用户授权、购物车确定性、支付网络可见性」固化成结构化对象；
- 通过 购物代理、商户代理、凭证提供方、商户支付处理方（MPP） 等角色按序交换这些对象；
- 在 A2A 上，用约定的 Message / Artifact / DataPart 键名（如
ap2.mandates.CartMandate）封装上述对象，使不同厂商实现能互操作。
下面分 人在场（Human Present） 与 人不在场（Human Not Present） 两种主流程讲解。
2. 参与方与协议角色（执行视角）
| 角色（概念） | 典型职责（执行链路上） |
|---|---|
| User | 发起购物任务；在可信界面上确认购物车与支付方式；完成挑战（如 3DS）。 |
| Shopping Agent（UA/SA） | 理解需求、与商户协商购物车、向凭证方要支付方式、展示最终购物车、协助生成用户侧授权消息。 |
| Credentials Provider（CP） | 管理支付方式与令牌；在支付执行阶段参与扣款相关交互。 |
| Merchant / Merchant Agent（ME） | 展示商品、收敛购物车、在合适时机产出 商户签名的购物车承诺（与 Cart Mandate 流程衔接）。 |
| Merchant Payment Processor（MPP） | 构造面向支付网络的授权报文，并附上 Payment Mandate 以体现交易的「代理化」特征。 |
| Network & Issuer | 风控、授权、可能发起 Challenge；返回授权结果。 |
A2A 侧最低要求（与数据文档一致） ：支持 AP2 的代理必须在 AgentCard 的 capabilities.extensions 中声明扩展 URI：https://github.com/google-agentic-commerce/ap2/tree/v0.1，并在 params.roles 中给出至少一个角色：merchant、shopper、credentials-provider、payment-processor（承担 merchant 时建议将扩展标为 required）。
3. 两种主模态：执行路径如何分叉
在场
不在场
人不在场 Human Not Present
用户先签署 Intent Mandate
商户基于意图履约或拉回用户确认
可回到 Cart Mandate 或更新 Intent
人在场 Human Present
用户可随时确认最终购物车
Cart Mandate 绑定精确交易细节
支付执行 + 可选 Challenge
用户委托代理购物
模态
4. 人在场（Human Present）------官方步骤与含义
以下步骤与 docs/topics/life-of-a-transaction.md 中 Human Present Transaction 的 1--10 步一致，此处用中文归纳并映射到凭证类型。
| 步骤 | 名称（意译） | 要点 |
|---|---|---|
| 1 | Setup | 用户可在购物代理与受支持的凭证提供方（如数字钱包）之间建立关联。 |
| 2 | Discovery & Negotiation | 用户下达任务；购物代理与一个或多个商户交互，组装满足需求的购物车。 |
| 3 | Merchant Validates Cart | 用户授权一组待购商品；商户对最终购物车签名，表示履约承诺。 |
| 4 | Provide Payment Methods | 购物代理向 Credentials Provider 请求可用支付方式。 |
| 5 | Show Cart | 在可信界面展示 商户已签名的最终购物车 与所选支付方式。 |
| 6 | Sign & Pay | 用户批准产生密码学签名的 Cart Mandate （含明确购买细节）；并准备面向支付网络的 Payment Mandate。 |
| 7 | Payment Execution | 将支付细节送达凭证方与商户侧以完成交易动作。 |
| 8 | Send to Issuer | 商户或其处理方将交易送交支付网络/发卡行，并附上 Payment Mandate，使网络可见「代理化」特征。 |
| 9 | Challenge（如需） | 任一方可触发挑战（如 3D Secure）；用户在可信界面完成。 |
| 10 | Authorization | 发卡行批准支付；用户与商户收到确认以便履约。 |
4.1 人在场：端到端泳道图（概念级）
Network / Issuer MPP Merchant Merchant Agent Credentials Provider Shopping Agent User Network / Issuer MPP Merchant Merchant Agent Credentials Provider Shopping Agent User 生成 Cart Mandate（用户侧签名） 准备 Payment Mandate alt [需要挑战] 购物任务（自然语言） 1 发现与议价、组装购物车 2 授权待购商品集合 3 锁定最终购物车 4 商户签名购物车（履约承诺） 5 请求适用支付方式 6 支付方式列表 / Token 能力 7 在可信界面展示商户签名购物车 + 支付方式 8 确认并触发签署 9 提交与支付相关的最终对象（实现相关） 10 支付执行（含 Payment Mandate） 11 上送发卡行 / 网络 12 Challenge（如 3DS） 13 在可信界面完成 14 授权结果 15 确认 16 订单/收据 17 展示完成结果 18
4.2 凭证与 A2A 封装（实现互操作的关键）
人在场路径中，文档强调两类与「授权证据」强相关的对象（概念层）：
- Cart Mandate ：用户批准后生成，绑定明确的购买细节，并作为给商户的证据（对应人在场流程第 6 步）。
- Payment Mandate：面向支付网络准备，用于 issuer/网络侧理解交易的代理性质（对应第 6、8 步）。
在 A2A 中，AP2 类型使用标准 DataPart 键名 装入 Message 或 Artifact：
| AP2 对象 | A2A 载体类型 | DataPart 键名 |
|---|---|---|
| Intent Mandate（意图授权，常用于不在场或意图阶段） | Message（IntentMandate Message） |
ap2.mandates.IntentMandate |
| Cart Mandate（购物车授权） | Artifact（CartMandate Artifact） |
ap2.mandates.CartMandate |
| Payment Mandate（支付授权） | Message（PaymentMandate Message） |
ap2.mandates.PaymentMandate |
商户侧强制规则（原文语义） ：Merchant Agent 在收齐所有「影响支付的信息」之前，不得产出 CartMandate Artifact。
其中「影响支付的信息」指：由客户端提供、会改变 CartContents 从而改变应付金额的任何信息（例如收货地址变化导致运费计入 CartContents）。IntentMandate Message 可额外携带键 risk_data；CartMandate Artifact 亦可携带 risk_data。完整条文与 JSON 示例见 ap2_data_flow_and_w3c.md 第 5 节。
AP2 数据层
A2A 传输层
Message
Artifact
IntentMandate
CartMandate
PaymentMandate
5. 人不在场（Human Not Present）------与人在场的关键差异
适用场景示例：「当价格低于 100 美元时再买这双鞋」------用户当时未必在会话中完成最终购物车点击。
与人在场相比，核心差异为：
- 意图被捕获 ：用户不是确认最终购物车，而是确认代理对需求的理解 ；通过会话内强认证（如生物识别）生成签名的 Intent Mandate。
- Intent Mandate 被使用：其中可包含自然语言描述的目标；商户据此判断是否可履约。
- 商户可强制拉回用户 ：若商户无法仅凭 Intent 确认履约，可要求用户回到会话：要么在最终选项上确认（走向 Cart Mandate ），要么补充/更新 Intent Mandate。
用户签署 Intent Mandate
商户评估可履约性
可自动推进支付链（实现与策略相关）
需要用户确认
用户确认最终购物车
更新 Intent Mandate
SignedIntent
MerchantEval
AutonomousPay
NeedUser
CartMandate
UpdateIntent
6. 「执行」如何被约束：验证点与失败语义（工程视角）
协议层不会替你在全球范围内「约束模型权重」，但会在集成边界上形成可拒绝性：
- 结构约束 ：对等方只接受符合 schema 的
IntentMandate/CartMandate/PaymentMandate载荷（键名与字段在 A2A DataPart 中约定）。 - 业务约束 ：例如商户侧仅在购物车与价格条件满足后才发布
CartMandateArtifact。 - 密码学与授权约束 ：生产实现应对
PaymentMandate.user_authorization等做完整验签与风控；教学样本可能只检查字段是否存在。
因此，一次「合规执行」= 各节点按角色发送/接收正确的 A2A 封装对象 + 在关键步骤完成用户签名或挑战 + 支付网络侧授权。
7. 小结
- AP2 执行流程 是多角色、分阶段的协作：从任务与购物车收敛，到 Cart Mandate / Payment Mandate 等凭证落地，再到网络授权与挑战。
- A2A 扩展 规定了 AP2 类型在 Message/Artifact 中的标准容器格式，是跨实现互操作的要点。
- 人在场 强调对最终购物车 的显式确认与商户签名；人不在场 以 Intent Mandate 为起点，并允许商户把用户拉回以生成 Cart Mandate 或更新意图。
具体可运行样本的步骤顺序可能因场景脚本而异，但协议层步骤与上表一致 ；对象字段一律以 ap2_data_flow_and_w3c.md 为准。