智能体商务与支付协议

协议全景与选型：三条不同的路

背景与原理

三者常被并列成「agent 支付协议」，但它们切的是不同的面，搞混就会选错。

• AP2（Agent Payments Protocol, Google，2025-09 发布，60+ 伙伴）— 授权层。回答「用户到底授权 agent 买什么、花多少」。它支付方式无关（卡、稳定币、实时转账都行），用密码学签名的 Mandate 承载授权，扩展自 A2A、与 MCP 协同。定位：跨 agent、跨商户的可信授权底座。
• ACP（Agentic Commerce Protocol, OpenAI + Stripe + Meta）— 结账层。让 agent 在对话里直接完成一次商户结账（ChatGPT 的 Instant Checkout 即基于它）。商户仍是 merchant of record，Stripe 的 Shared Payment Token 传递支付凭证。定位：把「你的商品被 agent 买走」这条链路标准化。
• x402（Coinbase + Cloudflare）— 结算层。用 HTTP 402 让一次 API 调用本身可以按次收费，稳定币（USDC）秒级链上结算，无账户无 API key。定位：agent↔API、agent↔agent 的机器原生微支付。

选型一句话：代人购物、要跨商户可信授权 → AP2；你是商户、想被 ChatGPT 这类 agent 买到 → ACP；你在卖 API/工具、想让调用方（人或 agent）按次付费 → x402。复杂系统往往同时出现：AP2 定「授权语义」，x402 或卡做「实际结算」。

AP2 的 Mandate：可验证的授权委托

背景与原理

AP2 要解决 agent 支付的三难：授权（authorization）——agent 真的被允许买这个吗？真实性（authenticity）——这笔请求真是这个用户/agent 发的、没被篡改吗？问责（accountability）——出事后能不能证明是谁、在什么约束下批准的？三者都靠 Mandate 解决。Mandate 是一张 W3C Verifiable Credential（JSON-LD），用 ECDSA P-256 签名、SHA-256 完整性哈希，内含请求载荷、时间戳、nonce、公钥引用与签名——防篡改、不可否认、可移植。

两种关键 Mandate 对应两种场景：

• Intent Mandate（意图授权）— 人不在场。装的是用户的自然语言请求 + 硬约束：最高价、商品规格、有效期（TTL）、允许的商户、agent 身份引用。等于「我授权你在这些边界内替我买」，agent 之后可自主成交。
• Cart Mandate（购物车授权）— 人在场。由商户按用户请求生成具体购物车，用户用设备上硬件密钥当场签名，绑定 payer/payee 身份、tokenized 支付方式、风控载荷、最终交易明细。

第三种 Payment Mandate 传给支付网络，让发卡行/网络也能看到「这是 agent 发起的交易」信号。价值：每一步授权都留下密码学证据链，谁在什么约束下批了什么，事后可验、不可赖。

实战示例

一个 Intent Mandate 的结构（简化）：

{
  "@context": ["https://www.w3.org/ns/credentials/v2",
               "https://ap2-protocol.org/context/v1"],
  "type": ["VerifiableCredential", "IntentMandate"],
  "issuer": "did:user:8f3a...",           // 用户身份
  "issuanceDate": "2026-07-01T09:00:00Z",
  "credentialSubject": {
    "agent": "did:agent:bigcat-shopper",  // 被授权的 agent
    "intent": "买一台 65 分贝以下的便携榨汁机",
    "constraints": {
      "maxPrice": {"amount": 80, "currency": "USD"},
      "allowedMerchants": ["merchant:xyz-store"],
      "expiry": "2026-07-03T00:00:00Z"       // TTL：过期即失效
    }
  },
  "proof": {                               // 密码学签名
    "type": "EcdsaSecp256r1Signature2019",
    "nonce": "a1b2c3...",                  // 防重放
    "jws": "eyJ..."
  }
}

验证方（商户/网络）做三件事：验签（真实性）、检查 constraints 是否覆盖本次购买（授权）、把整张 VC 连同 nonce 存档（问责）。心智：你不是在传「一句话指令」，是在传「一份带边界、带签名、带时效的委托书」。

x402：HTTP 402 的机器原生支付流

背景与原理

HTTP 402 Payment Required 是 1990 年代就留在协议里、却尘封 30 多年的状态码。x402（Coinbase + Cloudflare）把它激活成机器原生支付层。流程三步：

1. 报价：客户端无凭证调用付费端点 → 服务端返回 402，body 里 accepts[] 列出可接受的支付选项（链、币种、金额、收款地址、facilitator）。
2. 授权：客户端选一个选项，钱包用 EIP-3009 TransferWithAuthorization 对这些确切条款签名，把签名载荷 base64 后放进 X-PAYMENT 头，重放同一请求。
3. 结算：服务端验签，通过 facilitator 在链上结算（USDC 等稳定币），然后返回真正的响应。

整个来回约 2 秒，无需账户、无需 API key，支持 Base / Ethereum / Arbitrum / Polygon / Solana。对超级个体的意义：你写的一个工具/数据 API，可以直接对「任何 agent」按次收费，不用注册体系、不用发 key、不用月度账单。x402 生态已归入 Linux Foundation，Stripe、Cloudflare 接入。

实战示例

HTTP 层（与语言无关）的一次完整往返：

# 1) agent 首次请求，无支付
GET /api/premium-forecast HTTP/1.1
Host: data.example.com

# 2) 服务端报价
HTTP/1.1 402 Payment Required
Content-Type: application/json
{
  "accepts": [{
    "scheme": "exact", "network": "base",
    "asset": "USDC", "amount": "0.01",
    "payTo": "0xMerchant...",
    "facilitator": "https://facilitator.example"
  }]
}

# 3) agent 用钱包签 EIP-3009，带 X-PAYMENT 重试
GET /api/premium-forecast HTTP/1.1
Host: data.example.com
X-PAYMENT: eyJzY2hlbWUiOiJleGFjdCIsInNpZ25hdHVyZSI6...

# 4) 验签 + 链上结算后返回内容
HTTP/1.1 200 OK
X-PAYMENT-RESPONSE: {"settled":true,"tx":"0xabc..."}
{ "forecast": "..." }

心智：402 把「计价、鉴权、结算」从「注册-发 key-开发票」的重流程，压缩成一次 HTTP 挑战-应答。适合 pay-per-call 的数据、推理、工具服务。

工程落地与失败模式：授权边界、重放、问责

背景与原理

把前三节拼成能上线的系统，必须补上四道治理：

• 授权边界（scope）：Intent Mandate 的 constraints 是第一道闸——每次授权都给最小必要范围（单次预算、白名单商户、TTL）。绝不发「无上限、无过期、无商户限制」的 mandate。
• 重放与幂等：每个 mandate/支付带 nonce + expiry，服务端记录已用 nonce；x402 侧对每请求做幂等键，防止一次授权被结算多次。
• 人在环分级（HITL）：低额、白名单内 → agent 自动成交；超阈值、新商户、异常 → 暂停并升级给人批准（承接 Day 34 的置信度路由 auto/ask/deny）。Intent Mandate 本质就是一种「预授权的 HITL」——把人的批准提前固化成带边界的凭证。
• 问责与审计：每笔交易连同它的 mandate/签名/nonce/结算 tx 一起入库，可回放「谁、在什么约束下、批了这笔」。这是出事时唯一能自证的东西。

实战示例

一个下单前的守卫，把三难落成可执行的检查——顺序不能省：

def authorize_purchase(mandate, cart):
    verify_signature(mandate)                    # 真实性
    assert not nonce_seen(mandate.proof.nonce)   # 防重放
    assert now() < mandate.expiry                # 时效
    c = mandate.constraints
    assert cart.total <= c.maxPrice              # 授权边界
    assert cart.merchant in c.allowedMerchants
    if cart.total > HITL_THRESHOLD or cart.merchant not in TRUSTED:
        return escalate_to_human(mandate, cart)  # 分级：升级
    record_audit(mandate, cart)                  # 问责
    return settle(cart)                          # 结算（AP2/x402/卡）

顺序即防线：验签 → 防重放 → 查边界 → 分级 → 审计 → 结算。少一环，就多一个能被利用的口子。