再见 MCP

好吧，代理 AI 社区正在经历一次重大的现实检验。

如果你关注开发者动态已有一段时间，模型上下文协议（MCP） 本应是通用标准。

我不会说它没有帮助。我构建了 Splitwise MCP，因为付费升级 pro 不是一个好主意。

它是将 Claude 或 Gemini 安全连接到我们的本地数据库、API 和文件系统的神奇粘合剂。

但我认为这个阶段正式结束了。

在过去的 24 小时里，社区炸开了锅。

Perplexity 的 CTO 确认他们将在内部退回到 MCP，转而使用传统的 REST API 和 CLI，特别是针对他们的企业客户。

同时，Cloudflare 发布了一篇大规模的技术分析，解释了为什么传统的 MCP 工具调用架构对复杂的 AI 代理有根本性缺陷。

1、为什么 Perplexity 要拔掉插头

MCP 的前提很聪明：标准化 LLM 与外部数据交互的方式。但根据 Perplexity 泄露的内部共识，在大规模企业环境中执行目前是一场噩梦。

安全差距： 对于小型初创公司，本地 MCP 很好。但对于大型企业客户，MCP 中的认证机制实际上不存在。当处理严格的合规要求、速率限制和审计日志时，开发者意识到传统的 REST/GraphQL API 早在十年前就解决了这些问题。
Stdio 传输缺陷： 开发者报告说，使用 stdio 传输（本地 MCP 服务器与 IDE 通信的默认方式）在重负载下变得非常脆弱。
协议不成熟： 许多基础设施工程师认为规范已经过时，使其更像是出色的本地开发工具，而不是企业级管道。

注意：Perplexity 并非完全删除 MCP，他们仍然维护它，以便 Claude Desktop 等工具可以连接到他们的搜索。

但对于他们的核心、跨组织企业路由？他们正在回归无聊但经过实战验证的 REST API 现实。

虽然 Perplexity 引用了基础设施和安全问题，但 Cloudflare 攻击了 LLM 通过 MCP 使用工具的实际机制。

在一篇广泛传播的文章中，他们指出了标准工具调用的三个致命缺陷：

缺乏训练数据： LLM 已吸收了数百万行代码，但很少有原始 JSON 工具调用的例子。正如 Cloudflare 所说："让 LLM 使用工具调用就像让莎士比亚参加一个月的普通话课程，然后让他用普通话写剧本。"
工具过载（基数问题）： 当你将 30 多个 MCP 工具放入上下文窗口时，模型开始产生幻觉，因为描述模糊在一起。它难以选择正确的工具。
"令牌浪费"循环： 这是最大的架构缺陷。在多步骤任务中（例如 A → B → C），每个中间结果都必须通过 LLM 传回。
调用 API A → 结果发送到 LLM → LLM 读取它 → 调用 API B → 结果发送到 LLM → LLM 读取它 → 调用 API C。* 每次往返增加 1-5 秒延迟，并浪费数千个令牌仅用于复制数据。

Cloudflare、Pydantic（带 Monty）以及 Zapcode 等新的开源运行时正在推动的替代方案是一个根本性的转变：

不再让 LLM 一个一个地调用工具。

让 LLM 编写一个调用它们的脚本。

这就是 Cloudflare 所称的"代码模式"。

LLM 不会进行三次单独的往返调用来比较两个城市的天气，而是生成一个单一的 TypeScript 代码块。

LLM 发出代码，一个沙盒运行时（如 Cloudflare Workers 上的 V8 隔离区）执行整个链。

中间值停留在代码中，它们永远不会传回神经网络。

过去需要四次昂贵的 LLM 往返，现在变成一次生成步骤，接着是代码执行。

如果你正在运行 M3 Max 并依赖 Claude Code CLI 来管理你的后端，这场辩论至关重要。

MCP 没有死。它只是被降级了。

Cloudflare 明确表示 MCP 仍然是绝对最好的"工具发现协议"。

改变的是执行的最后一英里。

不再是让 Claude 调用我的数据库 15 次来生成报告，堆栈的未来涉及 Claude 读取 MCP 模式，编写一个 50 行的 TypeScript 或 Python 脚本，然后将这个脚本交给一个沙盒本地运行时（如 Zapcode）一次性执行。

所以，如果你本周正在构建代理工作流，不要丢弃你的 MCP 服务器。

只是不要再把它们像魔法棒一样对待。

把它们像 API 模式一样对待，让你的 LLM 做它最擅长的事：编写消费它的代码。

汇智网翻译整理，转载请标明出处