模型上下文協議(Model Context Protocol, 簡稱 MCP)是一種正在迅速普及的協議，它允許模型客戶端與外部服務和工具服務器進行交互，讓模型客戶端不再局限于對話和信息檢索，而是能夠采取實際行動，比如發送郵件、部署代碼、或發布文章等，我在周刊的 30、35、43、44、45 期[1]都曾介紹過。 關于 MCP 介紹的文章已經很多了，本篇不再贅述，這里我想重點談談深度使用下來發現的一些問題，以及這些問題帶來的潛在掘金機會。

有哪些問題

MCP 作為一個開放標準協議，任意的模型客戶端都可以選擇去支持，Sever 端也可以一次構建多處分發，節省開發者的精力，比起模型廠商各自提供的 function calling 或 tool use 確實方便多了，我從去年剛發布就在關注使用，但長期使用下來仍然存在一些問題。

無謂的復雜性

有點為了標準而標準（這也是新進者應對現存守成者的常見策略，可以理解），如果想讓 LLM 使用現有服務，為什么不讓 LLM 直接調用它的 API 呢，利用成熟的 RESTful 和 Swagger/OpenAPI 規范生成工具所需的JSON schema不是更簡潔（ 比如使用 agents.json[2]），專門新建 MCP Server 包裝現有的 API 顯得多此一舉，因此也延伸出新的安全性和訪問權限的問題。

安全性

創建時通過注冊與合法 MCP Server 相似或相同的名稱，欺騙用戶安裝惡意 Server；代碼注入攻擊發生在 MCP Server 的源代碼或配置文件中。

運行時多個工具可能使用相同或相似的名稱，導致在選擇工具時發生沖突，進而執行錯誤的操作或泄露敏感數據，多個工具注冊了相同或類似的命令，導致執行時出現歧義，出現錯誤操作。

在 MCP Server更新后，過時或撤銷的權限未被及時清除，可以繼續利用這些過時權限執行惡意操作，關于這部分的討論更多細節可以查看 論文《Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions》[3]。

訪問權限

企業用戶更傾向于自行托管 MCP Server，并希望分離數據層和控制層確保安全性和合規性，以支持不同用戶訪問 MCP Server，從最新的規范[4]來看，對遠程 Server 已經做了更多的支持，但還存在問題。

基于 OAuth 2.1 的身份驗證機制 將之前的 HTTP+SSE 傳輸方式替換為流式 HTTP 傳輸 支持 JSON-RPC 批處理

即使某工具通過了身份驗證，還需明確其使用范圍，由于 MCP 尚未內置細粒度權限控制，當前僅局限于會話級別，這意味著工具要么完全開放，要么完全禁用，隨著工具數量增加，權限管理將變得日益復雜。

持久連接與狀態性

最初設計更偏向本地運行（uv/uvx 的使用），讓本地服務作為獨立進程進行集成，但子進程會帶來安全隱患。在 MCP 中，連接是有狀態的，支持在連接的生命周期內進行多次請求和響應。這種設計使得客戶端和服務器之間可以進行持續的交互，維護上下文信息，從而提高交互的效率和連貫性，不過這與當前流行的無狀態 API 架構（如 AWS Lambda, Cloudflare Workers）不太契合。

工具過多占用上下文

MCP 當前是將所有工具都塞入模型上下文，缺乏優先級或路由機制，這不僅浪費 token，還可能導致模型行為不穩定，當我讓 Claude Desktop 從超過 60 種的工具列表中的選擇 5 種工具調用時，性能明顯下降，大多數時候它不會選擇最適合的工具，需要一種分級路由（逐步、選擇性暴露 tool 選項）的方式（社區目前在探索通過命名空間和拓撲感知方式進行分層）。

總結

MCP 目前存在的問題還有很多，MCP 社區如果能把上面的問題都能解決好（Roadmap 上都提出了針對性方案[5]），那無疑潛力巨大，在此之前我保持謹慎樂觀，繼續投入我感興趣的 Agent Network 和多輪持續對話場景下工具調用的研究。

問題就是機會

模型上下文協議（MCP）的核心仍然是模型，其主要目標是搶占下一個用戶交互入口，使模型客戶端成為主要的交互界面。通過這種方式，用戶可以通過 API 完成操作，而無需依賴各個垂直 SaaS 軟件的圖形用戶界面（GUI）。

在長鏈條任務中，這種設計與用戶利益一致，因此，OpenAI 沒有理由不支持 MCP，因為在這一點上，它與 Anthropic 的利益是一致的。不過這種模式可能會受到擁有海量用戶的平臺類產品的抵制，因為現有的守成者并不希望大模型成為新的入口，MCP 的陽謀在于“挾開發者和用戶以令巨頭”：即使某些平臺不愿意，標準協議也能幫助它們實現更體面的交互方式 （比如 mcp-browser-use[6]），這種模式對開發者和新創產品具有吸引力。

接下來，除了完善協議本身，模型廠商還需要圍繞消費級需求提供更優化的存儲、Server 商店等配套設施，由于這些領域單靠模型廠商自身難以完全覆蓋，這便為現有基礎設施廠商和開發者創造了機會。

Server 網關

作為 MCP Client 與 Server 之間的中介組件，其主要職責包括統一管理連接、分配任務以及執行安全驗證。

隨著 MCP 的廣泛應用，網關逐漸成為系統中的關鍵中間層，負責統一認證、權限控制、流量調度和工具選擇。其功能類似于傳統的 API 網關，具體包括訪問控制、請求路由、負載均衡，并通過緩存響應提升效率。

在多租戶環境中，網關的作用尤為重要，因為不同用戶和 Agent 可能具有不同的訪問權限，一個標準化的 MCP 網關能夠簡化 Client 與 Server 之間的交互，從而增強系統的安全性、可觀測性和可擴展性，同時讓 MCP 的部署和管理更加便捷。

反應迅速的廠商已經提供類似的能力了，比如 Zapier 推出 MCP 全流程方案[7]，通過一個動態的 MCP 端點將 AI 助手與 Zapier 的廣泛集成網絡連接起來，實現了對超過 8000 個應用的直接訪問。它允許 AI 執行真實動作，如發送 Slack 消息或管理 Google Calendar 事件，Zapier 讓開發者能夠專注于編碼，同時由 Zapier 管理身份驗證、API 限制和安全性，國內的騰訊輕聯、集簡云等 iPaaS 平臺也都可以快速實現類似改造。

Server 發現

用戶要找到并配置 MCP 服務器仍是一個手動過程，需要自行查找服務地址或腳本，配置認證信息，可以構建安裝工具（比如 mcp-get），簡化跨不同 MCP 客戶端的 Server 安裝流程，或者構建一個 Server 目錄導航站，用于發現和訪問可用的 MCP 服務器。

不過根據 官方 2025 上半年的 Roadmap[8]，在分發和發現方面，MCP 包管理（MCP Server 的標準化打包格式）、安裝工具、沙盒安全和服務器注冊表已經在日程上了，到時候按照標準做體驗更好的工具就是機會。

Server 托管

提供遠程 MCP Server 托管的服務，現有基礎設施廠商已經在進入，比如Cloudflare 推出遠程 MCP Server 部署功能[9]，提供四個核心組件來簡化遠程 MCP Server 的構建過程：

• workers-oauth-provider作為一個 OAuth 2.1 庫，簡化了用戶認證和授權流程，使得開發者無需自行實現復雜的 OAuth 認證；

• McpAgent 類集成在 Cloudflare Agents SDK 中，負責處理遠程傳輸，使得 MCP Server 能夠接收和處理來自 MCP Client 的消息；

• mcp-remote是一個適配器，它允許本地 MCP Client 使用遠程 MCP Server，讓這些客戶端能夠連接和使用遠程服務器；

• AI playground作為一個遠程 MCP Client，提供了一個在線聊天界面，允許用戶連接到遠程 MCP Server，并進行必要的認證檢查，從而使得用戶可以直接在網頁上與遠程 MCP Server 交互和測試。

MCP Server 安全可以參考 DevSecOps，需要一大堆安全工具，圍繞 MCP Server 的生命周期，創建階段（包括 Server 注冊、安裝部署和代碼完整性驗證，確保 Server 正確配置并安全準備好處理請求）、運行階段（MCP Server 根據 AI 應用請求執行工具操作，處理命令，執行沙箱機制以保證環境安全，并穩定地與外部資源交互）、更新階段（確保 MCP Server 持續更新并適應需求變化，包含授權管理、版本控制和舊版本管理，防止安全漏洞和權限問題）。

工具調用管理

在構建 MCP 客戶端時，工具選擇是一個關鍵問題，面對海量服務，工具顯然不能全丟進上下文自動選擇（我遇到 60 選 5 已經奔潰了），也不能依賴人工決策，難道每位開發者都需要為工具實現一套獨立的檢索邏輯？是否存在一個可標準化的“中間層”，以減少重復開發并提升效率？其其次缺少工具調用接口和一致的 UI/UX 設計模式，一些工具依賴 slash commands，而另一些則采用自然語言指令。通過引入一個標準化的客戶端層級，可以覆蓋工具的發現、排序和調用過程，從而為開發者和終端用戶提供更一致、更可靠的體驗。

交互需要依次調用多個工具（單輪對話的多步驟工具調用 & 多輪對話的工具分批調用），但當前 MCP 尚未提供內建的工作流管理機制，期望每個客戶端獨立實現中斷恢復、失敗重試等功能既不現實也低效。因此，構建一個統一的工作流管理系統顯得尤為重要。

寫在結尾

如果對 MCP 的使用和理解還不清楚，可以后臺回復「MCP」，手把手教你借助 MCP 構建 Anthropic 官方博客Building effective agents[10]定義的 6 種 Agent 模式，可以作為學習 MCP 的絕佳模板，畢竟 MCP 就是 Anthropic 自己發起的。

如果覺得內容不錯，歡迎點個關注，分享和在看～

參考資料

周刊的 30、35、43、44、45 期: https://liduos.com/the-memeber-newsletter-30.html

agents.json: https://github.com/wild-card-ai/agents-json

論文《Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions》: https://arxiv.org/pdf/2503.23278

最新的規范: https://spec.modelcontextprotocol.io/specification/2025-03-26/

[5]

Roadmap 上都提出了針對性方案: https://modelcontextprotocol.io/development/roadmap#roadmap

[6]

mcp-browser-use: https://github.com/Saik0s/mcp-browser-use

[7]

Zapier 推出 MCP 全流程方案: https://zapier.com/mcp

[8]

官方 2025 上半年的 Roadmap: https://modelcontextprotocol.io/development/roadmap#roadmap

[9]

Cloudflare 推出遠程 MCP Server 部署功能: https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/

[10]

Building effective agents: https://www.anthropic.com/engineering/building-effective-agents