Cloudflare 给 MCP 工具加上付费门槛：Agent 的「花钱权」该由谁签字？

Cloudflare 正在把付费访问机制引入 MCP（Model Context Protocol）工具的调用路径。据 The New Stack 报道，这一动作让 AI 代理在调用外部工具时，首次面对一个明确的「付费门槛」——工具不再默认免费开放，而是需要某种形式的支付或授权才能访问。

技术细节尚不完整，但它提出的问题比实现方式更重要：当一个 AI 代理自主决定调用某个 MCP 工具、并为此产生费用时，谁有权批准这笔支出？是发起任务的用户、部署代理的平台，还是工具提供方？这个问题的答案，决定了 Agent 支付能否从演示走向生产。

MCP 的付费化，把授权问题从后台推到前台

MCP 在过去一年成为 AI 代理连接外部能力的通用接口。代理通过 MCP 调用搜索、数据库、API、代码执行等工具，完成用户交办的任务。问题在于，这些调用此前基本是免费的——工具提供方要么靠自有预算支撑，要么把成本转嫁给最终用户，但代理本身并不感知「这次调用花了多少钱」。

Cloudflare 引入付费访问，等于在工具调用链路上加了一个计费点。代理在调用前需要确认支付能力，调用后产生可计量的费用。这在工程上是一个清晰的信号：Agent 支付不再只是「代理之间转账」的抽象概念，而是嵌入到每一次工具调用的具体动作里。

但计费点的出现，同时暴露了授权链的空白。一个代理在完成任务时可能连续调用数十个工具，每个工具都有独立定价。如果没有单笔额度、单日累计、收款白名单这类约束，代理的支出行为就处于「有支付能力、无支付纪律」的状态。这正是 OceanAlt 关注的结算前防火墙要解决的问题：在资金离开账户之前，先判断这笔支出是否在授权范围内。

谁控制 Agent 的花钱权，决定了谁承担风险

从合规角度看，付费 MCP 工具把 KYA（Know-Your-Agent）从可选项变成必要项。工具提供方需要知道调用方是谁——是一个受用户明确授权的代理，还是一个行为边界模糊的自动化脚本。没有身份核验，工具方无法区分正常调用和滥用，也无法在出现争议时完成归因。

从结算角度看，付费访问意味着资金流动有了明确的触发点。每一次工具调用都可能对应一笔小额支付，这些支付如果走传统支付通道，成本和延迟都难以承受；如果走稳定币或链上结算，则需要解决链上污点、制裁名单筛查、不可抵赖等问题。Cloudflare 的动作，实际上是在为这些结算需求搭建入口。

对工具提供方而言，付费访问打开了一条收入路径，但也带来了新的责任：如果代理用被盗的凭证或未授权的额度调用付费工具，损失由谁承担？对代理部署方而言，付费工具让成本变得可计量，但也要求更精细的授权管理——否则一次失控的代理循环可能产生意外账单。

结构性变化：从「能不能付」到「该不该付」

Cloudflare 的这一步，标志着 Agent 支付基础设施的重心正在转移。过去一年，行业讨论的焦点是「代理能不能付款」——x402、稳定币结算、MCP 集成，都在解决支付通道的问题。现在，随着付费工具进入 MCP 生态，问题变成了「这笔付款该不该发生」。

这个转变对基础设施提出新要求：授权意图需要被结构化表达，单笔额度和单日累计需要被强制执行，收款白名单需要在结算前生效。这些能力不会自动从支付通道里长出来，需要有人专门构建。Cloudflare 把付费门槛放在 MCP 工具层，等于把这些问题提前暴露给了整个生态。

目前尚不清楚 Cloudflare 的付费访问具体采用何种结算方式、是否涉及稳定币、以及授权模型如何设计。据 The New Stack 报道，这一机制仍在推进中。但方向已经明确：当 AI 代理开始为工具调用付费，「谁控制 Agent 的花钱权」就不再是一个哲学问题，而是一个需要在每一次调用前回答的工程问题。

---

原文来源：The New Stack · https://news.google.com/rss/articles/CBMiZEFVX3lxTE9GNWFHQlNueVBaU252ekpLdHVNaXBiR0ZsbFZLT1JPMzgxNjlOWUE3NUVoUmlPRGgycjZIeDJ5UFB4SnpaRkdJTEZVcGR6dnVHT3YtbnJrUWxUM2dBc3AwVkFpQ1Q?oc=5