AI大模型領(lǐng)域，最近比較火的一個詞是MCP（MCP：Model Context Protocol）。

比如，Tripo推出Tripo3D MCP，允許Blender/Cursor/Claude直接集成；Claude桌面客戶端內(nèi)置了MCP服務器；還出現(xiàn)了MCP做的“App Store” Fleur，以及MCP導航網(wǎng)站mcp.so/ ，收錄了近3000個MCP Server。

那么什么是MCP，它到底對AI生態(tài)發(fā)展有什么價值，小編邊學邊整理了這個材料，供大家參考。

目前大語言模型的局限在于，無法直接連接外部真實環(huán)境，比如不知道今天是哪一天，不知道外面天氣如何，不能用計算器，不能搜索、訪問網(wǎng)頁。

就像你有臺電腦，除了鍵盤鼠標顯示器啥都沒有，不能上網(wǎng)，不能接掃描儀、攝像頭等等。

API是互聯(lián)網(wǎng)的第一個偉大統(tǒng)一者——為軟件通信創(chuàng)建了一種共享語言——但 AI模型缺乏相應的等價物。

2024年11月推出的 Model Context Protocol (MCP)在開發(fā)者和 AI 社區(qū)中獲得了顯著關(guān)注，被視為一種潛在的解決方案。

什么是MCP？

MCP是一種開放協(xié)議，允許系統(tǒng)以可跨集成推廣的方式，為AI模型提供上下文。該協(xié)議定義了AI模型如何調(diào)用外部工具、獲取數(shù)據(jù)以及與服務交互。

做個比喻的話，有點類似你電腦上的USB協(xié)議。

有了這個協(xié)議，你的電腦就可以連接各種外界設(shè)備——比如通過USB接口的攝像頭，可以錄視頻；通過USB接口的掃描儀，可以掃描文檔等。

可以說，MCP就是大語言模型的USB協(xié)議——開發(fā)者們可以基于這套協(xié)議，開發(fā)各種服務，比如連接本地微信聊天記錄的服務、天氣預報的服務等。

作為一個具體示例，以下是Resend MCP服務器與多個MCP客戶端協(xié)同工作的方式。

這個想法并不新鮮；MCP從LSP（Language Server Protocol）中獲得了靈感。在LSP中，當用戶在編輯器中輸入時，客戶端會查詢語言服務器以獲取自動補全建議或診斷信息。

MCP超越LSP之處在于其以代理為中心的執(zhí)行模型：LSP主要是反應式的（基于用戶輸入響應IDE的請求），而MCP則旨在支持自主的AI工作流。根據(jù)上下文，AI代理可以決定使用哪些工具、按什么順序使用以及如何將它們串聯(lián)起來以完成任務。MCP還引入了人在回路的能力，使人類能夠提供額外數(shù)據(jù)并批準執(zhí)行。

當今的流行用例

借助合適的MCP服務器，用戶可以將每個MCP客戶端轉(zhuǎn)變?yōu)椤叭軕谩薄?/p>

以Cursor為例：盡管Cursor是一個代碼編輯器，但它也是一個實現(xiàn)良好的MCP客戶端。

終端用戶可以通過Slack MCP服務器將其轉(zhuǎn)變?yōu)镾lack客戶端，通過Resend MCP服務器作為郵件發(fā)送器，以及通過Replicate MCP服務器作為圖像生成器。

更強大的利用MCP的方式是在一個客戶端上安裝多個服務器，以解鎖新的流程：用戶可以安裝一個服務器從Cursor生成前端UI，同時讓代理使用圖像生成 MCP服務器為網(wǎng)站生成主圖。

除了Cursor，當今大多數(shù)用例可以總結(jié)為以開發(fā)人員為中心的本地優(yōu)先工作流，或使用LLM客戶端的新網(wǎng)絡(luò)體驗。

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

對于每天沉浸在代碼中的開發(fā)者來說，一個普遍的感受是，“我不想離開我的 IDE去做 x”。MCP服務器是實現(xiàn)這一夢想的絕佳方式。

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

Cursor代理如何使用Browsertools訪問控制臺日志和其他實時數(shù)據(jù)并更高效調(diào)試的示例。

在與開發(fā)者工具交互的工作流之外，MCP服務器開啟的新用途是能夠通過爬取網(wǎng)頁或基于文檔自動生成MCP服務器，為編碼代理添加高度準確的上下文。開發(fā)者無需手動配置集成，可以直接從現(xiàn)有文檔或API啟動MCP服務器，使AI代理即時訪問工具。

這意味著減少在樣板代碼上的時間，更多時間實際使用工具——無論是拉取實時上下文、執(zhí)行命令，還是動態(tài)擴展AI助手的能力。

全新體驗

像Cursor這樣的IDE并不是唯一的MCP客戶端，盡管由于MCP對技術(shù)用戶的強大吸引力，它們受到了最多的關(guān)注。對于非技術(shù)用戶來說，Claude Desktop是一個極佳的入門選擇，它使MCP驅(qū)動的工具對普通用戶更加易用和友好。很快，我們可能會看到針對以業(yè)務為中心的任務（如客戶支持、營銷文案、設(shè)計和圖像編輯）的專門 MCP 客戶端出現(xiàn)，因為這些領(lǐng)域與 AI 在模式識別和創(chuàng)造性任務方面的優(yōu)勢密切相關(guān)。

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

一個例子是 Highlight 如何在其客戶端上實現(xiàn)@command來調(diào)用任何 MCP 服務器。結(jié)果是一種新的用戶體驗模式，其中 MCP 客戶端可以將生成的內(nèi)容傳輸?shù)饺魏芜x定的下游應用程序中。

Highlight 實現(xiàn) Notion MCP（插件）的一個示例

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

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

盡管我們主要考慮的是服務器和客戶端，但隨著協(xié)議的演進，MCP 生態(tài)系統(tǒng)正逐漸成形。這份市場地圖涵蓋了當前最活躍的領(lǐng)域，盡管仍有許多空白。鑒于 MCP 尚處于早期階段，我們期待隨著市場的發(fā)展和成熟，將更多參與者納入地圖。（我們將在下一節(jié)探討其中一些未來的可能性。）

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

我們所見的大多數(shù)MCP服務器都是本地優(yōu)先，專注于單人玩家。這是目前MCP僅支持基于SSE和命令連接的一種表現(xiàn)。然而，隨著生態(tài)系統(tǒng)將遠程MCP提升為一級支持，以及MCP采用可流式 HTTP 傳輸，我們預計會看到更多MCP服務器的采用。

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

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

未來可能性

然而，我們?nèi)蕴幱诖碓軜?gòu)演進的早期階段。盡管今天MCP引發(fā)了大量關(guān)注，但在使用MCP構(gòu)建和交付時，仍存在許多未解決的問題。

在協(xié)議的下一個迭代中需要解鎖的一些內(nèi)容包括：

托管與多租戶

MCP支持AI代理與其工具之間的一對多關(guān)系，但多租戶架構(gòu)（例如SaaS產(chǎn)品）需要支持多個用戶同時訪問共享的MCP服務器。默認情況下?lián)碛羞h程服務器可能是短期內(nèi)使MCP服務器更易于訪問的解決方案，但許多企業(yè)也希望托管自己的MCP服務器，并分離數(shù)據(jù)平面和控制平面。

支持大規(guī)模MCP服務器部署和維護的簡化工具鏈是推動更廣泛采用的下一個關(guān)鍵環(huán)節(jié)。

認證

MCP目前并未定義客戶端如何與服務器進行認證的標準機制，也未提供MCP服務器在與第三方API交互時應如何安全管理和委派認證的框架。認證目前由各個實現(xiàn)和部署場景自行決定。在實踐中，MCP迄今為止的采用似乎主要集中在本地集成上，這些場景下并不總是需要顯式認證。

更好的認證范式可能是遠程MCP采用的一大關(guān)鍵。從開發(fā)者的角度來看，統(tǒng)一的方法應涵蓋：

·客戶端認證：用于客戶端與服務器交互的標準方法，如OAuth或API tokens

·工具認證：用于與第三方API進行身份驗證的輔助函數(shù)或封裝器

·多用戶認證：面向企業(yè)部署的租戶感知認證

授權(quán)

即使工具經(jīng)過認證，誰應被允許使用它以及他們的權(quán)限應有多細粒度？MCP缺乏內(nèi)置的權(quán)限模型，因此訪問控制在會話級別——意味著工具要么可訪問，要么完全受限。雖然未來的授權(quán)機制可能會形成更細粒度的控制，但目前的方法依賴于基于OAuth 2.1的授權(quán)流程，一旦認證，便授予整個會話的訪問權(quán)限。隨著更多代理和工具的引入，這帶來了額外的復雜性——每個代理通常需要其自己的會話和唯一的授權(quán)憑證，導致基于會話的訪問管理網(wǎng)絡(luò)不斷擴展。

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

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

MCP 服務器可發(fā)現(xiàn)性與可用性

目前，尋找和設(shè)置MCP服務器是一個手動過程，要求開發(fā)者定位端點或腳本、配置身份驗證，并確保服務器與客戶端之間的兼容性。集成新服務器耗時，且AI代理無法動態(tài)發(fā)現(xiàn)或適應可用服務器。

根據(jù)Anthropic在上個月的AI工程師大會上的發(fā)言，聽起來MCP服務器注冊與發(fā)現(xiàn)協(xié)議即將推出。這可能會開啟MCP服務器采用的下一個階段。

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

大多數(shù) AI 工作流程需要依次進行多個工具調(diào)用——但MCP缺乏內(nèi)置的工作流程概念來管理這些步驟。要求每個客戶端實現(xiàn)可恢復性和可重試性并不理想。盡管如今我們看到開發(fā)者探索如 Inngest 等解決方案來實現(xiàn)這一點，但將狀態(tài)執(zhí)行提升為一等概念將為大多數(shù)開發(fā)者理清執(zhí)行模型。

標準客戶體驗

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

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

調(diào)試

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

AI工具的影響

MCP的開發(fā)體驗如同2010年代的API開發(fā)。范式新穎且令人興奮，但工具鏈尚處于早期階段。如果我們快進到幾年后，如果MCP成為AI驅(qū)動工作流程的事實標準，會發(fā)生什么？一些預測：

·以開發(fā)者為先的公司的競爭優(yōu)勢將演變。從提供最佳 API 設(shè)計擴展到提供最佳工具集合供代理使用。如果MCP能夠自主發(fā)現(xiàn)工具，API和SDK的提供者需要確保他們的工具易于通過搜索被發(fā)現(xiàn)，并且足夠差異化，以便代理為特定任務選擇。這可能比人類開發(fā)者尋找的內(nèi)容更加細化和具體。

·可能會出現(xiàn)一種新的定價模式。如果每個應用都成為 MCP 客戶端，每個 API 都成為MCP服務器，可能會出現(xiàn)一種新的定價模式：代理可能會根據(jù)速度、成本和相關(guān)性的組合更動態(tài)地選擇工具。這可能導致一個更加市場驅(qū)動的工具采用過程，選擇性能最佳和模塊化程度最高的工具，而不是最廣泛采用的工具。

·文檔將成為 MCP 基礎(chǔ)設(shè)施的關(guān)鍵部分。因為企業(yè)需要設(shè)計具有清晰、機器可讀格式（例如llms.txt）的工具和 API，并基于現(xiàn)有文檔使 MCP 服務器成為事實上的工件。

·僅靠API已不再足夠，但它們可以成為很好的起點。開發(fā)者會發(fā)現(xiàn)，從 API 到工具的映射很少是 1:1 的。工具是一種更高層次的抽象，在任務執(zhí)行時對代理最有意義——代理可能選擇 draft_email_and_send()函數(shù)，而不是簡單地調(diào)用 send_email()，該函數(shù)包含多個 API 調(diào)用以最小化延遲。MCP 服務器設(shè)計將以場景和用例為中心，而不是以 API 為中心。

· 將會有一種新的托管模式。如果每個軟件默認都成為 MCP 客戶端，將會出現(xiàn)一種新的托管模式，因為工作負載特征將與傳統(tǒng)網(wǎng)站托管不同。每個客戶端本質(zhì)上都是多步驟的，并且需要執(zhí)行保證，如可恢復性、重試和長時間運行的任務管理。托管提供商還需要在不同 MCP 服務器之間進行實時負載平衡，以優(yōu)化成本、延遲和性能，使 AI 代理能夠在任何給定時刻選擇最高效的工具。

MCP已經(jīng)在重塑AI代理生態(tài)系統(tǒng)，但下一波進展將取決于我們?nèi)绾螒獙A(chǔ)性挑戰(zhàn)。如果處理得當，MCP可能成為AI與工具交互的默認接口，并開啟新一代自主、多模態(tài)、深度集成的AI體驗。

如果MCP被廣泛采用，它可能代表工具構(gòu)建、消費和貨幣化方式的轉(zhuǎn)變。我們期待看到市場將它們帶向何方。今年將是關(guān)鍵的一年：我們會看到一個統(tǒng)一的 MCP市場崛起嗎？AI 代理的認證會變得無縫嗎？多步執(zhí)行能否被正式納入?yún)f(xié)議？

掃碼邀請進群，我們帶你一起來玩轉(zhuǎn)ChatGPT、GPT-4、文心一言、通義千問、訊飛星火等AI大模型，順便學一些AI搞錢技能。

往期文章回顧