MCP 真凉了？

最近AI圈有个很有意思的现象：去年被捧上天的MCP，现在又成了人人喊打的过街老鼠。 Perplexity联合创始人Denis Yarats说"正在放弃MCP，回归API和CLI"，YC总裁Garry Tan直接发帖"MCP糟透了"，甚至有人开始高呼"拆除MCP服务器，换成Markdown文件"。 这剧情反转得也太快了。MCP从AI时代的TCP/IP到简直烂透了，满打满算也就一年时间作业。 说实话，看到这些言论的时候我挺唏嘘的。去年这个时候，整个行业都在吹MCP，说什么"一键连接所有工具"、"让AI真正成为万能助手"。 结果现在风向突变，那些当初最热情的人也骂得最凶。 这到底是怎么回事？是MCP真的不行，还是我们当初的期待本来就不切实际？

MCP为什么从宠儿变成弃儿

要回答这个问题，得先搞清楚MCP最初解决的是什么问题。

MCP的愿景很美好：搞一个标准化的协议，让AI能够连接任何第三方工具。

开发者不用再为每个AI模型、每个工具组合写专门的适配代码，只需要实现一次MCP服务器，就能让所有支持MCP的AI助手调用。

理想很丰满，现实很骨感。

这个标准化是有代价的。

Garry Tan吐槽说，MCP的上下文窗口臃肿、身份验证笨拙、需要手动开关服务器。他自己花30分钟写了个命令行包装器，效果比MCP好100倍，代码只有100行。

这话听起来有点极端，但细想之下很有道理。

MCP的设计逻辑是先让机器看懂协议，再让AI执行操作。

这就得每次AI要调用一个工具，都得先理解一套复杂的协议定义。

好比你每次进餐前都要先通读一遍《食品安全法》和《餐具使用规范》——不是说这些规范没用，而是大部分时候真的没必要。

有个数据特别能说明问题：GitHub的MCP服务器为了教会AI如何使用GitHub，需要消耗大约50,000个Token的上下文；而一个写着"使用gh命令操作"的Markdown文件，只需要200个Token就能达到同样效果。

250倍的差距。在长上下文模型依然昂贵的今天，这个差距直接决定了一个AI产品是盈利还是亏损。

Perplexity为什么放弃MCP？

因为他们算过账了。与其花那么多Token去理解MCP协议，不如直接调API。

一个简单的CLI调用，200个Token搞定，它不香吗？

开发者集体叛逃背后

有意思的不只是Perplexity这样的明星公司，很多一线开发者也在做同样的事：拆除MCP，换成Markdown文件。

Sentry的David Cramer说得更直接："许多MCP服务器根本没有存在的必要，因为它们要么是糟糕的API封装，要么可以用Skills文件替代。"

开源系统CompanyOS的创始人Brad Feld则在用实际行动打脸MCP。

他的系统虽然连接了8个MCP服务器，但真正的灵魂是那些Markdown文件。

每个Skill文件编码了工作流、护航规则、语气校准以及决策逻辑。

即便MCP断开连接，这些Skills依然有效，只需要把自动发送改成手动复制粘贴就行。

这说明啥？

说明很多开发者意识到，MCP服务器从一开始就是为了解决错误的问题而设计的。

MCP试图解决的是让AI理解工具的问题。

但现实是，对于大部分简单场景，AI根本不需要那么复杂的协议定义。

一个简简单单的Markdown文件，告诉AI这是API端点，这是参数，开火吧，就够了。

这背后的逻辑是：在AI时代，描述比定义更高效。

MCP是给机器看的——严苛的JSON架构、复杂的验证逻辑、繁琐的服务器握手。

API加Skill是给AI看的——一个.md文件，语义清晰，执行高效。

MCP真的要消亡了吗

更深一层看，这场MCP争议其实反映了AI工程化的两种路线之争。

一派是协议派，追求大一统的理想主义。

Anthropic等大模型厂商是典型代表，他们试图建立一套AI时代的全球标准语。

先有协议，再有连接，就像互联网需要TCP/IP一样，AI Agent要调用成千上万的工具，必须有一套严谨、标准化的沟通协议。

这种思路不能说错，但它带来的工程代价是：为了实现通用性，系统变得极其沉重。

Agent在执行任务前，需要进行复杂的"握手"和"语义校验"，50,000Token的上下文开销就是这么来的。

另一派是实效派，追求极简的实用主义。

Perplexity、Garry Tan以及广大一线开发者是典型代表。

他们对"过度工程化"表现出强烈的反感。

在他们看来，AI时代连接大于协议。

既然API已经是现成的、成熟的，为什么还要在外面包一层厚重的MCP？

极致的上下文密度、绕过繁琐验证、200个Token直接命中API端点——这才是工程师应该追求的效率。

有个梗很形象：别跟我谈什么全球标准，我只想用最少的Token让我的Agent把活干完。

那么，MCP真的要消亡了吗？

说实话，现在说MCP已死还为时过早。

MCP并不是毫无用处，它只是正在退缩到它最擅长的领域：企业内网的复杂工具链。

微软最新的.NET Skills Executor就给出了一个新的思路——混合架构。

第一层用极简的Markdown引导AI，第二层只在涉及跨系统、高频调用的复杂工具时，才在后台静默调用MCP。

这种思路很务实。

在需要深度系统集成、复杂权限管理、严格审计追踪的企业场景，MCP的标准化优势依然明显。而在面向消费者的、追求极致体验的Agent场景中，简单直接的API调用正在收复失地。

说到底，MCP的困境不是因为它本身有多糟糕，而是因为它被用在了错误的地方。

就比如你有一把好锤子却被用来拧螺丝，然后抱怨锤子不好用。

MCP的真正价值，可能在于那些需要标准化、安全性、高度规范化的企业级应用场景，而不是那些追求极致效率和低成本的个人开发者应用。

结语

一个扎心的提醒是：在AI领域，过度工程化有时候是创新的天敌。

当我们热衷于构建完美的协议和架构时，往往忽略了实际执行者的需求。

Perplexity的做法值得思考：把搜索、模型、嵌入打包成全栈API，跳过复杂的协议层，直接接管底层基座。

用最简单的方式解决实际问题，而不是在技术方案的复杂度和功能全面性之间反复纠结。

也许在2026年，最好的协议就是没有协议。当然，这话有点极端。但它提醒我们：技术方案的最终目的，是解决问题，而不是展示技术的复杂性。

MCP凉了吗？部分场景是的。

但彻底死去？

恐怕没那么简单。

它只是在找到自己真正的位置——那个不需要被吹捧，也不需要被贬低的位置。

大家觉着呢？