如何為 MCP server 加入 x402 付款機制：agent 付款開發指南

發布於 2026年8月26日閱讀時間 5 分鐘

大多數 API 的收費方式是要求你先註冊：建立帳號、取得金鑰、之後再收費。x402 完全跳過這些步驟。伺服器可以改成依每次請求收費，不需要註冊、金鑰或發票。而且這已經在正式環境中運行：Coinbase 在 2025 年 5 月推出了它、Cloudflare 將它接進了自家的 Agents SDK，我們的 agent gateway 則用它來向 agent 收取 RPC 與資料存取的費用。

本篇指南適用於任何要打造這個交易兩端的人：想要依呼叫次數收費的 MCP 伺服器或 API，或是需要支付這筆費用的 agent。我們會逐步說明請求與回應的流程，接著展示實際程式碼，示範如何為工具呼叫收費、以 USDC 計量並結算每次呼叫的費用、為 agent 提供可用來支付的錢包，以及 AP2 等其他付款協定如何融入其中。

x402 到底在做什麼？

HTTP 402 Payment Required 自 1990 年代就存在於 HTTP 規格中，卻從未被實作過。x402 是終於用上這個狀態碼的協定：

伺服器對未付款的請求回應 402 狀態碼，並附上機器可讀的價格
客戶端附上簽署好的付款並重新發送請求
伺服器驗證、結算，並在同一次交易中回傳資源

這裡沒有 session、沒有儲存的信用卡資訊、也沒有後台儀表板，錢包本身就是帳號。在 x402 v2 中，相關資訊儲存在 HTTP 標頭裡：

Header	Direction	Carries
`PAYMENT-REQUIRED`	伺服器到客戶端	價格、目的地位址、網路，以及可接受的付款方案，以 base64 編碼
`PAYMENT-SIGNATURE`	客戶端到伺服器	已簽署的付款內容，以 base64 編碼
`PAYMENT-RESPONSE`	伺服器到客戶端	結算結果，以 base64 編碼

這三個標頭本身不會改變。會改變的是 PAYMENT-REQUIRED 所攜帶的 JSON 內容中的 scheme 欄位，它告訴客戶端這次呼叫使用的是哪一種計費模式。在每一種方案中，負責檢查與轉移資金的都是同一個第三方：facilitator，這是一個負責驗證客戶端已簽署付款並提交鏈上結算的服務，讓賣方和客戶端都不必自己處理這兩件事。方案之間真正的差異，只在於 facilitator 檢查的內容以及結算的時機。

大多數呼叫使用 exact：價格是固定且事先已知的，因此客戶端會針對這個確切金額簽署，結算時也結算這個確切金額。以下是簡化後只保留關鍵欄位的內容。amount 是 10,000 個最小單位，相當於 $0.01 USDC：

jsonCopied
{
"accepts": [{
  "scheme": "exact",
  "amount": "10000",
  "asset": "0x036C...F7e",
  "payTo": "0x2096...87C"
}]
}

有些呼叫的費用是可變的，只有在工作完成後才知道確切金額，例如依生成 token 數量計費的 LLM 輸出。這種情況下，伺服器會使用 upto。內容看起來幾乎一樣，但 amount 現在代表的是客戶端同意的上限，而不是價格。這裡的上限是 $5.00：

jsonCopied
{
"accepts": [{
  "scheme": "upto",
  "amount": "5000000",
  "asset": "0x036C...F7e",
  "payTo": "0x2096...87C"
}]
}

客戶端只會針對這個上限簽署一次。伺服器完成工作後，facilitator 會結算實際金額（假設實際使用了 $1.20），並在移動任何資金之前確認該金額不超過已簽署的上限。客戶端不需要簽署第二次；只有結算步驟才會填入實際數字。

第三種方案 batch-settlement，適用於高頻率、每次金額不到一分錢的收費，此時若每次呼叫都要支付 gas 費，成本反而會超過呼叫本身。在 x402 方案中，買方先一次性存入一份託管合約，之後針對每次請求以鏈下方式簽署憑證，賣方再批次於鏈上兌現。Circle Gateway 針對相同用途使用了一種類似的微支付機制。

facilitator 本身從不持有資金，它只負責檢查已簽署的指令並執行它們。x402.org 提供一個免費的公開 facilitator，僅供開發與測試網使用，而 Coinbase 的 CDP 提供一個具備合規篩查的正式生產環境 facilitator。你可以將程式碼指向其中任一個。

x402 的請求與回應流程如何運作？

握手流程共有九個步驟：

客戶端在未附加付款的情況下請求資源。
伺服器以 402 Payment Required 回應，附上價格、目的地位址，以及它接受的付款方案。
客戶端針對其中一個接受的方案簽署付款，並附上簽章重新發送請求。
伺服器請 facilitator 依其宣告的要求驗證已簽署的付款。
facilitator 回傳驗證結果。
伺服器執行工作（執行查詢、呼叫模型、產生報告）。
伺服器請 facilitator 在鏈上結算付款。
facilitator 回傳結算結果。
伺服器回傳資源，並附上結算收據。

在 HTTP 上，這個流程是透過 HTTP 標頭（PAYMENT-REQUIRED、PAYMENT-SIGNATURE、PAYMENT-RESPONSE）執行的。在 MCP 上，這相同的九個步驟則改以 JSON 執行：

未附加付款的呼叫會回傳帶有 isError: true 與 PaymentRequired 內容的結果（相當於 PAYMENT-REQUIRED）
客戶端重新發送同一次呼叫，並在 _meta["x402/payment"] 附上已簽署的付款（相當於 PAYMENT-SIGNATURE）
伺服器在 _meta["x402/payment-response"] 回傳實際結果與結算資訊（相當於 PAYMENT-RESPONSE）

如何為 MCP 伺服器加入 x402 付款功能？

這個範例對應一個常見的實際情境：一個混合了付費與免費工具的 MCP 伺服器，例如提供免費基本查詢、但對深入生成報告收費的研究或資料伺服器。

在這個範例中，generate_report 每次呼叫收費 $0.01，而 ping 保持免費，兩者都建構在開源的 x402 Foundation SDKs 之上（不綁定特定 facilitator，因此你可以先用免費的公開 facilitator 起步，之後再換成商用版本），並以 Wallet APIs 的智慧帳戶作為收款位址。

首先，準備用來收款的錢包。@alchemy/wallet-apis（v5）能提供一個智慧帳戶位址，讓你的伺服器完全不需要接觸私鑰：

tsxCopied
// wallet.ts
import { createServerSigner } from "@account-kit/signer";
import { createSmartWalletClient, alchemyWalletTransport } from "@alchemy/wallet-apis";
import { baseSepolia } from "viem/chains";

const signer = await createServerSigner({
auth: { accessKey: process.env.ALCHEMY_ACCESS_KEY! },
connection: { apiKey: process.env.ALCHEMY_API_KEY! },
});

const walletClient = createSmartWalletClient({
transport: alchemyWalletTransport({ apiKey: process.env.ALCHEMY_API_KEY! }),
chain: baseSepolia,
signer,
});

export const receiverAccount = await walletClient.requestAccount();
// receiverAccount.address is the payTo address for every quote you issue below

接著把這個位址接進一個受 x402 保護的 MCP 工具。@x402/core 負責建構與驗證付款要求，@x402/evm 實作了適用於 EVM 鏈的 exact 方案，而 @x402/mcp 則會包裝工具處理函式，讓一個普通函式變成付費函式：

tsxCopied
// server.ts
import { createServer } from "node:http";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import { x402ResourceServer } from "@x402/core/server";
import { HTTPFacilitatorClient } from "@x402/core/facilitator";
import { createPaymentWrapper } from "@x402/mcp";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { z } from "zod";
import { receiverAccount } from "./wallet";

// Base Sepolia for testing; swap to eip155:8453 for Base mainnet
const NETWORK = "eip155:84532";

// Start against the free public facilitator, then swap the url for a
// commercial facilitator (compliance screening, higher throughput, an
// SLA) for production.
const facilitator = new HTTPFacilitatorClient({
url: "https://x402.org/facilitator",
});

const resourceServer = new x402ResourceServer(facilitator);
resourceServer.register(NETWORK, new ExactEvmScheme());
await resourceServer.initialize();

const accepts = await resourceServer.buildPaymentRequirements({
scheme: "exact",
network: NETWORK,
payTo: receiverAccount.address,
price: "$0.01",
});

const paid = createPaymentWrapper(resourceServer, { accepts });

const server = new McpServer({
name: "paid-report-server",
version: "1.0.0",
});

server.tool(
"generate_report",
"Generate a research report on a topic. Costs $0.01 in USDC.",
{ topic: z.string() },
paid(async ({ topic }) => ({
  content: [
    {
      type: "text",
      text: "Report on " + topic + ": trending up, no anomalies.",
    },
  ],
})),
);

server.tool("ping", "Free health check", {}, async () => ({
content: [{ type: "text", text: "pong" }],
}));

const transport = new StreamableHTTPServerTransport({
sessionIdGenerator: undefined,
});
await server.connect(transport);

createServer((req, res) => {
const path = new URL(req.url ?? "/", "http://localhost").pathname;
if (path === "/mcp") {
  void transport.handleRequest(req, res);
  return;
}
res.writeHead(404).end();
}).listen(3000);

server.connect(transport) 只是把協定附加到傳輸層上。真正開啟 3000 連接埠、並把 /mcp 轉發到 transport.handleRequest(...)（也就是下方客戶端呼叫的端點）的，是 Node 的 HTTP 監聽程式。

任何你沒有用 paid(...) 包裝的東西都維持免費，因此你可以在同一個伺服器上混合付費與免費的工具。先用 curl 或任何未附加付款的 MCP 客戶端測試一下：你應該會收到一個要求付款的結果，而不是報告本身，這可以確認在接上付費客戶端之前，這道防護已經生效。

如果你完全不想自己維護與 facilitator 的關係，又想在不必挑選特定協定的情況下，同時支援 x402 及其他新興的 agent 付款協定，這正是 AgentPay 存在的目的：把它指向你現有的端點，它就能在一次整合中處理 x402、ACP、MPP 與 AP2 之間的協定轉換。

如何依呼叫次數計量並向 agent 收費？

每次呼叫收取固定價格是最基本的情況。正式環境的伺服器還需要追蹤誰付了款、付了多少，而且不應該只把 facilitator 的結算回報當成資金確實已轉移的唯一證明。要進行驗證，請留意以下幾點：

定價形式。使用 exact 來設定每次呼叫的固定價格，也就是上面的模式。當費用會依呼叫而變動（例如較長的報告會消耗比短報告更多的 token）、你想預先授權一個上限、再結算實際用量時，使用 upto。當呼叫頻繁且金額低到個別在鏈上結算的成本會超過呼叫本身時，使用 batch-settlement。
歸戶與記帳。客戶端簽署的付款內容中包含付款位址。每次呼叫結算時，將這個位址連同工具名稱、價格與結算結果一併記錄下來，你就免費得到了一份按 agent 分類的用量帳本：

tsxCopied
const paid = createPaymentWrapper(resourceServer, {
accepts,
hooks: {
  onAfterSettlement: async ({ toolName, settlement }) => {
    await usageLedger.record({
      payer: settlement.payer,
      tool: toolName,
      amountUsd: 0.01,
      txHash: settlement.transaction,
      settledAt: new Date(),
    });
  },
},
});

不要只信任結算回應本身就把它當成唯一的判斷依據。facilitator 可能會回報 settled: true，但請求實際上仍回傳非 200 狀態，反之亦然；在計入營收前，請同時檢查這兩者。若要進行定期的核對，我們的 Transfers API 可以讓你獨立確認實際到達你收款位址的內容，藉此抓出 facilitator 結算回報與鏈上實際情況不一致的少數情況：

tsxCopied
const res = await fetch("https://base-sepolia.g.alchemy.com/v2/" + apiKey, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
  jsonrpc: "2.0",
  method: "alchemy_getAssetTransfers",
  params: [{
    toAddress: receiverAccount.address,
    category: ["erc20"],
    contractAddresses: [USDC_ADDRESS],
    withMetadata: true,
  }],
  id: 1,
}),
});
const { result } = await res.json();
// result.transfers is the ground truth for what actually arrived onchain,
// independent of what any single facilitator reported settling

如何為 agent 提供一個可用來付款的 USDC 錢包？

一個需要向付費端點（無論是你自己的還是別人的）付款的 agent，需要一個已注資的錢包，以及能在遇到 402 時簽署付款的程式碼（或 CLI）。

對於由人操作或在本地測試的 agent 來說，最快的方式是使用 Alchemy CLI。它會建立一個受限範圍的錢包 session，讓 agent 可以使用而完全不需要接觸私鑰：

bashCopied
npm i -g "@alchemy/cli@latest"
alchemy auth
alchemy wallet connect --mode session --instance-name "my-agent"

# decode a quote without paying anything, useful for a first look at an unfamiliar endpoint
alchemy x402 request "https://api.example.com/report" --estimate

# pay it for real, with a hard spend cap; required for any non-interactive run
alchemy --json --no-interactive x402 request "https://api.example.com/report" --max-payment 0.01

--max-payment 設定了 CLI 願意支付的最高金額，伺服器回傳的任何內容都無法把這個數字往上推。如果你在沒有人在場核准的情況下執行這個指令（--no-interactive），又忘了設定 --max-payment，CLI 會直接停止而不會付款，因為 402 回應中的價格來自一個你無法控制的伺服器，在你的額度先檢查過之前，不應該有任何東西去支付它。完整的指令內容請參閱 x402 payments CLI 文件。

對於需要在沒有人核准每個 session 的情況下自主付款的後端 agent，請用一個由簽署者支援的付款處理程式包裝 fetch（或你的 MCP 客戶端）。如果 agent 呼叫的是付費 HTTP 端點，請使用 @x402/fetch：

tsxCopied
import { x402Client } from "@x402/core/client";
import { wrapFetchWithPayment } from "@x402/fetch";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

const signer = privateKeyToAccount(process.env.AGENT_WALLET_KEY as `0x${string}`);
const client = new x402Client();
registerExactEvmScheme(client, { signer });

const fetchWithPayment = wrapFetchWithPayment(fetch, client);
const response = await fetchWithPayment("https://api.example.com/report");

如果 agent 呼叫的是 MCP 伺服器上的付費工具，而不是普通的 HTTP 端點，請改用同樣的方式包裝 MCP 客戶端，而不是 fetch。CDP 針對 MCP 買方記載了相同的模式：

tsxCopied
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";
import { x402Client } from "@x402/core/client";
import { wrapMCPClientWithPayment } from "@x402/mcp";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

const signer = privateKeyToAccount(
process.env.AGENT_WALLET_KEY as `0x${string}`,
);
const paymentClient = new x402Client();
registerExactEvmScheme(paymentClient, { signer });

const mcp = wrapMCPClientWithPayment(
new Client(
  { name: "my-agent", version: "1.0.0" },
  { capabilities: {} },
),
paymentClient,
{ autoPayment: true },
);

await mcp.connect(
new StreamableHTTPClientTransport(
  new URL("http://localhost:3000/mcp"),
),
);

const report = await mcp.callTool({
name: "generate_report",
arguments: { topic: "USDC on Base" },
});

把原始私鑰放在環境變數中，用來在測試網進行第一次測試或許還可以接受，但在正式環境中是不可接受的。對於正式環境的 agent，請改用同一個簽署者介面來搭配 Wallet APIs 的智慧帳戶或 Agent Wallet session，讓 agent 可以依你設定的規則簽署，而完全不必持有私鑰本身。

如何在不要求 agent 持有 gas 的情況下以 USDC 結算？

每一筆鏈上交易都需要 gas：由發送交易的一方持有的原生代幣（例如 ETH），用來支付網路處理該筆交易的費用。這對每次呼叫都要付款的 agent 來說是個問題。它不能在每次 $0.01 的付款前都先停下來取得一種 gas 代幣，而預先囤積一堆以防萬一，又違背了自動化流程的初衷。

USDC 結算透過 EIP-3009（transferWithAuthorization）繞開了這個問題：它讓 agent 可以簽署一筆轉帳，而不需要自己提交交易或持有任何 gas 代幣。agent 只需要簽署；真正提交這筆鏈上交易並支付 gas 的是 facilitator。exact 與 upto 的結算通常使用 EIP-3009 來處理 USDC，並使用 Permit2 來處理任何不支援 EIP-3009 的其他 ERC-20 代幣。batch-settlement 仍然是每次請求都由 agent 簽署，只是賣方稍後才在鏈上批次兌現，而不是逐筆單獨結算。Circle Gateway 針對這種高頻率情境使用了一種類似的微支付機制。以美元計價的 USDC 也在這之上讓事情變得更簡單：雙方都不需要為一筆 $0.01 的費用去計算匯率。

以上涵蓋了付款本身。如果你的收款位址是一個普通的外部持有錢包（externally-owned wallet），故事就到此結束：它只是接收 USDC，不涉及任何部署步驟。如果它是像本指南前面建立的智慧帳戶那樣，它還會在 x402 流程之外的另外兩個時刻用到 gas：第一次收到資金時需要在鏈上部署一次，以及之後每次把收到的 USDC 匯出到金庫錢包時。我們的 Gas Manager 可以為這兩個時刻贊助 gas；不論如何，它都不涉及 x402 付款本身的結算，因為那已經由 facilitator 負責處理。

在大多數工具中，Base 是預設網路，因為原始的參考 facilitator 就是在那裡運行，而且大多數既有的 x402 整合也都建立在那裡，但 x402 v2 並不限於 Base。它同時涵蓋任何 EVM 鏈（包括 Ethereum 主網與 Polygon），以及 Solana、TON、Algorand、Stellar、Aptos、Hedera、Keeta、NEAR、Concordium 與 XRPL，隨著 facilitator 陸續加入支援，預期還會有更多鏈加入。「在 Ethereum 上以 USDC 付款」這種特定情境今天是否真的可行，取決於你選用的 facilitator 是否已實作該網路，而不是取決於協定本身。

x402 在更廣泛的 agent 付款技術堆疊中處於什麼位置？

x402 是一個快速發展領域中的其中一種協定，並不是唯一的一種。

Stripe 與 Tempo 打造了 MPP，是同一種 402 模式的一個版本，但不綁定於穩定幣，賣方可以在同一個流程下接受信用卡或穩定幣（而且 MPP 與 x402 的 exact 流程向後相容，因此為其中一方打造的客戶端通常也能與為另一方打造的伺服器溝通）。
OpenAI 與 Stripe 的 ACP 涵蓋的是不同的層面：AI 驅動購物的結帳流程，而不是逐次請求的 API 付款。
Google 的 AP2 處理的是完全不同的問題：無論付款方式是信用卡、銀行轉帳或穩定幣，都要證明使用者已授權 agent 進行消費，方式是使用經簽署的 Checkout 與 Payment mandate。AP2 並不是一條相互競爭的結算軌道；當 AP2 流程需要以穩定幣結算時，它是透過 Google 與 Coinbase、Ethereum Foundation 以及 MetaMask 共同打造的 A2A x402 extension 來進行的，因此 x402 是其底層的加密軌道，而不是它的替代方案。

Protocol	Steward	Payment type	Primary job	Settles per request?
x402	x402 Foundation（原為 Coinbase）	鏈上穩定幣	透過 HTTP 或 MCP 為每次 API 呼叫、工具呼叫或每份內容付款	是
MPP	Stripe 與 Tempo	信用卡或穩定幣，相同流程	依請求付款，不限定付款方式	是
ACP	OpenAI 與 Stripe	信用卡（透過 Stripe checkout）	由 agent 驅動的購物結帳流程，而非依請求付款的 API	否，每筆採購一次結帳
AP2	Google，與業界夥伴合作	不限定付款方式：信用卡、銀行轉帳、穩定幣	證明使用者已授權 agent 進行消費；底層透過 x402 或信用卡／銀行軌道結算	否，授權一條軌道而非自行結算

隨著協定生態持續演進，AgentPay 是一個與協定無關的代理服務，能幫助商家一次整合就支援所有這些協定。

如果你正在為特定專案在 x402 與 MPP 之間做選擇，請參閱我們的 x402 vs MPP 比較文章。如果你正在選擇基礎設施供應商，請參閱涵蓋 Alchemy、Coinbase 的 Developer Platform、Circle、Crossmint、Privy 與 Turnkey 的錢包、gas 與資料層比較。

常見錯誤

絕對不要簽署一個你自己沒有檢查過的報價。402 回應只是一個由你無法控制的伺服器送出的數字；在簽署之前先確認網路、資產與金額，就像 Alchemy CLI 在簽署報價之前會先在本地檢查一樣。
不要把 200 回應當成付款的證明，也不要把 facilitator 的 settled: true 當成唯一需要的證明。請檢查結算收據本身，並如上所述定期使用我們的 Transfers API 與鏈上實際情況做核對。
不要在自主 agent 上省略支出上限。無論你的 --max-payment 相當於什麼設定，都把它設成能完成工作的最小值，因為這是唯一能夠阻擋你的 agent 被一個回傳虛高報價的伺服器占便宜的防線。
除非驗證簽章、篩查交易並大規模提交鏈上結算真的是你的產品，否則不要自己打造 facilitator。直接使用託管服務，把工程時間花在你真正的服務上。
不要假設「支援 x402」就等於「支援所有網路與方案」。在正式串接之前，先確認你所使用的 facilitator 與對方實際實作了哪些方案（exact、upto、batch-settlement）以及哪些鏈；網路與代幣支援頁面是最準確的資訊來源。

常見問題

如何為 MCP 伺服器加入 x402 付款功能？

使用 x402 Foundation 的 @x402/mcp 套件中的付款包裝器，包裝你想要收費的工具處理函式，並搭配一個已在 facilitator 註冊、且知道應由哪個錢包位址收款的伺服器。完整可運作的範例已在上方，除非你也包裝其他工具，否則伺服器上其餘部分都維持免費。

AI agent 若要透過 x402 使用穩定幣支付 API 費用，需要什麼基礎設施？

三個部分：一個能持有並簽署 USDC 的錢包、一個懂得 x402 握手流程的已簽署付款函式庫或 CLI，以及賣方那端用來驗證與結算的 facilitator。你不需要自己執行區塊鏈節點，也不需要持有 gas 代幣；結算的 gas 由 facilitator 負責。

讓 AI agent 能在 Ethereum 上發送 USDC 付款的最佳方式是什麼？

給它一個可以直接簽署的錢包，可以是像 Alchemy Agent Wallet 這樣受限範圍的 session，或是透過我們的 Wallet APIs 建立的程式化智慧帳戶，再搭配一個 x402 客戶端函式庫，例如 @x402/fetch 或 Alchemy CLI 的 x402 request 指令。請先確認你要使用的 facilitator 確實支援該特定網路；x402 v2 涵蓋 Ethereum，但實際的支援範圍取決於 facilitator，而不只是協定本身。

如何為 AI agent 提供用於鏈上付款的 USDC 錢包？

若是用於測試或由人監督的 agent，alchemy wallet connect --mode session（屬於 Alchemy CLI 的一部分）能在幾分鐘內建立一個受限範圍、可撤銷的錢包 session，而 agent 完全不會接觸到私鑰。若是完全自主的後端 agent，請透過 @alchemy/wallet-apis 或由 CDP 管理的錢包來建立智慧帳戶，再把它的簽署者交給 x402 客戶端函式庫。

agent 如何透過 x402 支付 API 存取費用？

agent 呼叫 API，收到一個附有價格與目的地位址的 402 回應，針對伺服器接受的其中一種方案簽署付款，然後附上已簽署的付款重新發送同一個請求。伺服器透過 facilitator 進行驗證與結算，並在同一次往返中回傳資源。

如何以加密貨幣付款方式計量並向 AI agent 收取 API 使用費？

對於每次呼叫的固定價格，使用 exact 方案；當費用依用量變動時，使用 upto；並將每筆已結算付款的付款方位址，連同它所支付的工具或端點一起記錄下來。定期將這份帳本與鏈上轉帳紀錄做核對，例如使用我們的 Transfers API，而不是只信任單一的結算回報。

什麼是最適合 agent 化加密支付與鏈上商務的基礎設施？

這取決於你希望技術堆疊中有多少部分（錢包託管、付款軌道、gas 與鏈上資料）由單一供應商提供，還是要從多家供應商組裝。針對這整套堆疊，我們在基礎設施比較頁面上完整比較了 Alchemy、Coinbase 的 Developer Platform、Circle、Crossmint、Privy 與 Turnkey。

什麼是 AP2？它與 x402 有什麼關係？

AP2 是 Google 提出的、與付款方式無關的框架，用來透過經簽署的 Checkout 與 Payment mandate 證明使用者已授權 agent 進行消費。它是建立在 x402 之上，而不是取代它：當 AP2 流程需要以穩定幣結算時，會透過 Google 與 Coinbase、Ethereum Foundation 以及 MetaMask 共同打造的 A2A x402 extension 來進行。

什麼是 agent 化商務？它需要什麼基礎設施？

Agent 化商務是指 AI agent 在不需要人類每次點擊結帳流程的情況下，自行探索、支付並收取商品、服務與 API 存取的費用。它需要一個已注資的錢包、一條像 x402 或 MPP 這樣能依請求移動價值的付款軌道、讓 agent 不需要持有原生代幣的 gas 處理機制，以及足夠的鏈上或目錄資料，讓 agent 能判斷要為什麼付款並確認款項確實到帳。

如何實作 x402 付款協定，讓 agent 能存取付費的鏈上服務？

在客戶端這一側，安裝一個 x402 客戶端函式庫（@x402/fetch、@x402/axios，或 MCP 客戶端包裝器），用一個錢包簽署者註冊一種付款方案，並用它包裝你既有的 HTTP 客戶端或 MCP 客戶端；之後遇到 402 時，付款就會自動完成。上方買方端的程式碼同時涵蓋了 HTTP 與 MCP 兩種情況。

AI agent 如何在鏈上收款？

機制與任何其他 x402 賣方相同：由 agent 執行的服務用 x402 為自己的端點或 MCP 工具定價，把款項收進它自己或其操作者控制的錢包中，並透過 facilitator 結算，就跟本指南前面建立的那個 MCP 伺服器一模一樣。收款與付款，從請求的兩端來看，其實是同一個協定。

開始打造付費的 MCP 工具

使用 Alchemy CLI 為 agent 提供一個受限範圍的錢包，用 x402 為你的工具設下付費門檻，並用我們的 Transfers API 確認結算結果。或者，也可以略過 facilitator 的串接，透過 AgentPay 直接接受 agent 付款。若要了解更完整的技術堆疊（託管、付款軌道、gas 與資料），可以從最適合 agent 化付款的基礎設施開始了解。

打造區塊鏈魔法

Alchemy 結合最強大的 Web3 開發者產品與工具，並提供資源、社群與卓越的支援。

取得您的 API 金鑰

如何為 MCP server 加入 x402 付款機制：agent 付款開發指南

x402 到底在做什麼？

x402 的請求與回應流程如何運作？

如何為 MCP 伺服器加入 x402 付款功能？

如何依呼叫次數計量並向 agent 收費？

如何為 agent 提供一個可用來付款的 USDC 錢包？

如何在不要求 agent 持有 gas 的情況下以 USDC 結算？

x402 在更廣泛的 agent 付款技術堆疊中處於什麼位置？

常見錯誤

常見問題

如何為 MCP 伺服器加入 x402 付款功能？

AI agent 若要透過 x402 使用穩定幣支付 API 費用，需要什麼基礎設施？

讓 AI agent 能在 Ethereum 上發送 USDC 付款的最佳方式是什麼？

如何為 AI agent 提供用於鏈上付款的 USDC 錢包？

agent 如何透過 x402 支付 API 存取費用？

如何以加密貨幣付款方式計量並向 AI agent 收取 API 使用費？

什麼是最適合 agent 化加密支付與鏈上商務的基礎設施？

什麼是 AP2？它與 x402 有什麼關係？

什麼是 agent 化商務？它需要什麼基礎設施？

如何實作 x402 付款協定，讓 agent 能存取付費的鏈上服務？

AI agent 如何在鏈上收款？

開始打造付費的 MCP 工具

相關總覽

最佳 AI 代理支付基礎設施：2026 年比較

x402 vs MPP：比較 agent 付款協議

什麼是代理支付？AI 代理如何為 API、資料與運算付費

打造區塊鏈魔法