付钱结算 — 当交互涉及钱
1. 这条分支是什么
共性落到最高风险的一面:
当 agent 的交互涉及钱,契约必须同时回答“买什么(发现/下单)、凭什么允许它付(授权)、钱怎么真的过去(结算)”——三者环环相扣,且每一步都要可验证、可追责。
第一性原理:人结账时,“选商品、刷卡授权、银行清算”三步糊在一次点击里。agent 没有人在场,这三步必须被拆成显式、可验证的契约层——否则没人能证明“这笔钱是用户真授权 agent 花的”。本分支四个库恰好分别钉在这三层上,而且它们是叠层而非互斥。
2. 分支内有哪几种做法(三层,叠着用)
付钱结算(三层,自上而下叠)
├── 交易流程层:发现商品 → 购物车 → 下单
│ ├── UCP ............... 通用商务协议(发现/购物车/结账,REST + MCP + A2A 绑定)
│ └── ACP-commerce ..... OpenAI/Stripe 代理结账(RFC 化:cart/checkout/delegate_payment)
├── 授权层:把用户的支付权限可验证地委托给 agent
│ └── AP2 .............. mandate(意图/购物车授权),不管线上结算
└── 结算层:钱在传输上真的过去
└── x402 ............. HTTP 402 挑战/应答(PaymentRequirements/PaymentPayload),绑 HTTP/A2A/MCP
关键:这不是“四选一”。一条完整链路可能是 UCP/ACP 跑流程 → AP2 出 mandate 做授权 → x402 在传输层结算。
3. 对比矩阵
| 库 | 在哪一层 | 标准化的核心对象 | 绑定/传输 | 治理 | 成熟度 | 代码锚点 |
|---|---|---|---|---|---|---|
| ucp-protocol | 交易流程(发现→结账) | catalog / cart / checkout / order;复用 AP2 mandate | REST + MCP + A2A 多绑定 | Universal Commerce Protocol | dated release(钉日期,别用 latest) | ucp-protocol/docs/specification/checkout-mcp.md、cart-rest.md、ap2-mandates.md |
| acp-agentic-commerce | 交易流程(代理结账) | agentic_checkout / cart / capability_negotiation / delegate_payment 等 RFC | REST-first,另有 MCP 绑定文档 | OpenAI + Stripe(驱动 ChatGPT Instant Checkout) | 各 RFC 成熟度不一,逐份看 header | acp-agentic-commerce/rfcs/rfc.agentic_checkout.md、rfc.delegate_payment.md;docs/mcp-binding.md |
| ap2-protocol | 授权(mandate) | mandate(把用户支付权限可验证地委托给 agent);角色/信任边界 | 与 A2A 组合;授权而非结算 | Google 发起,2026-04 入 FIDO Alliance | 已成形,留意 spec 迁移 | ap2-protocol/docs/overview.md:211(mandate);code/(样例) |
| x402-protocol | 结算(传输层) | PaymentRequirements / PaymentPayload / SettlementResponse;scheme(exact/upto) | 绑 HTTP、A2A、MCP 三种传输 | x402 Foundation(2026-04 从 Coinbase 迁出) | v2 为准,v1 仅迁移用 | x402-protocol/specs/x402-specification-v2.md:66;specs/transports-v2/{a2a,mcp,http}.md |
4. 模式与权衡
- 三层叠加,不是竞品。 AP2 管“凭什么允许付”(mandate 授权),x402 管“钱怎么过”(传输结算),UCP/ACP 管“买什么、怎么走完流程”。同一条结账链路可以三者同时在场。
- UCP 与 ACP-commerce 在“交易流程层”确有重叠。 两者都覆盖发现→购物车→结账;选型看生态(ACP 绑 OpenAI/Stripe + ChatGPT Instant Checkout;UCP 更中立、多绑定)。下游集成挑主参考前先查 audit。
- 授权与结算必须分开。 AP2 刻意只定义授权(mandate),不定义线上结算;结算交给 x402——职责分离才能让“授权可验证”和“结算可换实现”各自演进。
- REST 优先,MCP/A2A 是桥。 这条分支的规范语言大多 REST-first;要接 tool-based agent,看各自的 MCP/A2A 绑定文档(UCP 的
checkout-mcp.md、ACP 的mcp-binding.md、x402 的transports-v2/mcp.md)。
5. 趋势
- 治理近期剧烈变动:AP2 入 FIDO、x402 从 Coinbase 迁到 x402 Foundation——旧链接可能指向旧 org,引用钉 lock commit。
- 支付正被设计成可跨协议组合:x402 同时绑 HTTP/A2A/MCP,A2A 用扩展(a2a-x402)接 x402,UCP 复用 AP2 mandate(见总纲 §4)。趋势是“小而可叠的支付原语”而非单体结账协议。
6. 代表作 + 深入
- 首读:
x402-protocol(specs/x402-specification-v2.md是 v2 线格式权威)。 (TODO: 待 x402-protocol 子库 doc) - 授权概念:
ap2-protocol(docs/overview.md的 mandate)。 (TODO: 待子库 doc) - 交易流程:
ucp-protocol、acp-agentic-commerce。 (TODO: 待各子库 doc)