一文讀懂MCP與AI工具生態的未來，它會是AI智能體的「萬能插頭」嗎？

選自 a16z.com

作者：Yoko Li

編譯：凱文、2049

如今，隨著基礎模型變得越來越智能，人們越來越需要有一個用於執行、數據獲取和工具調用的標準接口。

自 OpenAI 在 2023 年發佈函數調用功能以來，AI 智能體與外部工具、數據和 API 的交互能力卻日益碎片化：開發者需要為智能體在每個系統中的操作和集成實現特定的業務邏輯。

顯然，執行、數據獲取和工具調用需要一個標準接口。API 曾是互聯網的第一個偉大統一者——為軟件之間的通信創造了一種共享語言，但 AI 模型卻缺乏類似的機制。

2024 年 11 月 Anthropic 推出的模型上下文協議（Model Context Protocol，簡稱 MCP），在開發者和 AI 社區中迅速獲得了廣泛關注，被視為一種潛在的解決方案。

近日，全球知名投資機構 a16z 發佈了一篇博客文章，深度介紹了 MCP 以及 AI 工具生態的未來。

博客鏈接：https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

本文將深入探討 MCP 是什麼，它如何改變 AI 與工具的交互方式，開發者已經用它構建了哪些應用，以及仍需解決的挑戰。

讓我們跟隨博客一探究竟。

MCP 是什麼？

MCP（Model Context Protocol，模型上下文協議）是一種開放協議，它允許系統以可泛化的方式為 AI 模型提供上下文信息，從而跨越不同集成場景實現通用性。該協議定義了 AI 模型如何調用外部工具、獲取數據以及與服務交互。舉個具體的例子，以下展示了 Resend MCP 服務器如何與多個 MCP 客戶端協同工作。

這一理念並非創新，MCP 從語言服務器協議（LSP）中汲取了靈感。在 LSP 中，當用戶在編輯器中輸入時，客戶端會向語言服務器查詢以獲取自動補全建議或診斷信息。

而 MCP 超越 LSP 的地方在於其以智能體為中心的執行模型：LSP 主要是被動的（基於用戶輸入響應 IDE 的請求），而 MCP 則旨在支持自主的 AI 工作流。根據上下文，AI 智能體可以決定使用哪些工具、以什麼順序使用，以及如何將它們串聯起來以完成任務。

此外，MCP 還引入了人機協作能力，允許人類提供額外數據並批準執行。

當前熱門應用場景

通過使用合適的 MCP 服務器，用戶可以將每一個 MCP 客戶端變成「萬能應用」。

我們以 Cursor 為例：雖然 Cursor 本質上是一個代碼編輯器，但它也是一個功能強大的 MCP 客戶端。終端用戶可以通過 Slack MCP 服務器將其變成 Slack 客戶端，通過 Resend MCP 服務器將其變成郵件發送器，使用 Replicate MCP 服務器將其變為圖像生成器。

利用 MCP 的更強大方法是在一個客戶端上安裝多個服務器以解鎖新流程：用戶可以安裝服務器以從 Cursor 生成前端 UI，也可以要求智能體使用圖像生成 MCP 服務器為站點生成主頁橫幅。

當然，除了 Cursor 以外，當前的應用場景大致可以分為兩類：以開發者為中心、本地優先的工作流，以及基於 LLM 客戶端的全新體驗。

以開發者為中心的工作流

對於開發者來說，一個普遍的願望是：「我不想離開我的 IDE 去完成某件事」。MCP 服務器正是實現這一夢想的絕佳方式。

基於 MCP 服務器，開發者不再需要切換到 Supabase 來檢查數據庫狀態，而是可以直接在 IDE 中使用 Postgres MCP 服務器執行只讀 SQL 命令，或通過 Upstash MCP 服務器創建和管理緩存索引。在迭代代碼時，開發者還可以利用 Browsertools MCP 服務器，讓編程智能體訪問實時環境，獲取反饋並進行調試。

Cursor 智能體使用 Browsertools 訪問控制台日誌和其他實時數據並更有效地進行調試的示例。

如上圖所示，Cursor 智能體可以通過 Browsertools 訪問控制台日誌和其他實時數據，從而更高效地進行調試。

除了與開發工具交互的工作流，MCP 服務器還解鎖了一種全新的應用場景：通過爬取網頁或基於文檔自動生成 MCP 服務器，為編碼智能體提供高度準確的上下文信息。開發者無需手動配置集成，而是可以直接從現有文檔或 API 中快速啟動 MCP 服務器，使 AI 智能體能夠即時訪問這些工具。這意味著更少的時間花在樣板代碼上，更多的時間用於實際使用工具 —— 無論是拉取實時上下文、執行命令，還是動態擴展 AI 助手的能力。

全新體驗

Cursor 等 IDE 並不是唯一可用的 MCP 客戶端，對於非技術用戶來說，Claude Desktop 是一個極好的切入點，它使 MCP 驅動的工具更易於普通用戶使用。很快，我們可能會看到專門的 MCP 客戶端出現，用於以業務為中心的任務，例如客戶支持、營銷文案、設計和圖像編輯，因為這些領域與 AI 在模式識別和創意任務方面的優勢密切相關。

MCP 客戶端的設計及其支持的特定交互在塑造其功能方面起著至關重要的作用。例如，聊天應用不太可能包含矢量渲染畫布，就像設計工具不太可能提供在遠程機器上執行代碼的功能一樣。最終，MCP 客戶端體驗定義了整體 MCP 用戶體驗 —— 而對於 MCP 的體驗，我們還有更多東西需要解鎖。

一個典型的例子是 Highlight 如何通過實現「@」命令來調用其客戶端上的任何 MCP 服務器。這創造了一種全新的用戶體驗模式，即 MCP 客戶端可以將生成的內容直接導入到任何下遊應用中。

Highlight 實現 Notion MCP（插件）

另一個例子是 Blender MCP 服務器的用例：現在，幾乎不瞭解 Blender 的業餘用戶可以用自然語言描述他們想要構建的 3D 模型。隨著社區為 Unity 和 Unreal 引擎等其他工具實現服務器，我們正在實時見證「文本到 3D」工作流的落地。

使用 Claude Desktop 與 Blender MCP 服務器的示例

雖然我們主要關注服務器和客戶端，但隨著協議的發展，MCP 生態系統正在逐步成型。當前的市場地圖覆蓋了最活躍的領域，但仍有許多空白。考慮到 MCP 仍處於早期階段，我們期待隨著市場的演變和成熟，將更多參與者加入這張地圖。（我們將在下一部分探討其中的一些未來可能性。）

在 MCP 客戶端方面，目前我們看到的高質量客戶端大多以編程為中心。這並不令人意外，因為開發者通常是新技術的早期採用者。但隨著協議的成熟，我們預計會看到更多以業務為中心的客戶端出現。

在 MCP 服務器方面，目前大多數服務器都以本地優先為主，專注於單一功能。這是由於 MCP 目前僅支持基於 SSE 和命令的連接。然而，隨著生態系統將遠程 MCP 提升為首要支持對象，並採用可流式 H湯臣P 傳輸，我們預計會看到更多的 MCP 服務器被廣泛採用。

此外，一波新的 MCP 市場和服務託管解決方案正在湧現，使 MCP 服務器的發現成為可能。像 Mintlify 的 mcpt、Smithery 和 OpenTools 這樣的市場，正在讓開發者更容易發現、分享和貢獻新的 MCP 服務器 —— 就像 npm 徹底改變了 JavaScript 的包管理，或 RapidAPI 擴展了 API 的發現一樣。這一層對於標準化訪問高質量 MCP 服務器至關重要，使 AI 智能體能夠動態選擇和集成所需工具。

隨著 MCP 的普及，基礎設施和工具將在使生態系統更具可擴展性、可靠性和可訪問性方面發揮關鍵作用。像 Mintlify、Stainless 和 Speakeasy 這樣的服務器生成工具正在減少創建 MCP 兼容服務的摩擦，而像 Cloudflare 和 Smithery 這樣的託管解決方案則正在解決部署和擴展的挑戰。與此同時，像 Toolbase 這樣的連接管理平台正在開始簡化本地優先 MCP 的密鑰管理和智能體。

未來可能性

智能體原生架構（agent-native architecture）的發展仍處於萌芽階段。儘管業界已經對 MCP 展現出極大熱情，但構建和部署 MCP 過程中仍面臨諸多亟待解決的技術難題。協議在下一輪迭代中需要重點突破的領域包括：

託管與多租戶

MCP 支持 AI 智能體與其工具之間的一對多關係，但多租戶架構（例如 SaaS 產品）需要支持多用戶同時訪問共享的 MCP 服務器。近期解決方案可能是預設採用遠程服務器，使 MCP 服務器更易於訪問，但許多企業同樣希望能夠託管自己的 MCP 服務器並實現數據面和控製麵的分離。

為促進 MCP 的廣泛採用，下一個關鍵要素是開發簡化的工具鏈，用於支持規模化的 MCP 服務器部署和維護。

認證

MCP 目前尚未定義客戶端與服務器之間認證的標準機制，也沒有提供框架說明 MCP 服務器在與第三方 API 交互時應如何安全地管理和委託認證。目前，認證問題留給各個實現和部署場景自行解決。在實踐中，MCP 的應用主要集中在不需要顯式認證的本地集成場景。

更完善的認證範式可能是推動遠程 MCP 廣泛採用的關鍵突破點之一。從開發者視角，統一的認證方法應包括：

• 客戶端認證：用於客戶端-服務器交互的標準方法，如 OAuth 或 API 令牌

• 工具認證：用於第三方 API 認證的輔助函數或包裝器

• 多用戶認證：適用於企業部署的租戶感知式認證機制

授權 

即使工具已通過認證，我們仍需考慮誰應被允許使用它，以及如何精細劃分用戶權限。MCP 缺乏內置的權限模型，導致訪問控制僅限於會話級別 —— 即工具要麼可訪問，要麼完全受限。雖然未來可能會出現更精細的授權機制，但目前的方法依賴基於 OAuth 2.1 的授權流程，一旦認證成功即授予整個會話的訪問權限。隨著智能體和工具數量增加，系統複雜性隨之提高 —— 每個智能體通常需要獨立會話和唯一授權憑證，造成基於會話的訪問管理網絡不斷擴大。

網關

隨著 MCP 採用規模的擴大，網關可作為集中化層，負責認證、授權、流量管理和工具選擇。與 API 網關類似，它將執行訪問控制、將請求路由到適當的 MCP 服務器、處理負載均衡，並緩存響應以提高效率。這在多租戶環境中尤為重要，因為不同用戶和智能體需要不同權限級別。標準化網關將簡化客戶端 – 服務器交互，增強安全性，並提供更好的可觀測性，使 MCP 部署更具可擴展性和可管理性。

MCP 服務器的可發現性和可用性

目前，查找和設置 MCP 服務器仍是一個手動過程。開發者需要定位端點或腳本、配置認證，並確保服務器與客戶端之間的兼容性。集成新服務器不僅耗時較長，而且 AI 智能體無法動態發現或適應可用的服務器。

不過，根據 Anthropic 上個月在 AI 工程師大會上的演講，他們似乎正在開發一套 MCP 服務器註冊表 (server registry) 和發現協議 (discovery protocol)。這項技術可能將為 MCP 服務器的應用推廣開啟嶄新階段。

執行環境 

大多數 AI 工作流程需要按順序執行多個工具調用，但 MCP 缺乏內置的工作流概念來管理這些步驟。要求每個客戶端都實現可恢復性和可重試性是不理想的。儘管目前開發者正在嘗試使用 Inngest 等解決方案來實現這一功能，但將有狀態執行提升為一級概念將能為大多數開發者簡化執行模型。

標準客戶端體驗 

開發者社區經常提出的一個問題是：在構建 MCP 客戶端時如何考慮工具選擇 —— 是否每個開發者都需要為工具實現自己的 RAG，還是有一個等待標準化的層？

 除了工具選擇外，目前還沒有統一的工具調用 UI/UX 模式（從斜杠命令到純自然語言的各種方式都存在）。一個用於工具發現、排序和執行的標準客戶端層可以幫助創建更可預測的開發者和用戶體驗。

調試

MCP 服務器的開發者經常發現，讓同一個 MCP 服務器輕鬆地跨客戶端工作是很睏難的。通常情況下，每個 MCP 客戶端都有自己的特性，而客戶端跟蹤要麼缺失要麼難以找到，這使得調試 MCP 服務器成為一項極其困難的任務。隨著越來越多遠程優先的 MCP 服務器被構建，需要一套新的工具來使開發體驗在本地和遠程環境中更加流暢。

AI 工具的影響

MCP 的開發體驗讓人聯想到 2010 年代的 API 開發。這種範式雖然新穎且令人興奮，但其工具鏈仍處於早期階段。如果展望幾年後，假設 MCP 成為 AI 驅動工作流的事實標準，會發生什麼？以下是一些預測：

• 以開發者為中心的公司競爭優勢將從最佳 API 設計轉向提供最優工具集。若 MCP 能自主發現工具，API 提供商需確保其工具易於被發現，並具備差異化特性，使智能體能為特定任務選擇它們。

• 當每個應用都成為 MCP 客戶端、每個 API 都成為 MCP 服務器時，將出現新定價模式：智能體會基於速度、成本和相關性動態選擇工具。這可能使工具採用過程更市場化，優先選擇性能最佳和模塊化的工具。

• 文檔將成為 MCP 基礎設施的關鍵，企業需設計具有清晰、機器可讀格式的工具和 API，使 MCP 服務器成為基於現有文檔的事實性產物。

• 僅有 API 還不夠，但可作為良好起點。工具與 API 的映射很少是一對一關係。工具是更高層次的抽像，智能體可能選擇包含多個 API 調用以最小化延遲的函數。MCP 服務器設計將以場景和用例為中心。

• 若軟件預設成為 MCP 客戶端，將出現新的託管模式。每個客戶端本質上都是多步驟的，需要可恢復性、重試和長時間運行任務管理。託管提供商需跨不同 MCP 服務器進行實時負載均衡，優化成本與性能。

MCP 正在重塑 AI 智能體生態系統，而下一階段的發展將取決於如何應對其基礎性挑戰。若實施得當，MCP 有望成為 AI 與工具交互的標準接口，並開創自主、多模態且深度整合的新一代 AI 體驗。

如果 MCP 獲得廣泛應用，它將從根本上改變工具的構建、使用和商業化方式。業內專家正密切關注市場將如何引導 MCP 的發展方向。

今年將是決定性的一年：我們是否會看到統一的 MCP 市場崛起？AI 智能體的身份驗證是否能實現無縫對接？多步驟執行能否被正式納入協議標準？