2024 年 11 月，由 Anthropic 公司發布的模型上下文協議 MCP（Model Context Protocol）—— 被稱為“AI 世界的 USB 接口”，如同一場颶風席卷全球。

在開源中國舉行的一場以為主題的直播中，我們既看到了一些業內共識，也聽到了很多不一樣的聲音。

MCP 成事實標準，短期不會被取代

MCP 已經被廣泛應用于多種 AI 工具中，包括 Claude、ChatGPT、Replit 和 Cursor 等，并且支持多種編程語言的 SDK（如 Python、TypeScript、Java、Kotlin 和 C#），進一步擴展了其應用范圍。根據全球最大的 MCP 服務器集合網站 MCP.so 的公開信息，已收錄的 MCP 服務器數量已超過 1.3 萬個。從當前發展態勢看，MCP 已然成為業界公認的事實標準。

“所謂協議標準的本質，不在于技術先進性，而在于行業共識。—— 當足夠多的參與者認可其價值，它自然成為標準。” 字節跳動技術專家劉康認為，MCP 的成功恰逢天時地利：背靠具有行業影響力的核心廠商，截至目前，OpenAI、Google 等頭部企業已明確表態接入其生態，這直接鞏固了其市場地位。

“短期內，不太可能再出現類似的協議來挑戰 MCP 的地位。”Gitee 公有云技術負責人羅雅新表示，MCP 協議誕生最初，就是要解決 AI Agent 調用各種工具時的碎片化問題 —— 因為現在不同工具、不同軟件都有自己的接口標準，甚至每個工具的說明書格式可能完全不一樣，得針對每個工具單獨做適配，相當于重復勞動。所以開發團隊初期參考了 LSP 這種已被驗證的標準 —— 就像編程語言工具通過統一協議集成各種編譯器，他們把這種思路遷移到 AI 領域。

有了 MCP ，就能給所有工具調用定義一套規范格式，讓 Agent 能更順暢地獲取資源、調用功能。因此，即使未來可能有新協議出現，本質上也都是沿著 “擴展 Agent 能力” 這條主線，最多在實現細節上優化（比如兼容性更強或性能更好），但底層邏輯不會變。

“這種標準化是必然趨勢。” 羅雅新指出：” 就像當年開發工具從各自為戰到通過 LSP 統一接口。當系統復雜度提升，Agent 需要對接的工具數量爆炸增長時，就必須有這種協議來打破混亂，這是技術演進的自然結果。”

MCP 整體設計還不錯，但結構偏復雜

就在這如日中天的發展態勢中，MCP 也在被不斷神化。所以，現在流行一個說法， 叫萬物皆可 MCP。

“MCP 協議被提及得非常多，大家對他的預期，超出了他本身定義的范圍。” 劉康認為，大眾認知與技術圈理解存在明顯偏差：技術社區清楚 MCP 本質是定義智能體（agent）與外部工具資源（tool resource）間的交互協議，而大眾討論中卻賦予其超出設計范疇的期待。實際上，該協議僅聚焦于標準化連接接口，但輿論場中常被誤解為能解決智能體生態的所有問題。

在常高偉看來，雖然 MCP 整體設計還不錯 —— 例如服務端的三個核心概念（資源、工具、提示詞）設計合理，但協議結構確實偏復雜，比如客戶端支持 root 權限同時，開放采樣能力，將客戶端 AI 能力賦予服務端。

“我其實并未完全理解這個設計邏輯。首先，采樣功能因缺乏典型應用場景呈現過度設計傾向；其次，實現度也存在疑問 —— 即便是 Cloud 客戶端的采樣支持都尚未落地，更遑論完整的服務端能力遷移。推測他們在設計時可能設想過這個功能要怎么用。” 常高偉是智能體協議 ANP 的作者。MCP 最早發布時，并沒有身份鑒權機制，常高偉等人還向 MCP 提供了自己設計的 DID 提案。

最近，MCP 的 SSE 模式做了調整，常高偉認為這一改進不錯。新方案采用“”機制，提升兼容性并實現無狀態化。“總之協議設計的精髓在于用簡單方案解決專門問題，過度復雜的設計反而會影響其生命周期。”

MCP 需要做減法

在完整研讀了 MCP 協議文檔并進行實踐驗證 —— 開發了實現 MCP 服務器接口的通用數據庫網關 DBHub 之后，Bytebase CEO 陳天舟產生了一些困惑。“它做的事情不夠純粹 —— 一方面它涉及數據獲取層面的功能，另一方面又介入到應用層的實現。MCP 在技術社區里也存在爭議：究竟該定位為 Agent 開發框架，還是作為通用數據接口。”

尤其實在 Google 推出的智能體通信協議 A2A 之后，更加暴露出了這一問題。盡管 A2A 協議更側重于應用層規范，但其部分功能確實與 MCP 存在重疊。

“MCP 需要做減法，應該專注于成為純粹的信息獲取原子能力接口，而非像其路線圖中提到的 agent 開發方向。” 陳天舟認為，MCP 的發展前景將取決于開發團隊的戰略聚焦。如果 MCP 堅持向 Agent 領域延伸，其發展前景不容樂觀。反之，若能聚焦于構建標準化的信息獲取接口，MCP 將具有強大的生命力。“就像當前應用系統訪問數據庫時都需要 DAL（數據訪問層），MCP 完全可以占據類似的‘基礎能力層’生態位。但若試圖向更高層抽象發展，則存在較大的不確定性。”

常高偉也認可這一觀點：“MCP 專注在模型連接工具和資源上才會有更好的發展。如果既想解決這個問題，又要解決那個問題，可能不是個好方案。”

常高偉指出，協議越做越復雜，會導致使起來比較困難。另外，MCP 發展到現在，應用規模已相當可觀，已經成為模型連接工具和資源領域的事實標準。“從全球來看，整個行業不會再出現第二個 MCP 了。除非 MCP 既想做智能體層又想涉及應用層，那可能將這一優勢地位拱手相讓。”

Gitee 私有云產品總監林靖靖認為，就現階段而言，MCP 的先發優勢確實存在，但這不意味著它會一帆風順。“作為連接 agent 與 tools 的協議，當前外界對 MCP 的期望過高。接下來是否順利，關鍵在于 MCP 能否快速演進并補足短板。一個較有可能的發展路徑是：MCP 被新協議逼退到專精某個細分領域，而其他功能被新協議瓜分。”

【數智漫談】

OSCHINA 視頻號直播暢聊欄目【數智漫談】，每期一個技術話題，三五位專家圍坐，各抒己見，暢聊開源。給大家帶來最新的行業前沿、最熱門的技術話題、最有趣的開源項目、最犀利的思想交鋒。如果你手上也有新點子、好項目，想要跟同行交流分享，歡迎聯系我們，講壇隨時開放～