0%

MCP 要死了吗

2026 年 4 月 22 日,Anthropic 发布了一篇关于 MCP 定位与演进的官方博客。这篇文章的背景并不平静——在过去几个月里,社区围绕 MCP 的成本、上下文占用和 Schema 设计产生了大量争议,Perplexity 的 CTO 甚至公开表示内部正在远离 MCP。Anthropic 的这篇博客没有逐条反驳这些批评,而是给出了一个更完整的框架来理解 Agent 连接外部系统这个问题,同时提出了两个具体的技术优化方案来回应社区的核心质疑。

社区指控:成本、上下文和 Schema

对 MCP 的批评集中在三个方面,每一个都有具体的数据支撑。

ScaleKit 的测试显示,在相同操作下 MCP 的成本是 CLI 的 17 倍。这个差距不是小幅领先,而是数量级的差异,直接让很多团队在技术选型时把 MCP 排除在外。

Perplexity 的 CTO 给出了另一个维度的数据:MCP 在他们的系统中占用了高达 72% 的上下文窗口。对于需要处理长对话和复杂任务的 Agent 来说,上下文窗口是最宝贵的资源,被工具定义吃掉大半意味着留给实际推理和业务逻辑的空间所剩无几。

GitHub 的 MCP Schema 则把第三个问题具象化了。43 个工具,每个工具的描述平均 4026 个 Token,每次交互都要把全部工具定义发给模型。光是工具定义的传输就构成了一笔不小的固定开销,无论当次任务实际用到几个工具。

这三个问题归结起来是一件事:MCP 的设计在工具规模扩大之后,Token 消耗会快速失控。

三种连接方式及其适用边界

Anthropic 在博客中把 Agent 连接外部系统的方式分成了三类,并且明确了每一类的适用场景。

方式 适用场景 优势 劣势
直连 API 简单、固定的集成场景 直接、快速 扩展性差,工具增多后陷入 M×N 集成问题
CLI 本地开发环境 高效、灵活,Token 消耗最低 无法在云端运行,依赖本地文件系统
MCP 云端和跨平台环境 标准化协议,一次接入多端复用 成本和上下文开销较高

Anthropic 承认 CLI 在本地环境下确实高效,成本优势明显。但他们指出了一个正在发生的趋势:越来越多的生产级 Agent 运行在云端,没有本地文件系统,也无法执行 CLI 命令。Claude 网页版、移动端 App、部署在云上的企业级 Agent,这些场景下 CLI 不可用,MCP 提供了一个标准化的远程连接层来填补这个空白。

这个定位比之前清晰了很多。MCP 不是要取代 CLI,而是在 CLI 触达不了的云端和跨平台场景中充当标准化的接入层。

市场数据也印证了开发者对这个方向的认可。MCP SDK 的月下载量从 1 亿增长到 3 亿,只用了几个月时间。

针对社区批评最集中的 Token 消耗问题,Anthropic 提出的第一个解法是 Tool Search。

传统方式的问题很直观:无论当次任务需要哪个工具,每次交互都要把所有工具定义塞进上下文。43 个工具就全量发送 43 个,2500 个 API 端点就全量发送 2500 个。这就像每次去图书馆找一本书,管理员都把整个书架搬到你面前。

Tool Search 的思路是把工具选择变成一个两阶段过程。模型先根据用户意图描述它想做什么,系统根据这个描述检索匹配的工具定义,只把相关的几个工具发给模型。工具的组织方式也从按 API 划分转变为围绕用户意图划分,让检索的粒度更贴近实际使用场景。

效果数据相当直接:工具定义的 Token 消耗减少超过 85%,同时工具选择的准确率没有下降。这个解法直接砍掉了全量发送工具定义带来的固定开销,让 MCP 的 Token 成本从固定全量变成了按需加载。

核心解法:程序化工具调用

第二个解法针对的是另一个 Token 消耗来源——工具返回的原始数据。

传统流程中,工具执行完毕后会把全部原始数据直接送回模型的上下文。一个查询返回了 500 条记录,这 500 条记录就全部进入上下文,即便模型可能只需要其中的统计摘要或过滤后的几十条。

程序化调用改变了这个流程。模型在安全的代码沙箱中生成一小段处理代码,由沙箱执行数据过滤、计算和整合,最终只把精炼后的结果返回给模型。数据处理的逻辑在沙箱里跑,Token 消耗只发生在最终结果上。

根据 Anthropic 的数据,这个方法在处理复杂任务时能额外减少约 37% 的 Token 消耗。它的价值在于:工具越多、返回数据越庞大的场景,程序化调用的压缩效果越明显。

两个解法叠加后的成本对比

把 Tool Search 和程序化调用叠加起来看,MCP 和 CLI 之间的成本差距变化如下:

阶段 MCP Token 消耗 CLI Token 消耗 倍数差距
原始状态 约 32000 约 1000 32 倍
应用两项优化后 约 10000 约 1000 约 7 倍

差距从 32 倍缩小到约 7 倍。MCP 仍然比 CLI 贵,但这个差距已经进入了可接受范围。在云端环境下,MCP 提供的标准化、安全性和跨平台能力所对应的工程价值,足以覆盖这 7 倍的成本差异。真正需要关注的反而是:如果不用 MCP,在云端场景中用其他方式实现同等能力的集成和维护成本会是多少。

Cloudflare 的实战设计

Cloudflare 是 MCP 的深度用户,他们的设计思路把 Anthropic 的理念落到了实处。

Cloudflare 需要通过 MCP 开放大约 2500 个 API 端点。如果按常规思路把这 2500 个端点全部注册为 MCP 工具,光工具定义的 Token 开销就是一个天文数字。他们的做法是对外只暴露两个工具:一个 search,一个 execute。Agent 先用 search 找到目标 API,再通过 execute 在服务端执行操作。

这个设计把工具定义的 Token 压缩到了约 1000 个,和 CLI 的消耗基本持平。它同时也体现了 Anthropic 提倡的一个设计理念:MCP 服务器应该像 CLI 一样设计,让 Agent 通过代码来编排和控制具体操作,而不是把每个原子操作都包装成一个独立的工具。

生态演进:MCP 与 Skills 的分工

Anthropic 在博客中还厘清了 MCP 和 Skills 的关系,并把 Skills 正式纳入了官方最佳实践。

MCP 负责连接各种服务、提供能力,Skills 负责告诉 Agent 如何使用这些能力来完成具体任务。两者的关系类似于工具箱和操作手册。以 Claude 的数据插件为例,它由 10 个 Skills 和 8 个 MCP 服务器组成,用户可以借此分析来自不同数据库的数据,Skills 处理分析逻辑和流程编排,MCP 服务器处理数据源连接和查询执行。

Canva、Notion 等第三方服务商也在跟进这个模式,发布 MCP 服务器的同时提供配套的 Skills。这个趋势说明 Agent 生态正在从单个工具的竞争转向工具加编排的整体方案竞争。

未来分工格局

综合 Anthropic 的这次回应和社区的实际反馈,Agent 连接层的分工正在形成如下格局:

环境 推荐方案
云端生产环境(面向用户的 SaaS) MCP + Skills
开发者本地环境 CLI + Skills
简单固定集成 直连 API

MCP 的成本问题确实存在,但 Anthropic 用 Tool Search 和程序化调用给出了可量化的解法,把差距从 32 倍压缩到 7 倍。它没有变成万能方案,但它找到了自己最该待的位置:云端和跨平台环境中的标准化接入层。不存在一个统一所有场景的连接方案,Agent 时代的连接层正在走向按环境分工的格局。


关键数据来源:

数据项 来源 数值
MCP vs CLI 成本差距 ScaleKit 测试 17 倍
MCP 上下文占用 Perplexity CTO 72%
GitHub MCP 工具数 官方 Schema 43 个
Tool Search Token 减少 Anthropic 85%+
程序化调用 Token 减少 Anthropic 37%
MCP SDK 月下载量 npm 数据 3 亿
Cloudflare 工具定义 Token 实战案例 约 1000

参考资源:

扫描二维码分享