返回博客
Engineering
2026-09-0710 分钟阅读作者:StableOps

MCP 与 x402 有什么区别?AI Agent 从调用工具到完成支付的完整链路

本文对比 MCP 与 x402 在 AI Agent 交易中的职责:MCP 连接模型、工具与上下文,x402 表达价格并完成付款。文章通过调用链、架构模式和安全检查清单,说明 StableOps 如何用策略、预算、审批及客户自持签名支持可控的付费服务调用。

MCP
x402
AI Agent 支付

MCP 与 x402 解决的是 AI Agent 交易中的两个不同问题。MCP 让模型发现并调用工具、读取资源和取得结构化结果。x402 让服务声明价格、接收付款授权并返回结算结果。MCP 本身不是支付协议,x402 也不负责定义模型如何选择和调用工具。需要让 Agent 使用付费能力时,通常要把两者组合起来。

最简洁的理解是:MCP 负责“这个 Agent 可以调用什么,以及怎样调用”,x402 负责“这次调用需要付多少钱,以及怎样完成付款”。

MCP 与 x402 的核心区别是什么

对比维度MCPx402
核心问题模型如何连接外部工具、资源和工作流客户端如何为受保护的服务或资源付款
主要对象工具、资源、提示、输入与输出结构付款要求、付款载荷、结算结果
典型参与方MCP 主机、客户端和服务器付款客户端、资源服务器和可选协调服务
是否定义价格是,由服务端付款要求表达
是否移动价值可以,根据付款方案验证并结算
是否定义钱包策略核心协议不替具体组织定义预算、允许列表或审批规则
是否可以单独使用可以,绝大多数工具调用不需要付款可以,普通 HTTP 客户端也能使用 x402
组合方式调用一个会检查或执行 x402 付款的工具保护 MCP 工具,或保护工具背后的 HTTP 服务

这不是两种竞品协议之间的选择。它们位于不同层次,而且边界并非互斥。x402 可以保护普通 HTTP 接口,也可以与 MCP 工具组合。MCP 工具则可以调用免费的内部系统、使用 API Key 的服务,或者需要 x402 付款的外部资源。

MCP 具体解决什么问题

MCP 为模型应用与外部能力提供统一接口。MCP 服务器可以公开工具和资源,主机负责把适当的能力交给模型,并在用户、模型和服务器之间协调调用。

以工具为例,MCP 官方工具规范定义了两个关键动作:

  1. 客户端通过 tools/list 取得工具名称、说明和输入结构。
  2. 客户端通过 tools/call 提交工具名称和参数,并取得文本、结构化内容或资源链接等结果。

这解决了“怎样描述和调用能力”的互操作问题。天气查询、数据库检索、文件操作和支付单查询,都可以表现成模型能够理解的工具。

但是,看到一个工具不代表模型应该无条件调用它。MCP 官方规范把工具描述为由模型控制的能力,同时明确要求应用保留用户拒绝调用的能力,并把工具注释视为不可信信息,除非它们来自可信服务器。换言之,协议定义了调用方式,不会自动替你的组织决定权限边界。

MCP 中的“发现”也有明确范围。tools/list 让客户端发现已经连接的 MCP 服务器公开了什么工具,它不等于在整个互联网中寻找所有可购买服务。公开服务市场、私有服务目录或 x402 Bazaar 扩展可以负责更广范围的服务发现,之后再把候选能力接入 MCP 工作流。

x402 具体解决什么问题

x402 把付款协商放进请求与响应流程。对于常见的 HTTP 模式,客户端请求受保护资源时,资源服务器返回 402 Payment Required,同时说明金额、资产、网络和收款地址。客户端构造并签署付款载荷,然后携带付款证明重新请求资源。

x402 官方文档说明,v2 的 HTTP 流程使用三个标准头部:

头部方向作用
PAYMENT-REQUIRED资源服务器到客户端返回可接受的付款方案
PAYMENT-SIGNATURE客户端到资源服务器携带已签署的付款载荷
PAYMENT-RESPONSE资源服务器到客户端返回结算成功、失败或相关交易信息

资源服务器可以自行验证和结算,也可以把这两个步骤交给协调服务。x402 解决的是付款要求和结算怎样与资源访问衔接,并不规定某个企业是否允许 Agent 购买这项资源。

因此,x402 付款要求不应被直接理解成付款授权。服务端可以说“调用这个接口需要支付 0.10 USDC”,但买方仍然要决定:这个来源是否可信、收款地址是否允许、网络和资产是否正确、金额是否在上限内,以及这次任务是否需要人工审批。

MCP 与 x402 可以怎样组合

实际系统中常见三种架构。

架构一:MCP 工具调用付费 HTTP 接口

MCP 服务器向 Agent 公开一个工具。工具执行时请求外部 HTTP 接口。如果收到 x402 付款要求,中间层会完成检查、签名和重试,再把付费响应转换成 MCP 工具结果。

Agent
  -> MCP 工具调用
  -> MCP 服务器请求外部接口
  -> 402 / PAYMENT-REQUIRED
  -> 检查并签署付款载荷
  -> 携带 PAYMENT-SIGNATURE 重试
  -> 返回付费资源
  -> MCP 工具结果

x402 官方仓库提供了这种 MCP 与 x402 集成方式。它适合把现有的付费 HTTP 服务包装成模型可调用的工具。

架构二:直接为 MCP 工具增加付款要求

服务提供方也可以让 MCP 工具本身成为收费资源。调用方仍通过 MCP 发现和调用工具,但在取得结果之前完成 x402 付款。这里 MCP 描述工具,x402 描述使用该工具所需的付款。

这种模式适合已经以 MCP 交付能力的服务,例如付费数据查询、计算或内容生成。卖方必须保证未完成付款的探测调用不会提前执行收费背后的不可逆副作用,并让同一次调用在重试时保持业务幂等。

架构三:独立的付款控制工具调用 x402 服务

另一种做法是让业务工具和付款控制保持分离。Agent 先发现候选服务,再调用受控付款工具进行预检、审批、签名和购买。这样,钱包权限、预算和付款恢复不需要散落在每个业务 MCP 服务器中。

StableOps Agent Payments 采用这种边界。它把付款操作公开成一组受限 MCP 工具,但私钥留在客户自己的签名器中。控制面负责策略和预算,Agent 不能通过修改工具参数绕过审批。

StableOps 如何连接 MCP 与 x402

StableOps 中有两类用途不同的 MCP 服务:

服务使用者主要用途不能做什么
@stableops/mcp-server商户或运营侧 Agent查询或管理支付单、收款地址、Webhook、收银台和订阅不能持有钱包私钥或发起链上转账
@stableops/agent-payments-mcp-server买方付款 Agent配置付款轨道,发现和预检 x402 服务,在策略内购买并查询付款不能自行批准例外,也不能取得任意签名能力

第一类服务解决商户如何让 Agent 受控操作 StableOps 资源,详见 StableOps MCP Server。第二类服务解决 Agent 如何代表买方购买付费资源,完整配置见 Agent Payments 快速开始。两者都使用 MCP,但处在交易的不同一侧。

一次受控的 x402 购买会经过下面的链路:

用户提出任务
  -> Agent 通过 MCP 发现候选服务
  -> 预检准确的网址、方法、请求体和实时付款要求
  -> StableOps 校验来源、收款方、网络、资产、金额和预算
  -> 自动放行,或等待人工审批
  -> StableOps 签发短时、单次执行授权
  -> 客户自持签名器逐字段校验并签署付款
  -> MCP 运行时携带 PAYMENT-SIGNATURE 重试原请求
  -> 资源服务器验证并结算,返回资源与 PAYMENT-RESPONSE
  -> Agent 取得结构化结果和付款记录

在这条链路里,MCP 负责向 Agent 暴露 stableops_preview_x402_purchasestableops_x402_fetch 和付款查询等工具。x402 负责远端资源的付款协商。StableOps 策略、预算、审批和签名器负责确定这笔付款是否获得业务授权。

如果付款需要审批,Agent 必须保存原 intent_id,审批后恢复同一笔付款。若结算结果未知,也只能查询原付款,不能创建一笔替代付款。具体操作见 x402 付款测试

为什么 MCP 权限不等于付款权限

允许模型调用一个工具,只说明该工具出现在模型可用能力中。它并不自动回答下面这些资金问题:

  • 这个 Agent 每天最多能花多少?
  • 哪些来源和收款地址可以自动付款?
  • 报价改变后,旧审批是否仍然有效?
  • POST 请求的准确请求体是否与审批时一致?
  • 超时发生在签名后时,能否安全重试?
  • 谁持有私钥,签名器能够签署哪些内容?

同样,x402 支付成功也不代表 MCP 工具输出可信。远端资源返回的正文仍是外部数据,不能借助一次成功付款获得更高的信任等级。主机和 Agent 应继续把结果当作不可信输入,防止提示注入、越权工具调用和敏感数据外传。

因此,生产系统至少需要区分五道控制:

控制边界需要回答的问题
工具可见性Agent 能看到和调用哪些 MCP 工具?
业务授权当前任务是否允许调用这个服务?
付款授权来源、收款方、网络、资产和金额是否符合策略?
签名授权准确的付款载荷是否与短时执行授权逐字段一致?
结果处理工具结果和结算状态应该怎样验证、记录与恢复?

只设置预算仍然不够。预算限制的是总量,无法表达付款目的、收款对象和请求内容。有关完整授权模型,可以继续阅读只设预算,不足以约束 AI 智能体支付

应该使用 MCP、x402,还是同时使用

可以按目标直接判断:

目标建议
让 Agent 查询数据库、操作内部系统或调用免费工具使用 MCP
让普通应用为一个 HTTP 接口按次付款使用 x402
让 Agent 调用已有的 x402 收费 HTTP 接口同时使用 MCP 与 x402
让 MCP 工具本身按次收费用 MCP 描述工具,用 x402 增加付款要求
让 Agent 在生产环境自主付款在 MCP 与 x402 之外增加策略、预算、审批、受限凭据和客户自持签名

不要从协议名称出发设计系统。先判断调用对象是什么、付款发生在哪一侧、谁有权批准,以及超时后如何恢复,再决定协议组合。

上线前检查清单

面向买方 Agent

  • 日常运行时只持有属于当前 Agent 的受限凭据,不持有组织管理密钥。
  • 在付款前锁定准确来源、网址、方法、请求体摘要、收款地址、网络、资产和金额。
  • 同时设置单笔上限、Agent 预算和组织预算。
  • 未知来源、未知收款方和超自动付款阈值的请求进入人工审批。
  • 签名器只接受短时、单次、逐字段绑定的执行授权,不公开任意签名接口。
  • 同一次购买的所有重试复用稳定的幂等键。
  • 结算结果未知时查询原付款,不重新授权第二笔付款。

面向收费服务

  • 工具名称、说明、输入结构和价格对应同一项明确能力。
  • 在验证付款之前不执行受保护的不可逆操作。
  • 对探测、刷新付款要求和已付款重试保持业务幂等。
  • 明确返回网络、资产、金额、收款地址和有效期。
  • 把协议结算、资源交付和内部记账作为可以分别核对的状态。
  • 对失败、超时、重复提交和结算状态未知建立恢复流程。

常见问题

x402 可以代替 MCP 吗?

不可以。x402 可以让资源或工具收费,但不会替 MCP 定义工具名称、输入结构、调用方法和结果格式。一个普通应用可以只用 x402,一个不收费的 Agent 工具也可以只用 MCP。

MCP 可以调用付费 API 吗?

可以。MCP 工具可以调用使用订阅、API Key、账户余额或 x402 的外部服务。MCP 不限制商业模式,只要求工具以双方能够理解的方式公开和执行。

MCP 工具本身可以使用 x402 收费吗?

可以。x402 官方集成已经展示了付费 MCP 工具和由 MCP 工具访问付费 HTTP 服务的模式。无论采用哪种方式,生产环境都应在签名前增加金额、资产、网络和收款方检查。

MCP 是否自带钱包、预算和付款审批?

不自带。MCP 提供工具调用和授权框架,但不会替应用定义财务策略。钱包隔离、预算、允许列表、审批和付款恢复需要由具体产品实现。

使用 x402 是否一定需要协调服务?

不一定。资源服务器可以自行验证和结算,也可以把这些操作委托给协调服务。选择取决于所用网络、付款方案和团队希望承担的基础设施工作。

如何找到可以购买的 x402 服务?

可以通过服务提供方文档、x402 Bazaar 等发现机制,或 StableOps x402 服务列表查找候选接口。发现只产生候选项。付款前仍要读取实时要求并执行策略检查。

从一个受控调用开始

第一次组合 MCP 与 x402 时,先选择一个低金额、结果容易验证且没有外部副作用的收费接口。让 Agent 先发现和预检,人工核对来源、收款方、网络、资产与金额,再恢复同一笔付款。确认幂等、审批和未知结算恢复都符合预期后,再逐步扩大自动付款范围。

可以从 Agent Payments 快速开始配置沙盒支付轨道,再通过 x402 付款测试完成第一笔受控调用。MCP 让能力可以被 Agent 使用,x402 让能力可以按调用收费,而策略和受限签名决定这套组合能否安全进入生产环境。

相关文章

用买方策略、预算、审批和客户自持签名构建 AI Agent 支付,再以卖方支付订单、最终性、Webhook 与对账完成稳定币收款闭环。

AI 智能体支付不能只靠每日预算。本文说明如何用来源与收款人允许列表、不可变策略、精确请求审批、受限签名者、幂等重试和结算不确定状态,在钱包密钥始终由客户控制的前提下,安全扩大自动付款范围,并为每一次授权留下可验证、可审计的完整记录。

把 x402 用在 HTTP 原生的智能体支付上,但商户侧的订单状态、策略、最终性、事件通知和审计仍要单独保留。

稳定币转账并不等于支付完成。本文从支付订单状态机、链与资产精确匹配、确认和重组处理、接口幂等、Webhook 事件去重及可恢复履约出发,说明如何把链上转账转化为可安全进入生产环境、能够审计并支持异常恢复的支付事件。