---
2025年3月那會兒，MCP這三個字母在中文互聯(lián)網(wǎng)上屬于頂流。
鋪天蓋地的分析文章、教程、"手把手教你5分鐘接入MCP"。所有大廠排隊表態(tài)支持，GitHub上MCP Server一個月新增三千個。那場面，恍惚間讓人覺得：下一個iOS生態(tài)就要靠這玩意兒定義了。
2026年4月呢？
安靜。
不是死寂——該支持的還在支持，該接入的還在接入。但那種"不追就落后"的緊迫感沒了。朋友圈里沒人轉(zhuǎn)發(fā)MCP教程了，評論區(qū)也不吵了。熱度這東西，降起來比登天還快。
那么問題來了：MCP是踩過了應(yīng)該踩的坑，開始走向真正有用的階段？還是那場爆發(fā)本來就不是真實需求，全靠FOMO情緒撐著，現(xiàn)在泡沫破了？
---
一、先說清楚2025年那波爆發(fā)是什么
2024年11月，Anthropic推出MCP的時候，這個協(xié)議解決的是一個真實問題：AI工具和外部世界之間的連接方式太亂了。每個廠商、每個工具都有自己的插件系統(tǒng)，互相不兼容。Cursor有Cursor的，Claude有Claude的，OpenAI有OpenAI的。你想在一個AI編程環(huán)境里調(diào)用內(nèi)網(wǎng)的代碼庫？得單獨適配。想讓AI讀一份PDF？得另外寫接口。
MCP說：別折騰了，我統(tǒng)一標(biāo)準(zhǔn)，一次接入，到處運行。
這個價值主張是真實的。所以才有了后來的連鎖反應(yīng)——OpenAI在2025年3月跟進，Google在4月跟進，Microsoft在Win11里做原生集成。阿里云百煉、騰訊云、百度、高德，全都在推自己的MCP服務(wù)。
然后整個行業(yè)就嗨了。
但我需要提醒一件事：大廠擁抱一個協(xié)議，跟這個協(xié)議真的好使，是兩件不同的事。
---
二、質(zhì)疑方說的到底對不對
力推陣營的核心邏輯是：MCP會成為"AI時代的USB-C"。2026年4月，Meta在Connect大會上宣布AI工具支持MCP。Docker發(fā)了MCP Toolkit。Linux Foundation接管了協(xié)議規(guī)范，成立了AAIF。這些都是真金白銀的投入，不像是玩票。
質(zhì)疑陣營的核心邏輯是：你解決的那個問題，方法選錯了。
ScaleKit在2026年2月做了一次基準(zhǔn)測試，測的是MCP和CLI兩種方案在真實開發(fā)任務(wù)上的表現(xiàn)。結(jié)果是這樣的：
| 方案 | 任務(wù)完成率 | 平均耗時 |
|:---|:---|:---|
| CLI | 100% | 基準(zhǔn) |
| MCP | 72% | 基準(zhǔn)的1.3倍 |
28%的任務(wù)直接失敗。失敗原因主要是超時和連接不穩(wěn)定。
這個數(shù)字在開發(fā)者社區(qū)引起了廣泛討論。有人反駁說測試環(huán)境有問題，測試用例不公平。但Perplexity CTO Denis Yarats在2026年3月的一篇內(nèi)部帖子被截圖傳出來了，原話大概是：我們在實際產(chǎn)品里測了半年，結(jié)論就是MCP帶來的復(fù)雜度遠(yuǎn)大于它解決的那個問題，轉(zhuǎn)回API和CLI。
YC CEO Garry Tan的表態(tài)更直接，在推特上打了兩個字：MCP sucks。
一個字的評論，評論區(qū)關(guān)了。
Simon Willison是Python社區(qū)很有影響力的開發(fā)者，他在博客里寫過一件事：某主流AI IDE的MCP Server捆綁了43個工具描述，AI接入之后光工具定義就往上下文里塞了55000個token。干活之前先把token預(yù)算花掉一半，這不是本末倒置嗎？
最后這個細(xì)節(jié)很有意思：OpenClaw——就是那個34萬星的明星開源AI編程工具——從第一天起就不支持MCP，用自己的Skills系統(tǒng)。創(chuàng)始人Peter Steinberger后來加入OpenAI，也沒改變這個立場。
這些聲音加在一起，構(gòu)成了一個完整的質(zhì)疑鏈條：MCP解決的是連接標(biāo)準(zhǔn)化問題，但標(biāo)準(zhǔn)化的代價是引入了新的復(fù)雜性——啟動失敗、上下文膨脹、認(rèn)證不一致、調(diào)試?yán)щy。這些問題在概念層面不存在，但在工程實踐里天天都在發(fā)生。
---
三、MCP的防守
但話說回來，質(zhì)疑陣營的勝利從來沒有轉(zhuǎn)換成市場勝利。
一個協(xié)議好不好用和技術(shù)圈認(rèn)不認(rèn)，是兩件事。JavaScript的回調(diào)地獄好不好用？不好用。但JavaScript贏了。微服務(wù)架構(gòu)好不好用？很多人罵，但整個行業(yè)還是往這個方向走。
2026年3月26日，MCP規(guī)范做了一個重要更新：Auth認(rèn)證機制從草案進入正式版，HTTP transport升級為Streamable HTTP。這兩個變化解決的是之前被罵得最狠的兩個問題：明文密碼和長連接不穩(wěn)定。
這不是小修小補。Auth認(rèn)證進入規(guī)范，意味著企業(yè)級的權(quán)限控制終于有標(biāo)準(zhǔn)可以遵循了。Streamable HTTP取代SSE，意味著MCP終于可以在瀏覽器環(huán)境里原生運行了。
而且還有一個更諷刺的事實：Anthropic自己的Claude Code，核心架構(gòu)是CLI，不是MCP。Anthropic工程師寫的最佳實踐文檔里，CLAUDE.md自定義指令系統(tǒng)占了大量篇幅，MCP只是"可選擴展"。
這說明什么？說明Anthropic自己都不覺得MCP是必選項。但他們依然在推這個協(xié)議。
因為對大廠來說，協(xié)議的價值不在于它是不是最優(yōu)解，而在于它是不是足夠多人用。用的人越多，生態(tài)越完整，后來者的切換成本越高。這套邏輯在USB-C、TypeScript、Kubernetes上都驗證過。
---
四、為什么2026年相對平靜了
我認(rèn)為原因是真實的，但方向是兩個不同的故事疊加在一起。
第一個故事：技術(shù)圈的需求本來就沒有那么大。
AI編程工具的早期采用者，大多是個人開發(fā)者和小型團隊。他們對工具鏈的簡潔性要求極高，能用CLI解決的事情不愿意多加一層協(xié)議。MCP的第一波熱度，主要就是這批人炒起來的。到了2026年，這批人要么已經(jīng)遷就了MCP的復(fù)雜度，要么發(fā)現(xiàn)CLI更適合自己。兩種選擇的用戶都在沉淀，輿論自然就安靜了。
第二個故事：大廠沒有停下來。
OpenAI沒有停，Google沒有停，Microsoft把MCP做進了Win11系統(tǒng)層，阿里云百煉上線了全生命周期的MCP服務(wù)。這些動作的決策周期比技術(shù)圈討論的周期長得多，落地也慢得多。2026年看起來平靜，是因為大廠在做實事，不是在發(fā)新聞稿。
所以我自己的判斷是：MCP正在經(jīng)歷一個正常的成熟路徑。
2025年的爆發(fā)有泡沫，泡沫是真實存在的。2026年的平靜也有誤解，誤解在于把沉默當(dāng)成了衰退。這兩個判斷都不對。
---
五、如果你在選技術(shù)方向
給一個相對實用的參考框架：
| 場景 | 我的建議 |
|:---|:---|
| 企業(yè)內(nèi)部系統(tǒng)集成，需要對接多個數(shù)據(jù)源 | 等MCP安全標(biāo)準(zhǔn)成熟，目前階段認(rèn)證機制各家自己實現(xiàn)，風(fēng)險自擔(dān) |
| 開發(fā)者工具鏈，追求穩(wěn)定和調(diào)試便利 | CLI優(yōu)先，已經(jīng)驗證過的方案不需要為了追新?lián)Q架構(gòu) |
| AI編程助手個人使用 | MCP可以嘗鮮，但不要超過5個Server，工具數(shù)量和上下文質(zhì)量成反比 |
| 想投奔一個協(xié)議等它長大 | 現(xiàn)在進場賭MCP是可以的，但別All in，協(xié)議戰(zhàn)爭的終局從來不是因為技術(shù)最強 |
最后說一句。
Anthropic工程師在內(nèi)部實踐里用了幾百個Skills，CLAUDE.md是他們最重要的工具鏈載體，不是MCP。這條信息很少有人放在文章里，但它最能說明一件事：
真正在用AI編程的人，最后都選了最簡單的路徑。
MCP能不能走到那一步，不知道。但它現(xiàn)在正在經(jīng)歷一個協(xié)議最重要的階段——不是最熱的時候，而是最關(guān)鍵的時候。
