Agent Payments Protocol：为智能体支付建立可验证授权链
Agent Payments Protocol（AP2）以可验证凭证和授权 Mandate 为核心，为智能体代表用户发起交易提供开放、支付方式无关的信任框架。
Agent Payments Protocol agent-protocol agentic-commerce open-source Agent Payments Protocol（AP2）以可验证凭证和授权 Mandate 为核心，为智能体代表用户发起交易提供开放、支付方式无关的信任框架。
1. 调研缘由
Google 在 2025 年 9 月发布 Agent Payments Protocol（AP2），目标是在智能体代表用户购物或付款时，为授权、意图真实性和责任追踪提供共同语言。[S1] 智能体支付把传统“用户亲自点击购买”的假设打破，因而协议层比单一支付接口更值得关注。
2. 协议定位
AP2 是开放、共享且与具体支付方式无关的框架，可作为 Agent2Agent 协议和 Model Context Protocol 的扩展使用。[S1] 它不取代银行卡网络、银行转账或稳定币结算，而是在用户、智能体、商家与支付方之间传递可验证的授权和交易上下文。
3. 核心机制
协议以 Mandate 为关键对象：这是由可验证凭证签署、用于证明用户指令的数字合同。[S1] 在用户在线的购买中，Intent Mandate 记录最初意图，用户确认购物车后形成 Cart Mandate；在委托购买中，用户预先给出价格、时间和条件，智能体在条件满足时据此行动。
4. 工作流与实现
完整链路应把意图、购物车和付款结果关联起来，使参与方能追溯“谁授权了什么”。官方代码库公开了规范、流程、FAQ、SDK、JSON Schema 和多种参考场景，示例覆盖 Python、Go 与 Android。[S2] 示例使用 Google ADK，但仓库明确说明 AP2 本身不要求使用特定智能体框架。[S2]
5. 适用场景
AP2 可用于有人实时确认的智能购物，也可用于限价补货、票务抢购、行程组合预订和企业自动采购等异步委托。协议尤其适合需要跨商家或跨智能体协作、且事后必须证明授权边界的场景。普通单次结账若没有智能体代理链路，采用它的收益可能有限。
6. 部署路径
实施应从低金额沙箱开始，先定义 Intent 与 Cart Mandate 的字段、签名主体、有效期、撤销方式和重复提交处理，再接入支付渠道。服务端必须验证凭证、金额、商品、时效与授权范围；任何字段不一致都应拒绝或转人工。日志要保留协议证据，但避免暴露完整支付凭证。
7. 主要风险
开放协议不能自动解决欺诈、退款、争议归责和地区合规。密钥泄露、重放攻击、被篡改的商品信息、过宽的委托条件或错误时区都可能导致非预期交易。不同参与方若对 Mandate 语义理解不一，也会产生互操作假象，因此版本、必填字段和失败码必须通过契约测试固定。
8. 生态与边界
Google 公布时表示与多家支付和技术组织协作，并说明 AP2 支持卡、稳定币及实时银行转账等不同支付类型。[S1] 这表明其目标是成为上层信任框架，而不是绑定某一结算轨道。但参与者名单不等于生产级支持，采用方仍需逐一确认对方实现、认证与责任条款。
9. 归纳洞察 ★
AP2 是否可用，应通过对抗式验收判断：修改金额后签名必须失效，过期委托必须被拒绝，重复请求不能重复扣款，撤销后智能体不能继续交易，审计记录应能还原每次授权。只有这些边界跨参与方一致，协议的互操作价值才从文档主张变成工程事实。
10. 来源与更新时间
本文基于 Google Cloud 官方公告与 google-agentic-commerce 官方代码库，信息截点为 2026-08-11。协议仍可能演进，生产接入前应锁定规范版本并复核仓库最新安全说明。