MCP 入門（上）：為什麼需要 MCP？從預訓練模型的三大限制談起

一篇寫給初學者的完整指南，帶你理解為什麼我們需要 Model Context Protocol

如果你曾經使用過 ChatGPT、Claude 或其他 AI 聊天工具，你可能會有這樣的疑惑：

• 「為什麼 AI 不知道今天的新聞？」
• 「為什麼 AI 看不到我公司的內部文件？」
• 「為什麼 AI 只會『說』，不能真的幫我『做』事情？」

這些問題的答案，都藏在「預訓練模型」的本質裡。

本文將帶你從最基礎的概念開始，一步步理解：

1. 預訓練模型有什麼天生的限制？
2. 業界如何用 RAG、Fine-tuning、Tool Call 來解決這些限制？
3. 為什麼這些解法還不夠好？MCP 又是什麼？

讀完這篇文章，你將能夠清楚地向別人解釋：為什麼 MCP（Model Context Protocol）是 AI 發展的重要里程碑。

預訓練模型的天生限制

預訓練模型（像 GPT、Claude）本質上是「壓縮後的知識庫」，訓練完成後就被「凍結」了。這導致它們有三個天生的限制：

限制 A：知識有截止日期

問題描述

每個預訓練模型都有一個「知識截止日期」（Knowledge Cutoff Date）。這是因為訓練資料的收集有一個終點——在那之後發生的事情，模型完全不知道。

具體例子

這不是模型「笨」

這裡要強調一個重要觀念：模型答不出這些問題，不是因為它能力不足，而是因為這些資訊從未出現在它的訓練資料中。

就像你不能期待一個 2020 年印刷的百科全書告訴你 2024 年的新聞一樣。

為什麼不能一直更新訓練資料？

你可能會想：「那就持續更新訓練資料，重新訓練模型啊！」

問題是：

• 訓練一個大型模型需要數百萬美元的成本
• 訓練過程需要數週甚至數月的時間
• 即使每天重新訓練，也無法追上「即時」的資訊變化

因此，「知識截止日期」是預訓練模型無法避免的結構性限制。

限制 B：無法存取私有資料

問題描述

預訓練模型的訓練資料來自「公開的網路資訊」。這意味著：

• 你公司的內部文件：模型從未見過
• 你的私人筆記：模型從未見過
• 你公司的客戶資料庫：模型從未見過
• 你團隊的 Slack 對話記錄：模型從未見過

具體例子

這是隱私保護的必然結果

從另一個角度看，這其實是件好事。如果模型能夠「知道」你公司的內部文件，那代表這些文件在訓練過程中被「吸收」了——這會造成嚴重的隱私和資安問題。

但這也意味著：如果你想讓 AI 幫你處理工作上的事情，你需要額外的機制把私有資料「餵」給它。

限制 C：只能「說」，不能「做」

問題描述

這是最容易被忽略、但可能是最重要的限制。

預訓練模型本質上只是一個「文字產生器」。你給它文字輸入，它給你文字輸出。僅此而已。

它無法：

• 真的去查詢資料庫
• 真的發送一封郵件
• 真的訂一張機票
• 真的呼叫某個 API
• 真的在你的電腦上執行程式

具體例子

為什麼會這樣？

因為預訓練模型被設計成一個「純粹的語言模型」。它的輸入是文字，輸出也是文字。它沒有「手」可以去操作外部世界。

想像一下：一個被關在房間裡的超級智者，只能透過紙條和外界溝通。你遞給他一張紙條問問題，他寫一張紙條回答你。但他不能走出房間、不能打電話、不能操作任何機器。

這就是預訓練模型的處境。

小結：三個限制的總整理

理解了這三個限制，我們就能理解為什麼業界發展出了 RAG、Fine-tuning、Tool Call 這些技術——它們都是為了「突破」這些限制而生的。

三種現有的解決方案

既然預訓練模型有這些限制，工程師們當然不會坐以待斃。過去幾年，業界發展出了三種主要的解決方案。

RAG：讓模型能「查資料」

RAG 是什麼？

RAG 的全名是 Retrieval-Augmented Generation，中文可以翻譯成「檢索增強生成」。

這個名字聽起來很複雜，但概念其實很簡單：

在模型回答問題之前，先幫它從外部資料庫「查」相關資料，然後把查到的資料一起丟給模型參考。

RAG 的運作流程

讓我們用一個具體的例子來說明：

場景：員工問「我們公司的請假規定是什麼？」

沒有 RAG 的情況

員工問題 → 模型 → 「抱歉，我不知道貴公司的請假規定。」

員工問題 → 模型 → 「抱歉，我不知道貴公司的請假規定。」

有 RAG 的情況

步驟 1：員工問題

        ↓
        
步驟 2：系統從公司知識庫搜尋「請假」相關文件

        ↓
        
步驟 3：找到《員工手冊》第三章「請假規定」

        ↓
        
步驟 4：把問題 + 找到的文件內容，一起送給模型

        ↓
        
步驟 5：模型根據提供的文件內容回答

        ↓
        
結果：「根據公司規定，年假為 14 天，病假需附醫生證明...」

步驟 1：員工問題

        ↓
        
步驟 2：系統從公司知識庫搜尋「請假」相關文件

        ↓
        
步驟 3：找到《員工手冊》第三章「請假規定」

        ↓
        
步驟 4：把問題 + 找到的文件內容，一起送給模型

        ↓
        
步驟 5：模型根據提供的文件內容回答

        ↓
        
結果：「根據公司規定，年假為 14 天，病假需附醫生證明...」

RAG 解決了什麼問題？

RAG 主要解決了前面提到的 限制 A（知識截止） 和 限制 B（私有資料）：

RAG 的技術細節（進階）

如果你想更深入理解 RAG，這裡提供一些技術細節：

向量資料庫（Vector Database）

RAG 系統通常使用「向量資料庫」來儲存和搜尋文件。基本原理是：

1. 把每份文件轉換成一組數字（向量）
2. 把問題也轉換成向量
3. 用數學方法找出「最相似」的文件

常見的向量資料庫包括：Pinecone、Weaviate、Milvus、Chroma 等。

文件切割（Chunking）

因為模型能處理的文字長度有限，RAG 系統通常會把長文件切成小段落（chunks），每個段落獨立儲存和搜尋。

如何切割文件是一門學問——切太大可能超過模型限制，切太小可能丟失上下文。

RAG 的缺點

雖然 RAG 很強大，但它也有明顯的缺點：

缺點一：每家公司各自實作，沒有統一標準

• A 公司用 Pinecone + LangChain
• B 公司用 Weaviate + 自己寫的程式
• C 公司用 Chroma + LlamaIndex

每家公司的實作方式都不同，程式碼無法共用，經驗無法累積。

缺點二：換模型可能要大改程式

如果你原本用 OpenAI 的模型，想換成 Claude，你可能需要調整：

• Prompt 的格式
• 文件切割的大小
• 搜尋結果的處理方式

這些都是額外的工作量。

缺點三：搜尋品質高度依賴調校

RAG 的效果好不好，很大程度取決於：

• 向量模型（Embedding Model）的選擇
• 文件切割的策略
• 搜尋演算法的參數

這些都需要大量的調校和實驗。

Fine-tuning：讓模型「內化」特定知識

Fine-tuning 是什麼？

Fine-tuning（微調）是一種「繼續訓練」的技術。

基本概念是：

拿一個已經訓練好的模型，用你自己的資料繼續訓練它，讓它「學會」你想要的知識或行為。

Fine-tuning 的運作流程

場景：法律事務所想讓模型更懂法律

步驟 1：收集大量法律文件（判例、法條、法律意見書）

        ↓
        
步驟 2：把這些資料整理成訓練格式

        ↓
        
步驟 3：用這些資料「繼續訓練」預訓練模型

        ↓
        
步驟 4：得到一個「法律專業版」的模型

        ↓
        
結果：模型更懂法律術語、更會引用判例、更符合法律寫作風格

步驟 1：收集大量法律文件（判例、法條、法律意見書）

        ↓
        
步驟 2：把這些資料整理成訓練格式

        ↓
        
步驟 3：用這些資料「繼續訓練」預訓練模型

        ↓
        
步驟 4：得到一個「法律專業版」的模型

        ↓
        
結果：模型更懂法律術語、更會引用判例、更符合法律寫作風格

Fine-tuning 和 RAG 的差異

這是一個常見的疑問：Fine-tuning 和 RAG 有什麼不同？

Fine-tuning 的優點

優點一：模型「真的學會」了

Fine-tuning 後的模型，不需要每次都查外部資料，它已經把知識「內化」了。這通常意味著更快的回應速度。

優點二：可以改變模型的行為風格

除了知識，Fine-tuning 還能改變模型的「語氣」、「格式」、「推理方式」等。

例如：

• 讓模型用更專業的語氣說話
• 讓模型固定用某種格式輸出
• 讓模型在回答前先列出思考步驟

Fine-tuning 的缺點

缺點一：成本高昂

Fine-tuning 需要：

• 大量的 GPU 運算資源
• 專業的機器學習工程師
• 數天到數週的訓練時間

這些都是真金白銀的成本。

缺點二：知識還是會過時

Fine-tuning 只是讓模型在「某個時間點」學到特定知識。隨著時間推移，這些知識一樣會過時，你需要持續重新訓練。

缺點三：不適合「即時資料」

有些資料是「即時」變化的：

• 今天的股票價格
• 目前的天氣
• 最新的新聞

這些無法用 Fine-tuning 解決，因為你不可能每分鐘都重新訓練模型。

缺點四：可能讓模型「忘記」其他知識

機器學習中有一個現象叫「災難性遺忘」（Catastrophic Forgetting）。如果 Fine-tuning 的方式不當，模型可能會「忘記」原本就會的東西。

Tool Call：讓模型能「執行動作」

Tool Call 是什麼？

Tool Call（工具呼叫），也被稱為 Function Calling（函式呼叫），是一種讓模型「間接執行動作」的技術。

核心概念是：

模型負責「決定要做什麼」，你的後端程式負責「真的去做」。

這裡有一個關鍵：模型本身還是只能輸出文字，它不能直接呼叫任何 API。真正執行動作的是你寫的「應用程式後端」。

Tool Call 的架構

要理解 Tool Call，首先要知道它需要三個角色，以及資料如何在它們之間流動：

flowchart LR
    User["👤 用戶"]

    subgraph Backend["你的應用程式後端（中間人）"]
        Logic["程式邏輯"]
    end

    AI["🤖 AI 模型 API<br/>Claude/GPT"]

    subgraph Tools["外部工具"]
        Weather["🌤️ 天氣"]
        Email["📧 郵件"]
        DB["🗄️ 資料庫"]
    end

    User -->|1️⃣ 提問| Logic
    Logic -->|2️⃣ 問題+工具清單| AI
    AI -->|3️⃣ 決策指令| Logic
    Logic -->|4️⃣ 呼叫工具| Tools
    Tools -->|5️⃣ 回傳結果| Logic
    Logic -->|6️⃣ 結果| AI
    AI -->|7️⃣ 自然語言回答| Logic
    Logic -->|8️⃣ 顯示| User

重點：AI 模型和外部工具之間，必須有你的後端程式當「中間人」。

Tool Call 的運作流程

場景：用戶問「台北明天天氣如何？」

沒有 Tool Call 的情況

用戶：「台北明天天氣如何？」

        ↓
        
模型：「抱歉，我無法查詢即時天氣。你可以去中央氣象署網站查看。」

用戶：「台北明天天氣如何？」

        ↓
        
模型：「抱歉，我無法查詢即時天氣。你可以去中央氣象署網站查看。」

有 Tool Call 的情況

步驟 1：用戶在聊天介面問「台北明天天氣如何？」

        ↓
        
步驟 2：【你的後端】收到問題，把「問題 + 可用工具清單」一起發送給 AI 模型 API

        ↓
        
步驟 3：【AI 模型】判斷需要用工具，回傳結構化指令給【你的後端】
        （注意：這個 JSON 不會顯示給用戶看！是後端程式在處理）
        {
          "tool": "get_weather",
          "parameters": { "city": "Taipei", "date": "tomorrow" }
        }
        
        ↓
        
步驟 4：【你的後端】解析這個指令，實際呼叫天氣 API

        ↓
        
步驟 5：【天氣 API】回傳結果給【你的後端】：「晴天，28°C」

        ↓
        
步驟 6：【你的後端】把結果再次發送給 AI 模型

        ↓
        
步驟 7：【AI 模型】根據結果，生成自然語言回答

        ↓
        
步驟 8：【你的後端】把回答顯示給用戶

        ↓
        
用戶看到：「台北明天是晴天，氣溫約 28 度，適合外出活動！」

步驟 1：用戶在聊天介面問「台北明天天氣如何？」

        ↓
        
步驟 2：【你的後端】收到問題，把「問題 + 可用工具清單」一起發送給 AI 模型 API

        ↓
        
步驟 3：【AI 模型】判斷需要用工具，回傳結構化指令給【你的後端】
        （注意：這個 JSON 不會顯示給用戶看！是後端程式在處理）
        {
          "tool": "get_weather",
          "parameters": { "city": "Taipei", "date": "tomorrow" }
        }
        
        ↓
        
步驟 4：【你的後端】解析這個指令，實際呼叫天氣 API

        ↓
        
步驟 5：【天氣 API】回傳結果給【你的後端】：「晴天，28°C」

        ↓
        
步驟 6：【你的後端】把結果再次發送給 AI 模型

        ↓
        
步驟 7：【AI 模型】根據結果，生成自然語言回答

        ↓
        
步驟 8：【你的後端】把回答顯示給用戶

        ↓
        
用戶看到：「台北明天是晴天，氣溫約 28 度，適合外出活動！」

常見問題釐清

Tool Call 解決了什麼問題？

Tool Call 主要解決了 限制 C（只能說，不能做）：

一句話總結：模型負責「思考」，後端負責「動手」。

Tool Call 的技術細節（進階）

工具定義（Tool Definition）

在使用 Tool Call 之前，你需要告訴模型「有哪些工具可以用」以及「每個工具需要什麼參數」。

例如，定義一個天氣查詢工具：

{
  "name": "get_weather",
  "description": "查詢指定城市的天氣預報",
  "parameters": {
    "city": {
      "type": "string",
      "description": "城市名稱"
    },
    "date": {
      "type": "string",
      "description": "查詢日期，如 today、tomorrow"
    }
  }
}

{
  "name": "get_weather",
  "description": "查詢指定城市的天氣預報",
  "parameters": {
    "city": {
      "type": "string",
      "description": "城市名稱"
    },
    "date": {
      "type": "string",
      "description": "查詢日期，如 today、tomorrow"
    }
  }
}

簡化的程式碼範例

以下是一個簡化的 Python 範例，展示 Tool Call 的實際運作：

import anthropic  # Claude API
import requests   # 呼叫其他 API

# 1. 用戶輸入
user_message = "台北明天天氣如何？"

# 2. 把問題 + 可用工具清單 發給 Claude
client = anthropic.Client()
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    messages=[{"role": "user", "content": user_message}],
    tools=[{
        "name": "get_weather",
        "description": "查詢天氣",
        "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}}
    }]
)

# 3. Claude 回傳：「我要用 get_weather 工具」
if response.stop_reason == "tool_use":
    tool_name = response.content[0].name        # "get_weather"
    tool_input = response.content[0].input      # {"city": "Taipei"}

    # 4. 你的後端實際呼叫天氣 API
    if tool_name == "get_weather":
        weather_result = requests.get(f"https://weather-api.com/{tool_input['city']}")

    # 5. 把結果再丟回給 Claude，讓它生成自然語言回答
    final_response = client.messages.create(
        messages=[
            {"role": "user", "content": user_message},
            {"role": "assistant", "content": response.content},
            {"role": "user", "content": f"工具結果：{weather_result.json()}"}
        ]
    )

# 6. 顯示給用戶
print(final_response.content)  # "台北明天晴天，28度..."

import anthropic  # Claude API
import requests   # 呼叫其他 API

# 1. 用戶輸入
user_message = "台北明天天氣如何？"

# 2. 把問題 + 可用工具清單 發給 Claude
client = anthropic.Client()
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    messages=[{"role": "user", "content": user_message}],
    tools=[{
        "name": "get_weather",
        "description": "查詢天氣",
        "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}}
    }]
)

# 3. Claude 回傳：「我要用 get_weather 工具」
if response.stop_reason == "tool_use":
    tool_name = response.content[0].name        # "get_weather"
    tool_input = response.content[0].input      # {"city": "Taipei"}

    # 4. 你的後端實際呼叫天氣 API
    if tool_name == "get_weather":
        weather_result = requests.get(f"https://weather-api.com/{tool_input['city']}")

    # 5. 把結果再丟回給 Claude，讓它生成自然語言回答
    final_response = client.messages.create(
        messages=[
            {"role": "user", "content": user_message},
            {"role": "assistant", "content": response.content},
            {"role": "user", "content": f"工具結果：{weather_result.json()}"}
        ]
    )

# 6. 顯示給用戶
print(final_response.content)  # "台北明天晴天，28度..."

從這個程式碼可以看到：Claude API 和天氣 API 都是在「你的後端程式」裡面被呼叫的。

模型的「決策」能力

現代的大型語言模型經過訓練，已經能夠：

1. 判斷什麼時候需要使用工具
2. 選擇正確的工具
3. 填入正確的參數

這是一種「湧現」的能力——模型在大量訓練後，「學會」了理解工具的使用時機和方式。

Tool Call 的缺點

缺點一：各家廠商格式不統一

這是最大的問題。不同的 AI 廠商有不同的 Tool Call 格式：

這意味著什麼？如果你為 OpenAI 的模型寫了一套工具整合程式，想換成 Claude，你可能需要重寫一大部分程式碼。

缺點二：每個工具都要自己寫對接程式

假設你想讓 AI 能夠：

• 查天氣 → 寫一個天氣 API 的對接程式
• 發郵件 → 寫一個郵件 API 的對接程式
• 查資料庫 → 寫一個資料庫的對接程式
• 發 Slack → 寫一個 Slack API 的對接程式

每個工具都要從頭寫，工作量巨大。

缺點三：工具多了之後，整合變成一團亂

當你有 10 個、50 個、100 個工具時，管理這些工具的程式碼會變成一場惡夢：

• 不同工具的錯誤處理方式不同
• 不同工具的認證方式不同
• 不同工具的回傳格式不同

整個系統會變得極度複雜且難以維護。

三種解法的總整理

這三種解法都很有用，但它們有一個共同的問題：缺乏統一標準。

這就引出了我們的主角——MCP。

MCP 登場——為什麼需要統一協議

現狀的痛點：碎片化的困境

讓我們設想一個真實的場景：

你是一家企業的 AI 工程師，老闆要你打造一個「萬能 AI 助手」。

這個助手需要能夠：

• ✅ 回答公司內部文件的問題（需要 RAG）
• ✅ 查詢即時的市場資料（需要 Tool Call）
• ✅ 幫忙發 Slack 訊息通知同事（需要 Tool Call）
• ✅ 讀取和分析 Google Drive 上的報告（需要 Tool Call）
• ✅ 操作公司內部的 CRM 系統（需要 Tool Call）

你會遇到什麼問題？

問題一：每個功能都要自己寫整合程式

Google Drive 整合 → 寫一套程式
Slack 整合       → 寫一套程式
CRM 整合         → 寫一套程式
天氣 API 整合    → 寫一套程式
...

Google Drive 整合 → 寫一套程式
Slack 整合       → 寫一套程式
CRM 整合         → 寫一套程式
天氣 API 整合    → 寫一套程式
...

每個整合都有不同的：

• 認證方式
• API 格式
• 錯誤處理邏輯
• 回傳資料結構

問題二：被鎖定在特定模型

假設你最初選擇了 OpenAI 的模型，所有整合都是針對 OpenAI 的 Function Calling 格式寫的。

三個月後，老闆說：「Claude 的效果更好，我們換 Claude 吧！」

結果：你所有的整合程式都要改寫。因為 Claude 的 Tool Use 格式和 OpenAI 的不一樣。

問題三：無法共享生態系統

• 你公司寫了一個超棒的 Slack 整合
• 隔壁公司也寫了一個 Slack 整合
• 兩邊的程式碼無法共用，因為格式不同

整個產業都在做重複的工作，這是巨大的資源浪費。

一句話總結這個痛點

每個人都在做 AI + 外部工具的整合，但每個人的做法都不一樣，導致程式碼無法共用、換模型要重寫、生態系統無法形成。

這就是「碎片化」的困境。

MCP 是什麼？

MCP 的全名是 Model Context Protocol（模型上下文協議）。

它是由 Anthropic（Claude 的開發公司）提出的一個開放標準，目標是：

定義一套統一的「語言」，讓 AI 模型和外部工具/資料來源能夠用同一種方式溝通。

最佳類比：USB 標準

要理解 MCP 的意義，最好的類比是 USB。

USB 出現之前的世界

• 印表機用一種接頭
• 滑鼠用另一種接頭
• 鍵盤又是另一種
• 手機充電線每個品牌都不同
• 買新設備可能要買新的線、裝新的驅動程式

USB 出現之後的世界

• 統一的接頭形狀
• 統一的通訊協議
• 買新設備，插上就能用
• 同一條線可以用在不同設備

MCP 對 AI 產業做的事情，就像 USB 對電腦周邊產業做的事情一樣。

MCP 的核心價值

價值一：工具開發者只需實作一次

以前：

• 為 OpenAI 寫一個 Slack 整合
• 為 Claude 寫一個 Slack 整合
• 為 Gemini 寫一個 Slack 整合

用 MCP：

• 寫一個符合 MCP 標準的 Slack 整合
• 所有支援 MCP 的 AI 模型都能直接使用

價值二：AI 應用開發者不用管底層細節

以前：

• 要了解每個工具的 API 細節
• 要處理每個工具不同的認證方式
• 要處理每個工具不同的錯誤格式

用 MCP：

• 所有工具都用同一種介面
• 認證、錯誤處理都有統一規範
• 專注在應用邏輯，而不是整合細節

價值三：生態系統可以形成

當大家都遵循同一個標準：

• 工具可以被分享和重複使用
• 開源社群可以貢獻工具
• 企業可以放心投資建設，不用擔心被鎖定

📘 下一篇預告：MCP 的詳細架構（Host、Client、Server 三個角色）、運作流程、以及它如何改變工具開發者和 AI 應用開發者的工作方式，將在下一篇文章中深入說明。

總結與展望

完整的故事線

讓我們回顧一下整個故事：

第一幕：Pre-trained Model 登場

        ↓
        
        很強大，但有三個天生限制
        （知識截止、無法存取私有資料、只能說不能做）
        
        ↓
        
第二幕：三種解法出現

        ↓
        
        RAG → 解決知識截止和私有資料的問題
        Fine-tuning → 解決知識內化的問題
        Tool Call → 解決「只能說不能做」的問題
        
        ↓
        
        但都有一個共同問題：各家實作不同，生態碎片化
        
        ↓
        
第三幕：MCP 登場

        ↓
        
        統一協議，像 USB 一樣
        工具開發者只需實作一次
        AI 應用開發者用統一介面
        生態系統可以形成

第一幕：Pre-trained Model 登場

        ↓
        
        很強大，但有三個天生限制
        （知識截止、無法存取私有資料、只能說不能做）
        
        ↓
        
第二幕：三種解法出現

        ↓
        
        RAG → 解決知識截止和私有資料的問題
        Fine-tuning → 解決知識內化的問題
        Tool Call → 解決「只能說不能做」的問題
        
        ↓
        
        但都有一個共同問題：各家實作不同，生態碎片化
        
        ↓
        
第三幕：MCP 登場

        ↓
        
        統一協議，像 USB 一樣
        工具開發者只需實作一次
        AI 應用開發者用統一介面
        生態系統可以形成

下一步：如何開始使用 MCP？

如果你想開始使用 MCP，可以：

1. 安裝 Claude Desktop App：它已經內建了 MCP 支援
2. 探索現有的 MCP Servers：GitHub 上有許多開源的 MCP Server
3. 嘗試自己開發：閱讀 MCP 官方文件，嘗試寫一個簡單的 MCP Server

附錄：名詞對照表