如何为 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 自上世纪 90 年代起就存在于 HTTP 规范中，但从未被真正实现。x402 是最终把它用起来的协议：

服务器对未付款的请求返回状态码 402，并附带机器可读的价格
客户端附上已签名的支付信息并重试
服务器验证、结算，并在同一次交互中返回资源

这里没有会话、没有存储的银行卡，也没有仪表盘，钱包本身就是账户。在 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 针对同类需求使用了一种相关的微支付（nanopayments）模式。

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 SDK（不绑定特定 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) 只是把该协议接入 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 可能在某个请求实际返回非 200 状态的情况下报告 settled: true，反之亦然；在统计收入之前应同时检查两者。作为定期对账手段，我们的 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。它会创建一个受限范围的钱包会话，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 文档。

对于需要在没有人工批准每个会话的情况下自主付款的后端 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 会话，这样 agent 就能按你设定的规则签名，而无需自己持有私钥。

如何在不让 agent 持有 gas 的情况下以 USDC 结算？

每一笔链上交易都需要 gas：一种由发送交易的一方持有的原生代币（如 ETH），用来支付网络处理交易的费用。这对按 API 调用付费的 agent 来说是个问题。它不能在每次 $0.01 的支付前停下来去获取 gas 代币，而为以防万一而囤积一批 gas 代币又违背了自动化流程的初衷。

USDC 结算通过 EIP-3009（transferWithAuthorization）绕开了这个问题：它让 agent 只需签署一笔转账，而无需自己提交交易或持有任何 gas 代币。agent 只负责签名；由 facilitator 负责在链上提交该交易并支付其 gas。exact 和 upto 的结算通常对 USDC 使用 EIP-3009，对不支持 EIP-3009 的其他 ERC-20 代币使用 Permit2。batch-settlement 仍然让 agent 针对每个请求签名，但卖方之后是在链上批量兑现，而不是逐笔单独结算。Circle Gateway 针对同样的高频场景使用了一种相关的微支付模式。USDC 以美元计价这一点也让事情更简单：双方都不必对一笔 $0.01 的收费做汇率换算。

以上是支付本身的情况。如果你的收款地址是一个普通的外部拥有钱包（EOA），那就没有别的事情了：它只是接收 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 解决的是完全不同的问题：通过已签名的 Checkout 和 Payment mandate 证明用户已授权某个 agent 进行支出，无论支付方式是银行卡、银行转账还是稳定币。AP2 并不是一个与 x402 竞争的结算通道；当 AP2 流程需要以稳定币结算时，会通过 Google 与 Coinbase、Ethereum Foundation 和 MetaMask 共同打造的 A2A x402 扩展来实现，因此 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 与 MPP 对比。如果你正在选择基础设施提供商，可参阅我们对 Alchemy、Coinbase 的 Developer Platform、Circle、Crossmint、Privy 和 Turnkey 的钱包、gas 与数据层对比。

需要避免的常见错误

切勿签署一个你自己没有核实过的报价。402 响应只是一个由你无法控制的服务器发出的数字；在签名之前先确认网络、资产和金额，就像 Alchemy CLI 在签名之前会先在本地核实报价一样。
不要把 200 响应当作已付款的证明，也不要把 facilitator 的 settled: true 当作你唯一需要的证明。检查结算回执本身，并定期用我们的 Transfers API与链上实际情况对账，如上文所示。
不要在自主 agent 上跳过支出上限设置。无论你使用的等效于 --max-payment 的设置是什么，都应把它设为能完成任务的最小值，因为它是你的 agent 与一个返回虚高报价的服务器之间的唯一防线。
除非验证签名、筛查交易和大规模在链上提交结算真的是你的产品本身，否则不要自己搭建 facilitator。使用一个托管的 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 这样的受限会话，也可以是通过我们的 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 的一部分）可以在几分钟内创建一个受限范围、可撤销的钱包会话，且私钥从不会暴露给 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 扩展来实现。

什么是 agentic commerce，它需要哪些基础设施？

Agentic commerce 指的是 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 工具定价，把款项收进由它自己或其运营者控制的钱包，并像本指南前面构建的那个 MCP 服务器一样通过 facilitator 完成结算。收款和付款，从请求的两端来看，其实是同一个协议。

开始构建付费 MCP 工具

用 Alchemy CLI 为 agent 提供一个受限范围的钱包，用 x402 为你的工具设置收费闸门，并用我们的 Transfers API 确认结算情况。或者跳过 facilitator 的对接工作，直接通过 AgentPay 接受 agent 的支付。若想了解更广泛的堆栈（托管、通道、gas 与数据），可从面向 agentic 支付的最佳基础设施开始。

构建区块链应用

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 是什么关系？

什么是 agentic commerce，它需要哪些基础设施？

如何实现 x402 支付协议，让 agent 可以访问被付费墙保护的链上服务？

AI agent 是如何在链上收款的？

开始构建付费 MCP 工具

相关概览

智能体支付的最佳基础设施：2026年对比

x402 与 MPP：AI 代理支付协议对比

什么是 agent payments？AI agent 如何支付 API、数据和算力费用

构建区块链应用