再见 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 现实。2、Cloudflare 的分析token浪费和工具过载虽然 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 秒延迟并浪费数千个令牌仅用于复制数据。3、代码模式解决方案Cloudflare、Pydantic带 Monty以及 Zapcode 等新的开源运行时正在推动的替代方案是一个根本性的转变不再让 LLM 一个一个地调用工具。让 LLM 编写一个调用它们的脚本。这就是 Cloudflare 所称的代码模式。LLM 不会进行三次单独的往返调用来比较两个城市的天气而是生成一个单一的 TypeScript 代码块。LLM 发出代码一个沙盒运行时如 Cloudflare Workers 上的 V8 隔离区执行整个链。中间值停留在代码中它们永远不会传回神经网络。过去需要四次昂贵的 LLM 往返现在变成一次生成步骤 接着是代码执行。4、这对本地栈意味着什么如果你正在运行 M3 Max 并依赖 Claude Code CLI 来管理你的后端这场辩论至关重要。MCP 没有死。它只是被降级了。Cloudflare 明确表示 MCP 仍然是绝对最好的工具发现协议。改变的是执行的最后一英里。不再是让 Claude 调用我的数据库 15 次来生成报告堆栈的未来涉及 Claude 读取 MCP 模式编写一个 50 行的 TypeScript 或 Python 脚本然后将这个脚本交给一个沙盒本地运行时如 Zapcode一次性执行。所以如果你本周正在构建代理工作流不要丢弃你的 MCP 服务器。只是不要再把它们像魔法棒一样对待。把它们像 API 模式一样对待让你的 LLM 做它最擅长的事编写消费它的代码。原文链接再见 MCP - 汇智网