一文看懂MCP是怎么火起來的。
MCP為什么火了？時間線回顧
最近，海外AI圈正在瘋狂傳播一個概念——MCP。
MCP，模型上下文協(xié)議，是一種標準化的協(xié)議，由Anthropic于2024年11月提出并開源，用于將AI代理連接到各種外部工具和數據源。其設計靈感類似于“USB-C接口”，通過標準化協(xié)議簡化了AI模型與你的數據、工具和服務的交互方式。
Anthropic的發(fā)布原文：https://www.anthropic.com/news/model-context-protocol
起初，Anthropic發(fā)布的這一協(xié)議并未受到廣泛的關注。但 LangChain等平臺已經開始著手研究MCP的前景。
2月10日， LangChain發(fā)布通用API助手解決方案， 可自動將任何 OpenAPI 規(guī)范轉換為智能工具。它采用 LangGraph 和 MCP 構建，可實現與 API 的自然語言交互，而無需自定義集成代碼。
3月7日，一篇有關MCP的技術博客流行開來。 這篇文章 系統(tǒng)性講述了MCP的 價值、架構以及與傳統(tǒng) API 的區(qū)別：《 What is Model Context Protocol (MCP)? How it simplifies AI integrations compared to APIs》。
https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained/
3月9日，LangChain發(fā)布一項投票，討論MCP究竟是曇花一現還是未來標準，引發(fā)熱議。
此后，業(yè)內一系列的MCP的討論接踵而至。X博主Min Choi在兩天前整理了十個代表案例：
一是Blender MCP。Claude可以直接與Blender對話，通過提示詞或者圖片生成3D場景。（ 3月11日）
二是Perplexity MCP。人工智能助手現在可以進行實時網絡搜索。（3月12日）
三是MCP QGIS。Claude 現在可以直接使用 QGIS（開源地圖工具）進行“氛圍映射”。（3月14日）
四是Firecrawl MCP。根據 Claude 的提示克隆任何網站。（3月4日）
五是Claude MCP集成到PubMed學術數據庫中。（3月12日）
六是Supabase數據庫。通過MCP將Supabase數據庫連接到Cursor。（3月13日）
七是在 Gradio 接口中使用 STDIO 和 SSE 通信方法與 MCP 服務器進行交互。（3月7日）
八是Cursor的“通知MCP”。每項任務完成后播放聲音通知。（3月13日）
九是Weaviate?？梢詫CP主機連接到 Weaviate 的矢量搜索功能。（3月12日）
十是Figma MCP。輕松從 Figma 設計中創(chuàng)建代碼。（2月14日）
值得一提的是，MCP的走紅跟Manus的走紅時間線一致，因此有網友很自然地提出疑問，是否Manus也使用了MCP技術。
3月10日，Manus的聯合創(chuàng)始人季逸超否認了該猜測，理由是“Manus早在MCP推出之前就開始開發(fā)了”。
那么，MCP到底是什么呢？
在Anthropic最開始的定義中，MCP的通用架構如下：
該架構包含五個部分：
MCP 主機：如 Claude 桌面、IDE 或希望通過 MCP 訪問數據的 AI 工具
MCP 客戶端：與服務器保持 1:1 連接的協(xié)議客戶端
MCP 服務器：通過標準化的模型上下文協(xié)議暴露特定功能的輕量級程序
本地數據源：您的計算機文件、數據庫以及 MCP 服務器可以安全訪問的服務
遠程服務：可通過互聯網（例如，通過 API）訪問的外部系統(tǒng)（例如，MCP 服務器可以連接到）
如果將MCP理解為AI系統(tǒng)的USB接口，那么它的架構可以抽象成：
Matt Pocock也做了一張圖來定義MCP的生態(tài)位：
X博主Min Choi引用了這么一張圖：
將MCP想象成一座橋梁，就很清楚了：MCP本身并不處理復雜的邏輯；它只是協(xié)調AI模型與工具之間的數據和指令流動。
就像USB-C簡化了你將不同設備連接到電腦的方式一樣，MCP簡化了AI模型與你的數據、工具和服務的交互方式。
為什么使用MCP而不是傳統(tǒng)API？
傳統(tǒng)上，將AI系統(tǒng)連接到外部工具需要集成多個API。每個API集成意味著需要單獨的代碼、文檔、認證方法、錯誤處理和維護。
從比喻的角度來說，API就像是一扇扇獨立的門——每扇門都有自己的鑰匙和規(guī)則。
MCP與API快速對比：
MCP與傳統(tǒng)API的關鍵區(qū)別：
單一協(xié)議：MCP充當標準化的“連接器”，因此集成一個MCP意味著可以訪問多個工具和服務，而不僅僅是其中一個。
動態(tài)發(fā)現：MCP允許AI模型動態(tài)發(fā)現并交互可用的工具，而無需對每個集成進行硬編碼的知識。
雙向通信：MCP支持持久的實時雙向通信——類似于WebSockets。AI模型既可以檢索信息，也可以動態(tài)觸發(fā)操作。
為什么需要雙向通信？
MCP提供實時雙向通信：拉取數據：LLM向服務器查詢上下文信息→例如，查看你的日歷。觸發(fā)操作：LLM指示服務器采取行動→例如，重新安排會議、發(fā)送電子郵件。
實施MCP的好處：
簡化開發(fā)：一次編寫，多次集成，無需為每次集成重寫定制代碼。
靈活性：切換AI模型或工具時無需復雜的重新配置。
實時響應：MCP連接保持活躍，支持實時上下文更新和交互。
安全與合規(guī)：內置訪問控制和標準化的安全實踐。
可擴展性：隨著你的AI生態(tài)系統(tǒng)的發(fā)展，可以輕松添加新功能——只需連接另一個MCP服務器。
何時傳統(tǒng)API更好？
如果你的用例需要精確、可預測的交互，并且有嚴格的限制，傳統(tǒng)API可能更合適。MCP提供了廣泛的動態(tài)能力，適合需要靈活性和上下文感知的場景，但對于高度受控、確定性的應用可能不太適合。
在以下情況下堅持使用細粒度API：
- 需要細粒度控制和高度特定、受限的功能。
- 你希望通過緊密耦合實現性能優(yōu)化。
- 你希望最大限度地提高可預測性，減少上下文自主性。
MCP的應用場景：何時使用MCP？
考慮以下場景：
1. 旅行規(guī)劃助手
使用API：你需要為Google日歷、電子郵件、航空公司預訂API分別編寫單獨的代碼，每個API都有自己的認證、上下文傳遞和錯誤處理邏輯。
使用MCP：你的AI助手可以輕松檢查你的日歷以確認可用時間，預訂機票，并發(fā)送確認郵件——所有這些操作都通過MCP服務器完成，無需為每個工具編寫定制化集成代碼。
2. 高級IDE（智能代碼編輯器）
使用API：你需要手動將你的IDE與文件系統(tǒng)、版本控制、包管理器和文檔集成。
使用MCP：你的IDE通過單一的MCP協(xié)議連接到這些工具，實現更豐富的上下文感知和更強大的建議功能。
3. 復雜數據分析
使用API：你需要手動管理與每個數據庫和數據可視化工具的連接。
使用MCP：你的AI分析平臺可以通過統(tǒng)一的MCP層自主發(fā)現并交互多個數據庫、可視化工具和模擬工具。
開始使用MCP：高級步驟
MCP集成：
1. 定義能力：明確你的MCP服務器將提供什么功能。
2. 實現MCP層：遵循標準化的MCP協(xié)議規(guī)范。
3. 選擇傳輸方式：在本地（標準輸入/輸出）或遠程（服務器發(fā)送事件/WebSockets）之間選擇。
4. 創(chuàng)建資源/工具：開發(fā)或連接MCP將暴露的具體數據源和服務。
5. 設置客戶端：在你的MCP服務器和客戶端之間建立安全穩(wěn)定的連接。
結論
MCP提供了將AI代理和模型與外部數據和工具集成的統(tǒng)一和標準化方式。它不僅僅是一個新的API，而是一個強大的連接框架，能夠實現智能、動態(tài)和富有上下文的AI應用。
| |
熱門跟貼