博客 / 詳情

返回

MCP 爆火背後：是技術革命，還是精心包裝的“新瓶舊酒”？

2024 年末，MCP（Model Context Protocol）火了。各種技術文章蜂擁而至："MCP 革命性突破！"、"AI 工具調用的未來！"、"不懂 MCP 就out了！"

但當你真正去了解時，會發現很多文章要麼是概念科普（講了半天不知道怎麼用），要麼是願景描繪（聽起來很美好但落不了地）。

這篇文章就是來破局的。 我們不講故事，只講本質：MCP 到底是什麼？它解決了什麼問題？和 Function Call 有什麼關係？該不該用？

一、MCP 到底是什麼？

1.1 一句話説清楚

MCP（Model Context Protocol，模型上下文協議） 是一套標準化的協議，用來規範 AI 應用如何調用外部工具和數據源。

聽起來還是有點抽象？我們換個説法：

想象你在開發一個 AI 助手，需要接入：

  • 📍 地圖服務：查地址、規劃路線
  • 🌤️ 天氣查詢：實時天氣、天氣預報
  • 📊 數據庫：查用户數據、訂單信息
  • 📧 郵件服務：發送通知

沒有 MCP 之前：每個服務都有自己的接口格式

  • A 服務用 JSON-RPC
  • B 服務用 REST API
  • C 服務用 gRPC
  • D 服務要自定義協議

你得分別研究每個 API 文檔，寫不同的適配代碼，維護多套調用邏輯。團隊協作時還要反覆對齊接口格式。

有了 MCP 之後：大家約定統一的"接口標準"

  • 工具提供方按 MCP 協議暴露能力（MCP Server）
  • AI 應用按 MCP 協議調用工具（MCP Client）
  • 格式、認證、錯誤處理都有統一規範

類比理解：MCP 之於 AI 工具調用，就像 USB 之於數據傳輸。

  • 沒有 USB 前：每個設備都有自己的接口（各種圓口、方口、扁口），亂七八糟
  • 有了 USB 後：一個標準走天下，插上就能用

1.2 MCP 解決的核心問題

我們用一個實際場景説明：

場景：你在做一個智能客服系統，需要：

  1. 查詢用户訂單狀態（調用內部訂單系統 API）
  2. 查詢物流信息（調用順豐/京東物流 API）
  3. 查詢商品庫存（調用庫存系統 API）
  4. 發送客服消息（調用企業微信 API）

問題 1：接口格式不統一

// 訂單系統的接口
{
  "action": "query_order",
  "params": {"order_id": "12345"}
}

// 物流系統的接口
{
  "method": "trackShipment",
  "arguments": {"tracking_no": "SF123456"}
}

// 庫存系統的接口
POST /api/inventory/check
Body: {"sku": "PROD-001", "warehouse": "BJ"}

每個接口都不一樣，你得寫大量的適配代碼。

問題 2：AI 不知道該調用哪個工具

AI 收到用户問題"我的訂單什麼時候到？"，需要判斷：

  • 這個問題需要調用什麼工具？
  • 需要哪些參數？
  • 參數從用户的話裏怎麼提取？

沒有統一規範，每個開發者都自己定義，導致：

  • 工具描述格式不一致
  • 參數定義方式不一致
  • AI 難以準確判斷

問題 3：團隊協作困難

  • 前端開發者：後端接口怎麼調？參數格式是什麼？
  • 後端開發者：AI 會傳什麼參數過來？怎麼處理？
  • AI 工程師：工具列表怎麼維護？提示詞怎麼寫？

缺乏標準，溝通成本巨大。

MCP 的解決方案：

// 統一的 MCP 工具定義格式
{
  "name": "query_order",
  "description": "查詢訂單狀態",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "訂單ID"
      }
    }
  }
}

所有工具都按這個格式定義，AI 能統一處理，開發者能快速集成。

💡 Tip：MCP 不是銀彈，它只是把"調用外部工具"這件事標準化了。原有的問題（AI 判斷不準、參數提取錯誤）並沒有消失。

1.3 破除三個常見誤解

誤解 1："MCP 是一種新的 AI 技術"

很多文章會説"MCP 提升了 AI 的工具調用能力"，這是不準確的。

真相：MCP 底層用的還是傳統的 Function Call（工具調用）。

看一段 MCP 客户端的核心代碼：

// MCP 客户端決定使用哪個工具
const response = await openai.chat.completions.create({
  model: "gpt-4",
  messages: messages,
  tools: this.tools  // ← 這就是傳統的 Function Call 參數！
});

MCP 只是在 Function Call 外面包了一層標準化協議，沒有改變 AI 的判斷能力。

Function Call 原有的問題依然存在：

  • ❌ 工具選擇不準確（工具太多時容易選錯）
  • ❌ 參數提取錯誤（複雜參數容易提取不準）
  • ❌ 多意圖識別困難（一個問題涉及多個工具）

結論：MCP 是協議標準化，不是技術突破。

誤解 2："用了 MCP 就不用自己寫工具調用代碼了"

很多人以為 MCP 是什麼"開箱即用"的解決方案，裝上就能用。

真相：MCP 的工作流程和你自己實現 Function Call 幾乎一模一樣。

對比一下：

實現步驟 自己寫 Function Call 使用 MCP
1️⃣ 定義工具 寫工具描述 + 參數定義 MCP Server 定義工具（還是要寫）
2️⃣ AI 決策 調用 AI 的 Function Call MCP Client 調用 AI（還是 Function Call）
3️⃣ 執行工具 後端接收參數，調用真實 API MCP Server 執行並返回（還是要實現）
4️⃣ 生成回覆 把結果給 AI 生成回覆 MCP Client 把結果給 AI（邏輯一樣）

本質上是一樣的。

那 MCP 的價值在哪？答案是：生態標準化。

當大家都按同一套規則來：

  • ✅ 工具能跨項目複用
  • ✅ 團隊協作有統一規範
  • ✅ 第三方工具能方便集成
  • ✅ 降低學習和溝通成本

但如果你只是一個人開發，或者工具都是自己的內部 API，MCP 的價值就沒那麼大。

💡 Tip：把 MCP 理解成"工具調用的接口標準"，就像 RESTful API 是 Web 服務的接口標準一樣。

誤解 3："MCP 服務都是免費的"

看到各種 MCP Server（高德地圖、百度地圖、天氣服務），有人以為調用是免費的。

真相：API 調用成本最終還是要有人承擔。

以高德地圖 MCP 為例：

  1. 你通過 Cursor 調用高德地圖 MCP
  2. 高德的 MCP Server 收到請求後，會調用高德自己的地圖 API
  3. 這些 API 調用是計費的（按調用次數或配額）

有些大廠的 MCP 服務是免費的，但那是因為：

  • 前期投入，吸引開發者
  • 調用量有限制（超過就收費）
  • 培養生態、獲取數據、佔領市場

天下沒有免費的午餐，只是誰付費、怎麼付費的問題。

如果你用 MCP 接入收費服務，要注意：

  • ⚠️ 瞭解計費規則（按次數？按流量？按時長？）
  • ⚠️ 設置調用限額（防止意外超支）
  • ⚠️ 監控使用量（定期檢查賬單）
  • ⚠️ 考慮緩存策略（減少重複調用）

1.4 MCP 的真正價值：生態話語權

既然 MCP 沒有技術創新，為什麼 Anthropic（Claude 的母公司）要大力推？

答案是：爭奪 AI 工具生態的話語權。

類比：USB 標準的故事

還記得 USB 標準是怎麼來的嗎？

1990 年代：

  • 鍵盤用 PS/2 接口
  • 鼠標用串口
  • 打印機用並口
  • 掃描儀用 SCSI 接口
  • 每個設備都不一樣，亂七八糟

1996 年：

  • Intel、微軟、IBM 等巨頭聯合推出 USB 標準
  • 一個接口統一所有設備
  • 誰制定標準，誰就掌握話語權

今天：

  • USB 成為事實標準
  • USB-IF（USB 標準化組織）掌握生態控制權
  • 新技術（Type-C、USB4）都要通過他們認證

MCP 想做的就是 AI 領域的 USB

Anthropic 推 MCP 的真實意圖：

  1. 制定規則：讓大家按自己定的協議開發
  2. 佔領生態：所有工具提供商、AI 應用都接入 MCP
  3. 話語權：在未來的標準委員會中佔據關鍵位置

如果 MCP 真的成為行業共識：

  • 所有模型的工具調用格式可能被統一
  • Anthropic 在標準委員會的位置舉足輕重
  • 能影響整個 AI 工具生態的走向

對開發者來説，MCP 的價值在於：

  1. ✅ 快速接入現成服務：不用研究 API 文檔，裝個 MCP Server 就行
  2. ✅ 團隊協作規範：統一配置格式，方便版本控制
  3. ✅ 參與生態建設：早期參與者能佔先機
  4. ✅ 降低集成成本：一次開發，到處運行

但也要認清：

  • ⚠️ MCP 還在早期，規範可能變化
  • ⚠️ 生態不夠成熟，可用工具有限
  • ⚠️ 不是所有場景都適合用 MCP
  • ⚠️ 核心業務邏輯建議自己掌控

二、MCP 的工作原理

理解了 MCP 是什麼，我們來看它具體是怎麼工作的。

2.1 核心工作流程

MCP 的工作流程分為三步，我們用一個實際例子説明：

場景：用户在 Cursor 中問 AI："北京天安門的經緯度是多少？"

第 1 步：用户提問
┌─────────────────────┐
│   用户               │
│  "北京天安門的經緯   │
│   度是多少？"        │
└──────────┬──────────┘
           │
           ▼

第 2 步：MCP 客户端詢問 AI
┌─────────────────────┐
│  MCP 客户端          │
│  (Cursor)           │
│                      │
│  把問題和可用工具    │
│  列表發給 AI：       │
│  - 地理編碼工具      │
│  - 路徑規劃工具      │
│  - 天氣查詢工具      │
└──────────┬──────────┘
           │
           ▼

第 3 步：AI 決策
┌─────────────────────┐
│  AI 模型             │
│  (GPT-4/Claude)     │
│                      │
│  分析後決定：        │
│  ✓ 使用「地理編碼」  │
│    工具              │
│  ✓ 參數：            │
│    address=         │
│    "北京天安門"      │
└──────────┬──────────┘
           │
           ▼

第 4 步：MCP 服務端執行
┌─────────────────────┐
│  MCP 服務端          │
│  (高德地圖 API)     │
│                      │
│  收到請求後：        │
│  1. 調用高德地圖API  │
│  2. 獲取座標數據     │
│  3. 返回結果：       │
│     116.397428,     │
│     39.90923        │
└──────────┬──────────┘
           │
           ▼

第 5 步：AI 生成友好回覆
┌─────────────────────┐
│  用户看到的回覆：    │
│                      │
│  "北京天安門的經緯   │
│   度是：             │
│   經度：116.397428  │
│   緯度：39.90923"   │
└─────────────────────┘

關鍵點：

  • MCP 客户端負責和 AI 模型通信（這部分用的是 Function Call）
  • MCP 服務端負責真正執行工具邏輯（調用真實的 API）
  • 中間的數據傳輸按照 MCP 協議標準進行

💡 Tip：MCP 沒有改變 AI 的決策過程，只是規範了"工具列表 → AI 決策 → 工具執行"這個流程的數據格式。

2.2 MCP 的三個核心概念

MCP 定義了三種能力類型，理解它們只需記住：給什麼、做什麼、怎麼做。

📦 Resources（資源）—— 給 AI "看"的東西

簡單説：只讀的數據源，AI 可以讀取但不能修改。

常見例子：

  • 文件內容（代碼、文檔、配置）
  • 數據庫記錄（用户數據、訂單信息）
  • API 響應（第三方服務返回的數據）

使用場景："分析一下這個文件有什麼問題" → AI 讀取文件內容（Resource）→ 分析並給出建議

🛠️ Tools（工具）—— AI 能"做"的事情

簡單説：可執行的函數，AI 調用後會產生實際效果。

常見例子：

  • 查詢地理座標、規劃路線
  • 發送郵件、創建日曆事件
  • 讀寫數據庫、執行系統命令

使用場景："幫我查北京的天氣" → AI 調用天氣查詢工具（Tool）→ 返回實時天氣數據

💬 Prompts（提示詞模板）—— 標準化的工作流

簡單説：預定義的對話模板，用户一鍵觸發常見任務。

常見例子：

  • "代碼審查"：自動分析性能、安全、可讀性
  • "生成文檔"：根據代碼自動生成 README
  • "Bug 診斷"：系統化排查問題

使用場景：用户選擇"代碼審查"模板 → 自動填充代碼 → AI 按模板執行審查流程

一句話區分：

概念 一句話説明 最常見用途
Resources AI 讀取的數據 讀取文件、查詢數據庫
Tools AI 執行的操作 調用外部 API（最常用）
Prompts 用户觸發的模板 標準化工作流

💡 Tip：實際使用中 Tools 佔 90%，Resources 適合需要大量上下文的場景，Prompts 用於固定流程。

2.3 MCP 的傳輸方式

MCP 支持兩種主流傳輸方式（還有第三種 Streamable HTTP，但較少用），理解它們只需記住：本地還是遠程。

方式 1：STDIO —— 本地進程通信

簡單説：Cursor 啓動一個本地程序（如 Node.js 腳本），通過標準輸入輸出通信。

適用場景：

  • 本地文件系統操作（讀寫文件、搜索代碼）
  • 本地數據庫查詢（SQLite、本地 MySQL）
  • 開發和調試自己的 MCP Server

優點：快、安全、不需要網絡
缺點：只能本地用，需要安裝依賴

典型配置：

{
  "command": "node",
  "args": ["/path/to/mcp-server.js"]
}

方式 2：SSE —— 遠程 HTTP 服務

簡單説：Cursor 通過網絡訪問遠程服務器（如高德地圖的雲端 API）。

適用場景：

  • 第三方服務（地圖、天氣、翻譯）
  • 企業內部 API（統一部署的工具）
  • 生產環境（多人共享同一個服務）

優點：免安裝、可共享、易更新
缺點：需要網絡，有延遲

典型配置：

{
  "url": "https://mcp.example.com/sse?key=your_key"
}

如何選擇？

你的需求 推薦方式 典型例子
讀寫本地文件 STDIO 文件搜索、代碼分析
查詢本地數據庫 STDIO SQLite、本地 PostgreSQL
調用第三方 API SSE 高德地圖、天氣服務
團隊共享工具 SSE 企業內部 API、統一認證

💡 Tip：記住一句話：本地用 STDIO，遠程用 SSE。

寫在最後：看懂本質，少踩坑

讀到這裏，你應該已經明白：

MCP 不是什麼黑科技，它就是把 Function Call 包了一層標準化協議。
MCP 不會讓 AI 變聰明，該選錯工具還是會選錯，該提取錯參數還是會提取錯。
MCP 也不是免費午餐，API 調用成本該誰付還是誰付。

那為什麼還要了解 MCP？

因為它代表了一個趨勢：AI 工具生態的標準化。就像當年的 USB 標準，雖然技術上沒什麼創新，但統一了接口，讓整個生態繁榮起來。

給你三個建議

1. 不要盲目追新

看到 MCP 火了就覺得必須用，這是最大的誤區。如果你的項目：

  • 工具就幾個，都是自己的 API
  • 一個人開發，不需要團隊協作
  • 對工具調用有深度定製需求

那自己實現 Function Call 可能更合適，掌控力更強，調試也更方便。

2. 也不要一棍子打死

如果你需要快速接入：

  • 高德地圖、百度地圖這類現成服務
  • 團隊共享的標準化工具
  • 開源社區提供的 MCP Server

那 MCP 能幫你省不少事，不用研究每個 API 的文檔，裝上就能用。

3. 混合策略最務實

核心業務邏輯自己掌控，通用能力用 MCP 快速接入。

比如你做一個智能客服：

  • 查訂單、查庫存 → 自己實現（核心業務）
  • 地圖導航、天氣查詢 → 用 MCP（通用能力）
  • 發郵件、發短信 → 用 MCP（標準化操作）

這樣既能保證核心競爭力，又能享受生態紅利。

最後一句話

MCP 是個好協議，但不要神化它。

技術永遠是為業務服務的。理解它的本質，看清它的邊界，在合適的場景用好它——這才是工程師該有的態度。

就像你不會因為 USB 出現了，就把所有設備都換成 USB 接口。有些場景該用雷電口還得用雷電口，有些場景乾脆直接焊線更可靠。

工具是死的，人是活的。別讓工具框住了思維。

參考資料

📖 官方文檔

  • Anthropic MCP 協議規範
  • Cursor MCP 文檔
AI
user avatar
0 位用戶收藏了這個故事！

發佈 評論

Some HTML is okay.