深入理解 MCP 與 AI 工具生態的未來

本文作者是 Yoko Li，Andreessen Horowitz 合夥人，專注於企業及基礎設施領域。

自從 OpenAI 在 2023 年發佈了 function calling 功能後，我一直在思考如何才能真正解鎖一個以代理（agent）與工具爲中心的生態系統。隨着基礎模型的日益智能化，AI 代理對外部工具、數據和 API 的交互能力越來越分散：開發者不得不針對每個系統定製特殊的業務邏輯，才能讓代理完成在不同系統間的操作與整合。

顯而易見，我們需要一個標準化的接口，用於執行指令、獲取數據以及調用工具。在互聯網早期，API 曾是軟件之間通信的統一語言；但在 AI 領域，我們還缺少一個對應的標準。

自 2024 年 11 月發佈以來，Model Context Protocol（MCP）迅速在開發者和 AI 社區中獲得了廣泛關注，成爲解決上述問題的潛在方案。本文將探討什麼是 MCP，爲什麼它會改變 AI 與工具的交互方式，如今開發者如何使用它，以及仍亟待解決的挑戰。

讓我們開始吧。

什麼是 MCP？

MCP 是一個開放協議，允許各種系統以一種可泛化的方式向 AI 模型提供上下文。它定義了 AI 模型如何調用外部工具、獲取數據以及與服務進行交互。例如，下面展示了 Resend MCP 服務器與多個 MCP 客戶端的協同工作方式：

這種思路並不新穎；MCP 的靈感源於 LSP（Language Server Protocol）。在 LSP 中，當用戶在編輯器中輸入時，客戶端會向語言服務器請求自動補全或診斷信息。

MCP 相較於 LSP 的延伸在於：它採用了 “以代理爲中心” 的執行模型。LSP 主要是被動的（根據用戶輸入和 IDE 的請求進行響應），而 MCP 支持自主的 AI 工作流。基於給定的上下文，AI 代理可以自由決定使用哪些工具、以怎樣的順序調用它們，以及如何將這些調用串聯起來完成任務。MCP 還引入了 “人類介入” 環節，允許人在必要時提供額外數據並審批執行流程。

當下的主流應用場景

只要擁有適配的 MCP 服務器，用戶就可以將每一個 MCP 客戶端變成一個 “全能應用（everything app）”。

以 Cursor 爲例：雖然 Cursor 是一個代碼編輯器，但它同時也是一個實現完善的 MCP 客戶端。通過安裝 Slack MCP 服務器，它可以變成一個 Slack 客戶端；通過安裝 Resend MCP 服務器，它可以發送郵件；通過安裝 Replicate MCP 服務器，它可以生成圖像。更強大的是在一個客戶端上安裝多個 MCP 服務器來解鎖組合式任務：用戶可以安裝一個服務器來生成前端界面，同時讓代理調用圖像生成的 MCP 服務器爲網站生成一個英雄圖。

除了 Cursor，當下的大多數用例大致可分爲兩類：面向開發者的本地化工作流和利用 LLM 客戶端構建的新型體驗。

1. 面向開發者的工作流

對每天都沉浸在寫代碼的開發者來說，“我不想離開我的 IDE 去做 X 事情” 是一種常見的心聲。MCP 服務器爲這種需求提供了強力支持。

例如，開發者無需再切換到 Supabase 界面檢查數據庫狀態，可以直接通過 Postgres MCP 服務器在 IDE 中執行只讀 SQL 命令；也可以利用 Upstash MCP 服務器創建和管理緩存索引。編寫代碼時，開發者還能結合使用 Browsertools MCP，爲 AI 代理提供實時環境訪問權限，以獲取控制檯日誌和調試信息。

Cursor 代理如何使用 Browsertools 訪問控制檯日誌和其他實時數據並更高效調試的示例。

除此之外，MCP 服務器還可以爲開發者提供高度準確的代碼上下文。例如，通過抓取某個網頁，或根據文檔自動生成相應的 MCP 服務器，就可以讓 AI 代理即時獲得所需的外部工具。這意味着開發者可以減少寫樣板代碼的時間，把精力集中在實際使用這些工具上——無論是獲取實時上下文、執行命令，還是爲 AI 助手隨時擴充新能力。

2. 新型應用體驗

不僅 IDE（如 Cursor）可以成爲 MCP 客戶端，雖然它們在技術人羣中關注度更高，但面向大衆用戶的客戶端同樣也在崛起。比如，對於非技術用戶而言，Claude Desktop 就是一個友好易用的入口，讓更多人能輕鬆使用基於 MCP 的工具。接下來，我們也很可能看到專門針對客戶支持、營銷文案、設計和圖像編輯等業務場景的 MCP 客戶端出現——這些領域與 AI 擅長的模式識別和創意寫作天然契合。

MCP 客戶端的設計以及支持的交互模式，在很大程度上決定了它的功能邊界。比如，一個聊天應用通常不會提供矢量繪圖畫布，而設計工具也不太可能讓你遠程執行代碼。因此，MCP 客戶端的體驗決定了最終用戶與 MCP 交互的體驗，而在這個層面上，我們還有大量創新空間未被探索。

一個有趣的例子是 Highlight 實現的 “@命令”，用來調用其客戶端所安裝的任何 MCP 服務器。這樣一來，MCP 客戶端就能將生成的內容傳輸到任意下游應用中。

Highlight 實現 Notion MCP（插件）的一個示例。

另一個例子是使用 Blender MCP 服務器：即使是對 Blender 基本操作都不熟悉的新手，也能用自然語言描述自己想要創建的 3D 模型。我們正目睹 text-to-3D 工作流的興起，社區也在爲 Unity、Unreal Engine 等工具實現類似的 MCP 服務器。

_使用 Claude Desktop 與 _Blender MCP 服務器__的示例。

雖然我們常提到 “服務器” 和“客戶端”，但隨着協議的演進，MCP 生態系統正在逐步成形。下圖展示了目前最活躍的領域（當然仍有許多空白），隨着 MCP 逐漸成熟，我們期待看到更多新玩家的加入。（我們也將在下一章節探討 MCP 潛在的更多可能性。）

市場地圖示意圖

就 MCP 客戶端而言，如今大部分高質量的客戶端依舊以代碼開發爲核心，這不足爲奇——開發者往往是新技術的早期採用者。但隨着協議完善，也必然會出現更多聚焦商業場景的客戶端。

大多數現有的 MCP 服務器都偏向 “本地優先”，並且大多由單個開發者或團隊製作。這主要是因爲當前 MCP 僅支持基於 SSE 和命令式的連接方式。然而，我們相信，隨着遠程 MCP 成爲第一公民，以及 MCP 逐漸採用可流式傳輸的 HTTP 傳輸方式，整個生態的服務器也會越來越豐富。

與此同時，一批新的 MCP 市場和服務器託管解決方案正在崛起，推動 MCP 服務器的發現與分發。像 Mintlify 的 mcpt、Smithery、OpenTools 之類的市場平臺正在爲開發者提供更便捷的方式去發現、分享並貢獻新的 MCP 服務器——類似當年 npm 之於 JavaScript 包管理或 RapidAPI 之於 API 發現。這層市場化對於標準化高質量 MCP 服務器的獲取至關重要，也將讓 AI 代理能動態選擇並集成所需工具。

隨着 MCP 的進一步普及，基礎設施與開發工具鏈對可擴展性、可靠性與可訪問性將至關重要。Mintlify、Stainless、Speakeasy 等服務器生成工具正在簡化創建 MCP 兼容服務的過程；而 Cloudflare 和 Smithery 等託管服務則嘗試解決部署與擴容問題。同時，像 Toolbase 這樣的連接管理平臺也開始着手簡化本地 MCP 的密鑰管理與代理等流程。

未來的可能性

需要指出的是，我們仍處於代理原生（agent-native）架構發展的早期階段。雖然 MCP 如今廣受追捧，但使用 MCP 開發並上線仍面臨衆多未解難題。

以下是 MCP 協議下一階段可能需要解鎖的一些關鍵問題：

1. 託管與多租戶（multi-tenancy）

MCP 支持 “一個 AI 代理對多工具” 的場景，但多租戶架構（如 SaaS 產品）卻要求 “多個用戶對同一個 MCP 服務器” 的高併發支持。默認採用遠程服務器也許是短期內讓 MCP 服務器觸達更廣用戶的一種辦法，但很多企業依然希望在自己的環境中部署 MCP 服務器，並將數據平面和控制平面獨立分開。

要大規模地部署並維護 MCP 服務器，需要一個成熟的工具鏈，這也是廣泛普及的下一個關鍵環節。

2. 認證（Authentication）

MCP 當前並未定義標準的身份認證機制，也沒有規範如何在與第三方 API 交互時安全管理和委派授權。現階段，身份認證通常由各自的實現和部署場景自行解決。實際上，目前 MCP 在本地集成場景中使用較多——而這類場景往往對身份認證的需求不算強。

若要真正普及遠程 MCP，就需要一個更完善的認證範式。對開發者而言，一個統一的認證方法應包含：

3. 授權（Authorization）

即便工具完成了認證，誰有權使用它？使用權限的粒度有多細？MCP 尚未內置權限模型，目前的訪問控制幾乎都在會話層——工具要麼可訪問，要麼完全被禁止。雖然將來可能會有更細粒度的權限控制機制，但目前常見的做法是基於 OAuth 2.1 的授權流程，一旦通過認證，整個會話就擁有該工具的訪問權。

隨着代理數量和工具數量的持續增加，這種會話級別的訪問管理變得愈加複雜。目前，每個代理通常需要獨立的會話和授權憑證，形成一張不斷擴大的訪問管理網絡。

4. Gateway（網關）

當 MCP 應用規模擴大後，**可能需要一個網關層來集中處理身份認證、授權、流量管理以及工具選擇。**類似傳統的 API 網關，這個網關可以執行訪問控制，將請求路由到正確的 MCP 服務器，並進行負載均衡和緩存。對於多租戶環境來說，這點尤爲重要，不同用戶和代理往往需要不同的權限。一個標準化的網關能夠簡化客戶端與服務器的交互，增強安全性，並且提供更好的可觀測性，令 MCP 部署更容易擴展和管理。

5. MCP 服務器的可發現性（discoverability）與可用性

目前，要找到並設置 MCP 服務器依然比較繁瑣：開發者需要定位相關端點或腳本，配置認證，並確保服務器與客戶端兼容。集成新服務器費時費力，AI 代理無法動態發現或適配可用的服務器。

但從上個月 Anthropic 在 AI 工程師大會上的演講來看，他們正在籌備 MCP 服務器註冊表和發現協議。若能順利推出，這極可能成爲 MCP 大規模普及的下一個關鍵節點。

6. 執行環境

大部分 AI 工作流需要依次調用多個工具，但 MCP 並未內置 “工作流” 概念來管理這些調用步驟。若要求每個客戶端都自己實現可恢復（resumability）和可重試（retryability）的機制，難免增加複雜度。雖然目前有開發者在嘗試用 Inngest 等第三方方案，但如果能將有狀態執行升級爲 MCP 協議的核心概念，將大大簡化大多數開發者的執行模型。

7. 標準化的客戶端體驗

來自開發者社區的一個常見問題是：在構建 MCP 客戶端時，如何思考 “工具選擇” 這件事？每個人都需要自己實現一套基於檢索增強生成（RAG）的工具選型邏輯嗎？還是說這塊邏輯有機會被標準化？

不僅如此，業界也缺乏統一的 UI/UX 模式去調用工具（有些是斜線命令，有些是純自然語言觸發）。若能在客戶端層面實現統一的工具發現、排序與執行能力，開發者與用戶都能獲得更一致的體驗。

8. 調試（Debugging）

很多 MCP 服務器開發者都發現：要讓同一個 MCP 服務器在不同客戶端上正常工作，其實並不容易。大多數 MCP 客戶端都有各自的實現細節，客戶端側的調試信息往往缺失或難以獲取，**導致調試過程異常艱難。**隨着更多 MCP 服務器開始 “遠程化”，我們需要一整套新的工具來簡化本地與遠程環境下的開發體驗。

AI 工具生態的影響

MCP 的開發者體驗讓我想起 2010 年代的 API 開發。概念雖新且令人興奮，但周邊工具鏈依然處於初期。如果展望數年之後，假設 MCP 真的成爲 AI 驅動工作流的事實標準，會發生什麼呢？以下是一些可能的趨勢預測：

  1. 開發者導向型公司的競爭優勢將從 “最好的 API 設計” 演變到“最好的工具集合”。如果 MCP 能讓代理自動發現工具，那麼 API 或 SDK 提供商需要保證他們的工具能被輕鬆檢索，並且在同類任務中表現出色，足以讓代理選用。而且這將比人類開發者挑選更精細和即時。

  2. 如果每個應用都成爲 MCP 客戶端，而每個 API 都成爲 MCP 服務器，我們可能會看到全新的定價模式：代理會基於速度、成本和相關性動態選擇工具。這種更加市場化的採納方式會讓最 “好用” 的工具快速脫穎而出，打破只因用戶基數或歷史慣性而佔主導的局面。

  3. 文檔將成爲 MCP 基礎設施中的關鍵一環。公司需要提供機器可讀（例如 llms.txt）的工具與 API 規範，並根據已有文檔默認輸出 MCP 服務器，這樣 AI 才能迅速理解並使用這些功能。

  4. API 不再是終點，而只是起點。開發者會逐漸意識到，API 和工具的映射並非一一對應。工具是一種更高層的抽象，它根據任務場景做出最優調用組合 —— 例如，代理調用 draft_email_and_send() 可能包含多個底層 API 調用，但卻能大幅降低延遲。MCP 服務器的設計會更多地聚焦於具體場景和用例，而不是單純的 API 封裝。

  5. 如果每個軟件默認都是 MCP 客戶端，那麼託管方式也會發生演變。工作負載的特徵與傳統網站有極大差異。每個客戶端都可能需要多步執行，還需支持可恢復、可重試和長時間任務管理。託管商也需要對不同 MCP 服務器進行實時負載均衡，以兼顧成本、延遲和性能，從而讓 AI 代理能動態選擇最優工具。

MCP 已經在重塑 AI 代理生態；下一波進展的關鍵，將在於我們如何解決這些基礎性的挑戰。若能讓 MCP 成爲 AI 與工具交互的默認接口，就有可能催生新一代具有自主性、多模態和深度集成的 AI 體驗。

如果 MCP 得到廣泛採用，工具的構建、使用與商業模式都將被深刻重塑。我們對未來充滿期待，尤其是今年——這是關鍵之年：統一的 MCP 市場會不會崛起？AI 代理的身份認證會不會變得無縫？多步執行能否寫進協議？

如果你正在這個領域創業，或對其未來形態有想法，歡迎隨時與我聯繫。現在正是大展拳腳的時候！

作者：Yoko Li，翻譯：若飛

來源：a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Yr11ylltkCAbKKC_ki8qpg

猜你喜歡