做AI應用這段時間我最大的感受是模型能力已經不再是瓶頸真正卡脖子的是數據進不來、工具調不動。你訓練一個再聰明的模型它也沒法自己讀你公司的PostgreSQL沒法自己操作Figma沒法自己查藍湖里的設計稿。直到MCPModel Context Protocol出現這種每個應用各搞一套接口的混沌狀態(tài)才算有了收斂的趨勢。MCP說白了就是給AI接外部世界的通用接口它用一種標準化的方式讓AI應用能夠發(fā)現、協(xié)商、調用外部工具和數據源。這篇文章我不打算復述官方文檔而是從開發(fā)者的視角把MCP的架構、實操、邊界和坑一次性講透。1. 接口的戰(zhàn)國時代為什么AI接個數據這么費勁1.1 回看沒有MCP的日子每個集成都是一次性代碼在MCP出現之前AI應用接入外部數據源是一件非常原始的事情。我做過的第一個內部知識庫問答助手公司里同時用了飛書文檔、Confluence、MySQL還有一套自研的工單系統(tǒng)。為了讓模型能回答某個功能最近被吐槽最多的是什么這類問題我一個人寫了四套完全不同的適配代碼飛書要過開放平臺的權限校驗Confluence要處理分頁和富文本格式MySQL要自己拼查詢并做表結構文檔化工單系統(tǒng)更是連一個正經的API文檔都沒有全靠抓包逆向。這不是我一個人的處境是當時整個行業(yè)的狀態(tài)。每一家做AI應用的團隊都在重復造輪子。模型側呢OpenAI有Function CallingAnthropic有Tool UseGoogle也有自己的Function Calling每個平臺的定義方式、調用約束、返回格式都不一樣。你一旦選定了某個模型供應商對接外部工具的代碼就跟這個供應商深度綁定想換一個模型等于把集成層重寫一遍。這就像家里每個電器都自帶一根專用的插頭插座不通用線纜不通用連電壓都不一樣每次買新電器都得重新走線。1.2 AI應用的USB接口這個類比怎么理解MCP要解決的就是這個問題。大家喜歡把MCP比作AI界的Type-C接口這個類比其實非常貼切。Type-C的特點是什么一個物理接口標準既能傳數據又能充電所有支持它的設備不用管對面是不是同一個廠商插上就能用。MCP做的事情本質上是一樣的它定義了AI應用Host和外部能力Server之間的標準對話方式這個對話方式包括你是誰、你能做什么、我怎么調用你、你返回的結果長什么樣。一個支持MCP的AI客戶端就像一臺帶Type-C口的筆記本。你可以隨時插上U盤文件系統(tǒng)Server、網卡HTTP請求Server、顯示器瀏覽器操作Server不需要為每一個外設單獨裝驅動。對整個生態(tài)來說這是從私有協(xié)議到公共標準的一次躍遷。這個協(xié)議最早由Anthropic提出并開源但現在已經不是某一家公司的私有物而是被OpenAI、Google、微軟等主流廠商陸續(xù)接納的開放標準。生態(tài)里的任何一方只要愿意遵守這個協(xié)議就能跟所有遵守同一協(xié)議的另外一方互聯互通。1.3 核心設計動機模型需要的不是連接是上下文這里特別想強調一個容易被人忽略的動機。很多人以為MCP是為了讓AI更強大但更準確地說MCP是為了讓AI有東西可以思考。大模型本質上是一個推理引擎你給它什么上下文它就在什么上下文里推理。工具調用、資料檢索、數據庫查詢……這些能力的本質都是在模型推理的那一瞬間把外部世界的真實數據搬運到它的上下文窗口里。所以MCP協(xié)議全稱里那個Context不是隨便起的。它要傳輸的絕不僅僅是工具調用的結果而是整個上下文相關的數據、狀態(tài)和反饋。這個設計動機理解透了后面的很多決策——比如為什么要區(qū)分Resources和Tools、為什么工具描述要寫得詳細——你都會自然明白。很多人在使用過程中工具總是調用失敗根子上的原因就是沒有站在喂給模型上下文的角度去設計Server而是站在完成一個函數調用的角度去設計。2. MCP架構拆解Host、Client和Server的分工沒有你想象中復雜2.1 一次完整通信的旅程從用戶提問到工具返回MCP的架構聽起來名詞很多Host、Client、Server但拆開看就那么點事。我結合一個真實場景來講。假設你正在使用一個支持MCP的AI助手你問它幫我查一下上個月華東區(qū)的訂單總量。 背后發(fā)生的事情是HostAI助手應用收到你的問題把這個問題連同系統(tǒng)提示詞一起發(fā)給接入的大模型。模型在推理時發(fā)現要回答這個問題它缺少訂單數據——它需要一個查詢訂單數據庫的能力。這個能力從哪里來Host里注冊了一個MCP Client這個Client連接著一個MCP Server也就是你提前配置好的訂單數據庫服務。Client做的事情相當于一個翻譯官它把模型想調用工具這個意圖用MCP協(xié)議規(guī)定的格式JSON-RPC消息發(fā)給Server詢問你有哪些工具可以調用。Server返回自己暴露的工具列表以及每個工具的參數說明。這段說明在MCP里叫Tool Schema是用JSON Schema描述的。模型看到工具列表決定調用query_orders這個工具并填上參數region華東、month2024-11。Client把調用請求轉發(fā)給ServerServer執(zhí)行真實的SQL查詢將結果返回給Client。Client再把結果交給模型模型基于這份真實數據組織出自己的語言回答。整個鏈路里模型始終沒有直接跟數據庫打交道它只跟上下文里的描述打交道。數據庫在哪、用什么驅動、SQL怎么寫全部被Server屏蔽掉了。這正是通用接口的意義模型和工具之間不再是一對一定制化連接而是通過標準協(xié)議自由組合。2.2 三個核心對象Tools、Resources和PromptsMCP協(xié)議里有三個核心對象我管它們叫手、眼、記憶。Tools手模型可以主動觸發(fā)的動作比如發(fā)送HTTP請求寫入文件執(zhí)行SQL。工具是有副作用的模型在推理時會自主決定是否調用。每個工具都需要通過JSON Schema描述參數。要把工具的用途、參數含義寫得讓模型清楚這是MCP Server開發(fā)中最影響效果的一點。Resources眼模型可以主動讀取的數據比如一個文件的內容、一張表的結構、一份配置。Resources通常沒有副作用是只讀的。跟工具不同Resources更像是給模型提供的參考資料可以讓模型在行動之前先了解情況。比如讓AI做數據分析之前先給它讀一遍表結構說明它后面寫查詢語句的準確率會明顯上升。Prompts記憶MCP Server可以向客戶端暴露一些預設好的提示詞模板類似給這個場景定制好的開場指令。客戶端可以把這些模板當作功能入口展示給用戶。這個設計適合把某個領域的專家知識沉淀在Server里比如法律文件審查流程編程代碼審查清單。三者對比對象生命周期副作用誰觸發(fā)典型場景Tools調用時有模型自主觸發(fā)查詢訂單、發(fā)郵件、執(zhí)行命令Resources讀取時無模型按需讀取讀取表結構、加載文件、查看配置Prompts觸發(fā)時無客戶端引導或用戶選擇預設審查流程、角色設定2.3 傳輸層里的stdio和SSE到底是什么區(qū)別MCP協(xié)議在傳輸層給了兩種標準實現stdio和SSEServer-Sent Events。對于剛接觸MCP的人這兩個詞有點勸退其實一句話就能說清。stdio標準輸入輸出Server作為客戶端的一個子進程運行雙方通過標準輸入和標準輸出互相傳遞消息。所有數據都發(fā)生在本地進程之間不走網絡。優(yōu)點是簡單、安全、無網絡開銷適合綁定在本機上的工具比如讀取本地文件、運行本地腳本、操作本地數據庫。SSE服務器推送事件Server是一個遠程HTTP服務客戶端通過HTTP連接到它服務端通過SSE通道向客戶端持續(xù)推送事件。優(yōu)點是Server可以部署在中心機房多個客戶端共享同一個服務適合團隊共享的數據服務比如統(tǒng)一的Git倉庫操作服務、統(tǒng)一的數據庫查詢服務。實際開發(fā)中的選型原則也很簡單如果你是給個人電腦上的AI助手裝一個讀寫本地文件的工具用stdio就夠了如果你要給整個團隊提供一個查公司訂單數據庫的服務那必須用SSE否則每個同事的電腦上都要配置一份數據庫憑據想想都頭大。3. 從零寫一個MCP ServerPython官方SDK完整實操3.1 為什么我用Python官方SDK而不是Node或者直接用JSON-RPC現在實現MCP Server的路徑有三條直接用官方TypeScript SDK、用官方Python SDK、或者完全自己手寫JSON-RPC協(xié)議通信。我給的建議是如果沒有特殊的生態(tài)綁定需求優(yōu)先用Python官方SDK里的FastMCP。原因有三。第一FastMCP把協(xié)議細節(jié)封裝得非常好一個裝飾器就能暴露一個工具入門成本極低三五分鐘就能跑通一個能用的Server。第二AI工具生態(tài)里Python的存量最大你的Server如果不止接AI客戶端還想自己做數據清洗、調模型、跑分析Python都能無縫銜接。第三官方SDK的維護質量和社區(qū)活躍度目前是最高的遇到問題基本能在GitHub Issues或社區(qū)里找到現成答案。我的環(huán)境建議Python 3.10以上用uv管理依賴。uv可以直接通過pip install uv安裝然后uv init初始化項目。如果你不想引入uv用venv加pip也可以下面的代碼完全兼容。整個項目的依賴其實就兩個包mcp和psutilpsutil用來獲取系統(tǒng)信息換成別的第三方庫也完全無所謂。3.2 一個能查詢系統(tǒng)信息的最小Server下面這個Server麻雀雖小但五臟俱全它暴露了兩個工具一個獲取CPU信息一個獲取系統(tǒng)內存狀態(tài)。雖然業(yè)務價值一般但足夠你把MCP Server的開發(fā)鏈路完整走一遍。import platform import psutil from mcp.server.fastmcp import FastMCP # 創(chuàng)建MCP Server實例名字會出現在客戶端配置里 mcp FastMCP(system-info-demo) mcp.tool() def get_cpu_info() - dict: 獲取當前機器的CPU型號、核數等基礎信息 return { processor: platform.processor(), core_count: psutil.cpu_count(logicalTrue), physical_cores: psutil.cpu_count(logicalFalse), arch: platform.machine(), system: platform.system(), release: platform.release(), } mcp.tool() def get_memory_info() - dict: 獲取當前機器的內存總量、已用、可用情況 mem psutil.virtual_memory() return { total: mem.total, available: mem.available, used: mem.used, percent: mem.percent, } if __name__ __main__: # stdio傳輸模式供本地客戶端調用 mcp.run(transportstdio)可以注意幾個細節(jié)。第一工具函數上的docstring不是擺設這個字符串會被當作工具的說明傳給模型。模型判斷這個工具是干什么的、什么時候該用全靠它所以寫清楚說明效果好一半。第二mcp.run(transportstdio)指定的是本地傳輸模式如果要做遠程服務可以改造成SSE方式但具體寫法建議用的時候看一眼當前版本SDK的文檔。第三上面的代碼用到了psutil記得用pip install psutil安裝。運行方式最簡單python server.py如果一切正常程序會靜默地等待標準輸入上的消息什么都不會打印。這不是卡住了這是Server在等你給它發(fā)MCP協(xié)議消息。很多剛接觸MCP的人在這里會強行CtrlC以為寫錯了其實完全正常。3.3 用MCP Inspector把Server翻個底朝天MCP官方提供了一個用來調試Server的工具Inspector強烈建議任何寫MCP Server的人第一件事先學會用它。在項目目錄下執(zhí)行npx modelcontextprotocol/inspector python server.pyInspector會起一個本地的Web界面在這個界面里你能看到Server暴露的所有工具列表、每個工具的JSON Schema參數定義還能直接填參數手動調用工具看響應結果。這一步非常關鍵它能幫你把Server本身的功能和模型對工具的使用中間那一層隔離開來。你在調試時應該先在這里確認工具能正常工作再去接入真正的AI客戶端否則出了問題你都分不清是Server的bug還是模型亂調用。3.4 接入Claude Desktop和Cursor配置文件的那些坑工具寫好了接下來就是讓AI客戶端真正能調用到它。不同客戶端的配置方式大同小異我說兩個最常用的。Claude Desktop的配置在claude_desktop_config.json里macOS下通過Claude Desktop菜單直接打開配置目錄即可內容是{ mcpServers: { system-info-demo: { command: python, args: [/absolute/path/to/server.py] } } }Cursor的配置在~/.cursor/mcp.json{ mcpServers: { system-info-demo: { command: python, args: [/absolute/path/to/server.py] } } }這里有幾個我踩過的坑必須提醒你。第一command字段里的python一定要確認能解析到虛擬環(huán)境。如果你用venv直接寫python很可能用的是系統(tǒng)全局Python那個環(huán)境里根本沒裝mcp和psutil。最穩(wěn)妥的做法是把command寫成虛擬環(huán)境里python的絕對路徑比如/Users/xxx/.venv/bin/python。第二個坑是路徑args里的腳本路徑必須是絕對路徑寫相對路徑會有奇奇怪怪的找不到文件問題。第三個坑更隱蔽改了配置文件后大多數客戶端需要徹底重啟才會重新加載MCP Server。注意是徹底重啟進程不是簡單地在對話里刷新很多人在這一步卡半個小時其實是沒重啟。4. MCP與Function Calling、Computer Use到底什么關系4.1 Function Calling不是競爭是上下層網上經常有人把MCP和Function Calling放在對立面比較問有了Function Calling為什么還要MCP。我的看法是它是兩個不同層次的標準本身就不該拿來直接對比。Function Calling解決的是模型如何輸出一個結構化意圖的問題。它定義了模型在回答時如何以JSON的形式表達我想調用某個函數、參數是什么。它是模型推理能力的一部分發(fā)生在模型推理的那一瞬間到底要不要調用工具、調用哪個工具這是模型的自主決策。MCP解決的是模型想調用工具時工具在哪、怎么連、參數結構怎么定義的問題。它管的是調用意圖生成之后Client和Server之間怎么通信、怎么鑒權、怎么返回結果。換句話說Function Calling是大腦里決策的環(huán)節(jié)MCP是執(zhí)行的環(huán)節(jié)。在實際的MCP鏈路中模型往往正是通過Function Calling/Tool Use機制來表達調用意圖的然后Client把這個意圖翻譯成MCP協(xié)議消息發(fā)給Server。所以兩者是配合使用的關系不是替代關系。如果一定要打比方Function Calling像運輸合同里決定要發(fā)一批什么貨MCP像一套統(tǒng)一的集裝箱標準。集裝箱標準不管你發(fā)什么貨只管什么貨都能裝進去、裝上船、到港能卸下來。沒有集裝箱也能運貨但每一個港口都要為每一種貨物造專用吊具。這就是MCP的價值。4.2 Computer Use讓模型當人和讓模型當系統(tǒng)的差別Computer Use是另一條技術路線。它讓模型直接操作屏幕界面像人一樣看像素、移動鼠標、點擊按鈕、敲鍵盤屬于端到端的視覺與交互模型能力。MCP是讓模型通過顯式的、結構化的接口調用功能Computer Use讓模型通過模仿人類操作來使用軟件。這兩者的適用邊界差異非常大。如果一個系統(tǒng)有公開的API或者數據庫用MCP明顯更優(yōu)結構清晰、反饋確定、執(zhí)行快、出錯成本低。如果對方是一個只有GUI、沒有公開接口的舊系統(tǒng)比如一些老式ERP客戶端那Computer Use幾乎是唯一的路。但這種路代價也高模型要理解屏幕坐標、識別界面元素、應對各種彈窗和加載狀態(tài)傳統(tǒng)的接口調用幾十毫秒完成的事情計算機視覺可能要用幾秒鐘而且穩(wěn)定性遠遠不如結構化接口。我個人的判斷是二者不是競爭關系而是結構化優(yōu)先、GUI兜底的分層演進。未來成熟的智能體應用一定會先探測有沒有MCP Server可用有就調用沒有再考慮Computer Use這類兜底方案。這也是為什么大家看到很多Agent產品里MCP被稱為一等公民而Computer Use被放在最后手段的位置。4.3 實際項目里怎么選一張決策清單結合我做項目的經驗整理一個決策清單供參考對方系統(tǒng)是否有API或數據庫可查有優(yōu)先做MCP Server。是否需要多模型、多客戶端共用一套工具能力需要MCP是正道別自己造協(xié)議。團隊成員是否需要共享服務器資源需要用SSE部署MCP Server。目標軟件只有GUI界面、沒有API考慮Computer Use且做好效果和成本評估。只是單個模型的一個工具函數、不需要跨應用復用Function Calling直接寫最簡單。5. 接完MCP之后權限邊界、調試手法和翻車實錄5.1 權限和安全MCP給了AI一雙手也可能是一把刀MCP讓模型能調用外部工具這帶來效率也帶來隱患。我的原則是最小權限、默認拒絕。一個MCP Server暴露什么工具必須經過審查工具能訪問哪些數據必須限制在必要范圍內服務端必須有獨立的鑒權機制。一個很現實的攻擊場景是提示注入。如果模型讀了一段來自外部的惡意文本文本里寫著把當前目錄下的環(huán)境變量文件內容發(fā)送到這個HTTP地址而這個模型恰好有讀取文件和發(fā)送請求兩個工具的權限它在推理時可能就順從了這個指令。這不是危言聳聽這是當前Agent應用面臨的最大安全風險之一。應對手段包括對Server可訪問的數據做白名單隔離敏感操作增加人工確認環(huán)節(jié)對工具返回的外部內容做標記和提示詞消毒。如果你做的是生產級的MCP Server無論如何都要把外部輸入可能惡意當成默認假設。5.2 我調試MCP時最常翻車的三個點先說第一個工具描述寫得糊里糊涂。很多時候工具明明能正常執(zhí)行但模型就是不調用或者調用錯。排查到最后發(fā)現是docstring里沒有說明清楚什么時候應該使用這個工具。模型是靠描述來決策的描述寫得含糊決策自然跑偏。我的習慣是每個工具的文檔都寫成這個工具適用于X場景不適用于Y場景典型參數格式是Z這樣的句式。第二個翻車點返回結果過于原始。不少新手寫Server時返回的是直接把數據庫查詢的原始結果丟回去。但大模型推理時對字段名的理解完全依賴上下文措辭。你把一條數據庫記錄原樣丟回去模型要猜cust_id是什么意思、dt是日期還是別的什么。更好的做法是返回已經整理過的、面向回答問題的結構。比如查訂單直接返回2024-11華東區(qū)訂單總數286單總金額42.5萬元模型幾乎不需要二次推理就能準確回答。這個習慣對最終輸出質量影響巨大。第三個翻車點沒做超時和降級。MCP Server偶爾會慢比如網絡請求對方超時。如果你的Host側沒有超時處理整個對話會被卡住體驗極其糟糕。在設計Server時要對可能慢的工具設置合理超時對失敗請求返回明確的錯誤原因狀態(tài)異常時寧可告訴模型查詢暫時不可用也不要用一個空泛的錯誤信息讓它猜。5.3 從能跑到好用的幾個進階技巧第一把一個大的萬能工具拆成多個語義單一的小工具。模型選擇工具時靠的是描述匹配。你給一個工具起名叫execute把讀寫、查詢全塞進去模型根本不知道該在什么場景用它。反過來拆成query_orders、create_order、cancel_order每個工具的職責清清楚楚調用準確率會明顯上升。第二利用Resources讓模型先讀后寫。比如做一個數據庫MCP Server你應該先暴露一個讀取表結構的Resource讓模型在寫SQL之前先自動讀一遍表結構。這個小設計能大幅降低表名寫錯、字段不存在這類低級錯誤。數據驅動的AI應用上下文里多給一點結構信息輸出穩(wěn)定性完全是兩個等級。第三做好日志。MCP Server的日志比你想象中更重要。在開發(fā)階段可以把通信消息直接打到標準錯誤流stderr里客戶端通常會把stderr原樣呈現調試信息一目了然。等部署到生產環(huán)境一定要把日志打到獨立文件并且記錄下每次工具調用的參數和耗時。Agent應用出問題時如果拿不到模型當時調了什么、參數是什么、返回了什么這三條信息排查基本是瞎猜。做Agent應用這段時間我越來越覺得真正決定一個產品好不好用的往往不是模型的聰明程度而是它周圍那一圈基礎設施和腳手架。MCP的價值不在于某一個工具寫得有多巧妙而在于它第一次讓這些工具可以像U盤一樣即插即用。從個人項目到團隊協(xié)作從本地工具到云端服務它把給AI接外部世界這件事從手工作坊變成了流水線生產。你能在模型、數據源、用戶需求這三層之間做好設計把每個接口打磨得干凈、可信、夠用你的AI應用就已經贏過大多數人了。