矽谷的咖啡廳裡，永遠流傳著這樣的傳說：一個天才開發者，一臺電腦，一段顛覆行業的程式碼。但當 31 歲的 Maor Shlomo 在特拉維夫的公寓裡敲下 Base44 的第一行程式碼時，他沒想到這個故事會以 8000 萬美元的現金收購落幕——沒有風投加持，沒有百人團隊，只有 8 名員工和 180 天的閃電戰。
AI 正在快速發展，大語言模型處於這一變革的前沿。隨著這些模型在理解和生成類人文字方面日益精進，將其與外部系統整合的需求也顯著增長。這種整合有望開啟一個全新的應用時代，使之能夠利用真實世界的資料和工具來增強功能，並提供更符合語境的響應。
然而，將大語言模型連線到外部資源的傳統方法通常需要針對每個資料來源進行復雜且定製化的實現，從而導致架構碎片化且難以擴充套件。
Anthropic 的模型上下文協議 (MCP) 應運而生，成為應對這些挑戰的關鍵解決方案。
過去，如果我們想讓 AI 處理資料，通常只有兩種選擇：要麼依賴預訓練好的靜態知識庫，要麼手動上傳資料。這種方式不僅效率低下，還存在明顯的侷限性——即便是最強大的 AI 模型，也無法即時訪問新資料。每次遇到新資訊，都需要重新訓練或上傳，使得 AI 的擴充套件性和靈活性大打折扣。
而 MCP 的出現，徹底改變了這一局面。它像一位“資料橋樑工程師”，成功打破了 AI 對靜態知識庫的依賴，賦予模型動態互動的能力。有了 MCP，AI 可以透過 MCP 像人類一樣自由調用搜索引擎、訪問本地檔案、對接 API 服務，甚至直接操作第三方工具庫。這種能力讓 AI 不再是一座“資料孤島”，而是成為了一個可以即時連線萬物的智慧中樞。
更關鍵的是，MCP 是一套開放協議。只要開發者遵循這一標準，AI 就能無縫接入本地資料、網際網路資源、開發工具乃至整個生態社群。試想一下，當 AI 可以隨時呼叫你電腦裡的文件、即時檢索最新網路資訊、聯動專業軟體完成任務時，其協作效率和工作潛力將呈指數級提升。這不僅是技術的進步，更是邁向“萬物智慧互聯”的關鍵一步——而 MCP，正是這一切的基石。
既然 MCP 在大模型應用開發中如此重要，要從 0 到 1 開發出一款 MCP Server 到底難不難？
從搭建基礎框架到最終上線，MCP Server 的開發流程究竟如何？哪些關鍵環節決定著開發週期與質量？開發過程中，最難攻克的難題是什麼？行業內又有哪些實戰經驗可供借鑑？本次我們邀請到了集簡雲 CTO 杜江與我們共同深入探討上述問題，他將為我們揭開 MCP Server 開發的神秘面紗，剖析技術要點，分享實踐經驗，為 MCP Server 的開發與最佳化提供思路與方向。
杜江： 首先是進行環境準備和技術選型，目前官方提供的有 TypeScript、Python、Java、Kotlin、C# 的 SDK 可供選擇，當然也可以使用像 FastMCP 這樣的腳手架。FastMCP 是一款開源的、專為 Python 開發者打造的 MCP 神器。
前期語言和工具選好後，然後是進行核心功能的開發。MCP Server 的主要能力包括資源管理、工具整合、提示詞模板，這時候就看這個要開發的 Server 是使用的哪部分能力, 根據要實現的功能使用 SDK 進行相關邏輯的開發。
邏輯實現完了，就可以選擇使用哪種傳輸方式來實現，可以選擇本地通訊（Stdio）或者遠端通訊（SEE），傳輸方式實現完了就可以進行調測了。調測可以選擇 MCP Inspector 或者客戶端（Claude Desktop、VS Code 等）。測試沒問題後接下來就可以部署上線了，大概是這樣一個流程。
整個流程耗時情況取決於核心功能的複雜程度和開發人員的經驗，新手如果是實現一兩個簡單的 tool 進行本地除錯，1～3 天應該能完成，如果是整合外部 API、資源管理、SSE 部署這樣的，那就差不多需要 3～7 天能完成，如果要實現更復雜的功能耗時就會更長一點。
杜江： 我覺得最難的一環在於 tool 開發裡的定義工具，它的核心點在於讓 LLM “理解” 工具的語義、引數邏輯和使用場景，而非單純的程式碼實現。
MCP 只是解決了協議通訊的問題，LLM 透過協議中工具的文件字串和引數註解推斷呼叫方式，如果描述的比較模糊（比如“查詢天氣” 未明確 “城市” 是必填字串），可能會導致 LLM 生成無效引數（比如傳入數字 ID）。而現在業內普遍的解決方案都是在工具描述或者引數描述中加上一些約束性的示例，比如剛才這個例子，就可以寫城市名稱必須為中文，同時也可以給一些示例，比如：“北京” 這樣的情況。
總體來講就是工具文件的重要性大於程式碼實現，在調測的時候有時候花在這上面的時間比在程式碼實現上的時間還會多一些。
MCP Server 接入老舊系統，
如何解決延遲問題
杜江： 經過一段時間的發展，我覺得現在相容性問題比以前好多了，各大廠商都在積極的支援 MCP。但是也會遇到一些問題，比如在工具的引數處理上，引數要求是一個多層結構的字典型別，有的模型支援不了這麼複雜的結構，或者最多也就支援一層或者兩層，再多了就支援不了了，遇到這種問題就存在需要單獨適配的情況。
杜江： 可以透過引數扁平化處理、引數分層介面卡、能力協商機制、Fallback 策略等方式單獨適配。
引數扁平化處理，就是對於不支援多層巢狀的模型，將深層引數結構展開為帶命名分隔符（如"layer1_layer2_key"）的扁平化鍵值對，並在模型呼叫前後自動進行格式轉換；引數分層介面卡，為特定模型開發定製介面卡，自動將原始引數拆分為多個單層呼叫（如將 4 層結構拆分為 4 次 API 呼叫），最後聚合處理結果。
能力協商機制，在模型註冊階段透過元資料宣告其引數深度支援能力，MCP Server 根據宣告自動選擇相容的引數傳遞模式。
Fallback 策略就是當遇到不支援的引數結構時，自動降級為最小可用引數集，並透過日誌告警提示開發者需要手動最佳化引數結構。
杜江： 可以透過日誌記錄被呼叫時候的輸入輸出引數，透過這些引數幫助分析模型對於工具的描述、引數描述的準確性，幫助最佳化改善這些定義描述，也可以透過整合可觀測性工具（如 Prometheus、Grafana 等）即時監控伺服器負載、網路延遲、資源利用率等指標，定位效能瓶頸。
杜江：MCP 在和 Client 通訊的時候支援 SSE（Server-Sent Events） 或類似流式傳輸協議，允許資料在生成時逐步傳輸，消費端逐步處理。例如提到的金融交易風險預警場景中，MCP Server 可即時接收交易流資料，逐步分析並即時觸發風險警報，在 MCP Server 實現具體業務邏輯的時候，也是可以採用快取、非同步處理等技術的。
我舉個例子，比如智慧客服系統的語音流處理案例中，MCP Server 透過非同步處理分片上傳和即時轉錄技術，同時接收使用者語音流並返回文字響應，延遲可以控制在毫秒級。
杜江：MCP Client 連線到 MCP Server 時，會發送初始請求以獲取伺服器的能力資訊，伺服器會返回其可用的 tools、resources、prompts 以及相關引數的詳細資訊。當有新的資料來源接入時，MCP Server 會在下次進行能力交換時動態更新其能力描述, 透過客戶端呼叫如介面 tools/list，將新資料來源的相關資訊包含在其中。由於 MCP Client 無需硬編碼或預定義引數，只需查詢 Server 的最新能力就可以完成自動適配。
杜江： 當遇到老舊系統或者載入比較慢的系統的時候，可以提前實現一個持久化連線池，並維持連線活躍狀態，當系統啟動時的快取預熱，預先載入高頻訪問的核心資料（如使用者許可權、基礎配置、常用業務資料等）到記憶體快取中；或根據使用者行為的預測性預載入，分析歷史請求模式和使用者上下文資料，透過預測熱點資料並提前載入至多級快取；或增量式快取構建與自動重新整理，對於動態變化的資料，可以採用增量快取機制，僅預載入靜態或低頻變更的基礎資料，並結合自動重新整理功能確保快取一致性。當後端資料更新時，系統會觸發非同步更新快取，總的來說方法有很多，可以針對具體問題具體分析解決。
杜江：OpenAI 函式呼叫要求開發者為每個工具手動編寫完整的 JSON Schema 描述（包括函式名、引數定義等），並在程式碼中硬編碼工具呼叫邏輯，MCP 透過協議標準化和自動發現機制，可大幅減少此類重複工作。
OpenAI 函式呼叫的方式在模型廠商之間實現的介面還不完全一樣，那麼開發者切換模型時需重寫適配程式碼，而 MCP 作為開放協議，理論上可透過一次整合適配多模型和多工具，也可減少此類重複工作。假如我要在 5 個模型之間切換，我得調整 5 次，如果使用 MCP，那就一次就好了, 在這個例子中，就減少了 80% 的工作量。
6 月 27～28 日的 AICon 北京站將繼續聚焦 AI 技術的前沿突破與產業落地，圍繞 AI Agent 構建、多模態應用、大模型推理效能最佳化、資料智慧實踐、AI 產品創新等熱門議題，深入探討技術與應用融合的最新趨勢。歡迎持續關注，和我們一起探索 AI 應用的無限可能！
今日薦文
你也「在看」嗎？👇