1. 項目概述MCP的“死亡”與新生最近在AI開發圈里一個話題被反復提及“MCP Is Dead”。乍一聽這像是一個聳人聽聞的標題仿佛某個重要的技術標準一夜之間被宣判了死刑。但作為一名深度參與過多個AI Agent和工具集成項目的開發者我深知技術領域的“死亡”往往不是終結而是一次深刻的范式轉移或價值重估。MCP即 Model Context Protocol由 Anthropic 公司提出旨在為大型語言模型LLM提供一個標準化的協議讓它們能夠安全、可控地調用外部工具、數據和功能。它曾經被寄予厚望被認為是解決AI“工具使用”碎片化問題的終極方案。然而“MCP Is Dead”這個論斷的背后反映的正是社區在狂熱追捧后對其實際落地成本、復雜性以及生態現狀的集體反思。這篇文章我想從一個一線實踐者的角度拆解MCP協議的核心、它面臨的真實困境、以及在這個“后MCP時代”我們這些開發者該如何構建更務實、高效的AI工具集成方案。簡單來說MCP試圖做的是為AI和外部世界之間架設一座“標準化的橋梁”。想象一下你開發了一個AI助手你希望它能幫你查天氣、讀數據庫、操作Figma設計稿、或者控制智能家居。在沒有標準之前你需要為每一個功能編寫特定的代碼、處理復雜的授權和數據結構轉換。MCP協議定義了一套通用的“語言”基于JSON-RPC讓工具提供者Server和AI客戶端如Claude Code、Cursor能夠互相發現、描述和調用能力。它的理想很豐滿一次開發處處可用。但現實是這座“標準橋”的修建和維護成本可能比我們預想的要高得多。2. MCP協議的核心架構與理想藍圖要理解為什么有人會說“MCP Is Dead”我們首先得清楚它當初被設計出來要解決什么問題以及它是如何試圖解決的。2.1 MCP協議的三層架構解析MCP的架構可以清晰地分為三層理解這三層是看清其優劣的關鍵。第一層傳輸層Transport這是最底層負責在MCP Server工具提供方和MCP ClientAI客戶端如Claude Desktop之間建立通信通道。它支持兩種主要方式stdio標準輸入輸出最常見的方式Server作為一個獨立的進程啟動通過管道與Client交換JSON-RPC消息。這種方式簡單、跨平臺適合本地工具集成。SSEServer-Sent Events基于HTTP的協議允許Server向Client單向推送事件。這為一些需要實時通知的場景如文件變更提供了可能但在實際中應用較少。傳輸層本身不復雜它的目標是提供一個可靠的、雙向的通信基礎。第二層協議層Protocol這是MCP的核心定義了一套基于JSON-RPC 2.0的“語言”。所有交互都圍繞幾個核心的RPC方法展開initialize/initialized握手交換客戶端和服務器的能力信息。tools/list客戶端向服務器請求可用的工具列表。tools/call客戶端調用某個具體的工具并傳入參數。resources/list/resources/read用于暴露和讀取“資源”如文件、數據庫表結構等只讀數據。prompts/list/prompts/get用于管理可復用的提示詞模板。這個協議層設計得相當優雅和完備。它通過嚴格的Schema定義使用JSON Schema來描述工具的參數和返回值理論上能保證類型安全并讓AI能準確理解工具的用途。第三層生態層Ecosystem這是MCP雄心壯志的體現也是目前爭議最大的部分。Anthropic理想中的生態是豐富的Server市場開發者可以為各種服務GitHub、Figma、數據庫、命令行工具編寫MCP Server并發布到一個公共市場。兼容的Client所有主流的AI編碼助手Claude Code、Cursor、Windsurf等和桌面應用Claude Desktop都內置MCP Client支持。用戶無縫集成用戶只需在Client配置文件中添加一行Server配置就能立即獲得數十上百個新能力。這個藍圖如果實現無疑是開發者的福音。但正是這個生態層暴露了MCP的諸多“阿喀琉斯之踵”。2.2 MCP與相關概念的對比Function Calling, Skill, Plugin在討論MCP時我們經常聽到Function Calling、Skill特別是Cursor的Skill、Plugin如ChatGPT Plugin這些詞。它們有什么區別Function Calling這是OpenAI提出的一種機制本質上是LLM原生能力的一部分。你在請求LLM時可以附帶一個“工具列表”函數定義LLM在理解用戶意圖后可能會選擇調用其中一個函數并輸出結構化的參數。然后由你的應用程序代碼去執行這個函數。Function Calling是“描述”執行權在開發者手中。MCP可以看作是Function Calling的“遠程執行版”和“標準化版”它把函數的定義、發現和執行都協議化了。Skill (Cursor)Cursor的Skill是一個更上層的、應用特定的概念。一個Skill可能包含前端UI、特定的工作流、以及對一個或多個后端工具可能是MCP Server也可能是直接API調用的封裝。Skill追求的是開箱即用的用戶體驗而MCP追求的是底層能力的標準化。你可以用MCP Server為Skill提供“彈藥”但Skill本身不是MCP。Plugin (ChatGPT)ChatGPT Plugin是一個已經逐漸被邊緣化的方案。它更側重于為ChatGPT提供網絡訪問能力并且與OpenAI的生態系統深度綁定不夠通用。MCP在設計上更底層、更開放。簡單類比Function Calling是“菜譜”MCP是“標準化廚房和送餐流程”而Cursor Skill是“一家提供特定菜系的餐廳”。3. “MCP Is Dead”的深層原因理想與現實的裂縫喊出“MCP Is Dead”的開發者并非否定協議本身的技術價值而是對其實施成本、維護負擔和當前生態狀態感到失望。以下是幾個核心痛點3.1 高昂的開發和維護成本編寫一個功能完整的MCP Server遠非定義一個JSON Schema那么簡單。它要求開發者處理復雜的生命周期Server需要以獨立進程運行處理初始化、重連、錯誤處理和優雅關閉。實現完備的協議方法即使你只提供一個工具也需要完整實現tools/list,tools/call并妥善處理initialize握手。處理認證與安全很多工具需要API Key或OAuth認證。MCP協議沒有規定標準的認證流程這成了Server開發者的“噩夢”。你需要自己設計如何安全地傳遞和存儲密鑰例如通過環境變量或配置文件并確保在Client側的用戶體驗不會太差。處理數據轉換和錯誤將第三方API的響應轉換成MCP協議要求的格式并處理各種網絡超時、速率限制和API錯誤需要大量的膠水代碼。對于只是想快速讓AI調用某個小功能的開發者來說這個成本太高了。相比之下寫一個簡單的Python腳本或一個專用的CLI工具往往更快、更直接。3.2 貧瘠且不穩定的生態Anthropic官方維護的MCP Server數量有限而社區貢獻的Server質量參差不齊。維護狀態堪憂很多在Github上開源的MCP Server在發布初期更新活躍但很快就不再維護。當你滿懷希望地配置一個Server卻發現它因為依賴過期或API變更而無法工作時挫敗感極強。配置復雜每個Server都有自己獨特的配置方式環境變量、配置文件格式用戶需要在Client的配置文件如Claude Desktop的claude_desktop_config.json里小心翼翼地填寫。一個配置錯誤就可能導致整個Client啟動失敗。缺乏“殺手級”應用目前大多數MCP Server提供的功能都可以通過其他更簡單的方式實現如直接使用API或編寫一個Alfred/ Raycast腳本。真正能體現MCP“不可替代性”的、能極大提升AI助手能力的Server并不多見。3.3 性能與體驗問題啟動延遲MCP Client在啟動時需要加載所有配置的Server。如果某個Server啟動慢或出錯會拖慢整個Client的啟動速度。上下文污染當AI客戶端加載了太多MCP工具后這些工具的描述會被加入AI的上下文。這可能會干擾AI對主要任務的理解導致其過于頻繁地建議使用工具或者因為上下文太長而影響性能。調試困難MCP的通信是后臺進程間的JSON-RPC調試起來比普通的應用程序代碼要困難得多。當工具調用失敗時你需要查看進程日志、網絡抓包排查鏈條很長。3.4 來自替代方案的競爭就在MCP努力構建生態時更輕量、更務實的方案正在被廣泛采用。“代碼即工具”模式許多AI編碼助手包括Cursor的新版本強化了直接讓AI編寫并執行代碼片段的能力。例如AI可以當場寫一段Python代碼來讀取數據庫或者寫一段curl命令來調用API。這種方式靈活、直接無需事先準備Server。專用集成而非通用協議像Windsurf、Cursor這類IDE更傾向于為高頻、核心場景如Git操作、終端、文件樹打造深度、流暢的原生集成體驗而不是依賴一個通用的、可能不穩定的外部協議。本地函數調用對于一些復雜的、需要狀態管理的工具直接在應用程序內部實現一個函數調用接口然后通過簡單的提示詞工程暴露給AI往往比運行一個完整的MCP Server更高效、更可控。這些替代方案雖然“不標準”但它們解決了用戶眼前的問題而且體驗更好。這動搖了MCP存在的根本理由。4. 后MCP時代的務實工具箱我們該如何選擇那么作為一名開發者在“后MCP時代”我們應該如何為AI助手賦予工具能力呢我的建議是放棄對“萬能標準協議”的幻想回歸問題本質根據場景選擇最合適的工具。4.1 場景一快速原型與一次性任務 - 使用AI的代碼解釋與執行能力適用場景你需要AI幫你分析一個日志文件、從一個陌生API拉取數據做簡單分析、或者批量重命名文件。方案直接利用AI如Claude-3.5 Sonnet, GPT-4強大的代碼生成和理解能力。操作示例在ChatGPT或Claude Web界面我有一個名為 sales.csv 的文件請幫我寫一段Python代碼計算每個產品的總銷售額并找出銷售額最高的產品。你可以假設文件有product和revenue兩列。AI會生成代碼。對于Claude Code或Cursor你甚至可以直接在IDE里要求AI編寫并執行代碼片段。優勢極度靈活無需任何前期配置。AI能根據你的描述動態生成最合適的工具代碼。劣勢不適合需要持久化配置、認證或復雜狀態管理的任務執行環境有安全限制。4.2 場景二高頻、穩定的核心工作流 - 打造專用集成或使用成熟SDK適用場景你每天都需要用AI操作Git、查詢內部數據庫、或與Jira/Trello等項目管理工具交互。方案為IDE開發插件/擴展如果你主要使用Cursor或VS Code為其開發一個專用的擴展。這能提供最好的用戶體驗自定義UI、命令面板、狀態欄。構建一個輕量級CLI工具用Python/Rust/Go編寫一個功能聚焦的命令行工具做好錯誤處理和幫助文檔。然后你可以簡單地提示AI“要完成X請運行命令my-tool --arg1 value”。AI通常能很好地理解和使用CLI。使用官方或社區SDK對于Figma、GitHub、飛書等服務通常有成熟的SDK。你可以編寫一個簡單的腳本層封裝SDK然后通過上述“代碼執行”或“CLI”方式暴露給AI。優勢性能好、體驗佳、穩定可控、功能可以做得非常深入。劣勢有開發成本且綁定特定環境或工具鏈。4.3 場景三需要暴露給多種AI客戶端的復雜服務 - 考慮簡化版MCP或自定義API適用場景你開發了一個內部數據分析服務希望無論是Claude Desktop、Cursor還是未來的某個AI助手都能調用它。方案簡化版HTTP MCP Server如果你依然欣賞MCP的“描述發現”機制可以只實現最核心的tools/list和tools/call端點使用HTTP傳輸并簡化認證如使用固定的API Key。這比實現完整的Stdio Server要簡單。構建一個簡單的RESTful API這是最通用、最持久的方法。設計一個清晰的API提供Swagger/OpenAPI文檔。任何能進行HTTP請求的AI通過代碼或插件都可以調用它。許多AI現在能很好地理解OpenAPI規范。使用云函數Serverless將工具邏輯部署為AWS Lambda、Vercel Function或云開發云函數。通過一個API網關暴露按需執行無需管理服務器。注意選擇這種方案時務必把安全放在第一位。做好API的認證、授權、限流和輸入驗證避免AI被惡意引導調用危險操作。4.4 工具選型決策流程圖為了更直觀你可以根據以下問題來決定技術路徑開始 | V 你需要AI使用的工具是 -- (一次性/探索性任務) -- 方案讓AI寫代碼直接執行 | | (高頻、固定工作流) (需多客戶端訪問的復雜服務) | | V V 你主要的AI工作環境是 你更看重什么 | | (Cursor/VS Code等IDE) (其他) (標準化/發現) (簡單/可控) | | | | V V V V 開發IDE插件 打造專用CLI工具 簡化版MCP RESTful API5. 實操案例從MCP Server到專用CLI工具的轉型我曾經為一個團隊開發過一個MCP Server用于查詢項目內部的用戶行為數據倉庫。最初選擇MCP是希望分析師能在Claude Desktop里直接進行數據探索。但后來我們遇到了Server維護、依賴沖突和權限管理復雜等問題。最終我們將其重構為一個更簡單的方案體驗反而提升了。原始MCP Server方案痛點分析師需要在自己的電腦上配置Python環境、安裝依賴、設置數據庫連接字符串。Claude Desktop配置復雜經常因為路徑或環境變量問題連接失敗。添加新的查詢參數需要更新Server并重啟流程冗長。轉型后的方案專用CLI工具 別名提示用Go重寫核心邏輯編譯成一個獨立的、無依賴的二進制文件>