AI Agent 支付：連線買方安全付款與賣方穩定幣收款

AI Agent 能回答一次 HTTP 402 挑戰，並不代表這筆 Agent 支付已經足夠安全。買方仍要防止自主程式超出授權範圍花錢；賣方仍要知道究竟是哪張業務訂單收到了錢、轉帳是否已經最終確認，以及故障恢復時會不會重複履約。

所以，同一筆支付前後其實存在兩個獨立的控制問題：

• 在買方一側，Agent 應該能夠申請購買資源，但不能因此獲得不受限制的錢包控制權。
• 在賣方一側，成功的協議互動必須落成一張持久化訂單、一筆最終確認的鏈上支付和一個可審計的業務結果。

StableOps 用兩套邊界清晰的產品覆蓋這兩個方向。Agent Payments 控制 Agent 如何付款；現有收款產品控制商戶如何接收、確認並對帳穩定幣轉帳。x402 把 HTTP 請求和付款要求連線起來，但不會把買賣雙方壓進同一套共享狀態機。

一筆支付，兩條不同的信任邊界

買方和賣方信任的系統不同，持有的憑據不同，需要回答的營運問題也不同。把各自職責分開，反而更容易準確理解整筆交易。

這並不是買賣雙方共用的一個帳戶。即使付款人使用其他 x402 用戶端，賣方也可以單獨使用 StableOps 收款；Agent Payments 客戶也可以向使用其他商戶系統的 x402 賣方購買資源。當雙方都使用 StableOps 時，交易兩端會獲得一致的控制能力，但各自仍然擁有獨立的憑據與記錄。

AI Agent 支付的完整流程

當一項 x402 資源由 StableOps 付款訂單承載時，完整路徑如下：

賣方建立或複用付款訂單
  -> 賣方把分配的地址、鏈、資產和金額繫結到 x402 的 payTo
  -> Agent 請求資源並收到 402 / PAYMENT-REQUIRED
  -> Agent Payments 校驗來源、收款方、金額、策略與兩級預算
  -> 請求超出自動放行範圍時由管理員審批
  -> StableOps 簽發短時、單次執行授權
  -> 客戶自託管簽名器驗證授權並簽署精確的付款資料
  -> Agent SDK 攜帶 PAYMENT-SIGNATURE 重試 GET 請求
  -> x402 資源伺服器呼叫結算服務驗證並結算，然後返回資源
  -> 賣方付款訂單檢測並確認完全匹配的鏈上轉帳
  -> payment.finalized Webhook 驅動持久化記帳與賣方履約

這條流程有兩個關鍵交接點。

第一，賣方必須顯式把 StableOps 付款指令繫結到 x402 付款要求。僅僅建立一張付款訂單，並不會讓它自動關聯一筆無關結算。資源伺服器給出的 payTo 地址、網路、資產合約與金額，必須描述訂單期待的同一筆轉帳。

第二，協議結算與商戶最終確認回答的是兩個問題。付費 HTTP 回應告訴買方資源請求得到什麼結果；回應中的 PAYMENT-RESPONSE 在存在時還會報告協議結算結果。賣方的 payment.finalized 事件告訴商戶應用：完全匹配的轉帳已經到達平台設定的不可逆邊界。如果 HTTP 回應還會啟動長期任務、發放持久配額或修改外部系統，這些下游動作仍要支援安全重放，並與商戶訂單對帳。

已有的 x402 支付與穩定幣詳細解釋了這條協議邊界。本文關注的是 StableOps 目前買方與賣方產品如何在邊界兩端銜接。

在公開 payTo 前，先為賣方建立持久化訂單

賣方應該在 Agent 可以付款前確定業務身份。同一次收費使用穩定的商戶訂單標識和冪等鍵，分配精確收款地址，並在後設資料中保留足夠的請求上下文，便於後續排查。

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

const BASE_SEPOLIA_USDC = '0x036CbD53842c5426634e7929541eC2318f3dCF7e'
const X402_MAX_TIMEOUT_SECONDS = 300

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

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

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

  if (!instruction) throw new Error('未分配 Base Sepolia USDC 付款指令')

  return {
    paymentOrderId: order.id,
    payTo: instruction.address,
    network: 'eip155:84532' as const,
    asset: BASE_SEPOLIA_USDC,
    amount: order.amount,
    amountAtomic: parseUnits(order.amount, 6).toString(),
    maxTimeoutSeconds: X402_MAX_TIMEOUT_SECONDS,
    expiresAt: order.expiresAt,
  }
}

StableOps 付款訂單的 amount 是資產單位的十進位制字串，x402 PaymentRequirements.amount 則是最小單位整數字符串。賣方建置付款要求時必須使用上面返回的 amountAtomic，不能直接使用 order.amount。同時把 payTo、network、asset 和 maxTimeoutSeconds 原樣繫結進去，不要接受呼叫方提供的收款地址，也不要悄悄換成另一條鏈。

訂單有效期也必須納入付款要求的釋出條件。資源伺服器在首次返回和每次重新整理 402 前，都要重新讀取付款訂單：只有狀態仍為 created，並且剩餘有效期足以覆蓋 maxTimeoutSeconds 和必要的結算緩衝時，才能繼續公開原付款要求。訂單過期或剩餘時間不足時應停止接受舊要求；如需重新收費，應使用新的商戶訂單標識和冪等鍵開啟新的收費嘗試，買方也不能拿舊審批授權新的付款。這樣，即使人工審批晚於賣方訂單過期，也不會把資金轉入一張已經無法匹配的訂單。

訂單標識和冪等鍵解決的是兩類重放問題。merchantOrderId 保持與業務請求的關聯；冪等鍵讓同一次建立呼叫在重試時返回原結果，而不是再次分配一筆收費。付款訂單說明詳細介紹了地址分配與匹配行為。

讓 Agent 申請付款，而不是控制錢包

在買方一側，營運者要在模型執行前準備好付款軌道：

1. 登記並驗證付款錢包。
2. 建立付款 Agent，併為目標網路繫結錢包。
3. 啟用一份不可變策略版本，明確允許的來源、收款方、資產、單筆上限與自動付款閾值。
4. 設定組織與 Agent 兩級日預算。
5. 簽發受限 Agent Key，並把管理 API Key 留在執行時之外。
6. 在客戶自己的環境執行簽名器，並使用獨立的授權儲存。

之後，執行時透過 Agent SDK 發起付費請求：

import {
  AgentPaymentsControlClient,
  HttpAgentSignerSidecar,
  SafeHttpsRequester,
  SettlementUnknownError,
  StableOpsAgent,
} from '@stableops/agent-payments-sdk'

const payments = new StableOpsAgent({
  control: new AgentPaymentsControlClient({
    agentKey: process.env.STABLEOPS_AGENT_KEY!,
  }),
  sidecar: new HttpAgentSignerSidecar({
    url: 'http://127.0.0.1:8789',
    authToken: process.env.STABLEOPS_SIDECAR_TOKEN,
  }),
  requester: new SafeHttpsRequester(),
})

let result: Awaited<ReturnType<typeof payments.x402Fetch>>

try {
  result = await payments.x402Fetch('https://api.example.com/paid-report', {
    idempotencyKey: 'research-task-284:paid-report:v1',
  })
} catch (error) {
  if (error instanceof SettlementUnknownError) {
    const payment = await payments.getPayment(error.intentId)
    console.error({
      message: '結算結果未知，不得建立新的付款授權',
      intentId: error.intentId,
      authorizationId: error.authorizationId,
      paymentStatus: payment.status,
    })
  }
  throw error
}

if (result.status === 'paid' || result.status === 'not_required') {
  if (!result.response.ok) {
    const body = await result.response.text()
    throw new Error(`資源請求失敗：HTTP ${result.response.status} ${body}`)
  }

  const contentType = result.response.headers.get('content-type') ?? ''
  const report = contentType.includes('application/json')
    ? await result.response.json()
    : await result.response.text()
  if (result.status === 'paid') {
    const payment = await payments.getPayment(result.intentId)
    console.log({
      report,
      intentId: result.intentId,
      paymentStatus: payment.status,
      protocolSettlement: result.paymentResponse,
      resultReported: result.resultReported,
    })
  } else {
    console.log(report)
  }
} else if (result.status === 'awaiting_approval') {
  // 儲存 result.intentId，審批後恢復同一個 Intent。
  console.log(`等待審批：${result.intentId}`)
}

Agent Key 可以建立並檢視屬於自己的付款嘗試，但不能修改錢包、策略、預算或審批。簽名器也不信任 Agent 執行時：它會把每個欄位與短時執行授權逐一比對，並拒絕任意訊息或交易簽名。錢包金鑰始終留在客戶程序或 KMS 的信任邊界內。

目前產品範圍刻意比“讓模型使用錢包”更窄。Agent Payments 支援伺服器端 Node.js、HTTPS 上的 x402 v2 exact 資源、GET 請求和已設定的 USDC 網路；不開放直接轉帳、任意代幣消費、POST、瀏覽器執行或原始簽名介面。目前網路表以 Agent Payments 支援範圍為準，完整設定步驟見快速開始。

由策略決定什麼程度的自主權可以接受

僅有預算並不等於擁有完整的支付策略。即使 Agent 沒有突破每日總額，它仍可能向錯誤的收款方付款、接受被篡改的報價，或者把錯誤任務重複執行很多次。

StableOps 會先校驗來源、payTo、網路、資產和金額，再同時預留組織與 Agent 兩級預算。一次請求隨後會進入三條路徑之一：

建立付款 Agent 預設採用保守策略：自動付款閾值為零，營運者明確啟用更寬的規則前，每筆付款都需要審批。審批也不是讓 Agent 修改收費內容的入口。如果重新整理後的 x402 要求改變了收款方、網路、資產，或者提高了金額，舊審批不能授權新的付款。

按不確定性設計重試，不要按樂觀假設重試

AI 系統會積極重試，而支付系統必須假設：超時可能發生在價值已經轉移之後。因此，買賣雙方都需要穩定的身份標識。

• 買方對同一購買意圖複用一個任務級冪等鍵。
• 需要審批時，儲存返回的 Intent ID，並恢復該 Intent，而不是建立另一筆付款。
• 已簽名請求發生超時後，查詢現有付款並讓對帳流程判斷結果；不能因為沒有收到回應就建立替代 Intent。
• 賣方對同一次收費複用商戶訂單標識和建立呼叫冪等鍵。
• 賣方按事件標識去重已驗籤 Webhook，並讓履約冪等性獨立於投遞次數。

這些規則分別約束交易兩端的故障。買方避免重複扣款，賣方避免重複履約，任何一方的保證都不能替代另一方。穩定幣 Webhook 指南給出了賣方事件收件箱與安全重放模式。

讓兩個控制層都遠離資金託管

“非託管”在交易兩端有不同的實際含義。

對買方來說，StableOps 不接收錢包私鑰。客戶簽名器在本地驗證精確繫結的執行授權，x402 結算服務提交受支援的付款。Agent 執行時拿到的是可吊銷的 Agent Key，而不是通用錢包許可權。

對賣方來說，StableOps 從私鑰由商戶控制的地址中分配收款地址。StableOps 檢測並確認匹配的轉帳，但不持有收到的資金；資金歸集與退款仍由商戶執行。

這種拆分限制了每一種憑據的影響範圍。Agent Key 洩露時可以直接吊銷，無需遷移錢包；賣方 API Key 不能替買方錢包簽名；模型提示也不能修改不可變策略，或迫使客戶簽名器接受任意資料。

生產檢查清單

• 每個付費任務使用一個穩定的買方冪等鍵，每次賣方收費使用一個穩定的商戶訂單標識。
• 把賣方訂單的準確地址、網路、資產和最小單位金額繫結進 x402 付款要求。
• 每次返回或重新整理 402 前檢查賣方訂單狀態與剩餘有效期，不向已過期訂單繼續收款。
• 把 Agent Payments 管理憑據留在 Agent 執行時之外，執行時只持有自己的 Agent Key。
• 從一個來源、一個收款方、很小的單筆上限、很小的日預算和人工審批開始。
• 在客戶信任邊界內執行簽名器，並讓授權狀態能夠跨程序重啟持久儲存。
• 付款獲批後恢復同一個 Intent，不要另開一筆。
• 把已簽名請求超時視為結算狀態未知，而不是再次付款的許可。
• 按事件標識去重賣方 Webhook，並確保下游履約可以安全重放。
• 如果買賣雙方由同一業務營運，同時記錄買方任務標識、Agent Payment Intent ID、賣方付款訂單標識和交易引用。
• 提高額度前，測試審批、駁回、重複呼叫、簽名後超時、Webhook 投遞失敗和賣方對帳。

常見問題

AI Agent 支付一定要使用 x402 嗎？

從一般概念上說不一定，Agent 也可以參與其他支付流程。目前 StableOps Agent Payments 刻意只支援 x402 v2 exact GET 資源，而不是不受限制的轉帳。StableOps 收款產品不依賴 x402，也可以透過付款訂單與託管結帳頁接收普通錢包付款。

AI Agent 需要接觸錢包私鑰嗎？

不需要。Agent 執行時持有的是受限、可吊銷的 Agent Key。客戶自託管簽名器把錢包金鑰或 KMS 許可權留在模型程序之外，只簽署與有效短時執行授權完全一致的付款資料。

x402 已經結算，是否意味著賣方可以執行所有不可逆動作？

x402 資源伺服器可以按協議層規則交付目前資源，但這不會自動完成賣方更廣泛的業務流程。當收費由 StableOps 付款訂單承載時，持久化記帳與不可逆的下游工作應以已驗證的 payment.finalized Webhook 為準，並保證這些操作冪等。

從一筆受控交易開始

先選擇一個付費 GET 資源、一張 Base Sepolia USDC 賣方訂單、一個買方 Agent，並設定刻意偏小的額度。按照 Agent Payments 快速開始設定買方，再用付款訂單把賣方收款地址繫結到 x402 要求。確認付費回應、Agent Payment 記錄、鏈上轉帳、賣方最終事件和業務帳本全部一致後，再開啟自動付款。

這個窄範圍試點驗證的正是 AI Agent 支付棧的價值：機器能夠完成購買，即使交易偏離正常路徑，買賣雙方也不會失去必要的控制能力。