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

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

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

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

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

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

1

MCP 為什么出道即巔峰

2024 年 MCP 發布之所以引發轟動，是因為它精準擊中了當時 AI 應用開發最大的痛點：開發者不得不重復造輪子。

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

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

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

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

1

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

MCP 最大的問題是，其調用方式是要占用上下文的。

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

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

Anthropic 自己也承認了這個問題。他們在博客里寫道，當 Agent 需要讀取一份兩小時會議的文檔時，可能要額外處理 50000 個 Token，更大的文檔甚至會直接超出上下文窗口限制，整個工作流直接崩潰。

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

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

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

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

如果說，結果錯誤最多浪費錢，但設計不安全的 MCP 還會造成不可逆的錯誤。有人掛載了文件系統 MCP，AI 產生幻覺，把不該刪的代碼庫刪了。

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

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

1

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

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

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

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

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

1

Skills 上位，官方的隱性認錯

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

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

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

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

那個試圖用一套協議統一世界的宏大敘事，正在悄悄破產。

1

MCP、Skill，都只是過渡

當我們跳出協議的細節，站在更長的時間軸上看，會發現一個更有意思的事實。

無論是試圖用 JSON 標準化世界的 MCP，還是試圖用預設封裝能力的 Skills，亦或是我們每天絞盡腦汁編寫的那些 prompt，本質上都是同一類東西：補丁。

它們是我們為了彌補當前 AI 智力不足而不得不打的補丁。

因為現在的 AI 還不夠聰明，不懂得即興發揮。所以我們需要 MCP 告訴它這是數據接口，需要 Skill 告訴它這是標準流程，需要 prompt 告訴它這是注意事項。

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

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

MCP 涼了嗎？或許沒有徹底涼透。Anthropic 在路線圖里還在推進遠程連接、OAuth 認證、企業級部署等功能，IBM 也宣布會向 MCP 社區貢獻企業級資產。它只是從網紅跌落回了基建。高頻能力歸 Skills，長尾數據歸 MCP，這大概就是它最終的生態位。

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

點個“愛心”，再走 吧