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