AP2 是一份策略协议（把授权建模为 W3C VC），不是支付轨道——搞清这点就是全部要读的东西。
每一篇"AP2 将让智能体自主交易"的帖子都把一件事讲错了：AP2 不是支付轨道，而是一份授权协议。Intent、Cart、Payment 被建模为 W3C 可验证凭证，智能体把它们出示给商户；真正的资金流动仍走你原本已有的轨道。Google 在 2025 年 9 月宣布 AP2，60+ 合作方启用。这篇讲 AP2 到底做什么、它如何位于 A2A 和 MCP 之上，以及那套需要保持怀疑的稳定币叙事。
授权，不是轨道。
关于 AP2 最清晰的心理模型是：它是一份披着商务外衣的授权协议。当智能体代用户购物时，有三个各自独立的问题必须回答：用户授权智能体做什么、智能体实际尝试了什么、商户收取了什么。传统的卡不在场（CNP）流把三者压成一个"智能体输入卡号、商户扣款"，人点"购买"按钮时能凑效，智能体来做时其实无法凑效。AP2 把三者拆成互相独立的签名声明——Intent 记录用户所"同意"的内容、Cart 记录智能体即将购买的内容、Payment 记录商户执行的交易——并要求各方对绑住自己的那份签字。
轨道未变。若用户 Intent 授权一笔卡交易且 Cart 相符，商户仍走它一直用的支付处理器扣款；若流程是银行转账，转账仍走同一条 ACH 或 SEPA。AP2 不承载资金。它增加的是一份账本——加密签名、可独立验证——记录每方在每一步同意了什么。当拒付到来，商户不必强辩"客户的智能体输入了卡号"；它可以指着用户签名的 Intent VC 与商户签发的 Cart VC，证明两者匹配。协议的全部价值在于：商户从此能把一名自主智能体与一张被盗卡区分开——因为智能体出示一份范围合适的 Intent，而被盗卡没有。
Intent/Cart/Payment 作为 VC。
三个 artifact 每一份都是 W3C 可验证凭证——与可验证大学学位、政府身份的试点相同的形状，应用到商务。Intent VC 由用户（或用户身份服务代其）签发，声明智能体被授权购买的对象、价格上限、可涉及的商户类别、时间窗口。Cart VC 由智能体签发给商户，列出智能体实际提议购买的项目——商户在扣款前比对 Cart 与 Intent，若 Cart 越出 Intent 范围则拒绝交易。Payment VC 由商户签发回智能体（并抄给用户身份服务），作为"交易已按授权条款清算"的回执式证据。
{
"@context": ["https://www.w3.org/ns/credentials/v2",
"https://ap2-protocol.org/schemas/cart/v1"],
"type": ["VerifiableCredential", "CartMandate"],
"issuer": "https://agent.acme.example",
"validFrom": "2026-07-10T14:22:11Z",
"validUntil": "2026-07-10T14:32:11Z",
"credentialSubject": {
"intentRef": "urn:ap2:intent:9c4a2b",
"merchant": "https://merchant.example",
"items": [{"sku": "A-1027", "qty": 1, "price": {"amount": "42.50", "currency": "USD"}}],
"total": {"amount": "42.50", "currency": "USD"},
"authorisedBy": "did:key:z6Mkf..."
},
"proof": {"type": "DataIntegrityProof", "cryptosuite": "eddsa-2022", "proofValue": "..."}
}
三者的生命周期靠引用相扣：Cart VC 的 intentRef 指名它绑住的 Intent，Payment VC 引用它结算的 Cart。任何持有链的方均可独立验签——用户的身份服务能证明它签发的 Intent；商户能证明它接受的 Cart；两方都能证明 Payment。因为它们是 VC 而不是会话 cookie，artifact 能活出流程之外——可以归档、回放给审计、存留超过底层 HTTP 会话生命周期。这正是 AP2 的账本对合规有用，而不仅对实时授权有用的原因。
AP2 在栈中的位置。
AP2 位于 A2A v1.0 与 MCP 之上；不替代任何一方。典型购物流里，用户与购物智能体对话；购物智能体经 A2A 与商户智能体对话、或经 MCP 与商户 API 对话，或两者混用；AP2 是叠在两者之上的授权层，把 Intent/Cart/Payment 三元组承载在底层协议提供的传输里。在 A2A 上，授权作为 task 上的结构化 artifact；在 MCP 上，作为工具输入与结构化输出；在直接 HTTP API 上，作为请求与响应体。AP2 的传输无关性是刻意的——意味着已经接了 A2A 的商户不需新增一种传输就能接受授权，只需一种新内容类型。
Agent Card 机制与之扣合：接受 AP2 授权的 A2A 商户智能体会在其扩展卡片上声明这一点，附上它支持的授权 schema 与它信任的 Intent 签发方身份服务。购物智能体读商户卡片，发现商户是否愿接受用户的 Intent 格式，据此决定继续或退化到非-agent 流（把用户重定向到人工结账）。对架构的后果是：AP2 不把智能体推入新拓扑——同一 agent-to-agent 或 agent-to-tool 拓扑无需额外管线即可承载授权。
稳定币话术的检验。
2025 年末每一篇在 Hacker News 火过的 AP2 博客，第一段都是关于稳定币的、关于 AP2 将如何让智能体跨境秒到、绕过银行的段落。AP2 规范对底层轨道保持中立——它可以绑到卡网、银行轨道、实时支付方案、稳定币轨道——但规范并不要求也并不特别偏好稳定币。稳定币叙事来自首批启用合作方之中的一些——他们卖稳定币基础设施，商业上有理由领着这个框架走。规范本身把轨道视作 Payment VC 上众多签名字段之一。
值得对稳定币话术保持距离的理由是：2026-2027 年多数智能体商务仍会在商户已有轨道上跑，因为授权故事解决的才是真正的瓶颈。商户已经接卡；问题不在卡太慢，而在商户没法把智能体与被盗卡区分开。一旦 AP2 修好这个问题，"用稳定币结算"就退化为"如果你还能说服买家持稳定币，你能省下 interchange 费"——在小众场景里是真节省，但不是定义类别的转折。把稳定币主张读作 AP2 能承载的一件事，而不是采纳 AP2 的理由。
采纳现状。
Google 于 2025 年 9 月的 Cloud Next 上宣布 AP2，60+ 合作方启用，覆盖支付处理器、卡网、商户平台。作为信号该数字可信——主要处理器与两大卡网同时参与，意味协议站在了 interchange 那一侧的生态上，这是最难的部分。数字不等于"今天你能在 60 处通过 AP2 付款"；一如任何商务协议，商户侧上线滞后处理器侧承诺 12 到 24 个月，2026 年中生产可见的商户数比启用合作方数少一个大约五倍的因子。
今天要做架构决策时值得钉住两点。第一，若你的产品涉及智能体代用户购物，就把 AP2 当作授权层来规划，即便你还不能端到端地跑通——替代方案（共享卡凭证，或打断 agent 流的用户重定向）更糟且随商户反弹变得更糟。第二，别把 AP2 建进商户尚未 AP2-aware 的流的关键路径；保留一条可干净退化到人工结账的执行路径，并预期这条路径至少到 2027 年仍承载大部分交易量。商务层出于结构原因位于互操作层之上，其采纳曲线走商户时间尺度而不是 agent-vendor 时间尺度。