大模型的“智能插座”

高手論技

編者按：在人工智能越來越融入生活的今天，你是否好奇人工智能如何與外部系統“對話”，精準獲取信息并完成任務？Anthropic于2024年推出的MCP協議將給你答案。本系列文章將分兩部分解析MCP協議，本期重點介紹MCP協議的起源和工作原理，下一期將聚焦于MCP協議的具體實現方法。通過這兩期的文章，讀者將能夠了解MCP協議，并掌握其在實際應用中的具體操作方法。

關鍵詞：大模型；MCP協議；人工智能

中圖分類號：G434文獻標識碼：A論文編號：1674—2117（2025）13-0074-07

近年來，大模型技術成為推動行業進步的核心力量，從GPT的誕生開啟預訓練模型的新時代，到ChatGPT引發全球范圍內的廣泛關注與應用熱潮，再到DeepSeek等推理模型能力的不斷提升，人工智能（AI）正深刻影響著人們的生活、工作和學習方式。同時，隨著應用的深入，大模型的局限性也逐漸顯現，促使業界不斷探索新的技術路徑和解決方案，MCP協議便是其中的重要突破之一。

大模型的快速迭代

自2018年OpenAI推出首款GPT模型 GPT-1以來，AI在語言領域的發展便開啟了新的篇章。GPT-1基于Transformer架構，通過在海量文本數據上進行無監督預訓練，在一定程度上達到了理解語言知識以及語義層面的效果，而后隨著該系列模型不斷演進迭代，從GPT-2到GPT-3，模型參數量也在不斷提高，模型性能得到了極大程度的提升，特別是GPT-3幾乎能覆蓋絕大多數自然語言處理的文本生成任務，并能在如文本生成、問答、翻譯等任務中生成連貫、通順、具邏輯性的語句，促使更多的AI應用于自然語言處理方面。2022年底，基于GPT-3.5版優化微調而來的ChatGPT火爆全球，它可以根據對話場景展開工作，能夠自如地與人類對話，無論是旅游攻略問詢，還是知識性了解等，都可以得到準確又實用的答案。

隨著GPT和ChatGPT的成功，全球科研機構和企業紛紛涌入大模型研發賽道。我國的深度求索公司在2024年12月26日推出的DeepSeekV3在對話式AI及通用任務處理上表現優異；2025年1月20日推出的DeepSeekR1則在推理能力上一騎絕塵，在編程、數學等深度思考任務中超越OpenAI的ol模型。該系列模型不僅性能卓越，還在成本效益和開源策略上獨樹一幟。DeepSeek憑借創新架構設計和訓練方法，大幅降低模型訓練成本，同時采取開源策略，讓眾多開發者和研究人員得以基于其模型進行二次開發、創新應用，有力推動了AI技術的廣泛傳播與發展。

大模型的局限與突破

盡管大模型在語言文字處理甚至邏輯推理方面取得了顯著成就，但它們仍然存在一定的局限性。首先，大模型的知識更新存在滯后性，其訓練數據是基于過去某個時間點之前的信息，對最新的事件、知識和技術無法及時更新。其次，大模型生成的內容可能存在準確性和可靠性問題，尤其是在涉及專業領域知識時，容易出現錯誤或誤導性的回答。更大的難題是大模型在面對需要與外部世界進行交互和操作的任務時顯得無能為力，如控制外圍設備、調用特定軟件的功能等。為了解決這些局限性，RAG（Retrieval-AugmentedGeneration，檢索增強生成）和FunctionCalling（函數調用）應運而生。

RAG有效地解決了大模型知識更新不及時和生成內容準確性的問題。傳統的大模型主要依賴預訓練數據中的知識，而RAG通過引入外部知識檢索機制，在生成內容時能夠實時從網頁或數據庫中不斷抓取新知識，并帶到模型的生成任務中去，其工作原理如圖1所示（圖片來源于Daily Dose of Data Science）。例如，可以直接抓取相關的網站或數據庫，并將其中的內容加入到自己的回答中，或者針對某個領域，調用該領域相應的專業資料，然后再向模型提問，就能回答出更加專業準確的答案。RAG有著諸多優點，但也有劣勢。首先，由于在模型生成的過程中需要對外部知識進行檢索，因而需要付出大量的計算代價以及時間，這會延長模型做出回應的時間。其次，最終獲得的知識信息由檢索質量決定，在檢索過程中如果信息是錯誤的或者偏離問題太遠，最終生成的答案也會隨之發生偏差。RAG雖然對復雜語義理解和推理任務具有一定作用，但仍需依靠大模型自身的能力，在面對深度理解及綜合分析類問題時效果有限。

Function Calling可以讓大模型進入真實世界，實現由文字理解到文字產生，最后到行為輸出的躍遷。其讓大模型可以調用外部世界的函數或者工具去做一些事情，如調用第三方的API來獲取信息、連接外部世界的設備去做一些簡單的事情、執行如使用某種APP程序等更為復雜的功能。Function Calling在幫助大模型打破語言處理上的桎梏的同時，也能讓它實現更好的應用。例如，在數據分析領域，通過調用相關的函數來實現對數據的清洗、抽取或者其他操作，并在這些相關工作都完成之后生成一個相關的報表，這樣就可以更好地實現功能的發揮。其具體的工作原理如圖2所示（圖片來源于DailyDose ofData Science）。但同時它也產生了一些新的問題：一方面要建立模型的調用接口以及規則，保證大模型可以了解并調用正確的函數（這對模型開發與維護是不小的負擔）；另一方面，如何保證模型可以在調用的過程中避免或應對出現的錯誤等。除了模型要對具體的指定的函數或者動作進行相應的權限校驗，保證能調用到的是已授權的之外，也涉及一些安全問題。

開啟大模型新征程

隨著大模型應用領域的不斷擴大，對高效、安全、通用的模型間通信及交互的協議需求也在逐漸增加。為了滿足大模型與外界系統有效交流、大模型協同工作，以及對整個資源進行統一管理的要求，Anthropic公司于2024年11月25日發布了MCP協議（ModelContextProtocol模型上下文協議），以保證大模型更好地參與到多種任務場景之中，實現更有效率的工作。

MCP協議通過標準化的JSON消息格式和通用通信協議（如JSON-RPC、HTTP、WebSocket等），封裝多種不同的協議，從而實現與各種外部工具和數據源的交互。這種封裝方式使得開發者可以更加專注于AI模型的開發，而無需過度關注不同工具之間的集成問題。只需實現與MCP協議兼容的客戶端，即可與不同類型的服務器無縫連接。與RAG和Function Calling相比，MCP協議提供了統一的接口，解決了不同數據源和工具之間的兼容性問題，降低了集成成本，使AI模型能夠輕松接入多種服務，減少了開發和維護的工作量。此外，MCP協議的雙向通信機制支持更復雜和智能的交互，為未來智能應用提供了廣泛的可能性。同時，它支持多種數據傳輸機制和傳輸層協議，具有良好的擴展性，能夠適應不同的應用需求。

器（Client-Server）架構，工作流程如圖3所示，主要包括以下三個核心組件：

主機（Host）：Host是用戶與AI系統進行交互的入口，負責接收用戶的輸入、展示系統的輸出，并協調整個交互流程。它可以是一個應用程序、網頁界面或嵌入式系統等。

客戶端（Client）：Client運行在Host內部，負責與外部的Server進行通信。它根據Host的指令，向Server發送請求，并接收Server返回的響應。

服務器（Server）：Server提供各種外部工具、資源和服務，供Client調用。它可以是一個應用程序接口（API）、數據庫、傳感器設備或其他智能系統等。

在工作過程中，Host首先接收用戶的請求，然后將其傳遞給Client。Client根據請求的內容和預定義的規則，構造一個符合MCP協議的消

MCP協議采用客戶端-服務息，發送給相應的Server。Server在接收到消息后，解析其中的指令和參數，執行相應的操作，并將結果以

MCP協議規定的格式返回給Client。Client在收到響應后，將其傳遞回Host，Host再將最終的結果展示給用戶。整個過程遵循JSON-RPC2.0協議，確保了信息傳遞的準確性和可靠性。

案例模擬—天氣查詢與出行建議

1.MCP客戶端-服務器架構工作流程

初始化階段：Host在啟動時，會創建一個Client實例，Client會主動去連接Server，雙方進行初始化握手。這個過程主要是確認雙方的版本號是否匹配。

能力交換階段：Client會向Server請求提供能力列表，包括可用的工具、資源和提示。Server在收到請求后，會返回一個能力列表，描述每個工具和資源的功能。這一步相當于雙方互相了解對方能提供什么服務。

請求/響應階段：Host在接收到用戶的請求后，會根據請求內容判斷是否需要調用外部工具。如果需要，Host會指示Client向對應的Server發送請求。Server在接收到請求后，會執行相應的操作，如調用某個API，然后把結果返回給Client。Client再把結果傳遞給Host，Host最后生成最終的響應返回給用戶。

通知階段：在某些情況下，Server可能還需要向Client發送一些通知，如資源更新通知、進度通知等。Client在收到通知后，會更新本地的狀態，并觸發一些回調函數

通信細節：Client和Server之間的所有通信都遵循JSON-RPC 2.0協議，通過標準輸入輸出流（stdio）字段。

或服務器推送事件（SSE）進行傳輸。每個請求和響應都封裝成一個JSON對象，包含方法名、參數、ID等

安全和權限：在Sampling原語中，Server在請求AI模型進行推理時，需要用戶明確授權。協議限制了Server對提示內容的可見范圍，以保護用戶隱私。

全流程如第76頁圖4所示。Host相當于一個協調者，負責接收用戶請求并生成最終響應；Client相當于一個中間人，負責與Server建立連接并協調消息傳遞；Server相當于一個資源庫，提供各種工具和資源供Client調用。三者通過JSON-RPC協議進行標準化通信，實現了大模型與外部系統的高效交互。

2.系統架構與角色定義

Host：用戶意圖的解析與調度中心、系統的“大腦”，負責接收用戶輸入、解析意圖、調度工具并生成最終響應，通常是大模型運行的服務端。

Client：負責實現MCP協議的底層通信邏輯，通常是嵌入在Host中的軟件模塊（如Python庫、設備驅動），將Host的調度指令轉化為符合JSON-RPC規范的通信消息與各設備Server通信。

Server： ① 天氣預報Server。僅提供weather.query工具（查詢指定城市、日期的天氣）。 ② 地圖服務Server。整合map.recommend（景點推薦）、map.route（路線規劃）、map.restaurant（餐廳推薦）三個工具集成。

（1）過程一：初始化與能力發現階段

① Host啟動Client連接Server（如上頁圖5）。② 能力交換：Client獲取Server工具列表（如上頁圖6）。

3.關鍵技術細節說明

（2）過程二：用戶請求處理，多輪工具調用流程

① 用戶輸入解析與首輪工具調用（如上頁圖7）。② 基于天氣結果調用景點推薦工具（如上頁圖8）。③ 調用路線規劃工具（以頤和園為例），如圖9所示。④ 調用餐廳推薦工具（頤和園周邊），如圖10所示。

（3）過程三：結果整合與最終響應生成

① Host整合多輪工具調用結果（如圖11）。② Server向Client推送最終結果（如下頁圖12）。③ Host向用戶返回自然語言響應（如下頁圖13）。

上下文管理機制：整個流程通過contextId：\"beijing-trip-001\"串聯所有工具調用，Host可追溯歷史交互記錄，如用戶后續詢問“頤和園就餐環境如何”時，可直接通過contextId獲取餐廳推薦數據。

安全授權流程：首次調流式響應支持復雜查詢（如多景點路線規劃），Server可通過SSE分階段推送結果（如圖15）。

用weather.query時攜帶authorization字段，用戶需通過生物識別或密碼完成授權，Server根據權限列表限制數據訪問范圍（如僅允許獲取北京天氣，禁止訪問其他城市）。

錯誤處理示例：若路線規劃Server返回錯誤（如\"起點不可達\"），Client會自動重試并觸發備用方案（如圖14）。

Host在接收到錯誤后，會調用備選路線規劃（如公交方案）或提示用戶確認起點信息。

通過該案例可見，MCP協議通過標準化的能力描述、上下文管理和多輪交互機制，使大模型能夠高效協調多個外部工具，將自然語言請求轉化為完整的現實世界解決方案，顯著提升了AI系統的實用性和智能化水平。

結語

Anthropic公司推出的MCP協議擁有極強的兼容性以及擴展性，可讓大模型進行相互之間的交流以及同外界的交互，并可提供安全可靠的交流方式，大大增強了大模型的學習能力。相信隨著Deepseek等國產大模型的強勢崛起，我國人工智能領域的研究水平將會進一步得到提升。但與此同時也要注意到人工智能領域所引發的相關倫理、安全等風險，并據此進行把控，以使其朝著正確的方向發展。