高手論技

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

關(guān)鍵詞：大模型；MCP協(xié)議；人工智能

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

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

大模型的快速迭代

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

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

大模型的局限與突破

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

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

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

開啟大模型新征程

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

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

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

主機（Host）：Host是用戶與AI系統(tǒng)進行交互的入口，負責(zé)接收用戶的輸入、展示系統(tǒng)的輸出，并協(xié)調(diào)整個交互流程。它可以是一個應(yīng)用程序、網(wǎng)頁界面或嵌入式系統(tǒng)等。

客戶端（Client）：Client運行在Host內(nèi)部，負責(zé)與外部的Server進行通信。它根據(jù)Host的指令，向Server發(fā)送請求，并接收Server返回的響應(yīng)。

服務(wù)器（Server）：Server提供各種外部工具、資源和服務(wù)，供Client調(diào)用。它可以是一個應(yīng)用程序接口（API）、數(shù)據(jù)庫、傳感器設(shè)備或其他智能系統(tǒng)等。

在工作過程中，Host首先接收用戶的請求，然后將其傳遞給Client。Client根據(jù)請求的內(nèi)容和預(yù)定義的規(guī)則，構(gòu)造一個符合MCP協(xié)議的消

MCP協(xié)議采用客戶端-服務(wù)息，發(fā)送給相應(yīng)的Server。Server在接收到消息后，解析其中的指令和參數(shù)，執(zhí)行相應(yīng)的操作，并將結(jié)果以

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

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

1.MCP客戶端-服務(wù)器架構(gòu)工作流程

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

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

請求/響應(yīng)階段：Host在接收到用戶的請求后，會根據(jù)請求內(nèi)容判斷是否需要調(diào)用外部工具。如果需要，Host會指示Client向?qū)?yīng)的Server發(fā)送請求。Server在接收到請求后，會執(zhí)行相應(yīng)的操作，如調(diào)用某個API，然后把結(jié)果返回給Client。Client再把結(jié)果傳遞給Host，Host最后生成最終的響應(yīng)返回給用戶。

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

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

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

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

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

2.系統(tǒng)架構(gòu)與角色定義

Host：用戶意圖的解析與調(diào)度中心、系統(tǒng)的“大腦”，負責(zé)接收用戶輸入、解析意圖、調(diào)度工具并生成最終響應(yīng)，通常是大模型運行的服務(wù)端。

Client：負責(zé)實現(xiàn)MCP協(xié)議的底層通信邏輯，通常是嵌入在Host中的軟件模塊（如Python庫、設(shè)備驅(qū)動），將Host的調(diào)度指令轉(zhuǎn)化為符合JSON-RPC規(guī)范的通信消息與各設(shè)備Server通信。

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

（1）過程一：初始化與能力發(fā)現(xiàn)階段

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

3.關(guān)鍵技術(shù)細節(jié)說明

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

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

（3）過程三：結(jié)果整合與最終響應(yīng)生成

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

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

安全授權(quán)流程：首次調(diào)流式響應(yīng)支持復(fù)雜查詢（如多景點路線規(guī)劃），Server可通過SSE分階段推送結(jié)果（如圖15）。

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

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

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

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

結(jié)語

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