🦸🏻#14: 什麼是MCP，為什麼大家——突然間！——都在談論它？
你需要了解的關於模型上下文協議的一切
“即使是最複雜的模型也受限於它們與資料的隔離——被困在資訊孤島和遺留系統中。” Anthropic，關於上下文整合的重要性
當今的大型語言模型（LLMs）在獨立執行時非常智慧，但一旦需要超出其固定訓練資料範圍的資訊時，它們就會遇到困難。為了使AI代理真正有用，它們必須在正確的時間訪問正確的上下文——無論是你的檔案、知識庫還是工具——甚至可以根據該上下文執行更新文件或傳送電子郵件等操作。歷史上，將AI模型連線到所有這些外部來源一直是一項混亂的、臨時性的工作。開發人員必須為每個資料來源或API編寫自定義程式碼或使用專用外掛。這使得“連線”整合變得脆弱且難以擴充套件。
為了簡化這一點，Anthropic提出了模型上下文協議（MCP）——一個旨在將AI助手與資料和工具的世界連線起來的開放標準，以插入許多不同的上下文來源。他們於2024年11月宣佈了這一訊息。最初的反應有些平淡。但現在MCP正在流行，已經超越了Langchain，並有望很快超越OpenAPI和CrewAI。主要的AI參與者和開源社群正在圍繞MCP聚集，將其視為構建代理AI系統的潛在遊戲規則改變者。為什麼？
在本文中，我們將深入探討MCP——為什麼它現在是一個熱門話題，MCP如何實現向更整合、上下文感知AI的轉變，它在代理工作流中的位置，以及開發人員、研究人員、AI工程師和技術高管應該瞭解的幕後細節。我們還將探討一些很少有人嘗試過的MCP創新應用。總的來說，這是一份很好的入門指南，對於那些已經嘗試過MCP並希望瞭解更多資訊的人也很有用。深入瞭解！
🔳 Turing Post 在 🤗 Hugging Face 上駐紮 -> 點選關注！
更新：如果你對協議感興趣，你可能還想閱讀我們對A2A的深入探討
本期內容包括什麼？
- 為什麼MCP現在才引起轟動（而不是去年11月）？
- 那麼，什麼是MCP，它是如何工作的？
- MCP技術概述
- 我該如何開始使用MCP？
- 在MCP出現之前，AI系統是如何處理上下文和工具訪問的？
- MCP是萬能藥嗎？
- MCP在代理編排及其在代理工作流中的位置
- MCP解鎖的新可能性
- 總結
- 深入學習的資源
為什麼MCP現在才引起轟動（而不是去年11月）？
MCP最初於2024年11月下旬由Anthropic開源並宣佈。當時，它是一個令人興奮的想法，但沒有多少人注意到並認真對待。直到2025年初，MCP才真正進入AI社群的視野。最近的這一波熱潮有幾個主要原因：
- 整合問題解決者： AI代理和代理工作流在2023-2024年成為熱門詞彙，但它們的致命弱點仍然存在：將這些代理與現實世界的業務系統和資料整合。最初，大部分注意力都集中在模型能力和提示技術上，而不是整合。MCP透過定義“如何連線現有資料來源”（檔案系統、資料庫、API等）到AI工作流來直接解決這一差距。隨著人們對此的理解加深，MCP開始被視為用於構建嚴肅的、生產就緒的AI代理的缺失拼圖。（這是HumanX會議的觀點之一：近年來，我們主要專注於構建單個AI模型，每個模型都專門用於特定任務。但隨著複雜性和需求的增長，正在向整合系統轉變——多個專業模型、軟體元件、API、資料來源和介面協同工作的編排。）
- 社群和採納： 在短短幾個月內，MCP從一個概念發展成為一個不斷增長的生態系統。早期採用者包括Block（Square）、Apollo、Zed、Replit、Codeium和Sourcegraph等公司，它們開始整合MCP以增強其平臺。快進到2025年，生態系統已經爆發——到2月份，已經有超過1000個社群構建的MCP伺服器（聯結器）可用。顯然，隨著行業向更整合、上下文感知的AI發展，MCP引起了共鳴。這種網路效應使得MCP更具吸引力：透過MCP可用的工具越多，採用該標準就越有用。
- 事實標準勢頭： 與又一個專有SDK或一次性框架不同，MCP是開放的、模型無關的，並得到了主要AI參與者的支援。這意味著任何AI模型（Claude、GPT-4、開源LLM等）都可以使用MCP，任何開發人員或公司都可以在未經許可的情況下建立MCP整合。社群中的許多人現在認為MCP很可能成為標準化AI系統連線外部資料競賽的贏家（就像USB、HTTP或ODBC在其領域中變得無處不在的標準一樣）。
- 快速演進和教育： Anthropic不僅釋出了MCP並置之不理；他們一直在積極改進它並教育開發人員。在最近的AI峰會上，Anthropic的Mahesh Murag舉辦了一場病毒式傳播的研討會，加速了MCP的採用。（請記住，所有進一步學習的連結都包含在文章末尾。）
那麼，什麼是MCP，它是如何工作的？
MCP規定了AI如何發現、連線和使用外部工具的明確規則——無論是查詢資料庫還是執行命令。這使得模型能夠超越其訓練資料，使其更加靈活並感知周圍的世界。
MCP技術概述
一個顯著的特點是MCP的動態發現——AI代理自動檢測可用的MCP伺服器及其功能，無需硬編碼整合。例如，如果你啟動一個新的MCP伺服器（如CRM），代理可以透過標準化的API立即識別並使用它，提供傳統方法無法比擬的靈活性。
我該如何開始使用MCP？
最好的起點是官方的MCP文件和倉庫。Anthropic開源了規範並提供了SDK（包括Python和現在的Java等語言）。通常的步驟是：
- 執行或安裝您關注的工具或資料來源的MCP伺服器。 Anthropic有一個預構建的流行系統（Google Drive、Slack、Git、資料庫等）伺服器的開源倉庫。您可以安裝這些伺服器並進行配置（通常只需使用您的憑據或金鑰執行命令）。
- 在您的AI應用程式中設定MCP客戶端。 如果您使用Claude的應用程式，您可以在UI中新增伺服器。如果您正在編寫自己的代理，請使用MCP SDK連線到伺服器（提供地址/埠）。
- 一旦您在客戶端中啟用了MCP服務，客戶端將獲取額外提供的功能： 額外的工具、資源和提示模板。
- 呼叫並迭代。 模型/代理現在可以根據需要呼叫MCP工具操作。確保監控日誌以檢視它是否正確呼叫了伺服器。您將看到請求命中MCP伺服器並返回響應。
為了快速入門，Anthropic建議嘗試Claude桌面整合（如果您有許可權）或執行示例伺服器並使用其提供的快速入門指南。社群也非常活躍——MCP伺服器的目錄正在迅速擴充套件。一些流行的聯結器包括Google服務（Drive、Gmail、Calendar）、Slack（聊天和檔案訪問）、GitHub/Git（用於程式碼倉庫）、Postgres等資料庫、Web瀏覽器或Puppeteer（用於瀏覽網頁）等等。許多伺服器都列在社群目錄中（一些開發人員已經建立了網站來索引它們）。官方的MCP GitHub也託管了大量聯結器實現，供您入門。如果您有一個未涵蓋的利基工具，您可以使用SDK構建自己的MCP伺服器——通常它只是該工具API的一個薄包裝器，以MCP格式暴露一個函式。
我們感謝Will Schenk澄清了MCP和如何開始使用它的一些事情。他分享了這個快速的動手演練，演示了MCP與Tezlab的特斯拉監控服務協同工作。
在MCP出現之前，AI系統是如何處理上下文和工具訪問的？
讓我們簡要回顧一下為AI提供外部知識或行動的傳統方法，以及MCP的不同之處
- 自定義API整合（一次性聯結器）： 最常見的方法是為每個服務編寫自定義程式碼或使用SDK。例如，如果你想讓你的AI代理訪問Google Drive和SQL資料庫，你需要分別整合Google的API和資料庫驅動程式，每個都有自己的身份驗證、資料格式和怪癖。這真是個麻煩！相比之下，MCP提供了一個單一的“鑰匙”（協議），可以開啟許多門，並且無需更改客戶端即可新增新的MCP伺服器。
- 語言模型外掛（OpenAI外掛等）： 2023年引入的另一種方法是為模型提供標準化外掛規範（通常是OpenAPI模式），以便它能夠以受控方式呼叫外部API（例如ChatGPT外掛系統）。雖然在概念上與MCP相似（標準化工具訪問），但這些外掛是專有的且受限的——每個外掛仍需單獨構建和託管，並且只有某些平臺（如ChatGPT或Bing Chat）才能使用它們。外掛也傾向於專注於單向資料檢索（模型呼叫API並獲取資訊），而不是維護持續的互動式會話。MCP的不同之處在於它是開源和通用的（任何人都可以實現它，不與任何AI提供商繫結），並支援豐富的雙向互動。它就像AI和工具之間的對話，而外掛通常是無狀態的問答呼叫。
- 透過框架使用工具（LangChain工具、代理）： 代理編排庫（如LangChain）普及了為模型提供帶有描述的“工具”（函式）的想法。例如，你可能有一個search()工具或一個calculate()工具，代理（透過LLM）決定何時呼叫它們。這很強大，但每個工具在底層仍然需要自定義實現——LangChain的庫發展到500多個以一致介面實現的工具，但開發人員仍然需要連線這些工具或確保它們符合他們的需求。MCP在這裡可以被視為補充：它為工具的實現提供了一個標準化的介面。實際上，你可以將MCP伺服器視為一個隨時可用的工具庫，任何代理都可以使用。區別在於標準化所處的位置。LangChain建立了一個面向開發人員的標準（其工具類介面）來將工具整合到代理的程式碼中。MCP建立了一個面向模型的標準——執行中的AI代理本身可以在執行時發現和使用任何MCP定義的工具。這意味著即使你沒有為特定工具自定義構建代理的程式碼，模型也可以即時整合它。實際上，這些想法正在融合：例如，LangChain的團隊（當注意到MCP的激增時）提供了一個介面卡，以便所有這些MCP伺服器（聯結器）都可以輕鬆地被視為LangChain工具。因此，在LangChain或其他框架中構建的代理可以像呼叫任何其他工具一樣呼叫MCP工具，從而受益於不斷增長的MCP生態系統。
- 檢索增強生成（RAG）和向量資料庫： 為LLM提供上下文的一種常用方法是使用檢索器搜尋知識庫（文件、嵌入）並將頂部結果注入到提示中。這解決了模型的知識截止或有限記憶問題。然而，RAG通常處理靜態文字片段，並且本身不允許模型執行超出索引範圍的操作或查詢。MCP實際上可以與RAG協同工作——例如，MCP伺服器可以與向量資料庫或搜尋引擎介面，允許模型將搜尋查詢作為工具發出，而不是隱式地在每個提示中依賴檢索。可以說MCP是一種更通用的機制：RAG提供被動上下文，而MCP允許模型透過定義的通道主動獲取或操作上下文。在需要最新或互動式資料的場景中（例如，查詢即時資料庫或釋出更新），MCP超越了僅僅檢索文字——它可以觸發操作。
MCP是萬能藥嗎？
當然，MCP並非萬能藥，它是一個極其方便的整合層。但像任何新興技術一樣，它也帶來了自己的一系列複雜性和挑戰，開發人員和組織在大規模採用之前必須考慮這些：主要擔憂之一是管理多個工具伺服器帶來的額外開銷。執行和維護與這些本地伺服器的連線可能很繁瑣，尤其是在正常執行時間、安全性和可伸縮性至關重要的生產環境中。MCP的初始實現是為本地和桌面使用而設計的，這引發了它在基於雲的架構和多使用者場景中表現如何的問題。開發人員已經提出使MCP更無狀態並適應分散式環境，但這仍然是一個持續的挑戰。另一個問題在於工具可用性。僅僅因為MCP擴充套件了AI模型的工具集，並不意味著模型會有效地使用這些工具。以前基於代理的框架已經表明，AI模型可能在工具選擇和執行方面遇到困難。MCP試圖透過提供結構化的工具描述和規範來緩解這種情況，但成功仍然取決於這些描述的質量以及AI正確解釋它們的能力。LangChain創始人Harrison Chase強調的社群驅動方法表明，文件齊全的工具可以提高可用性，但這仍是一個持續改進的領域。除了實施障礙，MCP的成熟度也是一個考慮因素。作為一項相對較新的技術，它會受到快速變化和不斷發展的標準的影響。這可能導致破壞性更改，需要頻繁更新伺服器和客戶端。雖然MCP的核心概念看起來穩定，但開發人員應該預期併為版本升級和不斷發展的最佳實踐做好準備。相容性是另一個限制因素。 目前，MCP在Anthropic的生態系統（例如Claude）中獲得一流支援，但更廣泛的採用仍不確定。其他AI提供商可能不會原生支援MCP，需要額外的介面卡或自定義整合。在MCP在AI平臺中獲得更廣泛接受之前，其效用將受到一定限制。對於更簡單的應用程式，MCP甚至可能過於複雜。 如果AI模型只需要訪問一兩個簡單的API，直接API呼叫可能比實現MCP更有效的解決方案。與MCP的訊息傳遞系統和伺服器設定相關的學習曲線意味著，需要權衡其優勢和複雜性。安全和監控也帶來了持續的挑戰。 由於MCP充當中間層，它需要強大的身份驗證和許可權控制以防止未經授權的訪問。像MCP Guardian這樣的開源計劃已經出現，透過記錄請求和強制執行策略來解決這些問題，但在企業環境中保護MCP仍然是一項正在進行的工作。
總的來說，這些限制都不是障礙，但明智的做法是從實驗性或非關鍵部署開始，以瞭解其運作方式。 MCP最好的地方之一是——積極參與的社群。由於它是開放的，您面臨的問題可以共同討論和解決。
MCP在代理編排及其在代理工作流中的位置
在之前的文章中，我們探討了自主代理的構成要素：分析（身份和上下文）、知識、記憶、推理/規劃、反思和行動。代理需要觀察和理解其環境（分析/知識），記住過去的互動（記憶），規劃其行動（推理），執行行動（執行工具呼叫或輸出），然後反思和學習。MCP的作用是什麼？
MCP本身不是一個“代理框架”；相反，它充當代理的標準化整合層。MCP主要關注行動部分——具體來說，為代理提供一種標準化的方式來執行涉及外部資料或工具的行動。它提供了將AI代理以安全、結構化的方式連線到外部世界的管道。沒有MCP（或類似的東西），每次代理需要在世界上做某事——無論是獲取檔案、查詢資料庫還是呼叫API——開發人員都必須連線自定義整合或使用臨時解決方案。這就像建造一個機器人，但必須定製每個手指以抓取不同的物體——繁瑣且不可擴充套件。
重要的是再次強調，MCP本身不是編排引擎或代理大腦。相反，它是代理架構中的一個整合層。它透過充當統一的“工具箱”來補充LangChain、LangGraph、CrewAI或LlamaIndex等代理編排工具，AI代理可以從中呼叫外部操作。它不取代編排——編排決定代理何時以及為何使用工具——MCP定義了這些工具如何被呼叫以及資訊如何交換。
它類似於代理的標準API閘道器，透過允許客戶端（代理）和伺服器（工具）之間的通用相容性，將整合複雜性從“N×M”問題簡化為“N+M”問題。最終，MCP簡化了外部功能的整合，使代理更具通用性、適應性，並能夠在各種上下文中執行復雜的任務。
MCP解鎖的新可能性
MCP仍然很新，其全部潛力才剛剛開始被探索。第一波用例是顯而易見的——將企業資料連線到聊天助手，或透過倉庫訪問增強編碼代理。但一些新興的應用可能會將AI代理提升到新的水平。
- 多步驟、跨系統工作流：代理系統通常需要在不同平臺之間進行協調。 假設AI計劃一個事件：它檢查你的日曆，預訂場地，透過電子郵件邀請客人，安排旅行，並更新預算表。目前，這需要手動拼接API。有了MCP，所有這些操作都可以透過一個單一的介面進行。代理呼叫一系列MCP工具（每個任務一個），並在它們之間保持共享上下文——沒有丟失的執行緒，沒有自定義整合。
- 理解其環境的代理（包括機器人）： 除了工具訪問，MCP還可以使嵌入在智慧環境（無論是智慧家居還是作業系統）中的AI代理。AI助手可以透過標準化的MCP伺服器與感測器、物聯網裝置或作業系統功能進行互動。AI不再孤立執行，而是獲得即時感知，從而實現更自然和主動的協助。
- 協作代理（代理社會）——對此我非常興奮——MCP還可以充當多代理系統的共享工作空間。專門的AI代理——一個用於研究，一個用於規劃，另一個用於執行——可以使用MCP動態交換資訊和協調任務。有了MCP，每個代理都不需要直接整合；它們只需訪問一個通用工具集。
- 深度整合的個人AI助手： MCP可以允許使用者配置自己的AI，以安全地與個人資料和應用程式互動。本地MCP伺服器可以授予AI訪問電子郵件、筆記和智慧裝置的許可權，而無需將敏感資料暴露給第三方。這可以建立一個超個性化的AI助手，而無需依賴基於雲的服務。
- 企業治理和安全： 對於企業而言，MCP將AI對內部工具的訪問標準化，減少了整合開銷。它還實現了治理：AI互動可以透過監督層進行日誌記錄、監控和控制，防止意外操作，同時保持效率。
這些只是MCP潛力的初步展望。透過實現流暢、上下文感知、多步驟的互動，它使AI代理更接近真正的自主工作流執行。
結束語
MCP正迅速發展成為一個強大的標準協議，將AI從一個孤立的“大腦”轉變為一個多功能的“執行者”。透過簡化代理與外部系統的連線方式，它為更強大、更具互動性、更使用者友好的AI工作流鋪平了道路。
即將推出的關鍵功能（基於Anthropic的Mahesh Murag的研討會）
遠端伺服器和OAuth
- 使用SSE實現無縫遠端託管。
- 內建OAuth 2.0，用於安全整合（例如Slack）。
官方MCP登錄檔
- 伺服器的集中發現和驗證。
- 企業友好：主機可以執行私人登錄檔。
知名端點
- 用於第一方伺服器發現的標準化.well-known/mcp檔案。
進一步增強
- 流支援、無狀態連線、主動伺服器行為和更好的名稱空間。
每一次更新都將使MCP更加健壯，幫助AI代理更深入地整合到實際工作流中。這是一項社群驅動的工作，因此請關注路線圖，加入討論，並幫助塑造AI和軟體交叉的未來。
MCP迅速崛起，我們甚至不得不為此更改了我們的編輯計劃。這個話題需要解釋。在討論代理工作流中的行動之後，涵蓋它感覺很自然。在下一期中，我們將探討人機通訊和人機迴路（HITL）整合，然後轉向多代理協作。敬請期待。
分享這篇文章有助於我們成長並接觸更多人——謝謝！
深入學習資源：
- Anthropic推出模型上下文協議
- 模型上下文協議文件和快速入門指南
- MCP文件
- GitHub上的模型上下文協議
- GitHub上的MCP伺服器集合
- 使用模型上下文協議構建代理（特別是關於MCP下一步的部分）——來自Anthropic的Mahesh Murag，AI Engineering Summit研討會
- 為什麼MCP獲勝——來自Latent Space的swyx
- GitHub Star歷史（圖表）
- MCP：曇花一現還是未來標準？——來自LangChain
- GitHub上的MCP Guardian
- 使用MCP暴露服務
- Reddit上對MCP的初步反應
來自 Turing Post 的資料
- 🦸🏻#1：開放性和 AI 智慧體——從生成式 AI 到創造性 AI 的路徑？
- 🦸🏻#5：智慧體系統的構建模組
- 🦸🏻#9：AI 會記憶嗎？記憶在代理工作流中的作用
- 🦸🏻#10：當今的生成式 AI 真的能推理嗎？
- 🦸🏻#11：智慧體如何規劃和推理？
- 🦸🏻#12：代理如何從自己的錯誤中學習？反思在AI中的作用
- 🦸🏻#13：行動！AI代理如何使用UI和API工具執行任務
感謝您的閱讀！
📨 如果您想直接在收件箱中收到我們的文章，請在此訂閱
