MCP:AI 時代的工具接口標準?
1.前言
自從 OpenAI 在 2023 年推出函數調用(Function Calling),我一直思考,咋能真正解鎖 AI Agent與工具的生態系統。隨基礎模型越來越智能,AI Agent與外部工具、數據和 API 的交互方式卻變得越來越碎片化——開發者需針對每一個系統單獨編寫業務邏輯,讓Agent能夠適配不同環境。
2.標準化
顯然,我們需要一個標準化的接口來執行任務、獲取數據并調用工具。在互聯網時代,API 讓不同軟件之間可以相互通信,成為了軟件的通用語言。但對 AI 模型,目前還缺這樣的標準。
2024 年 11 月,**模型上下文協議(Model Context Protocol,MCP)**發布,迅速引起關注,被認為可能成為這一問題的解決方案。本文探討:
- MCP 是什么?
- 它如何改變 AI 與工具的交互方式?
- 開發者已經用 MCP 構建了哪些應用?
- MCP 仍然面臨哪些挑戰?
3.什么是 MCP
MCP 是一種開放協議,旨在讓不同系統能夠為 AI 模型提供可泛化的上下文信息。它規定了AI Agent如何調用外部工具、獲取數據,并與服務交互。
Resend MCP 服務器可以同時與多個 MCP 客戶端交互,使其具備郵件發送能力。MCP 靈感源于語言服務器協議(LSP,Language Server Protocol)。在 LSP 中,當用戶在代碼編輯器中輸入時,客戶端會向語言服務器請求自動補全建議或代碼診斷。
MCP進一步拓展,采用面向 AI Agent的執行模式:
- LSP 主要是被動的,只會在 IDE 發請求時提供反饋
- MCP 則支持 AI Agent自主決策,可以基于上下文信息選擇合適的工具,并決定調用順序,實現復雜任務的自動化
- MCP 還支持“人類參與(human-in-the-loop)”,允許人在關鍵節點提供額外信息或批準操作
3.MCP目前的熱門應用
如有夠多的 MCP 服務器,用戶就能將任何 MCP 客戶端變成“萬能應用”。
3.1 Cursor
作為一個代碼編輯器,同時也是高質量 MCP 客戶端。安裝不同 MCP 服務器,可變身為:
- Slack 客戶端(連接 Slack MCP 服務器)
- 郵件發送工具(連接 Resend MCP 服務器)
- AI 圖像生成器(連接 Replicate MCP 服務器)
更強大的,用戶可組合多個 MCP 服務器,解鎖新應用場景。如Cursor中,用戶可:
- 使用前端 UI 生成 MCP 服務器,自動創建網頁界面
- 讓 AI Agent調用圖像生成 MCP 服務器,為網頁自動生成一張配圖
這種跨工具協作的能力,正是 MCP 帶來突破。
4.核心應用方向
4.1 面向開發者的工作流優化
對開發者,MCP 一大價值是減少切換工具的時間。
開發者的痛點
“我不想為做某個任務而離開 IDE。”
MCP 服務器正滿足需求,如:
- Postgres MCP 服務器 → 讓開發者直接在 IDE 里執行 SQL 查詢,而無需打開數據庫管理界面
- Upstash MCP 服務器 → 讓開發者在 IDE 里管理緩存索引
- Browsertools MCP 服務器 → 讓代碼Agent訪問瀏覽器控制臺日志,輔助調試
MCP 還能幫助 AI Agent動態獲取代碼相關的上下文,如:
- 爬取網頁內容,為Agent提供實時信息
- 通過 API 自動生成 MCP 服務器,讓 AI Agent能直接訪問工具,而無需手動集成
即開發者可更少寫模板代碼,更多專注于業務邏輯。
4.2 全新的 AI 交互體驗
盡管 MCP 目前在開發者社區最受歡迎,但它的潛力遠不限于技術領域。如:
- Claude Desktop → 讓非技術用戶也能輕松使用 MCP 服務器,如營銷文案生成、設計、客服等任務
- Highlight MCP 客戶端 → 允許用戶通過 @ 命令調用 MCP 服務器,將生成內容直接輸入到任何應用
- Blender MCP 服務器 → 讓不會建模的用戶,通過自然語言描述 3D 模型,AI Agent自動生成對應的圖像或動畫
社區還正在開發適用于 Unity 和 Unreal Engine 的 MCP 服務器,AI 生成 3D 內容的流程正在變得越來越完善。
5.MCP現狀
MCP生態仍處早期階段,主要趨勢:
- 高質量的 MCP 客戶端仍以開發工具為主,但未來會有更多面向商業場景客戶端
- 大多數 MCP 服務器是本地優先(local-first)的,未來可能會向遠程 MCP 服務器擴展
- MCP 市場和托管解決方案正在興起,如 Mintlify 的 MCP 市場、Smithery 和 OpenTools,讓開發者可以更容易發現和共享 MCP 服務器
6.MCP的挑戰
6.1 托管與多租戶支持
目前MCP服務器主要1對1,未來需支持多個用戶同時訪問,尤其SaaS場景。
6.2 身份驗證(Authentication)
MCP 目前沒有標準的身份驗證機制,開發者需要自己實現 OAuth 或 API 令牌管理
6.3 權限管理(Authorization)
MCP 目前的權限是基于會話的,未來需要更細粒度的訪問控制。
6.4 網關(Gateway)
未來 MCP 可能需要一個集中式網關,類似 API 網關,管理身份驗證、授權、流量控制等功能
6.5 MCP 服務器發現與注冊機制
MCP 服務器目前需要手動配置,未來可能會有一個類似 npm 或 RapidAPI 的 MCP 服務器注冊中心,讓 AI Agent自動發現并集成工具。
7.MCP未來:AI Agent的 API 標準?
MCP目前像2010時的 API 生態——新穎但仍處早期階段。若MCP 成為 AI Agent的標準接口,會咋樣?
- 工具競爭力將取決于 AI Agent能否發現并調用它,而不僅是 API 設計是否優秀。
- 定價模式可能改變,AI Agent可能會動態選擇最便宜、最快、最相關的工具,而不是僅僅依賴市場占有率。
- 文檔將變得至關重要,因為 AI Agent需要機器可讀的格式來理解 MCP 服務器的功能。
- API 將不再是終點,開發者需要圍繞具體場景構建 MCP 服務器,而不是簡單地開放 API 端點。
MCP 正在重塑 AI Agent生態,但它的未來取決于開發者如何解決當前的基礎問題。如果一切順利,MCP 可能會成為AI Agent調用工具的默認接口,解鎖全新的自主、多模態、深度集成的 AI 體驗。
本文轉載自??JavaEdge??,作者:JavaEdge
