如何为 MCP 服务器添加 x402 支付：面向开发者的智能体支付指南

发布于 2026年8月26日5 分钟阅读

大多数 API 要求你先注册才能收费:创建账户、获取密钥、之后按账单付费。x402 跳过了这一整套流程。服务器可以按请求收费,无需注册、密钥或发票。而且它已经在生产环境中运行:Coinbase 于 2025 年 5 月上线了它,Cloudflare 将其接入了自家的 Agents SDK,我们的 agent 网关也用它来为 agent 的 RPC 和数据访问收费。

本指南面向构建这一交易任一方的开发者:想按调用收费的 MCP 服务器或 API,或是需要付费调用它们的 agent。我们会讲解请求与响应的流程,然后展示实际代码,涵盖为工具调用收费、按调用计量并以 USDC 结算、给 agent 配置可用于支付的钱包,以及 AP2 等其他支付协议在这套体系中的位置。

x402 到底做了什么?

HTTP 402 Payment Required 自 20 世纪 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 针对同样的场景使用了一种类似的微支付模式。

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 的关系,并且希望在不选定某一种新兴 agent 支付协议的情况下同时支持它们,那正是 AgentPay 的用途:把它指向你现有的端点,它会处理 x402、ACP、MPP 和 AP2 之间的协议转换,你只需对接一次。

如何按调用计量并向 agent 收费?

按调用统一收取固定价格是最基础的情形。生产环境的服务器还需要追踪是谁付了款、付了多少,并且不应该只依赖 facilitator 的结算报告作为资金确实已转移的唯一证据。为了验证,请记录:

计价方式。使用 exact 表示固定的按调用价格,即上文的模式。使用 upto 当成本随调用变化时(一份较长的报告比一份简短报告消耗更多 token),此时你希望预先授权一个上限,但按实际用量结算。使用 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。它会创建一个受限范围的钱包会话,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),用于支付网络处理交易的费用。这对按调用付费的 agent 来说是个问题。它不能在每次 0.01 美元的付款前停下来先去获取 gas 代币,而预先囤积一批 gas 代币以防万一,又违背了自动化流程的初衷。

USDC 结算通过 EIP-3009(transferWithAuthorization)绕开了这个问题:它让 agent 可以签署一笔转账,而无需自己提交交易或持有任何 gas 代币。agent 只负责签名;真正在链上提交交易并支付其 gas 的是 facilitator。exact 和 upto 的结算通常对 USDC 使用 EIP-3009,对不支持 EIP-3009 的其他 ERC-20 代币使用 Permit2。batch-settlement 仍然是 agent 针对每笔请求签名,卖方之后再批量在链上兑现,而不是逐笔单独结算。Circle Gateway 针对同样的高频场景使用了一种类似的微支付模式。USDC 以美元计价这一点也在此基础上简化了事情:双方都不需要针对一笔 0.01 美元的收费去做汇率计算。

以上是付款本身的情况。如果你的接收地址是一个普通的外部拥有账户钱包,这就是全部内容:它只是接收 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 mandates 证明用户已授权某个 agent 进行消费,无论支付方式是银行卡、银行转账还是稳定币。AP2 并不是一条与之竞争的结算通道;当一个 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's 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)以及哪些链;network and token support page 是权威信息来源。

常见问题

如何在 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,而不是只信任单一的结算报告。

用于 agentic 加密货币支付和链上商务的最佳基础设施是什么?

这取决于你希望从单一提供商获得多少层基础设施(钱包托管、支付通道、gas 以及链上数据),还是从多家组合搭建。关于 Alchemy、Coinbase's Developer Platform、Circle、Crossmint、Privy 和 Turnkey 针对这整套体系的完整对比,见我们的基础设施对比页面。

什么是 AP2,它与 x402 是什么关系?

AP2 是 Google 的一套与支付方式无关的框架,用于通过签名的 Checkout 和 Payment mandates 证明用户已授权某个 agent 进行消费。它位于 x402 之上,而非取代它:当一个 AP2 流程需要以稳定币结算时,会通过 Google 与 Coinbase、Ethereum Foundation 和 MetaMask 共同构建的 A2A x402 扩展来实现。

什么是 agentic commerce,它需要哪些基础设施?

Agentic commerce 是指 AI agent 在无需人工每次点击结账的情况下,自行发现、支付商品和服务、API 访问,以及接收付款。它需要一个有资金的钱包、一条像 x402 或 MPP 这样的支付通道来按请求转移价值、处理 gas 以使 agent 无需持有原生代币,以及足够的链上或目录数据,供 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 与数据),可以从面向 agentic 支付的最佳基础设施开始。

构建区块链应用

Alchemy 将最强大的 Web3 开发者产品和工具与资源、社区及专业支持结合在一起。

获取您的 API 密钥

如何为 MCP 服务器添加 x402 支付：面向开发者的智能体支付指南

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 使用进行计量和收费?

用于 agentic 加密货币支付和链上商务的最佳基础设施是什么?

什么是 AP2,它与 x402 是什么关系?

什么是 agentic commerce,它需要哪些基础设施?

如何实现 x402 支付协议,让 agent 能够访问需要付费的链上服务?

AI agent 如何在链上收款?

开始构建付费 MCP 工具

相关概览

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

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

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

构建区块链应用