暴論：2025年，程序員必學技能就是 MCP 原創 精華
MCP（模型上下文協議）就像是大模型世界里的“最后一公里”。大膽地說一句，MCP 應該是每個程序員在 2025 年必須掌握的知識點。
大模型的功能確實很強大，但它們也有明顯的短板。例如，大模型在數學計算方面表現不佳。曾經有一個知名的測試，讓大模型比較 9.8 和 9.11 哪個數更大，大約半年前，大部分大模型都會錯誤地回答 9.8 更小。如今，這種情況已經基本得到糾正，這主要得益于 RAG（檢索增強生成）技術。RAG 的原理與 MCP 有異曲同工之妙，它們都像是一個“外掛程序”，只不過 RAG 掛在了 LLM（大型語言模型）端，而 MCP 掛在了客戶端。
再比如，在大模型具備聯網功能之前，它無法告訴你實時天氣。大模型在處理推理工作時表現得更為出色，比如做總結、出報告、寫文章等。這也很合理，畢竟 LLM 的全稱是“大型語言模型”，它在處理語言方面自然更有優勢。再看看多模態模型，比如生圖模型，你讓它畫一幅畫，畫出的是梵高風格還是莫奈風格，對于很多人來說并不重要，只要畫作好看就行。
總結來說，大模型更擅長處理推理類的工作，或者說它在處理那些形而上的事物時更為得心應手。然而，當涉及到特別精細化的工具化操作，尤其是定制化需求時，大模型的表現就不那么理想了。
1、MCP 機制剖析
第一、什么是 MCP？
MCP，全稱 Model Context Protocol，是由 Anthropic 在 2024 年 11 月推出的一項創新技術。Anthropic 是目前公認的在代碼生成領域表現最為出色的大模型 Claude 的開發公司。MCP 作為一個社區共建的開放協議，旨在提供一個通用的開放標準，用于連接大語言模型（LLM）和外部數據及行為。
MCP 的重要性在于它提供了一個標準化的接口，使得大語言模型能夠更高效地與外部世界進行交互。這就好比電腦上的 USB 接口或手機上的 Type-C 接口，無論哪個廠家生產的數據線，只要遵循 USB 或 Type-C 標準，就能用來充電或傳輸數據。同樣，無論哪個硬盤廠商生產的硬盤，只要支持 Type-C 接口，就能連接到電腦上使用。
再舉一個開發中的例子，我們通常使用 JSON 格式進行接口調用。JSON 的格式就是一個標準，只要數據格式符合 JSON 規范，無論誰來接收數據，無論使用哪個 JSON 庫，甚至手動解析，只要符合 JSON 格式，數據傳輸就能暢通無阻。
Anthropic 通過 MCP 制定了一套標準，使得開發者可以基于這一標準構建和連接各種工具和服務。這不僅簡化了開發流程，還極大地擴展了大語言模型的應用場景。通過 MCP，開發者可以輕松地將 LLM 與各種外部數據源和工具集成，從而實現更復雜、更高效的任務處理。
第二、MCP 的核心組件
1.MCP 主機（MCP Hosts）
MCP 主機是那些希望通過 MCP 訪問數據的程序，例如 Claude Desktop、IDE 或其他 AI 工具。目前，像 VsCode 中的 Cline 插件、Cursor、WindSurf 等都支持 MCP，未來支持 MCP 調用的終端都可以成為 MCP 主機。甚至，你自己也可以開發一個客戶端。
2.MCP 客戶端（MCP Clients）
MCP 客戶端是通過協議與服務器保持 1:1 連接的程序。主機和客戶端通常是一起的，客戶端更偏重于編程概念中的解釋。可以類比數據庫工具，比如 Navicat 軟件本身可以理解為主機，而一個 Navicat 可以同時連接多個數據庫，每連接一個數據庫需要一個連接（設置多個），這些連接可以理解為 MCP 里的客戶端。
3.MCP 服務器（MCP Servers）
MCP 服務器是輕量級程序，每個程序通過標準化的模型上下文協議暴露特定功能。這部分是“最后一公里”的具體實現，需要根據具體需求開發。例如，如果你想讓 LLM 訪問自研系統的數據，就需要提供開放接口并供 LLM 使用，這部分就是 MCP 服務器。
MCP 服務可以用 Python、JavaScript（NodeJS）、Java 來開發，目前官方已經開放了這些語言的 SDK。未來，還會有 Go、Rust、.NET 等語言的 SDK。
4.本地數據源（Local Data Sources）
本地數據源包括你的計算機文件、數據庫和服務，MCP 服務器可以安全地訪問這些數據源。
5.遠程服務（Remote Services）
遠程服務是可以通過互聯網訪問的外部系統（例如，通過 API），MCP 服務器可以連接到這些服務。例如，查詢實時天氣時，你的 MCP 服務器需要去國家氣象局等第三方平臺獲取數據，這需要 API 調用。
第三、調用機制
MCP 的調用機制需要客戶端、MCP 服務端和 LLM 三方配合。
1.啟動 MCP 服務
例如，一個查詢天氣的 Spring Boot 應用，按照官方標準實現具體的服務接口，并在本地啟動。
將服務在客戶端進行配置，就像在注冊中心注冊一樣，通常是啟動命令，例如 npx 或 java。客戶端打開后，在本地同時啟動 MCP 服務。
配置文件示例：
{
"mcpServers": {
"spring-ai-mcp-weather": {
"command": "java",
"args": [
"-Dspring.ai.mcp.server.stdio=true",
"-jar",
"/Users/fengzheng/model-context-protocol/weather/starter-stdio-server/target/mcp-weather-stdio-server-0.0.1-SNAPSHOT.jar"
]
},
"brave-search": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-brave-search"
],
"env": {
"BRAVE_API_KEY": "xxxx"
},
"autoApprove": [
"brave_web_search"
]
}
}
}2.調用流程
- 用戶發送消息：用戶通過客戶端應用程序發送一條消息。
- 客戶端傳遞消息：客戶端將用戶的消息傳遞給 LLM。
- LLM 請求工具或數據：LLM 可能需要額外的工具或數據來處理請求，因此向客戶端發出請求。
- 客戶端向 MCP 服務器請求：客戶端根據 LLM 的需求，通過 MCP 協議向 MCP 服務器發送請求。
- MCP 服務器訪問數據源：MCP 服務器根據請求訪問相應的數據源。
- 數據源返回數據：數據源將所需的數據返回給 MCP 服務器。
- MCP 服務器返回工具或數據：MCP 服務器將獲取到的工具或數據返回給客戶端。
- 客戶端提供工具或數據給 LLM：客戶端將工具或數據傳遞給 LLM。
- LLM 返回處理結果：LLM 使用提供的工具或數據生成處理結果，并返回給客戶端。
- 客戶端顯示最終結果：客戶端將 LLM 的處理結果展示給用戶。
整個原理其實比較簡單，但通過這種機制，MCP 能夠極大地擴展 LLM 的能力，使其能夠處理更復雜的任務。
第四、為什么 MCP 重要？
文章開頭提到，盡管大模型功能強大，但它們也有明顯的短板。而這些短板往往對應著一部分用戶的真實需求。例如，有人需要精確的實時天氣信息，這正是大模型的一個短板。有人可能會說，查天氣直接打開一個 APP 不就行了嗎？當然可以，但如果能在一個應用或終端中直接完成，豈不是更方便，省去了拿起手機打開 APP 的麻煩。
再比如，在大模型聊天窗口中直接操作本地數據庫，現在已經有多種 MCP 服務可以實現這一點。
又比如，想要建立自己的知識庫。假設我對大模型說：“把我曾經寫的關于 JVM 的文章找出來，并給我匯總成一篇帶目錄結構的文章合集。” 如果沒有 MCP 的輔助，現有的任何大模型客戶端都無法實現這一需求。但有了可以訪問本地文件的 MCP，這個需求就有可能實現。
類似的需求數不勝數，幾乎每一個現有 APP 的功能都可能成為 MCP 需要支持的功能。
2、MCP、Function Calling、Agent 區別
說到 MCP，就不得不提到 Function Calling 和 Agent。從表面上看，這三者似乎功能相似，目的也相近，都是為了彌補大模型的短板。
第一、MCP
MCP（Model Context Protocol）是一種開放協議，旨在提供一個通用的開放標準，用于連接大語言模型（LLM）和外部數據及行為。MCP 運行在本地（至少目前是），由像 Cursor 這樣的主機（或統稱為終端）調用，可以訪問本地資源、個性化的 API 等。
第二、Function Calling
Function Calling 是 AI 模型與外部函數或服務交互的一種機制。在這種模式下，模型生成一個函數調用請求，宿主應用解析該請求并執行相應的操作，然后將結果返回給模型。Function Calling 通常具有以下特點：
同步執行：調用函數后，程序會等待函數執行完畢并返回結果，才繼續執行后續代碼。
緊耦合：模型與函數或服務之間的關系較為緊密，需要在代碼中明確指定。
特定實現：函數調用的實現方式可能因平臺或服務提供商而異，缺乏統一標準。
第三、Agent
Agent（智能體）是具備自主行動能力的系統，能夠執行一系列復雜的任務，比如前一段時間很火的 Manus。Agent 通常具備以下特征：
自主性：能夠根據環境變化和目標自主做出決策。
任務執行：能夠執行多步驟、多環節的任務，往往需要調用多個工具或服務。
集成性：通常集成多種功能模塊，如 MCP 和 Function Calling，以實現復雜的任務處理。
第四、主要區別
MCP：作為一種協議，主要解決模型與外部工具和數據源之間的交互問題，提供標準化的接口和通信方式。它非常靈活，只要遵循標準，幾乎能實現任何功能。
Function Calling：是模型與特定函數或服務交互的具體實現方式，關注如何在代碼層面實現功能調用。它需要大模型和特定客戶端緊密綁定，靈活性較低。
Agent：是一個復雜的系統，能夠自主執行任務，通常需要結合 MCP 和 Function Calling 等機制，以實現復雜的功能。
通過這些對比，我們可以更清晰地理解 MCP、Function Calling 和 Agent 的功能和應用場景。
3、MCP 發展預測
隨著 AI 的迅猛發展，它將在未來生活的各個領域扮演越來越重要的角色，而 MCP（Model Context Protocol）也將順應這一趨勢不斷進化。以下是對未來可能出現的幾種情況的預測，其中一些已經在逐步成為現實。
第一、超級客戶端的出現
目前，我們為了使用不同的功能，往往需要打開各種各樣的 APP。然而，隨著 AI 的普及，未來可能會出現超級客戶端或終端，就像豆包或小愛同學這樣的智能助手。這些超級客戶端將集成多種工具和服務，為用戶提供統一且無縫的體驗。例如，用戶可以在一個應用中輕松訪問本地文件、數據庫、瀏覽器以及其他服務，無需頻繁切換不同的 APP，從而大大提高工作效率。
以小愛同學為例，目前它主要被用于設置定時提醒和查詢天氣。但如果借助 MCP 的方式，與更多的服務商進行打通，小愛同學將能夠實現更多樣化的需求，為用戶提供更豐富的服務。
第二、MCP 市場的興起
未來可能會出現類似現在應用商店的 MCP 市場。在這個市場中，無論是個人開發者還是公司，都可以提交自己的 MCP。例如，某短視頻平臺可以提交一個推薦視頻的接口，用戶就可以在一個支持 MCP 的客戶端中直接刷視頻。目前，Cline 插件已經具備了 MCP 市場的功能，用戶可以查看并安裝各種開源的 MCP。不過，這一功能還處于初級階段，有時使用起來可能還不夠便捷。
第三、遠程運行能力的實現
MCP 支持多種通信方式，包括本地的 STDIO 和網絡上的 HTTP/SSE。當需要跨機器通信時，MCP 可以利用 HTTP/SSE 實現工具的遠程調用。這意味著，未來的 MCP 系統將能夠在本地和遠程環境中靈活地運行工具，為用戶提供了更廣泛的部署選項。
對于程序員來說，在本地運行 Node、Python、Java 等語言的程序并非難事。然而，對于那些沒有編程經驗的人來說，這無疑是一項艱巨的挑戰。因此，如果希望讓更多的人能夠使用 MCP，就必須解決本地啟動服務的問題，降低使用門檻，使 MCP 更加易于上手和使用。
本文轉載自公眾號玄姐聊AGI 作者：玄姐
