模型上下文協議是否是 AI 代理的缺失環節？簡明扼要的評測
更新於 2025年9月25日
9 分鐘
模型上下文協議是否是AI代理的缺失環節？一份不廢話的評論
如果您在2024-2025年間一直使用LLM進行構建，您可能已經感受到了摩擦：將模型連接到工具、資料庫和即時系統感覺就像每次都在重新發明輪子。模型上下文協議（Model Context Protocol，MCP）應運而生，這是一個旨在使模型具有工具意識、上下文豐富且可在應用程式和運行時之間互操作的開放標準。但MCP實際上是否已準備好標準化我們將AI連接到現實世界的方式，或者它只是更多的炒作？
在這份分析性和策略性評論中，我們將分解MCP是什麼、它的優點、缺點，以及它與LangChain工具抽象、OpenAI函數調用和代理框架等替代方案的比較。我們還將介紹採用信號、安全考量以及您今天可以交付的實用案例。
到最後，您將知道MCP是否屬於您的技術堆疊，以及在標準演進過程中需要關注什麼。
什麼是模型上下文協議（用簡單的英語解釋）？
模型上下文協議是一個開放標準，用於通過一致的介面將AI模型連接到外部工具、資料和系統。MCP提出了一種共享語言，而不是硬編碼函數或為每個供應商編寫一次性整合：伺服器公開功能（工具、資源、提示）；客戶端（IDE、應用程式、代理運行時）請求它們；模型獲得對上下文和操作的結構化訪問。
- 核心思想：將模型互動與供應商鎖定和定制API解耦。
- 實際承諾：統一的工具，因此代理可以使用相同的協議形狀跨環境調用搜索API、查詢資料庫、打開文件或運行作業。
Thoughtworks的分析捕捉到了這種精神：MCP旨在通過形式化大多數團隊重複重建的管道層，來穩定開發人員將模型連接到世界的方式，從而降低炒作。
一份關鍵的獨立評論更直率地指出：MCP引人注目，但它的真正價值取決於清晰的採用途徑、超越演示環境的互操作性，以及對安全和生命週期管理的可靠解答。
社群情緒反映了一種務實的中間立場：開發人員發現MCP在將代理連接到精選的工具伺服器時「非常有用」，尤其是在可重複的整合方面，同時也承認現在要獲得普遍認可還為時過早。
為什麼MCP現在很重要
以下是一個令人不舒服的現實：您今天對工具訪問的選擇是分散的。
- OpenAI函數調用緊密且方便，但它是供應商特定的，並且不同供應商的架構和行為存在差異。
- LangChain和類似的函式庫為您提供工具抽象，但它們是以框架為中心的，而不是系統之間的線路協議。
- 代理框架成倍增加，每個框架都有自己定義工具、提示、記憶體和上下文儲存的方式。
MCP試圖在協議層進行標準化，因此：
- 單個MCP客戶端可以與多個MCP伺服器（資料庫、文件系統、API）通信。
- 工具可以在應用程式和模型之間移植。
- IDE、終端和聊天應用程式可以提供相同的功能，而無需定制適配器。
底層原理：MCP提供什麼
將MCP視為想要使用工具的東西（客戶端）和提供工具/資料的東西（伺服器）之間的結構良好的合約：
- 工具註冊表：可發現的、類型化的工具，您可以使用結構化的參數調用。
- 資源訪問：標準化的加載文件、文檔或資料庫行的方式。
- 提示和上下文配置：跨應用程式共享的一致提示/模板。
- 會話語義：握手、功能協商和持續的消息交換。
這使得：
- 一次構建，多次整合：編寫一個「搜索伺服器」或一個「CRM伺服器」，並在多個專案中重複使用它。
- 可重現性：工具不僅僅是代碼，它們還是具有元資料和權限的已發布功能。
- IDE/代理融合：同一伺服器可以為VS Code擴展和面向客戶的副駕駛提供支持。
Thoughtworks強調，MCP的價值在於使互動介面可預測，從而減少了早期AI專案中佔主導地位的膠水代碼稅。
MCP的優勢（和不足）
優勢
- 互操作性：一種通用協議減少了一次性整合和供應商鎖定。
- 工具生命週期：伺服器可以進行版本控制、測試並作為標準化功能分發。
- 多環境覆蓋：同一伺服器可以為CLI代理、聊天UI和IDE副駕駛提供服務。
- 社群驅動的生態系統：精選的伺服器列表和示例可幫助團隊更快地入門。
局限性
- 早期成熟度：企業級安全性、治理和SLA仍在發展中。
- 運營複雜性：運行和保護MCP伺服器會增加基礎設施開銷。
- 模型供應商差異仍然存在：MCP標準化了工具端，但模型行為不同。
- 不是完整的代理框架：您仍然需要計劃、記憶體和編排層。
MCP與替代方案：何時使用
- MCP與OpenAI函數調用：
- 對於單一供應商、快速原型設計且不優先考慮可移植性的情況，請選擇OpenAI函數。
- 對於具有可重複使用伺服器和一致語義的多模型、多環境工具訪問，請選擇MCP。
- MCP與LangChain工具：
- LangChain提供框架級別的抽象和編排。
- MCP提供了一種可以由LangChain使用或與之一起使用的協議；它是關於共享佈線，而不是替換計劃邏輯。
- MCP與代理框架（AutoGen、CrewAI、Semantic Kernel等）：
- 代理框架處理計劃、角色和協調邏輯。
- MCP可以將標準化工具/資源提供給這些框架，以避免定制適配器。
- MCP與即時API（例如，串流語音、視覺、事件）：
- 即時API側重於低延遲的多模態互動。
- MCP標準化了與外部工具和資料的橋樑；將兩者都用於具有操作功能的語音代理。
安全性、治理和合規性：需要注意的事項
安全性是協議在企業中生存或死亡的地方。主要考慮因素：
- 身份驗證/授權：客戶端如何獲得對伺服器和工具的範圍權限？基於令牌的身份驗證、服務帳戶和每個工具的策略至關重要。
- 資料邊界：確保資源訪問（文件、資料庫）尊重最小權限和環境隔離。
- 可觀察性：記錄工具調用及其輸入/輸出以進行審計，但要編輯機密。
- 速率限制和配額：MCP伺服器應強制執行每個客戶端的預算以防止濫用。
- 治理工作流程：對伺服器進行版本控制、審查變更並發佈到私有註冊表。
重要的評論呼籲在這裡更加成熟，大多數團隊將需要疊加自己的安全態勢，直到生態系統標準化最佳實踐。
您現在可以交付的真實世界用例
- 具有真實文件和儲存庫訪問權限的IDE副駕駛：將文件讀/寫、測試運行器和套件管理器公開為MCP工具，以便您的編碼助手可以在防護欄的幫助下重構、運行測試和起草提交。
- 具有資料合規性的企業副駕駛：通過MCP伺服器提供對CRM/ERP/BI的唯讀視圖；嵌入行級權限和審計日誌記錄。
- 受監管內容的檢索：使用MCP公開經批准的知識庫和策略片段；模型永遠不會直接接觸原始系統。
- 運維自動化：工單分類、事件運行手冊和部署劇本作為工具，可由具有顯式步驟的代理觸發。
- 分析和SQL工作流程：提供參數化查詢和安全結果抽樣的資料庫MCP伺服器。
社群策劃的MCP伺服器列表可以幫助您通過經過實戰考驗的整合快速啟動。
開發人員體驗：使用MCP構建是什麼樣的
- 編寫伺服器：使用名稱、輸入架構、輸出形狀、權限定義工具。 實施處理程式；通過MCP傳輸公開。
- 在本地運行，集中部署：從用於開發的本地伺服器開始，然後部署到用於團隊的共享環境。
- 連接客戶端：與您的聊天UI、IDE插件或使用MCP的代理運行時整合。
- 使用合約進行迭代：將您的工具列表和架構視為API - 對其進行版本控制、測試並發佈發行說明。
對於任何已經發布微服務的人來說，這種模式都非常熟悉，但回報是您的「工具服務」可以在許多模型體驗中重複使用。
採用信號和生態系統健康狀況
- 主要諮詢公司的思想領導力持謹慎樂觀態度，強調實際利益而非炒作。
- 獨立分析師正在探索邊緣 - 安全性、可靠性以及大規模運營伺服器的成本。
- 從業者分享早期的成功案例和伺服器目錄，表明構建者之間的基層吸引力。
這不是必然的結論，但方向是有希望的：一個減少重複工作的標準主導層正是生態系統所需要的。
MCP如何適應您在2025年的技術堆疊
- 如果您正在交付一個與一個LLM供應商相關的單一副駕駛：從原生函數調用開始；在您預見多環境重複使用的地方引入MCP。
- 如果您正在構建平台功能（內部或面向客戶）：儘早使用MCP以避免定制適配器；為核心系統發佈內部伺服器。
- 如果您正在運行代理框架：將MCP用作工具平面；使用您首選的框架保持計劃/記憶體。
- 如果您需要嚴格的治理：從第一天開始就使用企業身份驗證、權限和審計層包裝MCP伺服器。
順便說一句，如果您的團隊在瀏覽器中進行原型設計，並且需要將模型連接到Web內容、PDF和編碼工作流程，那麼值得注意的是，Sider.AI可以充當前端副駕駛，同時將工具訪問委託給標準化的後端（如MCP伺服器），從而幫助您在標準演變時將UX與整合層分開，同時保持靈活性。
一個實際的推出計劃（90天）
- 第1-2週：選擇兩個高價值工具（例如，搜索+資料庫讀取）並定義架構。構建具有身份驗證的最小MCP伺服器。
- 第3-4週：連接內部聊天UI或IDE插件；與5-10個用戶進行測試。檢測日誌並添加防護欄。
- 第5-6週：添加兩個更多工具（例如，具有審查閘的票務+文件寫入）。記錄版本控制和SLA。
- 第7-10週：通過真實工作流程（支持分類、銷售問答或代碼重構）進行試點。 測量節省的時間和錯誤率。
- 第11-12週：生產化：可觀察性、速率限制、機密管理、災難恢復和私有伺服器註冊表。
結論：您應該押注MCP嗎？
簡短的回答：是的 - 如果您關心跨模型和應用程式的可移植性、治理和可重複使用性。 MCP不會取代您的代理邏輯或您的供應商API，但它為您提供了一致的工具平面，從而減少了整合稅並加速了多介面副駕駛。
需要謹慎的地方：安全性和運營成熟度。如果您處於受監管的環境中，請整合您的控制並將MCP伺服器視為一等服務，而不是側車。
需要關注的事項：開源伺服器的增長、IDE/客戶端支持以及更清晰的authz和可觀察性最佳實踐。如果這些加速，MCP將成為將AI連接到現實世界的預設方式。
主要結論
- 模型上下文協議標準化了模型訪問工具和資料的方式，從而減少了膠水代碼並提高了可移植性。
- 它作為跨IDE、聊天應用程式和代理運行時的共享工具平面最強大；它不能替代計劃框架。
- 早期的生態系統吸引力是真實的，但企業應該分層安全性、治理和可觀察性。
- 如果您已經在使用代理框架或多模型堆疊，MCP自然適用並且可以快速獲得回報。
詞彙表（快速入門）
- MCP伺服器：通過模型上下文協議公開工具/資源的服務。
- MCP客戶端：發現並調用伺服器功能的應用程式（IDE、聊天UI、代理運行時）。
- 工具：模型可以通過客戶端調用的結構化、類型化的操作。
- 資源：通過標準化介面公開的外部資料（文件、資料庫行、文檔）。
常見問題解答
Q1：什麼是AI中的模型上下文協議？
模型上下文協議是一個開放標準，它定義了AI模型如何通過一致的介面訪問外部工具和資料。 它將模型行為與定制整合解耦，從而實現可重複使用的伺服器和跨應用程式和模型的可移植工具訪問。
Q2：MCP與OpenAI函數調用相比如何？
OpenAI函數調用是供應商特定的，非常適合與單個供應商進行快速整合。 MCP是模型不可知的，並且可以跨環境標準化工具訪問，使其更適合多模型或多介面副駕駛。
Q3：模型上下文協議是否已為企業做好生產準備？
它很有希望但仍在成熟。 企業可以採用具有分層安全性的MCP - 身份驗證、權限、可觀察性和治理 - 同時監控生態系統最佳實踐和伺服器註冊表。
Q4：MCP可以取代LangChain或代理框架嗎？
不能。MCP標準化了工具和資源平面，而LangChain、AutoGen或Semantic Kernel等框架處理計劃和編排。 它們是互補的：使用MCP將工具公開給您選擇的框架。
Q5：模型上下文協議的實際用例是什麼？
常見的用例包括具有安全文件訪問權限的IDE副駕駛、從CRM和知識庫讀取的企業副駕駛、通過批准的內容進行檢索，以及運維自動化，例如工單分類或運行手冊執行。
