一周年即遇冷：MCP的興衰與AI工具的過渡本質(zhì)
11月25日，Anthropic官方博客發(fā)布了一篇周年慶文章，宣布MCP正式迎來一周歲生日，同時推出了新版規(guī)范。
官方公布的數(shù)據(jù)看似亮眼：MCP Registry目前已收錄近2000個Server，較9月上線時增長了407%。OpenAI在3月宣布全面支持MCP，Google、AWS、HuggingFace等企業(yè)也計劃接入，從表面看，這似乎是一個正被行業(yè)認可的開放標準。
然而，這條周年慶消息在社交媒體上幾乎無人問津，相關(guān)討論寥寥無幾。
回想一年前，MCP橫空出世時曾在硅谷引發(fā)轟動?！癆I界的USB-C”“Agent時代的基礎(chǔ)設(shè)施”“我們有救了”——那些曾讓人熱血沸騰的口號，如今聽來仿佛已是遙遠的過去。
更值得玩味的是，就連Anthropic自身似乎也在悄然“去MCP化”。打開最新版本的Claude，一套名為Skills的系統(tǒng)正接管越來越多的功能。生成PPT？調(diào)用Skill。處理Excel？還是依賴Skill。這個曾被寄予厚望的萬能協(xié)議，為何會落到如此境地？
1
MCP為何出道即巔峰
2024年MCP的發(fā)布之所以引發(fā)熱潮，是因為它精準解決了當時AI應用開發(fā)的一大痛點：開發(fā)者不得不重復開發(fā)類似功能。
在MCP出現(xiàn)前，開發(fā)者若想讓Claude訪問Google Drive，需編寫一套API接口；若要接入Slack，則需再開發(fā)一套。對于IDE廠商而言，情況更糟——Cursor要適配Linear，Windsurf也要適配Linear，每家都在做著幾乎相同的繁瑣工作。
MCP的核心承諾是“一次開發(fā)，多端運行”。例如，只要Linear官方開發(fā)好一個MCP Server，無論是Claude、Cursor還是未來的任何AI Agent，都能直接接入使用。
當時GitHub上的MCP項目如雨后春筍般涌現(xiàn)：查天氣、看股票、發(fā)小紅書等功能應有盡有。開發(fā)者們沉浸在“將世界接入AI”的狂歡中，都認為當大模型接入無數(shù)MCP后，就能具備無所不能的能力。
然而，實際的工程落地給所有人澆了一盆冷水。
2
致命缺陷：MCP越多，AI越“笨”，成本越高
MCP最大的問題在于，其調(diào)用方式會占用模型的上下文窗口。
MCP要求所有工具定義、調(diào)用請求和返回結(jié)果都必須通過模型的上下文窗口傳遞，因為模型需要“讀取”這些信息才能做出決策和推理。而且這個過程是累加的——每一輪MCP調(diào)用都會增加token數(shù)量，多次調(diào)用后上下文會迅速膨脹。
Django聯(lián)合創(chuàng)始人之一的Simon Willison在博客中提到，僅GitHub官方的MCP就定義了93個工具，消耗55000個Token。如果按照一些教程建議掛載20個MCP Server，幾輪對話后上下文就會超出限制。
Anthropic自己也承認了這一問題。他們在博客中寫道，當Agent需要讀取一份兩小時的會議文檔時，可能要額外處理50000個Token，更大的文檔甚至會直接超出上下文窗口限制，導致整個工作流崩潰。
Claude的Token成本之高有目共睹，加載過多MCP會導致未生成有效內(nèi)容就消耗大量費用。
更致命的是，當MCP安裝過多時，模型會出現(xiàn)“智商下降”的情況。
有開發(fā)者用MCP搭建了一個簡單計算器，結(jié)果模型調(diào)用減法工具后，明明服務器返回了-9，它卻錯誤地輸出+9——沒有信任工具返回值，反而用自身常識替代了結(jié)果。
這種問題在工具較少時幾乎不會出現(xiàn)，但當上下文被各種工具定義塞滿后，模型的注意力會被分散，從而出現(xiàn)錯誤推理。
若只是結(jié)果錯誤最多浪費成本，但設(shè)計不安全的MCP可能造成不可逆的損失。有人掛載了文件系統(tǒng)MCP后，AI產(chǎn)生幻覺，誤刪了不該刪除的代碼庫。
早期MCP的權(quán)限設(shè)計過于粗放，掛載一個文件系統(tǒng)往往意味著AI能讀寫整個磁盤。幾次事故后，大公司的安全部門迅速介入，設(shè)置白名單的成本甚至高于傳統(tǒng)API。
MCP多則模型智商下降，MCP少則模型能力受限——這個悖論至今無解。
3
雙刃劍：門檻降低，質(zhì)量卻失控
MCP的另一問題是門檻過低。
搭建一個MCP Server非常簡單，幾十行代碼就能運行，于是人人都參與其中。這導致大量重復、低質(zhì)量的項目出現(xiàn)。十個天氣查詢MCP中，可能九個半都是換皮復制，真正設(shè)計精良、維護活躍的寥寥無幾。
有論文研究顯示，在近1900個MCP Server中，大量存在憑證暴露、缺乏維護等問題。生態(tài)看似繁榮，實則泡沫居多。
開發(fā)者面對眾多選項，反而需要花更多時間甄別可用、靠譜的工具，篩選成本甚至高于自己開發(fā)一個。
4
Skills上位：官方的隱性調(diào)整
從另一方面看，如果MCP真的完美，Anthropic為何要“去MCP化”？
打開最新的官方文檔，Skills被置于核心位置，而MCP越來越像一個不得不保留的兼容層。其潛臺詞很明確：別再迷信通用MCP了，回歸定制化吧。
Skill本質(zhì)上是對MCP的一次修正，也有人認為這是在為MCP“擦屁股”。它不再試圖讓模型實時理解外部世界，而是將高頻、驗證過的能力封裝成精簡預設(shè)。對于編程、繪圖、網(wǎng)頁瀏覽等核心能力，原生集成永遠比通用協(xié)議更快、更穩(wěn)定、更省Token。
Anthropic最近發(fā)布的技術(shù)博客也變相承認了MCP的設(shè)計缺陷。他們提出了新思路：讓Agent通過代碼調(diào)用MCP，而非直接暴露工具定義。據(jù)稱這種方式能減少98.7%的Token消耗——這無疑是在暗示MCP原有的用法存在問題。
那個試圖用一套協(xié)議統(tǒng)一世界的宏大愿景，正在悄然瓦解。
5
MCP與Skill：都是過渡產(chǎn)物
跳出協(xié)議細節(jié)，從更長時間維度看，我們會發(fā)現(xiàn)一個有趣的事實：
無論是試圖用JSON標準化世界的MCP，還是用預設(shè)封裝能力的Skills，抑或是我們絞盡腦汁編寫的Prompt，本質(zhì)上都是同一類東西——補丁。
它們是為彌補當前AI智力不足而不得不打的補丁。
因為現(xiàn)在的AI還不夠聰明，不懂得即興發(fā)揮。所以我們需要MCP告訴它數(shù)據(jù)接口是什么，需要Skill告訴它標準流程是什么，需要Prompt告訴它注意事項是什么。
我們在用確定性的工程手段，試圖駕馭一個概率性的智能體。
想象一下真正強大的ASI（人工超級智能）出現(xiàn)的那天：它還需要你開發(fā)MCP Server來查天氣嗎？不，它會自己打開瀏覽器查看。它不需要協(xié)議，因為它本身就是“適配器”。
MCP徹底涼了嗎？或許沒有。Anthropic的路線圖仍在推進遠程連接、OAuth認證、企業(yè)級部署等功能，IBM也宣布將向MCP社區(qū)貢獻企業(yè)級資產(chǎn)。它只是從“網(wǎng)紅”回歸到“基建”的位置——高頻能力歸Skills，長尾數(shù)據(jù)歸MCP，這大概就是它最終的生態(tài)定位。
不再盲目給AI堆砌工具，而是思考哪些接口真正重要——這或許是MCP最大的貢獻。
本文來自微信公眾號“硅星人Pro”，作者：董道力，36氪經(jīng)授權(quán)發(fā)布。
本文僅代表作者觀點，版權(quán)歸原創(chuàng)者所有，如需轉(zhuǎn)載請在文中注明來源及作者名字。
免責聲明：本文系轉(zhuǎn)載編輯文章，僅作分享之用。如分享內(nèi)容、圖片侵犯到您的版權(quán)或非授權(quán)發(fā)布，請及時與我們聯(lián)系進行審核處理或刪除，您可以發(fā)送材料至郵箱：service@tojoy.com