MCP很好，但它不是萬靈藥（輕科技）

看完這篇文章，確實有點對 MCP 協議有了祛魅時刻。作爲程序開發人員，AI 編程的火爆，確實降低了很多編程門檻和提升了很多開發效率，而 MCP 的出現，讓 AI 的能力發揮更上一層樓 MCP 的出現就是爲了解決 LLM 接口碎片化，開發低效等問題。這也正是爲了解決開發者如何讓 AI 應用能夠與本地環境和外部工具無縫交互，而無須爲每個工具單獨開發接口的問題。MCP 提供了在有限資源條件下構建功能豐富 AI 應用的捷徑，讓我們無需在爲接入工具而煩惱，更多的是專注於使用上。當然，方便是方便了，但也存在了很多歧義，也有很多人希望 MCP 能夠一勞永逸的通過自動化改善 AI 系統的決策能力，或者提升任務規劃的效率。說明很多人對這個 MCP 理解是有偏差的，工具與工匠是兩碼事。實際上沒有理解 MCP 本質：一套“工具插座”的標準規範，它的使命是確保插頭能順利插入，而非決定用哪個電器、怎麼使用電器。簡單地說，MCP 則專注於提供統一的工具調用接口 總之，“在技術演進的長河中，我們總是傾向於尋找一勞永逸的解決方案，一種可以解決所有問題的銀彈。但如同軟件工程中著名的“沒有銀彈”論斷，AI 工具調用領域同樣不存在萬能的解決方案。”所以，未來也一樣吧

講MCP和Function call的區別部分用一個很清晰的視角解釋的很立體，我喜歡將MCP比喻成美團的那個例子。對MCP最準確的描述就是協議，但是協議本身也是一個很抽象的概念，這種具體的比喻對產生創意很有幫助。 揭露MCP的兩個痛點也很spot-on，開發的不成熟對應着社會進步中的哲學問題：快是慢的先導與前提，慢不是一個應該直接追求的結果，而是在快之後，大浪淘沙剩下的沉澱；實用性不足對應着真相與假象的一些思考：它是好的-它不夠好-但它也是好的。有遠見的公司應該給一些敢於革命的idea一些時間，允許自己更長久的馳騁在浪上的辦法是不抗拒海浪。正確認識MCP，也是正確認識技術變革與社會更替的必修課。

本書深入剖析了MCP在AI領域作爲統一工具調用協議的現象級崛起，探討了其技術架構、與Function Call的關係以及在實際應用中的表現。 通過分析MCP在本地和雲端的應用差異，揭示了其在開發過程中遇到的難題和市場中的浮躁現象。 此外，書中還探討了MCP協議的侷限性，強調其在實現全面AI功能上的不足，並指出AI工具選擇的重要性以及各大公司在MCP生態中的實踐。 通過對MCP的理性認知，本書幫助讀者理解其在AI領域的角色及其未來發展面臨的挑戰與機遇。

MCP解決的真實問題是什麼？ 以前 AI 調工具是這樣的： 每個 AI： 自己寫 GitHub API 接入 自己寫 Figma API 接入 自己寫 Slack API 接入 結果： 100個AI × 100個工具 = 10000個對接。 MCP 的思路很工程師： 不讓 AI 直接接工具，而是讓工具統一實現 MCP 標準。 於是變成： AI 只學 MCP 一種協議 工具各自實現 MCP server 變成： 100 AI × 1 MCP 100 工具 × 1 MCP 複雜度瞬間下降。 【以 Figma MCP 舉例說明】 底層發生的是： Claude/Codex：“我需要畫圖” 發現有 MCP 工具：Figma MCP server 於是： Codex → MCP → Figma MCP → Figma API → 創建圖 然後返回：圖 URL。 AI 不知道 API 怎麼用，但 MCP 可以把 API 變成 AI 能理解的“能力描述”。

當某項科技出現狂熱時，確實需要有人潑冷水，《MCP很好，但不是靈丹妙藥》就是對MCP的冷靜思考。 市場整合需要時間和時機，但大浪過後，總會有雜質重新衝回大海，但那些五彩斑斕的貝殼，卻被留了下來。

《MCP很好，但它不是萬靈藥》在介紹協議本身時並沒有停留在“概念”層面，而是把技術、市場與生態三條線索貫穿始終，形成了對 MCP 的立體審視。下面從三個維度梳理這一過程。 ​​一、技術底座：MCP 的設計初衷與實現路徑​​ 1. ​​起源​​：MCP 最初是 Anthropic 爲 Claude Desktop 定製的本地工具調用接口，目標是讓 AI 助手能夠統一地調用本地文件、應用與外部 API，從而“按需插件化”擴展能力。 2. ​​核心機制​​：它通過一套輕量級協議把“模型-工具-數據”解耦，客戶端與服務器端依靠 SSE 長鏈接+HTTP 短鏈接的雙鏈模型，既支持實時推送也兼顧一次性調用。但這種設計在企業級場景下帶來了併發、跨機器尋址和安全管控的額外複雜度。 3. ​​適用邊界​​：在本地桌面端，MCP 真正解決了“工具碎片化”痛點；到了雲端，它反而增加了 round-trip 開銷，與現有 RPC/無狀態服務範式存在天然衝突。 ​​二、市場與生態：熱度、混亂與篩選​​ 1. ​​爆發式增長​​：兩個月內獲 OpenAI、百度、字節、阿里等巨頭背書，被視作 Agent 工具調用的“通用語言”，甚至蓋過新模型發佈熱度。 2. ​​市場亂象​​：數千個 MCP 工具湧入，可用性低，“就像 App Store 初期的混亂”，真正能用的不足二成。 3. ​​自然選擇與收斂​​：作者指出，這正是新興生態必經的過度膨脹階段；經歷市場篩選後，只會留下真正有價值的部分——類比互聯網泡沫後留下電商與社交通道。 4. ​​產業鏈協同​​：具體應用案例把抽象框架轉成可見商業價值，觸發網絡效應——工具越多，AI Agent 越強大，反過來吸引更多供應商加入生態。 ​​三、案例視角：誰用得爽、誰被拖累​​ 1. ​​本地客戶端受益​​：Cursor 等編輯器藉助 MCP 動態加載插件，實現“開箱即用”的開發體驗。 2. ​​雲端服務掙扎​​：企業如果已有成熟 REST API，再做一層 MCP 適配既增維護成本又難獲直接收益，因此 Adoption 動力不足。 3. ​​大廠佈局​​：百度、字節、阿里分別在 C 端、工作流與支付場景中集成 MCP，試圖搶佔用戶日常交互入口，顯示協議正在成爲平臺競爭的新戰場。 ​​四、價值與侷限的綜合判斷​​ • ​​價值​​： – 爲桌面端和小型團隊提供“開箱即插”的工具集成捷徑； – 促進跨廠商、跨場景的 Agent 互操作，奠定統一接口的可能； – 在動態工具發現、實時推送等場景展現獨特優勢。 • ​​侷限​​： – 雲端和大型企業因現有 API 體系、安全管控與成本顧慮，對其興趣有限； – 協議自身仍在快速迭代（如從 SSE 遷向 streamable HTTP），生態兼容壓力大； – 市場泡沫導致工具質量參差，需要時間和規範去篩選。 ​​五、理性看待“行業通用語言”​​ 作者反覆強調：MCP 是“行業通用語言”的說法更多是一種營銷敘事，而非事實。它在特定場景（本地、開發者工具）確實解決了痛點，但在更廣闊的雲端、企業服務領域，它只是衆多互操作方案之一，需要與現有標準並行甚至被新的更高層框架（如 A2A）所抽象。真正的“萬能鑰匙”並不存在，只有對場景足夠了解、對成本與收益進行權衡，才能判斷是否以及如何採用 MCP。 通過技術深挖、市場觀察與生態案例並行的論述，本書幫助讀者在狂熱與質疑之間找到理性平衡：肯定其創新價值，也看清其落地邊界，這正是“很好，但不是萬靈藥”的題中之意。

MCP本質是一個開放協議，可以理解成“USB-C接口”，通過標準化接口解決AI模型與外部工具以及數據源的“M×N集成難題”，實現跨平臺、跨模型的交互，讓LLM升級爲“行動執行”。它的核心價值在於統一通信規範、降低開發成本，支持即插即用與上下文持續維護，同時通過數據隔離、權限管控保障安全，對於開放AI生態構建有積極意義。 這本書的“但是”是在強調它存在明確的侷限，使用前需要考慮清楚：它不具備決策與工具選擇合理性驗證能力，無法替代AI系統本身的智能；開放生態帶來安全風險，需應對名稱欺騙、代碼注入等攻擊；需要承擔老舊系統兼容成本，開發者需掌握特定技術，且目前爲止生態尚未成熟；工具增多易導致上下文膨脹，影響性能與成本控制。 在決定使使用MCP前，一定明確其“協議工具”定位，通過最小權限原則、嚴格輸入驗證、合理控制工具數量等方式規避風險，在發揮其連接價值的同時，依託人類監督與生態完善實現高效應用。

一個不錯的比喻說明mcp的整個執行流程： 老闆（用戶）要喝咖啡，於是，在辦公室（MCP Host）裏，辦公室主任（大模型）吩咐祕書（Agent）去買一杯美式（Function Call）。祕書（Agent）查了一下供應商名冊，發現美式咖啡的供應商已接入了美團或公司統一採購系統（實現了MCP Server），接着，祕書在採購系統中找到供應商（MCP Client）一鍵下單。 在過去沒有MCP時，大模型下發Function Call，Agent去執行翻譯，直接連接到API去調用工具。因此，你得爲每個API單獨設置對應的調用模式，去單獨定義工具列表和調用模式，這樣Agent才知道怎麼去翻譯。而有了MCP後，只是很多API都可以直接通過供應商MCP Client一鍵下單了，Agent省力了。但大模型的Function Call沒有任何變化。還是{tool: “買咖啡”, "type": “美式”}這個形式。

1. MCP只是一套協議，統一了大模型調用工具過程中的接口複雜性問題，如果某個工具實現了MCP協議，就可以更方便的給大模型調用 2. MCP沒有決策能力，大模型才能做出決策 3. MCP由於在發展初期，市場上大多數工具的MCP服務還比較的粗糙

我有一個不成熟的見解:爲什麼一個協議會這麼火？不過是大部分人無法從事大模型的開發，又爲了趕上AI這趟浪潮，從MCP這一個容易理解又能快速開始的協議上手，也算搭上了這趟車，不過可能是在火車車頂。