如今，隨著基礎(chǔ)模型變得越來越智能，人們越來越需要有一個用于執(zhí)行、數(shù)據(jù)獲取和工具調(diào)用的標準接口。

自 OpenAI 在 2023 年發(fā)布函數(shù)調(diào)用功能以來，AI 智能體與外部工具、數(shù)據(jù)和 API 的交互能力卻日益碎片化：開發(fā)者需要為智能體在每個系統(tǒng)中的操作和集成實現(xiàn)特定的業(yè)務(wù)邏輯。

顯然，執(zhí)行、數(shù)據(jù)獲取和工具調(diào)用需要一個標準接口。API 曾是互聯(lián)網(wǎng)的第一個偉大統(tǒng)一者——為軟件之間的通信創(chuàng)造了一種共享語言，但 AI 模型卻缺乏類似的機制。

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

近日，全球知名投資機構(gòu) a16z 發(fā)布了一篇博客文章，深度介紹了 MCP 以及 AI 工具生態(tài)的未來。

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

本文將深入探討 MCP 是什么，它如何改變 AI 與工具的交互方式，開發(fā)者已經(jīng)用它構(gòu)建了哪些應(yīng)用，以及仍需解決的挑戰(zhàn)。

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

MCP 是什么？

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

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

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

此外，MCP 還引入了人機協(xié)作能力，允許人類提供額外數(shù)據(jù)并批準執(zhí)行。

當前熱門應(yīng)用場景

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

我們以 Cursor 為例：雖然 Cursor 本質(zhì)上是一個代碼編輯器，但它也是一個功能強大的 MCP 客戶端。終端用戶可以通過 Slack MCP 服務(wù)器將其變成 Slack 客戶端，通過 Resend MCP 服務(wù)器將其變成郵件發(fā)送器，使用 Replicate MCP 服務(wù)器將其變?yōu)閳D像生成器。

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

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

以開發(fā)者為中心的工作流

對于開發(fā)者來說，一個普遍的愿望是：「我不想離開我的 IDE 去完成某件事」。MCP 服務(wù)器正是實現(xiàn)這一夢想的絕佳方式。

基于 MCP 服務(wù)器，開發(fā)者不再需要切換到 Supabase 來檢查數(shù)據(jù)庫狀態(tài)，而是可以直接在 IDE 中使用 Postgres MCP 服務(wù)器執(zhí)行只讀 SQL 命令，或通過 Upstash MCP 服務(wù)器創(chuàng)建和管理緩存索引。在迭代代碼時，開發(fā)者還可以利用 Browsertools MCP 服務(wù)器，讓編程智能體訪問實時環(huán)境，獲取反饋并進行調(diào)試。

Cursor 智能體使用 Browsertools 訪問控制臺日志和其他實時數(shù)據(jù)并更有效地進行調(diào)試的示例。

如上圖所示，Cursor 智能體可以通過 Browsertools 訪問控制臺日志和其他實時數(shù)據(jù)，從而更高效地進行調(diào)試。

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

全新體驗

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

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

一個典型的例子是 Highlight 如何通過實現(xiàn)「@」命令來調(diào)用其客戶端上的任何 MCP 服務(wù)器。這創(chuàng)造了一種全新的用戶體驗?zāi)Ｊ?，?MCP 客戶端可以將生成的內(nèi)容直接導(dǎo)入到任何下游應(yīng)用中。

Highlight 實現(xiàn) Notion MCP（插件）

另一個例子是 Blender MCP 服務(wù)器的用例：現(xiàn)在，幾乎不了解 Blender 的業(yè)余用戶可以用自然語言描述他們想要構(gòu)建的 3D 模型。隨著社區(qū)為 Unity 和 Unreal 引擎等其他工具實現(xiàn)服務(wù)器，我們正在實時見證「文本到 3D」工作流的落地。

使用 Claude Desktop 與 Blender MCP 服務(wù)器的示例

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

在 MCP 客戶端方面，目前我們看到的高質(zhì)量客戶端大多以編程為中心。這并不令人意外，因為開發(fā)者通常是新技術(shù)的早期采用者。但隨著協(xié)議的成熟，我們預(yù)計會看到更多以業(yè)務(wù)為中心的客戶端出現(xiàn)。

在 MCP 服務(wù)器方面，目前大多數(shù)服務(wù)器都以本地優(yōu)先為主，專注于單一功能。這是由于 MCP 目前僅支持基于 SSE 和命令的連接。然而，隨著生態(tài)系統(tǒng)將遠程 MCP 提升為首要支持對象，并采用可流式 HTTP 傳輸，我們預(yù)計會看到更多的 MCP 服務(wù)器被廣泛采用。

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

隨著 MCP 的普及，基礎(chǔ)設(shè)施和工具將在使生態(tài)系統(tǒng)更具可擴展性、可靠性和可訪問性方面發(fā)揮關(guān)鍵作用。像 Mintlify、Stainless 和 Speakeasy 這樣的服務(wù)器生成工具正在減少創(chuàng)建 MCP 兼容服務(wù)的摩擦，而像 Cloudflare 和 Smithery 這樣的托管解決方案則正在解決部署和擴展的挑戰(zhàn)。與此同時，像 Toolbase 這樣的連接管理平臺正在開始簡化本地優(yōu)先 MCP 的密鑰管理和智能體。

未來可能性

智能體原生架構(gòu)（agent-native architecture）的發(fā)展仍處于萌芽階段。盡管業(yè)界已經(jīng)對 MCP 展現(xiàn)出極大熱情，但構(gòu)建和部署 MCP 過程中仍面臨諸多亟待解決的技術(shù)難題。協(xié)議在下一輪迭代中需要重點突破的領(lǐng)域包括：

托管與多租戶

MCP 支持 AI 智能體與其工具之間的一對多關(guān)系，但多租戶架構(gòu)（例如 SaaS 產(chǎn)品）需要支持多用戶同時訪問共享的 MCP 服務(wù)器。近期解決方案可能是默認采用遠程服務(wù)器，使 MCP 服務(wù)器更易于訪問，但許多企業(yè)同樣希望能夠托管自己的 MCP 服務(wù)器并實現(xiàn)數(shù)據(jù)面和控制面的分離。

為促進 MCP 的廣泛采用，下一個關(guān)鍵要素是開發(fā)簡化的工具鏈，用于支持規(guī)?；?MCP 服務(wù)器部署和維護。

認證

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

更完善的認證范式可能是推動遠程 MCP 廣泛采用的關(guān)鍵突破點之一。從開發(fā)者視角，統(tǒng)一的認證方法應(yīng)包括：

• 客戶端認證：用于客戶端-服務(wù)器交互的標準方法，如 OAuth 或 API 令牌
• 工具認證：用于第三方 API 認證的輔助函數(shù)或包裝器
• 多用戶認證：適用于企業(yè)部署的租戶感知式認證機制

授權(quán) 

即使工具已通過認證，我們?nèi)孕杩紤]誰應(yīng)被允許使用它，以及如何精細劃分用戶權(quán)限。MCP 缺乏內(nèi)置的權(quán)限模型，導(dǎo)致訪問控制僅限于會話級別 —— 即工具要么可訪問，要么完全受限。雖然未來可能會出現(xiàn)更精細的授權(quán)機制，但目前的方法依賴基于 OAuth 2.1 的授權(quán)流程，一旦認證成功即授予整個會話的訪問權(quán)限。隨著智能體和工具數(shù)量增加，系統(tǒng)復(fù)雜性隨之提高 —— 每個智能體通常需要獨立會話和唯一授權(quán)憑證，造成基于會話的訪問管理網(wǎng)絡(luò)不斷擴大。

網(wǎng)關(guān)

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

MCP 服務(wù)器的可發(fā)現(xiàn)性和可用性

目前，查找和設(shè)置 MCP 服務(wù)器仍是一個手動過程。開發(fā)者需要定位端點或腳本、配置認證，并確保服務(wù)器與客戶端之間的兼容性。集成新服務(wù)器不僅耗時較長，而且 AI 智能體無法動態(tài)發(fā)現(xiàn)或適應(yīng)可用的服務(wù)器。

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

執(zhí)行環(huán)境 

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

標準客戶端體驗 

開發(fā)者社區(qū)經(jīng)常提出的一個問題是：在構(gòu)建 MCP 客戶端時如何考慮工具選擇 —— 是否每個開發(fā)者都需要為工具實現(xiàn)自己的 RAG，還是有一個等待標準化的層？

 除了工具選擇外，目前還沒有統(tǒng)一的工具調(diào)用 UI/UX 模式（從斜杠命令到純自然語言的各種方式都存在）。一個用于工具發(fā)現(xiàn)、排序和執(zhí)行的標準客戶端層可以幫助創(chuàng)建更可預(yù)測的開發(fā)者和用戶體驗。

調(diào)試

MCP 服務(wù)器的開發(fā)者經(jīng)常發(fā)現(xiàn)，讓同一個 MCP 服務(wù)器輕松地跨客戶端工作是很困難的。通常情況下，每個 MCP 客戶端都有自己的特性，而客戶端跟蹤要么缺失要么難以找到，這使得調(diào)試 MCP 服務(wù)器成為一項極其困難的任務(wù)。隨著越來越多遠程優(yōu)先的 MCP 服務(wù)器被構(gòu)建，需要一套新的工具來使開發(fā)體驗在本地和遠程環(huán)境中更加流暢。

AI 工具的影響

MCP 的開發(fā)體驗讓人聯(lián)想到 2010 年代的 API 開發(fā)。這種范式雖然新穎且令人興奮，但其工具鏈仍處于早期階段。如果展望幾年后，假設(shè) MCP 成為 AI 驅(qū)動工作流的事實標準，會發(fā)生什么？以下是一些預(yù)測：

• 以開發(fā)者為中心的公司競爭優(yōu)勢將從最佳 API 設(shè)計轉(zhuǎn)向提供最優(yōu)工具集。若 MCP 能自主發(fā)現(xiàn)工具，API 提供商需確保其工具易于被發(fā)現(xiàn)，并具備差異化特性，使智能體能為特定任務(wù)選擇它們。
• 當每個應(yīng)用都成為 MCP 客戶端、每個 API 都成為 MCP 服務(wù)器時，將出現(xiàn)新定價模式：智能體會基于速度、成本和相關(guān)性動態(tài)選擇工具。這可能使工具采用過程更市場化，優(yōu)先選擇性能最佳和模塊化的工具。
• 文檔將成為 MCP 基礎(chǔ)設(shè)施的關(guān)鍵，企業(yè)需設(shè)計具有清晰、機器可讀格式的工具和 API，使 MCP 服務(wù)器成為基于現(xiàn)有文檔的事實性產(chǎn)物。
• 僅有 API 還不夠，但可作為良好起點。工具與 API 的映射很少是一對一關(guān)系。工具是更高層次的抽象，智能體可能選擇包含多個 API 調(diào)用以最小化延遲的函數(shù)。MCP 服務(wù)器設(shè)計將以場景和用例為中心。
• 若軟件默認成為 MCP 客戶端，將出現(xiàn)新的托管模式。每個客戶端本質(zhì)上都是多步驟的，需要可恢復(fù)性、重試和長時間運行任務(wù)管理。托管提供商需跨不同 MCP 服務(wù)器進行實時負載均衡，優(yōu)化成本與性能。

MCP 正在重塑 AI 智能體生態(tài)系統(tǒng)，而下一階段的發(fā)展將取決于如何應(yīng)對其基礎(chǔ)性挑戰(zhàn)。若實施得當，MCP 有望成為 AI 與工具交互的標準接口，并開創(chuàng)自主、多模態(tài)且深度整合的新一代 AI 體驗。

如果 MCP 獲得廣泛應(yīng)用，它將從根本上改變工具的構(gòu)建、使用和商業(yè)化方式。業(yè)內(nèi)專家正密切關(guān)注市場將如何引導(dǎo) MCP 的發(fā)展方向。

今年將是決定性的一年：我們是否會看到統(tǒng)一的 MCP 市場崛起？AI 智能體的身份驗證是否能實現(xiàn)無縫對接？多步驟執(zhí)行能否被正式納入?yún)f(xié)議標準？