議詳解：AI Agent與外部工具的標(biāo)準(zhǔn)通信協(xié)議)
1. 從“AI Agent 的通用語言”說起為什么我們需要 MCP如果你最近在折騰 AI Agent尤其是那些需要調(diào)用外部工具、訪問數(shù)據(jù)庫或者操作復(fù)雜系統(tǒng)的 Agent你大概率會遇到一個核心痛點如何讓大語言模型LLM穩(wěn)定、可靠地與五花八門的外部資源對話我們當(dāng)然可以寫一堆零散的提示詞Prompt告訴模型“調(diào)用 API A 時用這個格式查詢數(shù)據(jù)庫 B 時用那個 SQL”。但這種方式在 Agent 功能稍微復(fù)雜一點后就會迅速變成一場維護噩夢。API 變了怎么辦新增一個數(shù)據(jù)源怎么辦不同工具返回的數(shù)據(jù)格式千差萬別模型能準(zhǔn)確理解嗎這背后是一個更本質(zhì)的問題在 AI Agent 的架構(gòu)中LLM大腦與外部工具手腳之間缺乏一種標(biāo)準(zhǔn)化的“通信協(xié)議”。就像人類社會的繁榮離不開語言和交通規(guī)則AI Agent 生態(tài)的規(guī)?；l(fā)展也需要一套被廣泛認可的“基礎(chǔ)協(xié)議”。這就是MCPModel Context Protocol出現(xiàn)的背景。它不是某個具體產(chǎn)品的 SDK而是一個由 Anthropic 牽頭、社區(qū)推動的開放協(xié)議。你可以把它理解為AI Agent 世界的“USB 協(xié)議”或“HTTP 協(xié)議”。它的目標(biāo)極其明確為 LLM 與任何外部數(shù)據(jù)源、工具或服務(wù)之間定義一套統(tǒng)一的、標(biāo)準(zhǔn)化的對話方式。簡單來說MCP 試圖回答“一個工具應(yīng)該以何種格式告訴 LLM ‘我能做什么’能力聲明LLM 又應(yīng)該以何種格式告訴工具‘請執(zhí)行這個動作’調(diào)用請求工具執(zhí)行完畢后又該如何把結(jié)果‘打包’好送回給 LLM響應(yīng)格式”理解了 MCP 要解決的“元問題”我們再來拆解它的具體實現(xiàn)。本系列文章我們將深入 MCP 協(xié)議的內(nèi)部從最基礎(chǔ)的消息格式到支撐其運行的傳輸層進行一次完整的“庖丁解?！?。今天這篇就是整個子系列的地基。2. MCP 協(xié)議的核心設(shè)計哲學(xué)聲明式與標(biāo)準(zhǔn)化在深入技術(shù)細節(jié)前我們必須先把握 MCP 的設(shè)計哲學(xué)這決定了它所有技術(shù)選擇的走向。MCP 的設(shè)計可以概括為兩個關(guān)鍵詞聲明式Declarative和標(biāo)準(zhǔn)化Standardized。2.1 聲明式讓工具“自我介紹”而非“被命令”傳統(tǒng)的集成方式是“命令式”的。開發(fā)者需要寫死代碼當(dāng)用戶說 X 時就調(diào)用函數(shù) Y并手動處理參數(shù) Z。這種方式將工具的邏輯硬編碼進了 Agent 的核心流程里。MCP 則采用了聲明式。工具在 MCP 中稱為 Server不需要被“命令”如何工作它只需要向 LLM在 MCP 中稱為 Client清晰地“聲明”自己有哪些能力以及使用這些能力需要提供什么信息。例如一個天氣查詢工具會聲明“我叫‘天氣查詢’我能根據(jù)‘城市名’這個參數(shù)返回該城市的天氣信息。” 它不需要知道 LLM 具體怎么組織對話只需要定義好能力的“接口規(guī)范”。這樣做的好處是巨大的動態(tài)發(fā)現(xiàn)與組合LLM或 Agent 框架可以在運行時動態(tài)發(fā)現(xiàn)可用的工具并根據(jù)當(dāng)前對話上下文智能地選擇并組合使用它們。工具可以隨時上線、下線或更新而無需修改 Agent 的核心邏輯。降低耦合工具提供方和 Agent 開發(fā)者可以獨立工作。工具提供方專注于實現(xiàn)功能并發(fā)布符合 MCP 協(xié)議的 ServerAgent 開發(fā)者則專注于設(shè)計提示詞和業(yè)務(wù)流程通過標(biāo)準(zhǔn)協(xié)議連接所需工具。提升可靠性由于交互格式是標(biāo)準(zhǔn)的LLM 生成錯誤調(diào)用的概率會降低工具也能更準(zhǔn)確地解析請求并返回結(jié)構(gòu)化的結(jié)果。2.2 標(biāo)準(zhǔn)化定義通用的“詞匯表”和“語法”聲明式的前提是大家說同一種語言。MCP 通過定義一系列標(biāo)準(zhǔn)化的 JSON Schema為工具能力的描述、調(diào)用請求和響應(yīng)建立了通用的“詞匯表”和“語法”。資源Resources代表可被讀取的靜態(tài)或動態(tài)數(shù)據(jù)如一個文件、數(shù)據(jù)庫查詢結(jié)果、API 返回的 JSON。MCP 定義了如何描述一個資源URI、MIME 類型、元數(shù)據(jù)以及如何讀取它resources/listresources/read。工具Tools代表可執(zhí)行的操作通常帶有輸入?yún)?shù)并產(chǎn)生副作用或返回結(jié)果如發(fā)送郵件、創(chuàng)建日歷事件、執(zhí)行命令。MCP 定義了工具的描述格式名稱、描述、輸入?yún)?shù) Schema和調(diào)用方式tools/listtools/call。提示詞模板Prompts一種特殊的資源它本身是一個文本模板可以被 LLM 獲取并用于生成更復(fù)雜的提示詞。這允許工具提供領(lǐng)域特定的提示詞片段。這三種核心抽象幾乎涵蓋了 AI Agent 需要與外部世界交互的所有主要模式。通過將它們標(biāo)準(zhǔn)化MCP 為 Agent 構(gòu)建了一個豐富、可插拔的“外部能力市場”。3. 消息格式全解MCP 協(xié)議的數(shù)據(jù)交換單元協(xié)議的核心是消息。MCP 中所有的通信都基于 JSON-RPC 2.0 規(guī)范這是一種輕量級的遠程過程調(diào)用協(xié)議。選擇 JSON-RPC 是因為它簡單、通用、語言無關(guān)并且有成熟的客戶端/服務(wù)器實現(xiàn)庫。一條 MCP 消息就是一個 JSON-RPC 消息。它主要包含以下幾個部分3.1 請求Request消息格式當(dāng) Client通常是 LLM 端或 Agent 框架需要 Server工具端做某事時會發(fā)送一個請求。{ jsonrpc: 2.0, id: 1, method: tools/list, params: {} }jsonrpc: 固定為2.0表明遵循 JSON-RPC 2.0。id: 請求的唯一標(biāo)識符數(shù)字或字符串。這個id至關(guān)重要因為 Server 的響應(yīng)必須攜帶相同的id這樣 Client 才能將響應(yīng)與對應(yīng)的請求匹配起來尤其是在異步通信中。method: 要調(diào)用的方法名。MCP 定義了一系列標(biāo)準(zhǔn)方法如tools/list列出所有工具、tools/call調(diào)用一個工具、resources/list列出所有資源等。params: 調(diào)用方法所需的參數(shù)是一個對象。例如調(diào)用tools/call時params里會包含工具名和具體的輸入?yún)?shù)。一個完整的tools/call請求示例假設(shè) Server 聲明了一個名為get_weather的工具它需要一個city參數(shù)。{ jsonrpc: 2.0, id: req_weather_001, method: tools/call, params: { name: get_weather, arguments: { city: 北京 } } }這里id用了字符串req_weather_001method是tools/callparams里指明了要調(diào)用的工具名和具體的參數(shù)。3.2 成功響應(yīng)Success Response消息格式Server 處理請求成功后會返回一個成功響應(yīng)。{ jsonrpc: 2.0, id: 1, result: { tools: [ { name: get_weather, description: 獲取指定城市的天氣信息, inputSchema: { type: object, properties: { city: { type: string, description: 城市名稱例如北京、上海 } }, required: [city] } } ] } }id: 必須與對應(yīng)請求的id完全一致。result: 請求的執(zhí)行結(jié)果。其內(nèi)容完全取決于method。例如對于tools/listresult是一個包含tools數(shù)組的對象對于tools/callresult會包含工具執(zhí)行后的輸出內(nèi)容可能是一個文本、一個結(jié)構(gòu)化對象甚至是一個包含多部分內(nèi)容文本、圖片、代碼的復(fù)雜結(jié)構(gòu)。接上例get_weather調(diào)用的成功響應(yīng)可能如下{ jsonrpc: 2.0, id: req_weather_001, result: { content: [ { type: text, text: 北京當(dāng)前天氣晴氣溫 25°C西北風(fēng) 2級。 } ] } }MCP 定義了一個靈活的content數(shù)組來承載結(jié)果支持text、image、resource等多種類型這為返回豐富內(nèi)容提供了可能。3.3 錯誤響應(yīng)Error Response消息格式如果請求無效或處理出錯Server 返回錯誤響應(yīng)。{ jsonrpc: 2.0, id: 1, error: { code: -32602, message: Invalid params, data: The parameter city is required but was not provided. } }error: 錯誤對象。code: 錯誤碼。JSON-RPC 定義了標(biāo)準(zhǔn)錯誤碼如 -32601 方法未找到-32602 無效參數(shù)MCP 也可以定義自己的應(yīng)用級錯誤碼。message: 簡短的錯誤描述。data可選: 提供關(guān)于錯誤的額外信息如詳細的驗證錯誤信息。3.4 通知Notification消息格式這是一種特殊的、不需要響應(yīng)的請求。它只有method和params沒有id。在 MCP 中這通常用于 Server 向 Client 主動推送信息例如通知某個資源的內(nèi)容發(fā)生了變化。{ jsonrpc: 2.0, method: notifications/resources/updated, params: { uri: file:///path/to/data.json } }Client 收到后可能會根據(jù)通知重新讀取相關(guān)資源但不需要向 Server 發(fā)送響應(yīng)。實操心得消息id的管理在實現(xiàn) MCP Client 時管理好請求id是保證通信可靠性的關(guān)鍵。尤其是在高并發(fā)或異步場景下必須維護一個從id到請求上下文如回調(diào)函數(shù)、Promise的映射。一個常見的坑是id重復(fù)或映射清理不及時導(dǎo)致內(nèi)存泄漏。建議使用單調(diào)遞增的數(shù)字或帶有時間戳的 UUID 來生成id并設(shè)置超時機制來清理過期的映射項。4. 傳輸層剖析MCP 協(xié)議如何“跑”起來定義了消息格式接下來就要解決消息如何在不同進程、甚至不同機器間傳遞的問題。這就是傳輸層的職責(zé)。MCP 協(xié)議設(shè)計上與傳輸層解耦這意味著它可以在多種傳輸方式上運行。目前社區(qū)主要支持和推薦兩種方式stdio標(biāo)準(zhǔn)輸入輸出和SSEServer-Sent Events。4.1 Stdio 傳輸簡單、可靠的進程間通信這是 MCP 最經(jīng)典、也是最常見的傳輸方式尤其適用于 Client 和 Server 在同一臺機器上以父子進程關(guān)系運行的場景。工作原理Client如 Claude Desktop、Cursor 或一個自定義的 Agent 框架啟動一個子進程這個子進程就是 MCP Server你的工具。Client 將自己的標(biāo)準(zhǔn)輸出stdout連接到 Server 的標(biāo)準(zhǔn)輸入stdin。Server 將自己的標(biāo)準(zhǔn)輸出stdout連接到 Client 的標(biāo)準(zhǔn)輸入stdin。雙方通過各自的 stdin 接收消息通過 stdout 發(fā)送消息。所有消息都遵循上一節(jié)定義的 JSON-RPC 格式每一條完整的 JSON 消息通常以換行符\n分隔即 JSON Lines 格式。流程示意圖簡化[Client進程] | | (fork/exec) v [Server進程] | | Client.stdout - Server.stdin (Client發(fā)送請求) | Server.stdout - Client.stdin (Server發(fā)送響應(yīng)/通知) v優(yōu)點部署簡單無需網(wǎng)絡(luò)配置非常適合本地工具集成。安全性好通信完全在本地進程間進行不暴露網(wǎng)絡(luò)端口。資源消耗低沒有網(wǎng)絡(luò)棧開銷。跨語言通用任何支持啟動子進程和讀寫標(biāo)準(zhǔn)流的編程語言都能實現(xiàn)。缺點僅限于本地?zé)o法實現(xiàn)遠程調(diào)用。生命周期綁定Server 進程的生命周期通常由 Client 管理。Client 退出Server 一般也會被終止。一個簡單的 Stdio Server 偽代碼示例Pythonimport sys import json def handle_tools_list(): return { tools: [{ name: echo, description: 回顯輸入的文字, inputSchema: { type: object, properties: {text: {type: string}}, required: [text] } }] } def main(): # MCP Server 通過 stdin 接收stdout 發(fā)送 while True: line sys.stdin.readline() if not line: break try: message json.loads(line) msg_id message.get(id) method message.get(method) if method tools/list: response { jsonrpc: 2.0, id: msg_id, result: handle_tools_list() } sys.stdout.write(json.dumps(response) \n) sys.stdout.flush() # ... 處理其他 method except json.JSONDecodeError: # 發(fā)送錯誤響應(yīng) error_resp { jsonrpc: 2.0, id: msg_id, error: {code: -32700, message: Parse error} } sys.stdout.write(json.dumps(error_resp) \n) sys.stdout.flush() if __name__ __main__: main()4.2 SSE 傳輸面向 HTTP 的輕量級流式通信當(dāng)工具Server需要以遠程服務(wù)的形式存在時例如一個部署在云端的數(shù)據(jù)庫查詢服務(wù)Stdio 就不適用了。這時SSEServer-Sent Events成為了更合適的傳輸層選擇。工作原理MCP Server 作為一個標(biāo)準(zhǔn)的 HTTP 服務(wù)器運行并暴露一個特定的 SSE 端點例如/sse。MCP Client 通過 HTTP 長連接連接到這個 SSE 端點。連接建立后Server 會通過這個 HTTP 連接以 SSE 格式data: {json}\n\n持續(xù)向 Client 推送消息如通知。當(dāng) Client 需要發(fā)送請求如調(diào)用工具時它通過向 Server 的另一個 HTTP 端點例如/rpc發(fā)送 POST 請求來實現(xiàn)。Server 處理該請求并將響應(yīng)通過 SSE 連接發(fā)回或者直接在 POST 請求的響應(yīng)體中返回。這是一種混合模式請求/響應(yīng)用 HTTP POST服務(wù)器推送用 SSE。這種設(shè)計利用了 SSE 在服務(wù)器向客戶端單向推送上的天然優(yōu)勢同時用簡單的 HTTP POST 處理客戶端發(fā)起的請求。優(yōu)點支持遠程訪問工具可以部署在遠程服務(wù)器上被多個 Agent 共享。基于 HTTP兼容現(xiàn)有的 Web 基礎(chǔ)設(shè)施易于在云環(huán)境部署和擴展。原生支持服務(wù)器推送非常適合 MCP 中 Server 主動發(fā)送通知的場景。缺點復(fù)雜度更高需要實現(xiàn) HTTP 服務(wù)器和 SSE 連接管理。存在網(wǎng)絡(luò)延遲不適合對延遲極度敏感的本地操作。需要處理身份認證和授權(quán)在 Stdio 中這不是問題。注意事項傳輸層的選擇策略開發(fā)本地桌面插件或 CLI 工具優(yōu)先選擇Stdio。它與 Claude Desktop、Cursor 等客戶端的集成最為順暢開箱即用。構(gòu)建共享的、中心化的工具服務(wù)例如為團隊提供一個公司內(nèi)部的數(shù)據(jù)庫查詢 Agent 工具應(yīng)選擇SSE over HTTP。你需要仔細設(shè)計 Server 的/sse和/rpc端點并處理好連接狀態(tài)管理和心跳?；?。網(wǎng)絡(luò)環(huán)境不穩(wěn)定如果通信雙方網(wǎng)絡(luò)延遲高或易抖動SSE 的長連接可能不穩(wěn)定需要實現(xiàn)完善的重連機制。Stdio 則沒有這個問題。5. 協(xié)議握手與初始化建立通信的“第一課”在 Client 和 Server 通過選定的傳輸層建立連接后并不能立刻開始請求工具列表或調(diào)用工具。它們需要先進行一次“握手”交換彼此的“身份”和能力信息這個過程稱為初始化Initialization。初始化過程由 Client 主動發(fā)起通過調(diào)用一個特殊的、名為initialize的 JSON-RPC 方法。Client 發(fā)送的初始化請求示例{ jsonrpc: 2.0, id: 0, method: initialize, params: { protocolVersion: 2024-11-05, capabilities: { roots: { listChanged: true }, sampling: { isSupported: false } }, clientInfo: { name: MyAwesomeAgent, version: 1.0.0 } } }protocolVersion: Client 支持的 MCP 協(xié)議版本。這確保了 Client 和 Server 使用兼容的協(xié)議特性。capabilities: Client 聲明自己支持哪些可選的協(xié)議能力。例如roots.listChanged為true表示 Client 可以處理 Server 發(fā)送的關(guān)于根資源列表變更的通知。這類似于 HTTP 的 Feature Detection。clientInfo: Client 的自我介紹方便 Server 進行日志記錄或差異化處理。Server 的初始化響應(yīng){ jsonrpc: 2.0, id: 0, result: { protocolVersion: 2024-11-05, capabilities: { tools: { listChanged: true } }, serverInfo: { name: WeatherService, version: 0.2.1 } } }protocolVersion: Server 確認使用的協(xié)議版本通常與 Client 發(fā)送的一致。capabilities: Server 聲明自己支持或要求哪些能力。例如tools.listChanged: true表示 Server 會在工具列表變化時發(fā)送通知。serverInfo: Server 的自我介紹。只有在收到成功的initialize響應(yīng)后Client 才能發(fā)送其他請求如tools/list或resources/list。隨后Client 通常會發(fā)送一個initialized通知這是一個沒有id的 JSON-RPC 通知告知 Server 初始化流程已完畢可以開始正常工作了。這個握手過程雖然簡單但它是保證通信雙方兼容性和穩(wěn)定性的關(guān)鍵一步。它避免了因版本不匹配或能力不支持而導(dǎo)致的后續(xù)通信混亂。6. 核心方法詳解MCP 協(xié)議的能力清單初始化完成后Client 和 Server 就進入了正式的交互階段。MCP 定義了一套核心的 JSON-RPC 方法構(gòu)成了協(xié)議的能力骨架。理解這些方法是編寫或使用 MCP Server 的關(guān)鍵。6.1 工具Tools相關(guān)方法這是 MCP 中最活躍的部分用于動態(tài)發(fā)現(xiàn)和執(zhí)行操作。tools/list: Client 調(diào)用此方法獲取 Server 提供的所有工具列表。Server 返回的result中包含一個tools數(shù)組每個工具對象都嚴(yán)格遵循聲明式的 Schema包含name、description和inputSchema。inputSchema是一個 JSON Schema 對象定義了調(diào)用該工具所需的參數(shù)這為 LLM 生成正確的參數(shù)提供了“說明書”。tools/call: Client 調(diào)用此方法來執(zhí)行一個具體的工具。請求的params中必須包含name工具名和arguments符合inputSchema的參數(shù)對象。Server 執(zhí)行工具邏輯并將結(jié)果放在響應(yīng)的result.content中返回。這里有一個關(guān)鍵點arguments中的值是由 LLM 根據(jù)自然語言理解和工具 Schema “猜測”生成的因此 Server 端的實現(xiàn)必須對參數(shù)進行嚴(yán)格的驗證和清理防止注入攻擊或意外錯誤。notifications/tools/listChanged: 這是一個從 Server 發(fā)往 Client 的通知沒有id。當(dāng) Server 的工具列表發(fā)生變化如新增、刪除、更新了某個工具時它可以發(fā)送此通知。收到通知后Client 應(yīng)該主動再次調(diào)用tools/list來獲取最新的工具列表。這實現(xiàn)了工具能力的動態(tài)更新。6.2 資源Resources相關(guān)方法用于訪問相對靜態(tài)的、可讀的數(shù)據(jù)內(nèi)容。resources/list: 獲取 Server 提供的所有可用資源的列表。返回的result中包含resources數(shù)組每個資源對象包含uri唯一標(biāo)識符如file:///notes/daily.md、mimeType如text/markdown和name等元數(shù)據(jù)。resources/read: 讀取指定uri的資源內(nèi)容。Server 返回result.content內(nèi)容格式與資源的mimeType對應(yīng)。這對于向 LLM 提供背景文檔、配置文件等內(nèi)容非常有用。resources/subscribe/resources/unsubscribe(可選): Client 可以訂閱某個資源的變化。當(dāng)資源內(nèi)容更新時Server 會通過notifications/resources/updated通知 Client。這對于監(jiān)控日志文件、實時數(shù)據(jù)流等場景至關(guān)重要。notifications/resources/updated: Server 發(fā)送的通知告知 Client 某個已訂閱資源的uri內(nèi)容已更新。6.3 提示詞模板Prompts相關(guān)方法提示詞模板是一種特殊資源旨在幫助 LLM 生成更符合特定場景的提示詞。prompts/list: 獲取可用的提示詞模板列表。prompts/get: 根據(jù)模板名和可選參數(shù)獲取渲染后的提示詞文本。例如一個“代碼審查”模板可能接受code和language參數(shù)Server 會將這些參數(shù)填充到預(yù)定義的模板中生成一段具體的提示詞返回給 ClientClient 再將其用于 LLM 對話。實操心得inputSchema的設(shè)計藝術(shù)定義工具的inputSchema是 MCP Server 開發(fā)中最體現(xiàn)功力的地方之一。一個好的 Schema 應(yīng)該描述精準(zhǔn)description字段要用自然語言清晰說明工具的功能和每個參數(shù)的用途這是 LLM 理解工具的主要依據(jù)。約束明確充分利用 JSON Schema 的type,enum,pattern(正則),minimum/maximum等關(guān)鍵字對參數(shù)進行嚴(yán)格限制。例如對于“城市名”參數(shù)可以設(shè)置enum: [“北京”, “上?！? “廣州”, “深圳”]來避免 LLM 胡編亂造。結(jié)構(gòu)扁平盡量使用扁平的對象結(jié)構(gòu)避免深層嵌套。LLM 在生成復(fù)雜嵌套的 JSON 時更容易出錯。提供示例在參數(shù)的description中或通過 JSON Schema 的examples字段提供示例值能顯著提升 LLM 填充參數(shù)的準(zhǔn)確性。 一個設(shè)計糟糕的 Schema 會導(dǎo)致 LLM 頻繁調(diào)用失敗而一個設(shè)計精良的 Schema 則能讓工具調(diào)用行云流水。7. 安全性與錯誤處理構(gòu)建健壯的 MCP 交互任何協(xié)議在實際應(yīng)用中都必須考慮安全性和魯棒性。MCP 作為連接 LLM 和外部世界的橋梁在這方面尤為重要。7.1 安全性考量輸入驗證與清理首要防線這是 Server 端最重要的安全措施。LLM 生成的arguments是不可信的輸入。Server 必須依據(jù)inputSchema進行嚴(yán)格驗證并對字符串參數(shù)進行清理防止 SQL 注入、命令注入、路徑遍歷等攻擊。永遠不要將 LLM 生成的參數(shù)直接拼接成命令或查詢語句執(zhí)行。權(quán)限最小化MCP Server 進程或服務(wù)應(yīng)該以最低必要的權(quán)限運行。例如一個文件讀取 Server 不應(yīng)該有寫入或刪除文件的權(quán)限。傳輸安全對于Stdio由于是本地進程間通信主要風(fēng)險來自惡意或存在漏洞的 Server 二進制文件。確保從可信來源獲取 Server。對于SSE/HTTP必須使用HTTPS來加密傳輸通道防止中間人攻擊。同時需要實現(xiàn)身份認證如 API Key、JWT Token和授權(quán)機制確保只有合法的 Client 可以連接。MCP 協(xié)議本身不規(guī)定具體的認證方式這需要在 HTTP 層自行實現(xiàn)。沙箱化執(zhí)行對于執(zhí)行任意代碼或命令的工具應(yīng)考慮在沙箱環(huán)境如 Docker 容器、nsjail中運行以隔離潛在風(fēng)險。7.2 錯誤處理與重試策略充分利用 JSON-RPC 錯誤碼Server 應(yīng)返回精確的錯誤碼和消息。例如參數(shù)缺失用-32602工具未找到用-32601自定義的業(yè)務(wù)邏輯錯誤可以使用-32000到-32099的范圍。清晰的錯誤信息有助于 Client或背后的 Agent 邏輯進行決策例如提示用戶補充信息或嘗試其他工具。Client 端的超時與重試網(wǎng)絡(luò)請求或工具執(zhí)行可能超時。Client 端應(yīng)為每個請求設(shè)置合理的超時時間并實現(xiàn)重試邏輯特別是對于冪等的操作如tools/list、resources/read。重試時應(yīng)采用退避策略如指數(shù)退避避免加重 Server 負擔(dān)。連接?；钆c重連針對 SSESSE 長連接可能因網(wǎng)絡(luò)問題中斷。Client 需要監(jiān)聽連接關(guān)閉事件并實現(xiàn)自動重連機制。在重連后可能需要重新執(zhí)行initialize流程并同步狀態(tài)如重新訂閱資源。優(yōu)雅降級當(dāng)某個 MCP Server 不可用時Agent 應(yīng)該有能力跳過該工具或者使用備選方案而不是整個流程崩潰。這要求 Agent 框架具備服務(wù)發(fā)現(xiàn)和健康檢查機制。8. 實戰(zhàn)視角從協(xié)議到實現(xiàn)的關(guān)鍵抉擇理解了協(xié)議規(guī)范當(dāng)我們著手實現(xiàn)一個 MCP Server 或集成一個 MCP Client 時還需要做出一系列工程上的抉擇。8.1 Server 端實現(xiàn)選型你是要開發(fā)一個一次性的小工具還是一個需要服務(wù)化、高可用的企業(yè)級組件快速原型與 CLI 工具使用官方或社區(qū)的SDK是最高效的方式。例如Anthropic 官方提供了TypeScript/JavaScript 的 SDK(modelcontextprotocol/sdk)它封裝了 Stdio/SSE 傳輸、消息序列化、初始化握手等底層細節(jié)你只需要專注于實現(xiàn)工具函數(shù)和資源邏輯。Python 等語言也有活躍的社區(qū) SDK。這能讓你在幾分鐘內(nèi)搭建起一個可運行的 Server。高性能或特殊語言需求如果你需要極致性能或者必須使用某種沒有成熟 SDK 的語言如 Rust, Go你可以基于 JSON-RPC 2.0 規(guī)范從頭實現(xiàn)。核心工作是實現(xiàn)傳輸層讀寫 stdin/stdout 或 HTTP/SSE 服務(wù)器。解析和序列化 JSON-RPC 消息。維護請求id與處理邏輯的映射。實現(xiàn)協(xié)議要求的各個方法處理器initialize,tools/list,tools/call等。 雖然工作量較大但能獲得完全的控制權(quán)。8.2 Client 端集成策略你是在構(gòu)建一個全新的 Agent 框架還是在現(xiàn)有應(yīng)用中如 Claude Desktop, Cursor使用 MCP在支持 MCP 的客戶端中使用這是最簡單的路徑。像 Claude Desktop、Cursor、Windsurf 等應(yīng)用已經(jīng)內(nèi)置了 MCP Client。你通常只需要在配置文件中指定你的 MCP Server 的命令行或 SSE 地址它們就能自動連接并加載工具。你只需要關(guān)心 Server 的實現(xiàn)。在自定義 Agent 框架中集成如果你在自研 Agent 系統(tǒng)你需要將 MCP Client 集成進去。這意味著實現(xiàn)或引入一個 MCP Client 庫用于管理到多個 Server 的連接。在系統(tǒng)啟動時初始化所有配置的 Server 連接。將tools/list返回的工具列表動態(tài)地轉(zhuǎn)換為你的 Agent 系統(tǒng)所能理解的“工具”格式并注入到給 LLM 的提示詞或函數(shù)調(diào)用列表中。當(dāng) LLM 決定使用某個工具時將 LLM 的輸出參數(shù)轉(zhuǎn)換為 MCPtools/call請求發(fā)送給對應(yīng)的 Server并處理響應(yīng)和錯誤。 這相當(dāng)于在你的框架和 MCP 協(xié)議之間建立一個適配層。8.3 調(diào)試與監(jiān)控開發(fā) MCP 組件離不開調(diào)試。日志是生命線在 Server 和 Client 的關(guān)鍵節(jié)點收到請求、發(fā)送響應(yīng)、發(fā)生錯誤添加詳細的日志。對于 Stdio 模式日志可以輸出到 stderr這樣不會干擾正常的 JSON-RPC 消息流stdout。對于 HTTP 模式使用結(jié)構(gòu)化的日志如 JSON并集成到現(xiàn)有的日志系統(tǒng)中。消息流可視化可以編寫一個簡單的“中間人”代理它位于 Client 和 Server 之間將所有經(jīng)過的 JSON-RPC 消息打印出來或保存到文件。這是分析復(fù)雜交互問題的利器。使用現(xiàn)有調(diào)試工具社區(qū)已經(jīng)有一些工具比如mcp-cli它可以作為一個通用的 MCP Client 來連接和測試你的 Server手動發(fā)送請求并查看響應(yīng)非常適合初期調(diào)試。從消息格式的定義到傳輸層的選型從握手初始化的流程到核心方法的調(diào)用再到安全與實踐的考量MCP 協(xié)議為我們勾勒出了一幅清晰的 AI Agent 擴展藍圖。它通過標(biāo)準(zhǔn)化和聲明式設(shè)計將 LLM 與外部世界的交互難題轉(zhuǎn)化為了一個可管理、可擴展的工程問題。掌握 MCP就如同掌握了為 AI Agent 打造“瑞士軍刀”的標(biāo)準(zhǔn)接口規(guī)范。在接下來的子系列文章中我們將深入更多實戰(zhàn)場景探討如何設(shè)計復(fù)雜的工具 Schema如何構(gòu)建生產(chǎn)可用的 MCP 服務(wù)以及 MCP 在具體 Agent 架構(gòu)中的最佳實踐。 MCP協(xié)議詳解：AI Agent與外部工具的標(biāo)準(zhǔn)通信協(xié)議
1. 從“AI Agent 的通用語言”說起為什么我們需要 MCP如果你最近在折騰 AI Agent尤其是那些需要調(diào)用外部工具、訪問數(shù)據(jù)庫或者操作復(fù)雜系統(tǒng)的 Agent你大概率會遇到一個核心痛點如何讓大語言模型LLM穩(wěn)定、可靠地與五花八門的外部資源對話我們當(dāng)然可以寫一堆零散的提示詞Prompt告訴模型“調(diào)用 API A 時用這個格式查詢數(shù)據(jù)庫 B 時用那個 SQL”。但這種方式在 Agent 功能稍微復(fù)雜一點后就會迅速變成一場維護噩夢。API 變了怎么辦新增一個數(shù)據(jù)源怎么辦不同工具返回的數(shù)據(jù)格式千差萬別模型能準(zhǔn)確理解嗎這背后是一個更本質(zhì)的問題在 AI Agent 的架構(gòu)中LLM大腦與外部工具手腳之間缺乏一種標(biāo)準(zhǔn)化的“通信協(xié)議”。就像人類社會的繁榮離不開語言和交通規(guī)則AI Agent 生態(tài)的規(guī)?；l(fā)展也需要一套被廣泛認可的“基礎(chǔ)協(xié)議”。這就是MCPModel Context Protocol出現(xiàn)的背景。它不是某個具體產(chǎn)品的 SDK而是一個由 Anthropic 牽頭、社區(qū)推動的開放協(xié)議。你可以把它理解為AI Agent 世界的“USB 協(xié)議”或“HTTP 協(xié)議”。它的目標(biāo)極其明確為 LLM 與任何外部數(shù)據(jù)源、工具或服務(wù)之間定義一套統(tǒng)一的、標(biāo)準(zhǔn)化的對話方式。簡單來說MCP 試圖回答“一個工具應(yīng)該以何種格式告訴 LLM ‘我能做什么’能力聲明LLM 又應(yīng)該以何種格式告訴工具‘請執(zhí)行這個動作’調(diào)用請求工具執(zhí)行完畢后又該如何把結(jié)果‘打包’好送回給 LLM響應(yīng)格式”理解了 MCP 要解決的“元問題”我們再來拆解它的具體實現(xiàn)。本系列文章我們將深入 MCP 協(xié)議的內(nèi)部從最基礎(chǔ)的消息格式到支撐其運行的傳輸層進行一次完整的“庖丁解?！?。今天這篇就是整個子系列的地基。2. MCP 協(xié)議的核心設(shè)計哲學(xué)聲明式與標(biāo)準(zhǔn)化在深入技術(shù)細節(jié)前我們必須先把握 MCP 的設(shè)計哲學(xué)這決定了它所有技術(shù)選擇的走向。MCP 的設(shè)計可以概括為兩個關(guān)鍵詞聲明式Declarative和標(biāo)準(zhǔn)化Standardized。2.1 聲明式讓工具“自我介紹”而非“被命令”傳統(tǒng)的集成方式是“命令式”的。開發(fā)者需要寫死代碼當(dāng)用戶說 X 時就調(diào)用函數(shù) Y并手動處理參數(shù) Z。這種方式將工具的邏輯硬編碼進了 Agent 的核心流程里。MCP 則采用了聲明式。工具在 MCP 中稱為 Server不需要被“命令”如何工作它只需要向 LLM在 MCP 中稱為 Client清晰地“聲明”自己有哪些能力以及使用這些能力需要提供什么信息。例如一個天氣查詢工具會聲明“我叫‘天氣查詢’我能根據(jù)‘城市名’這個參數(shù)返回該城市的天氣信息。” 它不需要知道 LLM 具體怎么組織對話只需要定義好能力的“接口規(guī)范”。這樣做的好處是巨大的動態(tài)發(fā)現(xiàn)與組合LLM或 Agent 框架可以在運行時動態(tài)發(fā)現(xiàn)可用的工具并根據(jù)當(dāng)前對話上下文智能地選擇并組合使用它們。工具可以隨時上線、下線或更新而無需修改 Agent 的核心邏輯。降低耦合工具提供方和 Agent 開發(fā)者可以獨立工作。工具提供方專注于實現(xiàn)功能并發(fā)布符合 MCP 協(xié)議的 ServerAgent 開發(fā)者則專注于設(shè)計提示詞和業(yè)務(wù)流程通過標(biāo)準(zhǔn)協(xié)議連接所需工具。提升可靠性由于交互格式是標(biāo)準(zhǔn)的LLM 生成錯誤調(diào)用的概率會降低工具也能更準(zhǔn)確地解析請求并返回結(jié)構(gòu)化的結(jié)果。2.2 標(biāo)準(zhǔn)化定義通用的“詞匯表”和“語法”聲明式的前提是大家說同一種語言。MCP 通過定義一系列標(biāo)準(zhǔn)化的 JSON Schema為工具能力的描述、調(diào)用請求和響應(yīng)建立了通用的“詞匯表”和“語法”。資源Resources代表可被讀取的靜態(tài)或動態(tài)數(shù)據(jù)如一個文件、數(shù)據(jù)庫查詢結(jié)果、API 返回的 JSON。MCP 定義了如何描述一個資源URI、MIME 類型、元數(shù)據(jù)以及如何讀取它resources/listresources/read。工具Tools代表可執(zhí)行的操作通常帶有輸入?yún)?shù)并產(chǎn)生副作用或返回結(jié)果如發(fā)送郵件、創(chuàng)建日歷事件、執(zhí)行命令。MCP 定義了工具的描述格式名稱、描述、輸入?yún)?shù) Schema和調(diào)用方式tools/listtools/call。提示詞模板Prompts一種特殊的資源它本身是一個文本模板可以被 LLM 獲取并用于生成更復(fù)雜的提示詞。這允許工具提供領(lǐng)域特定的提示詞片段。這三種核心抽象幾乎涵蓋了 AI Agent 需要與外部世界交互的所有主要模式。通過將它們標(biāo)準(zhǔn)化MCP 為 Agent 構(gòu)建了一個豐富、可插拔的“外部能力市場”。3. 消息格式全解MCP 協(xié)議的數(shù)據(jù)交換單元協(xié)議的核心是消息。MCP 中所有的通信都基于 JSON-RPC 2.0 規(guī)范這是一種輕量級的遠程過程調(diào)用協(xié)議。選擇 JSON-RPC 是因為它簡單、通用、語言無關(guān)并且有成熟的客戶端/服務(wù)器實現(xiàn)庫。一條 MCP 消息就是一個 JSON-RPC 消息。它主要包含以下幾個部分3.1 請求Request消息格式當(dāng) Client通常是 LLM 端或 Agent 框架需要 Server工具端做某事時會發(fā)送一個請求。{ jsonrpc: 2.0, id: 1, method: tools/list, params: {} }jsonrpc: 固定為2.0表明遵循 JSON-RPC 2.0。id: 請求的唯一標(biāo)識符數(shù)字或字符串。這個id至關(guān)重要因為 Server 的響應(yīng)必須攜帶相同的id這樣 Client 才能將響應(yīng)與對應(yīng)的請求匹配起來尤其是在異步通信中。method: 要調(diào)用的方法名。MCP 定義了一系列標(biāo)準(zhǔn)方法如tools/list列出所有工具、tools/call調(diào)用一個工具、resources/list列出所有資源等。params: 調(diào)用方法所需的參數(shù)是一個對象。例如調(diào)用tools/call時params里會包含工具名和具體的輸入?yún)?shù)。一個完整的tools/call請求示例假設(shè) Server 聲明了一個名為get_weather的工具它需要一個city參數(shù)。{ jsonrpc: 2.0, id: req_weather_001, method: tools/call, params: { name: get_weather, arguments: { city: 北京 } } }這里id用了字符串req_weather_001method是tools/callparams里指明了要調(diào)用的工具名和具體的參數(shù)。3.2 成功響應(yīng)Success Response消息格式Server 處理請求成功后會返回一個成功響應(yīng)。{ jsonrpc: 2.0, id: 1, result: { tools: [ { name: get_weather, description: 獲取指定城市的天氣信息, inputSchema: { type: object, properties: { city: { type: string, description: 城市名稱例如北京、上海 } }, required: [city] } } ] } }id: 必須與對應(yīng)請求的id完全一致。result: 請求的執(zhí)行結(jié)果。其內(nèi)容完全取決于method。例如對于tools/listresult是一個包含tools數(shù)組的對象對于tools/callresult會包含工具執(zhí)行后的輸出內(nèi)容可能是一個文本、一個結(jié)構(gòu)化對象甚至是一個包含多部分內(nèi)容文本、圖片、代碼的復(fù)雜結(jié)構(gòu)。接上例get_weather調(diào)用的成功響應(yīng)可能如下{ jsonrpc: 2.0, id: req_weather_001, result: { content: [ { type: text, text: 北京當(dāng)前天氣晴氣溫 25°C西北風(fēng) 2級。 } ] } }MCP 定義了一個靈活的content數(shù)組來承載結(jié)果支持text、image、resource等多種類型這為返回豐富內(nèi)容提供了可能。3.3 錯誤響應(yīng)Error Response消息格式如果請求無效或處理出錯Server 返回錯誤響應(yīng)。{ jsonrpc: 2.0, id: 1, error: { code: -32602, message: Invalid params, data: The parameter city is required but was not provided. } }error: 錯誤對象。code: 錯誤碼。JSON-RPC 定義了標(biāo)準(zhǔn)錯誤碼如 -32601 方法未找到-32602 無效參數(shù)MCP 也可以定義自己的應(yīng)用級錯誤碼。message: 簡短的錯誤描述。data可選: 提供關(guān)于錯誤的額外信息如詳細的驗證錯誤信息。3.4 通知Notification消息格式這是一種特殊的、不需要響應(yīng)的請求。它只有method和params沒有id。在 MCP 中這通常用于 Server 向 Client 主動推送信息例如通知某個資源的內(nèi)容發(fā)生了變化。{ jsonrpc: 2.0, method: notifications/resources/updated, params: { uri: file:///path/to/data.json } }Client 收到后可能會根據(jù)通知重新讀取相關(guān)資源但不需要向 Server 發(fā)送響應(yīng)。實操心得消息id的管理在實現(xiàn) MCP Client 時管理好請求id是保證通信可靠性的關(guān)鍵。尤其是在高并發(fā)或異步場景下必須維護一個從id到請求上下文如回調(diào)函數(shù)、Promise的映射。一個常見的坑是id重復(fù)或映射清理不及時導(dǎo)致內(nèi)存泄漏。建議使用單調(diào)遞增的數(shù)字或帶有時間戳的 UUID 來生成id并設(shè)置超時機制來清理過期的映射項。4. 傳輸層剖析MCP 協(xié)議如何“跑”起來定義了消息格式接下來就要解決消息如何在不同進程、甚至不同機器間傳遞的問題。這就是傳輸層的職責(zé)。MCP 協(xié)議設(shè)計上與傳輸層解耦這意味著它可以在多種傳輸方式上運行。目前社區(qū)主要支持和推薦兩種方式stdio標(biāo)準(zhǔn)輸入輸出和SSEServer-Sent Events。4.1 Stdio 傳輸簡單、可靠的進程間通信這是 MCP 最經(jīng)典、也是最常見的傳輸方式尤其適用于 Client 和 Server 在同一臺機器上以父子進程關(guān)系運行的場景。工作原理Client如 Claude Desktop、Cursor 或一個自定義的 Agent 框架啟動一個子進程這個子進程就是 MCP Server你的工具。Client 將自己的標(biāo)準(zhǔn)輸出stdout連接到 Server 的標(biāo)準(zhǔn)輸入stdin。Server 將自己的標(biāo)準(zhǔn)輸出stdout連接到 Client 的標(biāo)準(zhǔn)輸入stdin。雙方通過各自的 stdin 接收消息通過 stdout 發(fā)送消息。所有消息都遵循上一節(jié)定義的 JSON-RPC 格式每一條完整的 JSON 消息通常以換行符\n分隔即 JSON Lines 格式。流程示意圖簡化[Client進程] | | (fork/exec) v [Server進程] | | Client.stdout - Server.stdin (Client發(fā)送請求) | Server.stdout - Client.stdin (Server發(fā)送響應(yīng)/通知) v優(yōu)點部署簡單無需網(wǎng)絡(luò)配置非常適合本地工具集成。安全性好通信完全在本地進程間進行不暴露網(wǎng)絡(luò)端口。資源消耗低沒有網(wǎng)絡(luò)棧開銷。跨語言通用任何支持啟動子進程和讀寫標(biāo)準(zhǔn)流的編程語言都能實現(xiàn)。缺點僅限于本地?zé)o法實現(xiàn)遠程調(diào)用。生命周期綁定Server 進程的生命周期通常由 Client 管理。Client 退出Server 一般也會被終止。一個簡單的 Stdio Server 偽代碼示例Pythonimport sys import json def handle_tools_list(): return { tools: [{ name: echo, description: 回顯輸入的文字, inputSchema: { type: object, properties: {text: {type: string}}, required: [text] } }] } def main(): # MCP Server 通過 stdin 接收stdout 發(fā)送 while True: line sys.stdin.readline() if not line: break try: message json.loads(line) msg_id message.get(id) method message.get(method) if method tools/list: response { jsonrpc: 2.0, id: msg_id, result: handle_tools_list() } sys.stdout.write(json.dumps(response) \n) sys.stdout.flush() # ... 處理其他 method except json.JSONDecodeError: # 發(fā)送錯誤響應(yīng) error_resp { jsonrpc: 2.0, id: msg_id, error: {code: -32700, message: Parse error} } sys.stdout.write(json.dumps(error_resp) \n) sys.stdout.flush() if __name__ __main__: main()4.2 SSE 傳輸面向 HTTP 的輕量級流式通信當(dāng)工具Server需要以遠程服務(wù)的形式存在時例如一個部署在云端的數(shù)據(jù)庫查詢服務(wù)Stdio 就不適用了。這時SSEServer-Sent Events成為了更合適的傳輸層選擇。工作原理MCP Server 作為一個標(biāo)準(zhǔn)的 HTTP 服務(wù)器運行并暴露一個特定的 SSE 端點例如/sse。MCP Client 通過 HTTP 長連接連接到這個 SSE 端點。連接建立后Server 會通過這個 HTTP 連接以 SSE 格式data: {json}\n\n持續(xù)向 Client 推送消息如通知。當(dāng) Client 需要發(fā)送請求如調(diào)用工具時它通過向 Server 的另一個 HTTP 端點例如/rpc發(fā)送 POST 請求來實現(xiàn)。Server 處理該請求并將響應(yīng)通過 SSE 連接發(fā)回或者直接在 POST 請求的響應(yīng)體中返回。這是一種混合模式請求/響應(yīng)用 HTTP POST服務(wù)器推送用 SSE。這種設(shè)計利用了 SSE 在服務(wù)器向客戶端單向推送上的天然優(yōu)勢同時用簡單的 HTTP POST 處理客戶端發(fā)起的請求。優(yōu)點支持遠程訪問工具可以部署在遠程服務(wù)器上被多個 Agent 共享。基于 HTTP兼容現(xiàn)有的 Web 基礎(chǔ)設(shè)施易于在云環(huán)境部署和擴展。原生支持服務(wù)器推送非常適合 MCP 中 Server 主動發(fā)送通知的場景。缺點復(fù)雜度更高需要實現(xiàn) HTTP 服務(wù)器和 SSE 連接管理。存在網(wǎng)絡(luò)延遲不適合對延遲極度敏感的本地操作。需要處理身份認證和授權(quán)在 Stdio 中這不是問題。注意事項傳輸層的選擇策略開發(fā)本地桌面插件或 CLI 工具優(yōu)先選擇Stdio。它與 Claude Desktop、Cursor 等客戶端的集成最為順暢開箱即用。構(gòu)建共享的、中心化的工具服務(wù)例如為團隊提供一個公司內(nèi)部的數(shù)據(jù)庫查詢 Agent 工具應(yīng)選擇SSE over HTTP。你需要仔細設(shè)計 Server 的/sse和/rpc端點并處理好連接狀態(tài)管理和心跳?；?。網(wǎng)絡(luò)環(huán)境不穩(wěn)定如果通信雙方網(wǎng)絡(luò)延遲高或易抖動SSE 的長連接可能不穩(wěn)定需要實現(xiàn)完善的重連機制。Stdio 則沒有這個問題。5. 協(xié)議握手與初始化建立通信的“第一課”在 Client 和 Server 通過選定的傳輸層建立連接后并不能立刻開始請求工具列表或調(diào)用工具。它們需要先進行一次“握手”交換彼此的“身份”和能力信息這個過程稱為初始化Initialization。初始化過程由 Client 主動發(fā)起通過調(diào)用一個特殊的、名為initialize的 JSON-RPC 方法。Client 發(fā)送的初始化請求示例{ jsonrpc: 2.0, id: 0, method: initialize, params: { protocolVersion: 2024-11-05, capabilities: { roots: { listChanged: true }, sampling: { isSupported: false } }, clientInfo: { name: MyAwesomeAgent, version: 1.0.0 } } }protocolVersion: Client 支持的 MCP 協(xié)議版本。這確保了 Client 和 Server 使用兼容的協(xié)議特性。capabilities: Client 聲明自己支持哪些可選的協(xié)議能力。例如roots.listChanged為true表示 Client 可以處理 Server 發(fā)送的關(guān)于根資源列表變更的通知。這類似于 HTTP 的 Feature Detection。clientInfo: Client 的自我介紹方便 Server 進行日志記錄或差異化處理。Server 的初始化響應(yīng){ jsonrpc: 2.0, id: 0, result: { protocolVersion: 2024-11-05, capabilities: { tools: { listChanged: true } }, serverInfo: { name: WeatherService, version: 0.2.1 } } }protocolVersion: Server 確認使用的協(xié)議版本通常與 Client 發(fā)送的一致。capabilities: Server 聲明自己支持或要求哪些能力。例如tools.listChanged: true表示 Server 會在工具列表變化時發(fā)送通知。serverInfo: Server 的自我介紹。只有在收到成功的initialize響應(yīng)后Client 才能發(fā)送其他請求如tools/list或resources/list。隨后Client 通常會發(fā)送一個initialized通知這是一個沒有id的 JSON-RPC 通知告知 Server 初始化流程已完畢可以開始正常工作了。這個握手過程雖然簡單但它是保證通信雙方兼容性和穩(wěn)定性的關(guān)鍵一步。它避免了因版本不匹配或能力不支持而導(dǎo)致的后續(xù)通信混亂。6. 核心方法詳解MCP 協(xié)議的能力清單初始化完成后Client 和 Server 就進入了正式的交互階段。MCP 定義了一套核心的 JSON-RPC 方法構(gòu)成了協(xié)議的能力骨架。理解這些方法是編寫或使用 MCP Server 的關(guān)鍵。6.1 工具Tools相關(guān)方法這是 MCP 中最活躍的部分用于動態(tài)發(fā)現(xiàn)和執(zhí)行操作。tools/list: Client 調(diào)用此方法獲取 Server 提供的所有工具列表。Server 返回的result中包含一個tools數(shù)組每個工具對象都嚴(yán)格遵循聲明式的 Schema包含name、description和inputSchema。inputSchema是一個 JSON Schema 對象定義了調(diào)用該工具所需的參數(shù)這為 LLM 生成正確的參數(shù)提供了“說明書”。tools/call: Client 調(diào)用此方法來執(zhí)行一個具體的工具。請求的params中必須包含name工具名和arguments符合inputSchema的參數(shù)對象。Server 執(zhí)行工具邏輯并將結(jié)果放在響應(yīng)的result.content中返回。這里有一個關(guān)鍵點arguments中的值是由 LLM 根據(jù)自然語言理解和工具 Schema “猜測”生成的因此 Server 端的實現(xiàn)必須對參數(shù)進行嚴(yán)格的驗證和清理防止注入攻擊或意外錯誤。notifications/tools/listChanged: 這是一個從 Server 發(fā)往 Client 的通知沒有id。當(dāng) Server 的工具列表發(fā)生變化如新增、刪除、更新了某個工具時它可以發(fā)送此通知。收到通知后Client 應(yīng)該主動再次調(diào)用tools/list來獲取最新的工具列表。這實現(xiàn)了工具能力的動態(tài)更新。6.2 資源Resources相關(guān)方法用于訪問相對靜態(tài)的、可讀的數(shù)據(jù)內(nèi)容。resources/list: 獲取 Server 提供的所有可用資源的列表。返回的result中包含resources數(shù)組每個資源對象包含uri唯一標(biāo)識符如file:///notes/daily.md、mimeType如text/markdown和name等元數(shù)據(jù)。resources/read: 讀取指定uri的資源內(nèi)容。Server 返回result.content內(nèi)容格式與資源的mimeType對應(yīng)。這對于向 LLM 提供背景文檔、配置文件等內(nèi)容非常有用。resources/subscribe/resources/unsubscribe(可選): Client 可以訂閱某個資源的變化。當(dāng)資源內(nèi)容更新時Server 會通過notifications/resources/updated通知 Client。這對于監(jiān)控日志文件、實時數(shù)據(jù)流等場景至關(guān)重要。notifications/resources/updated: Server 發(fā)送的通知告知 Client 某個已訂閱資源的uri內(nèi)容已更新。6.3 提示詞模板Prompts相關(guān)方法提示詞模板是一種特殊資源旨在幫助 LLM 生成更符合特定場景的提示詞。prompts/list: 獲取可用的提示詞模板列表。prompts/get: 根據(jù)模板名和可選參數(shù)獲取渲染后的提示詞文本。例如一個“代碼審查”模板可能接受code和language參數(shù)Server 會將這些參數(shù)填充到預(yù)定義的模板中生成一段具體的提示詞返回給 ClientClient 再將其用于 LLM 對話。實操心得inputSchema的設(shè)計藝術(shù)定義工具的inputSchema是 MCP Server 開發(fā)中最體現(xiàn)功力的地方之一。一個好的 Schema 應(yīng)該描述精準(zhǔn)description字段要用自然語言清晰說明工具的功能和每個參數(shù)的用途這是 LLM 理解工具的主要依據(jù)。約束明確充分利用 JSON Schema 的type,enum,pattern(正則),minimum/maximum等關(guān)鍵字對參數(shù)進行嚴(yán)格限制。例如對于“城市名”參數(shù)可以設(shè)置enum: [“北京”, “上?！? “廣州”, “深圳”]來避免 LLM 胡編亂造。結(jié)構(gòu)扁平盡量使用扁平的對象結(jié)構(gòu)避免深層嵌套。LLM 在生成復(fù)雜嵌套的 JSON 時更容易出錯。提供示例在參數(shù)的description中或通過 JSON Schema 的examples字段提供示例值能顯著提升 LLM 填充參數(shù)的準(zhǔn)確性。 一個設(shè)計糟糕的 Schema 會導(dǎo)致 LLM 頻繁調(diào)用失敗而一個設(shè)計精良的 Schema 則能讓工具調(diào)用行云流水。7. 安全性與錯誤處理構(gòu)建健壯的 MCP 交互任何協(xié)議在實際應(yīng)用中都必須考慮安全性和魯棒性。MCP 作為連接 LLM 和外部世界的橋梁在這方面尤為重要。7.1 安全性考量輸入驗證與清理首要防線這是 Server 端最重要的安全措施。LLM 生成的arguments是不可信的輸入。Server 必須依據(jù)inputSchema進行嚴(yán)格驗證并對字符串參數(shù)進行清理防止 SQL 注入、命令注入、路徑遍歷等攻擊。永遠不要將 LLM 生成的參數(shù)直接拼接成命令或查詢語句執(zhí)行。權(quán)限最小化MCP Server 進程或服務(wù)應(yīng)該以最低必要的權(quán)限運行。例如一個文件讀取 Server 不應(yīng)該有寫入或刪除文件的權(quán)限。傳輸安全對于Stdio由于是本地進程間通信主要風(fēng)險來自惡意或存在漏洞的 Server 二進制文件。確保從可信來源獲取 Server。對于SSE/HTTP必須使用HTTPS來加密傳輸通道防止中間人攻擊。同時需要實現(xiàn)身份認證如 API Key、JWT Token和授權(quán)機制確保只有合法的 Client 可以連接。MCP 協(xié)議本身不規(guī)定具體的認證方式這需要在 HTTP 層自行實現(xiàn)。沙箱化執(zhí)行對于執(zhí)行任意代碼或命令的工具應(yīng)考慮在沙箱環(huán)境如 Docker 容器、nsjail中運行以隔離潛在風(fēng)險。7.2 錯誤處理與重試策略充分利用 JSON-RPC 錯誤碼Server 應(yīng)返回精確的錯誤碼和消息。例如參數(shù)缺失用-32602工具未找到用-32601自定義的業(yè)務(wù)邏輯錯誤可以使用-32000到-32099的范圍。清晰的錯誤信息有助于 Client或背后的 Agent 邏輯進行決策例如提示用戶補充信息或嘗試其他工具。Client 端的超時與重試網(wǎng)絡(luò)請求或工具執(zhí)行可能超時。Client 端應(yīng)為每個請求設(shè)置合理的超時時間并實現(xiàn)重試邏輯特別是對于冪等的操作如tools/list、resources/read。重試時應(yīng)采用退避策略如指數(shù)退避避免加重 Server 負擔(dān)。連接?；钆c重連針對 SSESSE 長連接可能因網(wǎng)絡(luò)問題中斷。Client 需要監(jiān)聽連接關(guān)閉事件并實現(xiàn)自動重連機制。在重連后可能需要重新執(zhí)行initialize流程并同步狀態(tài)如重新訂閱資源。優(yōu)雅降級當(dāng)某個 MCP Server 不可用時Agent 應(yīng)該有能力跳過該工具或者使用備選方案而不是整個流程崩潰。這要求 Agent 框架具備服務(wù)發(fā)現(xiàn)和健康檢查機制。8. 實戰(zhàn)視角從協(xié)議到實現(xiàn)的關(guān)鍵抉擇理解了協(xié)議規(guī)范當(dāng)我們著手實現(xiàn)一個 MCP Server 或集成一個 MCP Client 時還需要做出一系列工程上的抉擇。8.1 Server 端實現(xiàn)選型你是要開發(fā)一個一次性的小工具還是一個需要服務(wù)化、高可用的企業(yè)級組件快速原型與 CLI 工具使用官方或社區(qū)的SDK是最高效的方式。例如Anthropic 官方提供了TypeScript/JavaScript 的 SDK(modelcontextprotocol/sdk)它封裝了 Stdio/SSE 傳輸、消息序列化、初始化握手等底層細節(jié)你只需要專注于實現(xiàn)工具函數(shù)和資源邏輯。Python 等語言也有活躍的社區(qū) SDK。這能讓你在幾分鐘內(nèi)搭建起一個可運行的 Server。高性能或特殊語言需求如果你需要極致性能或者必須使用某種沒有成熟 SDK 的語言如 Rust, Go你可以基于 JSON-RPC 2.0 規(guī)范從頭實現(xiàn)。核心工作是實現(xiàn)傳輸層讀寫 stdin/stdout 或 HTTP/SSE 服務(wù)器。解析和序列化 JSON-RPC 消息。維護請求id與處理邏輯的映射。實現(xiàn)協(xié)議要求的各個方法處理器initialize,tools/list,tools/call等。 雖然工作量較大但能獲得完全的控制權(quán)。8.2 Client 端集成策略你是在構(gòu)建一個全新的 Agent 框架還是在現(xiàn)有應(yīng)用中如 Claude Desktop, Cursor使用 MCP在支持 MCP 的客戶端中使用這是最簡單的路徑。像 Claude Desktop、Cursor、Windsurf 等應(yīng)用已經(jīng)內(nèi)置了 MCP Client。你通常只需要在配置文件中指定你的 MCP Server 的命令行或 SSE 地址它們就能自動連接并加載工具。你只需要關(guān)心 Server 的實現(xiàn)。在自定義 Agent 框架中集成如果你在自研 Agent 系統(tǒng)你需要將 MCP Client 集成進去。這意味著實現(xiàn)或引入一個 MCP Client 庫用于管理到多個 Server 的連接。在系統(tǒng)啟動時初始化所有配置的 Server 連接。將tools/list返回的工具列表動態(tài)地轉(zhuǎn)換為你的 Agent 系統(tǒng)所能理解的“工具”格式并注入到給 LLM 的提示詞或函數(shù)調(diào)用列表中。當(dāng) LLM 決定使用某個工具時將 LLM 的輸出參數(shù)轉(zhuǎn)換為 MCPtools/call請求發(fā)送給對應(yīng)的 Server并處理響應(yīng)和錯誤。 這相當(dāng)于在你的框架和 MCP 協(xié)議之間建立一個適配層。8.3 調(diào)試與監(jiān)控開發(fā) MCP 組件離不開調(diào)試。日志是生命線在 Server 和 Client 的關(guān)鍵節(jié)點收到請求、發(fā)送響應(yīng)、發(fā)生錯誤添加詳細的日志。對于 Stdio 模式日志可以輸出到 stderr這樣不會干擾正常的 JSON-RPC 消息流stdout。對于 HTTP 模式使用結(jié)構(gòu)化的日志如 JSON并集成到現(xiàn)有的日志系統(tǒng)中。消息流可視化可以編寫一個簡單的“中間人”代理它位于 Client 和 Server 之間將所有經(jīng)過的 JSON-RPC 消息打印出來或保存到文件。這是分析復(fù)雜交互問題的利器。使用現(xiàn)有調(diào)試工具社區(qū)已經(jīng)有一些工具比如mcp-cli它可以作為一個通用的 MCP Client 來連接和測試你的 Server手動發(fā)送請求并查看響應(yīng)非常適合初期調(diào)試。從消息格式的定義到傳輸層的選型從握手初始化的流程到核心方法的調(diào)用再到安全與實踐的考量MCP 協(xié)議為我們勾勒出了一幅清晰的 AI Agent 擴展藍圖。它通過標(biāo)準(zhǔn)化和聲明式設(shè)計將 LLM 與外部世界的交互難題轉(zhuǎn)化為了一個可管理、可擴展的工程問題。掌握 MCP就如同掌握了為 AI Agent 打造“瑞士軍刀”的標(biāo)準(zhǔn)接口規(guī)范。在接下來的子系列文章中我們將深入更多實戰(zhàn)場景探討如何設(shè)計復(fù)雜的工具 Schema如何構(gòu)建生產(chǎn)可用的 MCP 服務(wù)以及 MCP 在具體 Agent 架構(gòu)中的最佳實踐。