x402 支付与稳定币：一个面向智能体的支付栈还需要什么

x402 很适合按请求计费的接口和机器调用。它把支付协商放进 HTTP 交互本身，让客户端先收到 402 Payment Required，再对支付负载签名并带着要求的头部重试请求。这个层次是对的，但它只是协议层，不是完整的生产支付栈。

如果你在经营真实的商户系统，x402 之后仍然需要订单模型、链与资产策略、最终性策略、事件通知处理和审计恢复。如果智能体可以代表用户或某个工作流花钱，你还需要工作区级别的权限策略，明确谁能发起或批准扣费。x402 负责支付握手，你的应用仍然负责业务判断。

从协议本身看，目前的 x402 v2 文档把它描述为一个开放的 HTTP 支付流程，使用 PAYMENT-REQUIRED、PAYMENT-SIGNATURE 和 PAYMENT-RESPONSE 这些头部。资源服务器可以自行验证和结算，也可以把这些操作委托给协调服务。你可以把它理解为协商层和传输层，不要把它误解成完整的商户运营模型。

x402 到协议边界就结束了

最清楚的理解方式，是把协议、可选的协调服务和商户运营拆开看。

这个分层很关键，因为协议成功不等于业务完成。一次请求可以已经付费、已经结算，但后面仍然要做很多事：写账本、扣配额、开通权限、触发工作流。那些都属于商户侧。

如果你的卖方系统也由智能体操作，就要把智能体策略和支付机制分开。MCP 服务器负责把工具暴露给智能体，而智能体策略决定哪些工具可用、写操作是否需要审批。x402 不会替你补上这个护栏。

x402 适合什么，不适合什么

x402 最适合的，是那些单次、同步、机器能理解的付费动作。

分界线不在于是不是用稳定币计价，而在于协议层的支付事件是否已经足以触发业务副作用。很多产品并不是。

如果某个请求只是解锁 HTTP 响应，那协议握手可能就够了。一旦这个请求还会写入配额、发送邮件、开通权限、改客户资料，或者触发其他内部流程，你就需要商户侧状态和恢复能力。这也是 StableOps 仍然重要的原因。

如果你想先对照一个不涉及智能体的基线，可以看不托管资金的 USDC 收款架构和确认状态模型。这里的道理是一样的：支付事件只是更大运营流程中的一个边界。

生产里仍然需要状态机

就算协议握手很快，智能体支付栈也仍然需要明确的状态机。

HTTP 请求
  -> 创建或复用商户订单
  -> 以订单收款地址作为 payTo，返回 402 / PAYMENT-REQUIRED
  -> 客户端对支付负载签名
  -> 资源服务器自行验证并结算，或委托协调服务处理
  -> 服务端返回资源
  -> StableOps 检测、确认并最终确认匹配的转账
  -> payment.finalized 事件通知
  -> 不可逆的下游业务动作

StableOps 提供的是商户侧那些能抵抗重试和重放的部分：支付订单、事件通知、确认状态和审计轨迹。这样你就能把协议层和业务层分开，而不会丢失可追踪性。

下面是一个简短的商户侧示例。它会在任何不可逆动作前先把请求记录成持久化订单，并保持这个请求的身份在重试之间不变。

import { StableOps } from '@stableops/api-sdk'

const stableops = new StableOps({
  apiKey: process.env.STABLEOPS_API_KEY!,
})

export async function openAgentCharge(input: {
  requestId: string
  agentSessionId: string
  resource: string
  amount: string
}) {
  const order = await stableops.paymentOrders.create(
    {
      merchantOrderId: `x402:${input.requestId}`,
      amount: input.amount,
      acceptedAssets: [{ chain: 'base', asset: 'USDC' }],
      expiresAt: new Date(Date.now() + 10 * 60 * 1000).toISOString(),
      metadata: {
        rail: 'x402',
        agentSessionId: input.agentSessionId,
        resource: input.resource,
      },
    },
    { idempotencyKey: `x402:${input.requestId}` },
  )

  const paymentInstruction = order.paymentInstructions.find(
    (item) => item.chain === 'base' && item.asset === 'USDC',
  )

  if (!paymentInstruction) {
    throw new Error('未分配 Base USDC 收款指令')
  }

  return {
    order,
    payTo: paymentInstruction.address,
  }
}

重点不在代码长什么样，而在身份控制和地址绑定。只要是同一个请求，就要复用同一个请求标识、商户订单标识和幂等键。让 x402 卖方集成在构建 PaymentRequirements 时使用这里返回的 payTo 地址，并确保链、资产和金额与 StableOps 订单一致。把资源信息和智能体上下文写进 metadata，这样匹配的转账就能在审计或对账时追溯到原始请求。

这里的地址绑定是必要条件：仅创建 StableOps 订单，并不会自动接收或关联一笔无关的 x402 结算。只有当 x402 把精确金额结算到订单分配的 payTo 地址后，StableOps 才能检测这笔转账并推进订单状态。收到最终的 payment.finalized 事件通知后，再把它作为下游副作用的不可逆边界。事件通知指南解释了投递、重试和重放；事件通知验签指南说明了如何在处理前验证原始请求体。

智能体支付需要策略，不只是支付通道

智能体会让运营侧变得更重要，而不是更不重要。它们会成批发起请求、积极重试，并且可能在没人盯着的情况下花钱。这意味着支付栈需要策略，也需要传输。

用智能体策略决定哪些工具或动作可以创建或批准扣费。用支付订单让商户侧保持确定性。用事件通知把链上进度变成持久化事件流。用确认状态模型决定在什么副作用上可以接受什么级别的支付状态。

StableOps 负责把这些决定变得可审计、可恢复。x402 负责让请求本身参与支付。

生产检查清单

• 在开放 x402 之前，先定义哪些端点或资源需要收费。
• 每次扣费都使用稳定的商户订单标识和幂等键。
• 把智能体权限控制留在智能体策略里，不要写进支付代码。
• 除非产品明确接受更高风险，否则把 payment.finalized 作为不可逆边界。
• 把请求标识、智能体会话标识、支付订单标识和交易哈希一起保存。
• 保持事件通知处理器短小，并且对重放安全。
• 把协议层成功和商户侧履约分开对账。
• 上线前先测试重试、重复请求、结算延迟和运营人员重放。

常见问题

做智能体支付一定要用 x402 吗？

不一定。x402 只是把 HTTP 交互变成“可支付”的一种方式。更本质的要求还是一样：要有持久化的商户订单、清晰的策略、最终性边界和恢复流程。如果你已经有这些，x402 可以成为协商层，而不是整个方案本身。

协议结算和业务履约是一回事吗？

不是。支付可以已经结算，但仍然不足以驱动你自己系统里的不可逆副作用。如果一次请求会改变 HTTP 响应之外的状态，最好等商户侧的最终事件，通常就是 payment.finalized。

如果我要安全地支持智能体自动花钱，应该先看什么？

先看智能体策略，再看支付订单、事件通知和确认状态模型。如果你想先看一个不涉及智能体的基础实现，可以再读如何在不托管资金的情况下接受 USDC。

从小处开始

如果你要试点 x402，先选一个范围较小的接口资源、一种商户订单结构和一个不可逆副作用。扩展之前，先接入事件通知流程和确认模型。协议让机器支付成为可能，而协议周围的那一层，才决定它能不能安全进入生产。