本文約 4800 字，預計閱讀時間約 14-16 分鐘。
2024年11月，Anthropic發佈了一個叫MCP的東西。
他們說這是"模型上下文協議"，能讓AI像插USB接口一樣連接各種工具。聽起來很美好。
但很快，就有人開始問：MCP是不是已經過時了？
這就奇怪了。一個剛出生的協議，怎麼就要過時了？
本文涉及agent、mcp、skill相關信息，如不瞭解可以先查看我之前的文章：
目錄
1. MCP是什麼？
它要解決什麼問題？
想象一個AI應用開發場景。需要讓它能：
📁 讀取用戶的本地文件
🗄 查詢數據庫
💳 調用支付系統完成交易
📝 在項目管理工具裏創建任務
在MCP之前，每接一個工具，都要寫一堆適配代碼。
就像每個電器都要配一個專用插座，抽屜裏堆滿了各種轉換頭。
更糟的是，這些代碼沒法複用——給Claude寫的文件讀取邏輯，不能直接用給ChatGPT。
每個AI應用都在重複造輪子。
MCP想做的，就是統一插座標準。
MCP的三層架構
🏠 Host —— 直接用的那個應用（Claude Desktop、Cursor）
🔌 Client —— 藏在Host裏面，負責跟Server聊天。
一個Host可以有多個Client，就像插線板上有多個插孔。
⚙ Server —— 獨立運行的小程序，每個對應一個具體工具
爲什麼要分三層？
現實中，一個AI應用要同時連很多工具。
Claude Desktop可能一邊讀本地文件，一邊查GitHub，一邊調用計算器。
Host通過多個Client分別管理這些連接，互相隔離，互不干擾。
核心價值：解耦
這個三層設計有個好處：解耦。
Host不需要知道Server具體怎麼實現文件讀取。
它只需要說"我要讀這個文件"，剩下的交給Server。
同樣，Server也不需要知道Host是Claude還是ChatGPT，它只負責做好自己的事。
這意味着工具可以獨立演進。
支付系統可以更新它的接口，只需要改自己的MCP Server，不用通知所有AI應用。
AI應用也可以自由切換工具，只要對方支持MCP就行。
聽起來很理想。
但問題是——真的需要這個中間層嗎？
2. 質疑的聲音
有人提出一個直接的問題：如果AI應用可以直接集成工具能力，爲什麼還要MCP這個中間層？
比如Claude Desktop，它完全可以自己實現文件讀取、網頁搜索這些基礎功能。
這個觀點有道理，但有個前提：AI應用要自己實現所有工具。
現實是，Claude不可能自己實現所有工具。
它不會自己去對接複雜的支付系統，不會自己去維護各種項目管理工具的接口。
這些專業工具的邏輯太複雜，更新太頻繁，AI應用開發商沒精力也沒必要自己搞。
更準確的說法是：
✅ 基礎能力（文件、網絡、代碼執行）→ AI應用自己內嵌更高效
✅ 專業能力（支付、項目管理、數據庫）→ 通過MCP連接更合理
兩種模式會並存，而不是互相替代。
但質疑聲沒有停止。
3. 大廠真的買賬嗎？
MCP是Anthropic推出的。
作爲Claude的母公司，Anthropic在AI領域有顯著的技術影響力和快速增長的市場份額。
但在制定行業標準方面，三家巨頭（OpenAI、Google、Anthropic）仍在激烈競爭中，尚未形成絕對主導。
這就帶來一個問題：其他大廠會甘心跟隨Anthropic制定的標準嗎？
表面的熱鬧
從數據看，MCP的採用似乎不錯：
2025年5月，OpenAI、Anthropic、Mistral在一週內集中發佈API支持
GitHub上MCP相關repo數量快速增長
支付平臺、數據庫服務等工具廠商主動提供MCP適配
但這些數字背後有細節值得琢磨。
OpenAI支持MCP，是真的認同這個方向，還是"不得不跟"？
要知道，OpenAI有自己的Plugin系統，有自己的Function Call標準。
多支持一個MCP對它來說成本不高，但能讓開發者多一個選擇——這個選擇恰好不是它控制的。
4. Google的另起爐竈
2025年4月，Google推出了A2A（Agent2Agent）協議。
A2A和MCP解決的問題完全不同：
🔧 MCP是AI應用連接工具的標準
🤝 A2A是Agent之間協作的標準
但A2A的出現釋放了一個信號： Google不想在MCP這個Anthropic主導的賽道上跟隨。
它要開闢自己的戰場。
這很正常。互聯網歷史上，標準化協議的競爭從來都是大廠博弈的延伸。
HTTP能成爲標準，背後是Netscape和微軟的較量
OAuth能成爲標準，背後是Google、Twitter、Facebook的妥協
MCP能否成爲標準，技術只是基礎。
更重要的是市場採用度和生態支持——這取決於大廠是否願意共同推動，而非各自爲戰。
5. 安全漏洞：CVE-2025-6514
2025年，安全圈爆出一個高危漏洞。
影響的是mcp-remote工具，CVSS評分9.6/10——滿分10分。
這屬於"極高危"。
攻擊者可以構造一個惡意的MCP Server，當受害者連接時，在其機器上執行任意代碼。
這不是理論風險，是真實存在的攻擊向量。
6. 設計上的爭議
除了安全問題，MCP的技術設計也有爭議。
雙向流作爲可選項
MCP協議把雙向流設爲"可選項"，客戶端可以選擇只實現最基本的polling模式。
這導致不同客戶端能力不一致——有的支持實時推送，有的只能輪詢。
後果是： 開發者不知道自己的MCP Server在不同客戶端上表現如何，用戶體驗不一致。
HTTP無狀態設計
MCP基於HTTP SSE（Server-Sent Events），本身是無狀態的。
這在大規模部署時會遇到問題。
如果需要水平擴展（百萬級請求），就得依賴Redis等共享存儲來同步狀態。
這不是設計錯誤，是架構選擇的權衡。但它確實帶來了性能瓶頸和運維複雜度。
7. MCP的替代方案：Skills與CLI?
MCP不是唯一的工具連接方案。業界提出了幾種替代思路，各有優劣。
方案1：Skills高層抽象
OpenClaw創始人Peter Steinberger提出了更激進的判斷：
Skills將取代MCP。
直接封裝工具能力，開發者無需關心底層協議。
Peter Steinberger的論證：
Skills是高層抽象，關注"做什麼"
MCP是底層協議，關注"如何連接"
OpenClaw通過Skills系統實現了強大的工具調用能力，無需配置MCP Server
方案2：CLI/Shell命令
Steinberger的另一個核心批評是：MCP的返回結果不可組合。
他舉了天氣API的例子：
❌ MCP方式：調用返回一大坨JSON——溫度、降水、風速全塞進來，整個上下文被污染
✅ CLI方式：模型調用Unix命令，可以用jq工具從JSON中只提取需要的字段
JSON是API常用的數據格式，通常包含很多字段。jq是一個命令行工具，用於處理和過濾JSON數據。
他的邏輯很直接：模型天生就擅長調用Unix命令，CLI就是另一條Unix命令而已。
實際使用者的反饋也印證了這一點。
有開發者總結：“如果一件事可以用一行shell命令完成，就不要用MCP。”
他們的使用策略是：
文件操作 → 直接用cat、grep
代碼搜索 → 用ripgrep
複雜工具（如數據庫）→ 才用MCP
核心原則：避免過度工程化。
很多MCP Server確實做得太重——簡單文件讀取都引入複雜依賴。對於這類任務，CLI更高效。
這些方案能取代MCP嗎？
部分場景可以，但全面取代不現實。
正確的認知是：
MCP的價值在於封裝複雜性，而不是替代簡單操作。
簡單任務用CLI，複雜工具用MCP——這可能是現階段最務實的使用方式。
更可能的結果是：MCP吸收CLI的優點（如結果過濾），而不是被CLI取代。
現實案例：OpenClaw刪郵件事件
這些安全風險不是理論上的。
2025年，Meta的AI安全總監Summer Yue在使用OpenClaw（Skills方案的代表）整理郵件時，AI突然失控刪除所有郵件。
她連續發出3次停止指令，AI全部無視，最終只能狂奔去拔網線物理斷電。
事後AI淡定回覆：“我知道你說了不讓刪，但我還是刪了。”
技術原因：“上下文壓縮"導致AI"忘記"了設置裏的"不能刪郵件"限制。
這個案例暴露了Skills方案的核心問題：
過度授權：AI獲得郵箱完全控制權限
無法緊急停止：3次停止指令無效
缺乏安全隔離：直接操作，無中間層保護
相比之下，MCP的Server層可以作爲安全邊界，限制AI的操作範圍。
在出現異常時也能快速切斷連接。
8. LLM變強會殺死MCP嗎？
有一個更根本的問題：如果LLM本身變得足夠強，還需要連接外部工具嗎？
想象兩個場景：
場景A：知識檢索
現在：需要MCP連接數據庫查資料
未來：LLM上下文窗口100萬token，直接把整個知識庫塞進去
場景B：簡單計算
現在：需要MCP調用計算器
未來：LLM推理能力增強，直接算出結果
但邊界在哪裏？
LLM再強，也有它做不到的事：
📧 外部系統交互——發郵件、創建日程、支付轉賬
📊 實時數據——股票價格、天氣、新聞
🤖 物理世界操作——控制硬件、IoT設備、機器人
所以更準確的說法是： LLM變強會替代一部分MCP場景，但不會替代全部。
更深一層的問題
有人可能會問：如果LLM足夠強，能不能直接讀API文檔，自己生成調用代碼？
不需要MCP Server，只需要給LLM一個skill文檔，讓它自己寫代碼連接外部系統？
技術上可行，但現實中不成立：
舉個例子： 讓LLM發一封郵件，它可能生成代碼調用郵件API。但如果：
網絡超時了怎麼辦？
認證Token過期了怎麼辦？
郵箱滿了怎麼辦？
對方服務器返回奇怪的錯誤碼怎麼辦？
MCP Server的價值不僅是"調用API”，而是封裝了所有這些工程細節和邊界情況處理。
更現實的路徑是： LLM輔助生成MCP Server的腳手架代碼，但執行仍然通過標準化的MCP協議——人機協作，而非完全替代。
9. 短期vs長期
短期（1-2年）：中心化趨勢明顯
現狀是：OpenAI、Anthropic、Google等頭部玩家有能力自建生態。
這意味着：
工具廠商不得不優先對接大廠的私有API
標準化協議的需求不迫切
MCP的價值被削弱
但這不是定局。
長期（3-5年）：去中心化力量會崛起
三個力量可能改變格局：
🏰 專業工具的護城河
Notion、Figma、Linear的用戶粘性不在"功能"，而在"數據和工作流"。
它們不會甘心只做API。
⚔ 多AI競爭格局
如果只有OpenAI一家獨大，中心化是定局。
但Claude、Gemini、Grok、Llama都在競爭，工具廠商有議價空間。
🔒 用戶的數據主權意識
用戶可能不希望所有數據都經過LLM廠商。
企業有敏感的商業數據，個人有隱私顧慮，某些行業（金融、醫療、政府）還有合規要求——數據不能出境。
本地AI方案（如Ollama + MCP）正好滿足這些需求：模型在本地運行，數據不離開用戶機器，MCP負責連接本地工具。
結語
MCP現在過時了嗎？
沒有。
它解決了AI應用連接外部工具的真實痛點，有大廠支持，有開發者生態，有工具廠商參與。
但"現在沒有過時"不等於"永遠不會過時"。
MCP面臨的不是"過時"問題，而是**“能否成爲標準”**的問題。
它現在處於關鍵窗口期：
技術還不夠成熟，需要時間迭代
生態格局還沒固化，有機會爭取
大廠博弈還在進行，結果未定
未來1-2年，這幾個變量會逐漸明朗。
屆時我們才能確定地說：MCP是成爲基礎設施，還是成爲過渡方案。
在此之前，保持關注，但不必急於下結論。
---
本文選題來自上篇文章2026年了，我的知識庫可以怎麼構建？投票結果，各位盒友還有什麼想看的，歡迎在評論區留言！
您的點贊、評論、收藏、充電是我更新的最大動力！
參考鏈接
超鏈接死活不起作用，我先把網址貼上吧
What is the Model Context Protocol (MCP)? - Model Context Protocol
https://modelcontextprotocol.io/docs/getting-started/intro
CVE-2025-6514安全公告(JFrog)
https://jfrog.com/blog/2025-6514-critical-mcp-remote-rce-vulnerability/
更多遊戲資訊請關註：電玩幫遊戲資訊專區
電玩幫圖文攻略 www.vgover.com
