誕生才一周年，MCP涼了

作者 ｜ 董道力
郵箱 ｜ dongdaoli@pingwest.com

11 月 25 日，Anthropic 官方博客更新了一篇慶祝帖，宣布 MCP 正式滿一周歲，配合發(fā)布的還有一份新版規(guī)范。

官方給出的數(shù)據(jù)看起來不錯：MCP Registry 目前收錄了近 2000 個 Server，比 9 月份剛上線時增長了 407%。OpenAI 在 3 月宣布全面支持 MCP，Google、AWS、HuggingFace 等都將接入，從紙面上看，這是一個正在被行業(yè)接受的開放標(biāo)準(zhǔn)。

但這條周年慶消息在社交媒體上幾乎沒有激起水花，鮮有討論。

要知道就在一年前，MCP 橫空出世時整個硅谷都炸了鍋。"AI 界的 USB-C"、"Agent 時代的基礎(chǔ)設(shè)施"、"我們有救了"，那些讓人熱血沸騰的口號，如今聽來恍如隔世。

更耐人尋味的是，就連 Anthropic 自己似乎也在悄悄"去 MCP 化"。打開最新版本的 Claude，一套叫做 Skills 的系統(tǒng)正在接管越來越多的工作。生成 PPT？讀 Skill。做 Excel？還是讀 Skill。曾經(jīng)被寄予厚望的萬能協(xié)議，怎么就淪落到這步田地？

1

MCP 為什么出道即巔峰

2024 年 MCP 發(fā)布之所以引發(fā)轟動，是因為它精準(zhǔn)擊中了當(dāng)時 AI 應(yīng)用開發(fā)最大的痛點：開發(fā)者不得不重復(fù)造輪子。

在 MCP 出現(xiàn)之前，開發(fā)者想讓 Claude 訪問 Google Drive？寫一套代碼接 API。想讓它訪問 Slack？再寫一套 API。對于 IDE 廠商更慘，Cursor 要適配 Linear，Windsurf 也要適配 Linear，每家都在做幾乎一模一樣的臟活累活。

MCP 的承諾是一次開發(fā)、處處運行。比如，只要 Linear 官方寫好一個 MCP Server，無論是 Claude、Cursor 還是任何未來的 AI Agent，插上就能用。

那時候 GitHub 上的 MCP 項目如雨后春筍：查天氣的、看股票的、發(fā)小紅書的。開發(fā)者們沉浸在"把世界喂給 AI"的狂歡中，人人都以為當(dāng)大模型接入無數(shù) MCP 后，將獲得無所不能的能力。

然后真實的工程落地給所有人潑了一盆冷水。

1

致命弱點：MCP 越多、AI 越蠢、越花錢

MCP 最大的問題是，其調(diào)用方式是要占用上下文的。

MCP 要求所有工具定義、調(diào)用請求和返回結(jié)果都必須經(jīng)過模型的上下文窗口，因為模型需要"看到"這些信息才能決策和推理。而且這個過程是累加的 MCP 每一輪調(diào)用都在累加 token，多次調(diào)用后上下文迅速膨脹。

Django 聯(lián)合創(chuàng)造者之一的 Simon Willison 在博客中寫到，光是 GitHub 官方的 MCP 就定義了 93 個工具，消耗 55000 個 Token。如果你像一些教程建議的那樣掛載 20 個 MCP Server，幾輪對話后上下文就爆了。

Anthropic 自己也承認(rèn)了這個問題。他們在博客里寫道，當(dāng) Agent 需要讀取一份兩小時會議的文檔時，可能要額外處理 50000 個 Token，更大的文檔甚至?xí)苯映錾舷挛拇翱谙拗疲麄€工作流直接崩潰。

Claude 的 Tokens 多貴大家是有目共睹的，加載太多 MCP，還沒生成內(nèi)容，錢就花出去很多了。

更致命的是，當(dāng) MCP 安裝過多時，模型開始犯蠢。

有開發(fā)者用 MCP 搭了個簡單計算器，結(jié)果模型調(diào)用減法工具后，明明服務(wù)器返回了 -9，它卻自作主張報了個 +9，沒有信任工具的返回值，而是用自己的常識替代了結(jié)果。

這種問題在工具少時幾乎不會出現(xiàn)，但當(dāng)上下文被塞滿各種工具定義后，模型的注意力被稀釋，開始胡亂推理。

如果說，結(jié)果錯誤最多浪費錢，但設(shè)計不安全的 MCP 還會造成不可逆的錯誤。有人掛載了文件系統(tǒng) MCP，AI 產(chǎn)生幻覺，把不該刪的代碼庫刪了。

早期 MCP 的權(quán)限設(shè)計過于粗放，掛一個文件系統(tǒng)往往意味著 AI 能讀寫整個磁盤，幾次事故后，大公司的安全部門迅速介入，搞白名單的消耗比傳統(tǒng) API 多。

MCP 多，模型智商下跌，裝的少，模型能力變少，這個悖論至今無解。

1

雙刃劍：門檻低了，但也太低了

MCP 的另一個問題是門檻太低。

搭建一個 MCP Server 實在太簡單了，幾十行代碼就能跑起來，于是人人都在做。這就導(dǎo)致了大量重復(fù)和低質(zhì)量的輪子。十個天氣查詢 MCP，可能九個半都是換皮復(fù)制，真正設(shè)計精良、維護(hù)活躍的屈指可數(shù)。

有論文研究了在近 1900 個 MCP Server 中，大量存在憑證暴露、缺乏維護(hù)等問題。生態(tài)看似繁榮，實則泡沫居多。

開發(fā)者面對琳瑯滿目的選項，反而要花更多時間甄別哪個能用、哪個靠譜，篩選成本甚至高過了自己寫一個。

1

Skills 上位，官方的隱性認(rèn)錯

從另一方來說，如果 MCP 真那么完美，為什么 Anthropic 自己都在“去 MCP 化”？

打開最新的官方文檔，Skills 被擺到了 C 位，而 MCP 越來越像是一個不得不保留的兼容層。潛臺詞很明確：別再迷信那個通用的 MCP 了，回來做定制化吧。

Skill 的本質(zhì)是對 MCP 的一次撥亂反正，也有人說這是給 MCP 擦屁股。它不再試圖讓模型實時去理解外部世界，而是把高頻的、經(jīng)過驗證的能力封裝成精簡的預(yù)設(shè)。對于編程、繪圖、網(wǎng)頁瀏覽這些核心能力，原生集成永遠(yuǎn)比走通用協(xié)議更快、更穩(wěn)、更省 Token。

Anthropic 最近發(fā)布的技術(shù)博客也在變相承認(rèn) MCP 的設(shè)計缺陷。他們提出了一個新思路：讓 Agent 寫代碼去調(diào)用 MCP，而不是直接暴露工具定義。據(jù)稱這種方式能減少 98.7%的 Token 消耗，這不就是在說 MCP 原來的用法是錯的嗎？

那個試圖用一套協(xié)議統(tǒng)一世界的宏大敘事，正在悄悄破產(chǎn)。

1

MCP、Skill，都只是過渡

當(dāng)我們跳出協(xié)議的細(xì)節(jié)，站在更長的時間軸上看，會發(fā)現(xiàn)一個更有意思的事實。

無論是試圖用 JSON 標(biāo)準(zhǔn)化世界的 MCP，還是試圖用預(yù)設(shè)封裝能力的 Skills，亦或是我們每天絞盡腦汁編寫的那些 Prompt，本質(zhì)上都是同一類東西：補丁。

它們是我們?yōu)榱藦浹a當(dāng)前 AI 智力不足而不得不打的補丁。

因為現(xiàn)在的 AI 還不夠聰明，不懂得即興發(fā)揮。所以我們需要 MCP 告訴它這是數(shù)據(jù)接口，需要 Skill 告訴它這是標(biāo)準(zhǔn)流程，需要 Prompt 告訴它這是注意事項。

我們在用確定性的工程手段，去試圖駕馭一個概率性的智能體。

想象一下真正強大的 ASI 出現(xiàn)的那一天。它還需要你寫一個 MCP Server 告訴它怎么查天氣嗎？不，它會自己打開瀏覽器看一眼。它不需要協(xié)議，因為它本身就是適配器。

MCP 涼了嗎？或許沒有徹底涼透。Anthropic 在路線圖里還在推進(jìn)遠(yuǎn)程連接、OAuth 認(rèn)證、企業(yè)級部署等功能，IBM 也宣布會向 MCP 社區(qū)貢獻(xiàn)企業(yè)級資產(chǎn)。它只是從網(wǎng)紅跌落回了基建。高頻能力歸 Skills，長尾數(shù)據(jù)歸 MCP，這大概就是它最終的生態(tài)位。

不再盲目地給 AI 堆工具了，而是開始思考，究竟哪幾個接口才是真正重要的，可能是 MCP 最大的貢獻(xiàn)。

點個“愛心”，再走 吧