为什么MCP能爆火，但ChatGPT插件之流全都死了？神贴断言：MCP吞噬一切！ 原创

编辑 | 伊风

出品 | 51CTO技术栈（微信号：blog51cto）

MCP（Model Context Protocol）其实并不新，它早在去年就由 Anthropic 正式提出。

但短短几个月后，它的支持阵容迅速扩展，从 Cursor、Zed 等新兴工具，到谷歌、OpenAI 等顶级玩家，几乎整个 LLM 工具链都开始围绕 MCP 建设生态。

你有没有想过一个问题：

为什么 MCP 之前的那些“前辈”都没活下来，它却突然火遍全场？

我们见过太多失败的尝试：Function Calling、LangChain、AutoGPT、Custom GPTs、Plugins……

MCP 真有什么技术上质变的地方吗？还是说它只是踩中了一个刚刚好的时机？

为什么Anthropic 能做成OpenAI做不成的事？

这个问题，今天在 Hacker News 上一篇爆火的帖子里被系统性地拆解了。

作者从模型能力、协议标准、开发体验、生态势能多个层面，把 MCP 能够迅速爆火的“天时地利人和”理得明明白白。

更大胆的是，他还提出了一个断言：MCP 将吞噬一切。

他说：

 “我们相信 MCP 会留下来：它已经‘够好’了，且好在了前人没做到的地方。不仅我们这样想，我们的 API-first 客户也已经将 MCP Server 视作 API 的核心部分。”

这篇帖子也引发了开发者的激烈讨论，有人赞叹 MCP 终于统一了接口调用的混乱局面，也有人冷笑——“这不就是个加了 decorator 的 tool calling 吗？”

那 MCP 到底改变了什么？又是否真的值得我们为它下注？

我们不妨从它的“失败前辈”们说起。

一、过去的失败：MCP的前辈们做错了什么？

MCP 的定位是：“帮助你基于大语言模型（LLM）构建智能代理和复杂工作流”。

如果你一直关注这类技术的发展，就会知道——这绝不是第一次有人尝试用结构化、自动化的方式，把外部世界连接到语言模型上。

过去的尝试包括：

• Function/tool 调用：写一个 JSON Schema，由模型来选择函数。但每次请求都需要手动连接函数，还要你自己承担重试逻辑的大部分实现。
• ​ReAct / LangChain：让模型输出一个 Action: string，然后你得自己解析——经常很不稳定，调试也很困难。
• ​ChatGPT 插件：功能丰富，但受限严重。你得自己搭建 OpenAPI 服务并通过 OpenAI 审核。
• ​Custom GPTs：入门门槛更低，但仍然困于 OpenAI 的运行时环境。
• ​AutoGPT、BabyAGI：雄心勃勃的代理框架，但配置繁复、循环混乱、错误层层叠加。

二、为什么是MCP杀出重围？

抛开夸张的炒作，MCP 既不是魔法，也谈不上什么技术革命。

但它确实简单、有效、执行得当——关键是，它生逢其时。

1.模型终于够好了

过去，工具调用的实际体验可以用一个词形容：混乱。

哪怕只是最基础的功能，也要配合大量的错误处理——重试逻辑、字段校验、异常提示，一步错，步步错，跑起来很费劲。

尤其是在智能体（Agent）场景下，对模型的鲁棒性要求极高。

很多人都踩过坑：模型输出一个莫名其妙的指令，导致后续对话彻底崩溃。我们通常叫这类问题“上下文污染”。

工具越多，风险越大。于是大多数 Agent 反而选择了保守策略——缩短链路，避免做多错多。

如今的新模型，已经足够强大。虽然仍不完美——更强的模型往往更慢，仍受限于上下文大小，信息过多时性能会下降——但已经“好到可以用了”。

而一旦模型能力跨过这个临界点，集成工具的复杂性就会显著下降。

MCP 的登场，正好踩在了这个节点上。

2.协议够实用了

过去的工具接口都被绑定在特定技术栈里：

• OpenAI 的 function calling 只能在他们自家 API 里用；
• ChatGPT 插件必须跑在他们的运行时中；
• LangChain 的工具深度耦合在提示循环里；

你无法随意将一个工具从 A 平台搬到 B 平台，每个平台都得重新接线。

更糟的是，不同平台对 JSON Schema 等规范的支持也略有差异。想要支持重试，你还得自己搞清楚怎么拼接提示信息、触发新的一轮生成，而且每个平台的做法都“略微不一样”——足够令人抓狂。

还有些隐性坑，比如：同样的提示词，在不同平台表现差异巨大，都是因为消息处理细节不同。

MCP 提供了一种共享的、与厂商无关的协议。你定义一次工具，任何支持 MCP 的 LLM 代理都能使用它。

当然，兼容性问题并没有完全解决。目前想让 MCP 同时在所有平台顺利跑通，依然具有挑战性。尤其在初期没有认证标准，导致集成更加困难。

但 MCP 的承诺很重要：只要你符合 MCP 标准，其它问题就变成了“别人的 bug”。当你不再需要对抗整个世界去实现某个想法时，创新速度会自然提升。

 MCP协议虽然不完美，但“已经足够好”。它作为一个抽象层，明确划清了工具与代理之间的界限，让工具开发者专注于工具，代理开发者专注于代理。

3.工具链够易用了

MCP 提供的开发工具链足够直观、质量上乘，也足够易上手。多语言 SDK 提供良好支持，不管你用什么技术栈都能方便集成。

无需多余搭建，无需自己处理重试逻辑，无需操心代理连接。门槛变低，意味着构建、共享、复用工具的速度都加快，可以部署到 CLI、IDE、代理、Web 服务等各种环境。

你可以很快开始，并立刻看到效果。

这里有个小结论：开发者体验至关重要。平台能否被广泛采用，有时只取决于那一点点摩擦是否被消除了。

4.势头够强劲了

不出所料，任何协议的成功都需要猛烈的上升态势和开发者中的口碑宣传。

一个协议的价值，来自于客户端和服务端的广泛支持。

在客户端，MCP 已获得广泛采纳：OpenAI Agent SDK 和 Google DeepMind 全面支持，Cursor、Cline、Zed 等主流代理工具已完成集成。

在服务端，MCP也在加速入场。越来越多 API-first 公司将自家服务封装成 MCP 工具。即使没有官方 MCP 工具，也有第三方服务填补空白。

除了 MCP 核心软件之外，丰富的独立生态也在迅速崛起：

• 工具注册表（如 awesome-mcp-servers、smithery.ai、postman、glama.ai）
• 第三方服务（如 Cloudflare、Vercel）
• 教程（glama.ai、Towards Data Science）
• 在线课程、活动等（Hugging Face）

这些动量不是一夜之间建立的。Anthropic 团队付出了大量努力，撰写优质文档、举办技术讲座、组织线下活动，甚至直接与企业合作，为 MCP 构建了一个已然具有吸引力的生态。

随着 MCP 成为主流，基础模型提供商未来可能会直接在训练中加入 MCP 使用模式的数据。这将反过来提升模型处理工具和代理任务的能力，巩固 MCP 作为未来 API 接入思维方式的地位。

三、开发者争论：MCP也是“重复造轮子”，如果消亡也不会奇怪！

到这里，我们已经梳理作者认为 MCP 能爆火的多个原因。但在开发者社区，对 MCP 的看法仍然分歧明显。

不少人承认 MCP 的确降低了接入工具的门槛，让复杂任务更容易落地。比如有位开发者提到，他们用 MCP 接入了 50 多个内部工具，Agent几秒钟就能自动完成本该几小时的 Jira 和 Confluence 浏览总结，对业务效率的提升非常实在。

但也有许多老牌程序员对 MCP 抱有强烈的保留意见。他们的核心观点是：MCP 不是突破，而是在重复造轮子。

一位资深开发者在评论中这样写道：

只是因为现在所有用户侧工具都支持 MCP，我才会用 MCP。

一旦业界选定了一个“正常”的统一标准，我会立刻把 MCP 扔掉，因为 MCP 并没有带来任何我用标准 API 做不到的东西。

我经历过从 EDI 到 EJB、XML-RPC 等整个演变过程。我们行业总爱造新 API 接口，但要么没设计好，要么难以复用。这种“无视已有经验，另起炉灶”的情况我早已见怪不怪。

只要出现一个更合理、可集成性强的替代方案，我会毫不犹豫地彻底换掉 MCP。企业领域很多人想法都一样——毕竟我们花了几十年构建完善的 API 管理系统，而 MCP 把这一切都搞乱了。

这番话引起了不少共鸣。另一位用户回复道：

完全同意，虽然我理解 MCP 在用户端工具方面的价值，但很多人似乎是在“重新造轮子”，因为他们根本不懂 REST。用 LLM 发起一个定义良好的 REST 请求，其实并不难。

更有人抛出了一个更具未来感的判断：

如果未来 LLM 支持直接发 HTTP 请求，我不会惊讶 MCP 会因此消亡，或者至少大幅减少使用场景。 因为如果你训练 LLM 直接调用 REST API，那 MCP 很多用例就没意义了。

或许，MCP 的成功并不是因为它有多先进，而是它刚好出现得足够及时——踩在了模型能力提升、工具生态爆发、标准化需求集中的那个临界点上。

但如果有一天，LLM 真能直接联网、调用 API、读写文件……我们还会需要 MCP 吗？

你怎么看？欢迎在评论区聊聊你的看法，或者分享你使用 MCP 的踩坑与收获。

参考链接：https://www.stainless.com/blog/mcp-is-eating-the-world--and-its-here-to-stay

本文转载自51CTO技术栈，作者：伊风