Agent Payments Protocol#
面向 Agent 商业的开放协议
Agent Payments Protocol 让 Agent 学会做生意。一段商业关系，而不仅是一次 HTTP 响应。
本页是 Agent Payments Protocol 的概览。完整内容详见：
Agent Payments Protocol 是什么#
Agent Payments Protocol 是一个开放协议，让 AI Agent 能够完成端到端的商业活动——不仅是付钱，还包括报价、托管、计量、结算和争议处理——并且这一切可以在任意消息通道上发生。
早期 Agent 支付工作把问题压缩成"一次 HTTP 响应"；Agent Payments Protocol 把交互单元从"一次 HTTP 402"泛化为一段完整的商业关系。
Agent Payments Protocol 可以用一个等式概括：
Agent Payments Protocol = MPP EVM + 四种 intent 信封 + Broker 编排 + 跨 IM/HTTP 传输
- MPP EVM：Agent Payments Protocol 与 MPP 消息格式兼容，直接消费 MPP EVM challenge / credential 结构
- 四种 intent 信封：
charge/escrow/session/upto——每种刻画一种独立的商业交互形态 - Broker 编排：协议定义的角色，承担编排负担（不是某个特定运营方）
- 跨通道传输：HTTP、XMTP、Telegram、Discord、Slack、Email、短信、deep link、QR、离线——只要能传输文本
四种 Intent#
charge | escrow | session | upto | |
|---|---|---|---|---|
| 场景 | 一次性直付 | 任务托管 | 流式消费 | 按量扣款 |
| 典型用例 | 小费、固定价 API | 翻译、设计、代码委托 | LLM 按 token、API 按调用 | 上限内的不定长任务 |
| 签名时金额已知 | 是 | 是 | 否（已知单价） | 否（已知上限） |
| 结算时机 | 即时 | 验收 / 争议解决后 | 通道关闭时 | Seller 报告用量后 |
| 内置争议 | — | 是 | — | — |
| 典型延迟 | 秒级 | 天级 | 连续 | 单请求 |
四种 intent 覆盖商业面：一次性、托管、流式、上限——每种都是独立的组合形态。
Onchain OS Payment 当前提供的四种支付方式（单次支付 / 批量支付 / 按量支付 / 担保支付）都是上述协议 intent 在产品层的具体实现。详细映射关系与底层协议见 核心概念。
部署形态：A2MCP 与 A2A#
Agent Payments Protocol 是一个协议，但实际部署有两种常见形态。两者共用同一套消息格式——区别只在于谁扮演 Seller、challenge 走哪个传输。
| 维度 | A2MCP（Agent-to-MCP） | A2A（Agent-to-Agent） |
|---|---|---|
| Seller 形态 | 计费 HTTP 服务 | 在 IM 网络上的 Agent |
| 发起方 | Buyer Agent（调用工具触发） | Seller Agent（发 invoice 触发） |
| Challenge 传输 | HTTP 402 响应 | IM（url / card / qrcode） |
| 典型 intent | charge、session、upto | charge、escrow（含分账） |
| 今天 Web 的对照 | 付费 API 端点 | DM 里的收款链接 |
A2MCP 直接对应 Agent 在 Web 上消费计费工具的方式（通常通过 MCP tool 调用）；A2A 把商业面扩展到 Agent 间协作：可协商任务、带托管的交付、流式消费、平台分账。
Broker —— 协议定义的角色#
Agent Payments Protocol 的协议消息（challenge、credential）不携带会话记忆。状态由 Broker 角色承载。
任何愿意承担以下职责的实体都可以是 Broker——钱包厂商、交易所、DAO、自托管服务，甚至参与方自己：
- 接受 Seller 的付款请求，铸造
paymentId - 生成 challenge 与分发物（url / card / qrcode / raw）
- 接收 Buyer 提交的 credential，验签、比对 challenge、重算 nonce
- 代发上链（可选为 Buyer 代付 gas）
- 提供状态查询接口供双方轮询
Broker 与 x402 Facilitator 同一架构位置，scope 不同：Facilitator 为单次 HTTP 往返设计，无状态；Broker 承担可能跨多步、跨多天的商业关系，需持久化 challenge / paymentId / voucher / 状态机。详见白皮书 §3.3。
与 x402 / MPP 的关系#
Agent Payments Protocol 不是 x402 / MPP 的竞品——它是采用 MPP 消息格式、叠加 4 种 intent 形状、由 Broker 编排，最终面向 IM 多通道的产品化协议层。
| 协议 | 层级 | Agent Payments Protocol 如何与它组合 |
|---|---|---|
| x402 | HTTP 402 中间件 | Agent Payments Protocol 在 request 层与 x402 消息格式兼容（charge 可发出 x402 形状的 402），并把同一思路延伸到 IM / QR / 离线 |
| MPP | EVM payment method + session 规范 | Agent Payments Protocol 是 MPP EVM challenge / credential 消息格式的严格超集。接入 MPP EVM 等于已经接入了 Agent Payments Protocol 的 charge |
x402 已经覆盖的场景，Agent Payments Protocol 沿用 x402；当对话离开 HTTP、跨过单次往返时，Agent Payments Protocol 用同一套词汇延伸出去。
设计哲学#
Agent Payments Protocol 守的四条架构不变量：
- 协议无状态，角色有状态——状态在 Broker，传输层上只有消息
- 签名是身份的真实来源——
payload.authorization.from经 ECDSA 恢复，不可伪造 - 与 MPP 消息格式兼容——Agent Payments Protocol 是 MPP EVM 消息格式的严格超集
- 角色可替换，协议不依赖运营方——任何符合接口规范的实现都是合法参与者
完整哲学论证、商业原语（splits 内置分账 / 可插拔争议仲裁 / 双钥计量 / 冷热钱分离）的详细设计见 Agent Payments Protocol Whitepaper §4、§8。