MCP：讓 AI 從只會聊天到真正做事

26 Jul 2026

手裡握著地表上最聰明的超級電腦，它讀過人類歷史上幾乎所有的書籍，推理能力頂尖——但它是完全癱瘓的。它沒有手可以打字，沒有眼睛可以看資料庫，甚至沒有連上 WiFi 去接觸外面的世界，被死死困在一個名叫對話框的小視窗裡面，只能不斷產生文字。

這就是目前世界上絕大多數頂尖 AI 的真實處境。不管 AI 的大腦有多強，只要它無法點選滑鼠、無法讀取最新的財務報表、無法幫我們傳送電子郵件，它就只是一個很聰明的聊天對象，而不是一個能真正替我們工作的代理人。

一起來看看 MCP（Model Context Protocol）是怎麼幫 AI 裝上這個橋樑。

現狀：各大巨頭都在拼算力，但卡在整合

過去這幾年，各大科技巨頭都在瘋狂提升模型的大腦運算力。但當企業真的想把這些超級聰明的大腦接入公司內部系統時，卻撞上了一堵高牆——每一家公司的資料庫、內部軟體、甚至是員工打卡系統，使用的都是完全不同的老舊架構，AI 根本聽不懂這些舊系統的語言。

工具呼叫 vs MCP

有人可能會問：AI 不是早就具備工具呼叫（Function Calling）的能力了嗎？這跟 MCP 有什麼不一樣？

工具呼叫是一種非常僵硬的一對一連線。就像為了讓 AI 去轉動一顆特定尺寸的螺絲，特地為它打造了一把專屬尺寸的扳手。今天如果螺絲換了，或者想讓它去釘釘子，這把扳手就毫無用處了——必須重新寫一套專屬的程式碼來教它使用新工具。

MCP 採用的是完全不同的思維。它不是給 AI 一把特定的扳手，而是在 AI 系統和外部世界之間建立一套全球通用的標準化通訊介面。就像出國旅行時帶的萬用轉接頭——不管去歐洲面對雙圓孔，還是去英國面對三扁孔，都不需要為了每一個國家的插座去把吹風機拆開來改裝。只要有這個萬用轉接頭，插上去就能直接通電。

兩者的核心差異：

面向	工具呼叫（Function Calling）	MCP
標準化	各家 LLM 供應商各自為政，格式不同	開放標準，跨 LLM 互通
範圍	呼叫特定預定義函數	LLM 與外部工具之間的通訊框架
架構	LLM 與工具處理邏輯之間一對一	客戶端—伺服器架構，可連接多個 MCP 伺服器
發現機制	明確告知 LLM 哪些工具可用	動態查詢，伺服器即時回報可用工具
可重複使用	與特定應用和 LLM 緊密綁定	獨立的 MCP 伺服器，任何相容應用都可存取

在過去，如果想讓最先進的 AI 去讀取企業內部那些十幾二十年前的遺留系統，可能要花幾百萬去重寫整個後端架構。現在有了 MCP 這個轉接頭標準，企業完全不需要去碰那些老舊系統，只需要在舊系統外面包上一層符合 MCP 標準的介面，AI 就能瞬間讀懂並指揮這些二十年前的軟體。

MCP 架構：四個核心元件

MCP 被設計成一個嚴謹的客戶端—伺服器架構，主要有四個元件：

1. LLM（大腦）：負責思考與規劃的 AI 模型本身。

2. MCP 客戶端（翻譯官）：緊跟著大腦的專屬翻譯官。當 AI 產生一個比較模糊的意圖（例如「我想知道今天的業績」），客戶端會把這個意圖嚴格格式化為符合 MCP 標準的請求。AI 只負責想，客戶端負責把想法變成標準的程式語言。

3. MCP 伺服器（保鏢 + 圖書館員）：這是整個架構中最關鍵的元件。為什麼不讓 AI 直接去抓資料庫？因為安全考量——絕對不希望一個可能會產生幻覺的 AI 直接擁有刪除公司核心資料庫的權限。MCP 伺服器站在資料庫門口，只向 AI 公開三種東西，各有不同定位：

元件	類型	範例
資源（Resources）	只能讀取的靜態資料	PDF 檔案、資料庫記錄
工具（Tools）	可執行的功能	傳送郵件、查詢 API
提示範本（Prompts）	互動模板，引導 LLM 如何使用資源和工具	結構化查詢模板

資源是「什麼」，工具是「做什麼」，提示是「怎麼做」。這三者的區分讓 MCP 伺服器可以精確控制 AI 能存取什麼、能做什麼、以及應該怎麼做。

4. 底層服務：最終端實際在運作的軟體和資料庫。

部署模式與傳輸機制

MCP 支援兩種部署模式，依資料的機密程度選擇：

本機部署：伺服器部署在公司內部環境，使用 STDIO（標準輸入/輸出） 直接通道傳輸資料，不經過外網，確保商業機密不會暴露在公開網路上。適合極度機密的內部資料。
遠端部署：伺服器架設在雲端，使用 Streamable HTTP 或 SSE（Server-Sent Events） 等 Web 協定，讓全世界的 AI 都可以共享。適合天氣預報、公開 API 這類公開資訊。

另外還有兩種使用模式：

按需模式：即時對話代理需要立即存取工具時使用，每次請求即時回應
批次模式：大量資料分析時使用，一次處理大批記錄，不需要即時回應

動態發現機制：五步驟迴圈

MCP 最精彩的部分是動態發現機制。AI 不需要預先知道外面有哪些工具可以用，整個過程是一個五步驟的迴圈：

Step 1：AI 面對任務 → MCP 客戶端主動敲伺服器的門
        「嘿，你現在手邊有哪些工具和資料可以給我用？」

Step 2：伺服器回傳一份當下可用的清單
        就像走進一家沒有固定菜單的無菜單料理店，
        AI 不需要提前背下整本菜單，坐下來直接問服務生
        「今天廚房進了什麼新鮮的魚？有什麼特餐可以點？」

Step 3：AI 大腦根據伺服器報的特產決定行動計劃

Step 4：客戶端把這張點菜單送進廚房
        MCP 伺服器轉身去呼叫底層的 API 執行

Step 5：伺服器把結果端出來給 AI，任務完成

企業今天如果買了一套新的行銷軟體，只要接上 MCP 伺服器，AI 下次點菜的時候就會自動發現這個新工具——完全不需要讓 AI 重新訓練或停機更新。

殘酷的現實：MCP 不是魔法

MCP 絕對不是魔法，它只是一條鋪設得非常完美的高速公路。如果這條高速公路的盡頭連接的是一個通往爛泥巴的破舊小鎮，整體運輸效率依然會是一場災難——也就是說，如果企業底層的軟體本身寫得很爛，接了 MCP 也救不了它。

舉例來說，假設有一個票務系統的 API 非常原始，不支援一次撈出一百筆資料，只允許一筆一筆去查詢。AI 就算再聰明，也得透過 MCP 發出幾千次單一請求，效率極差。

還有資料格式的問題。AI 透過 MCP 呼叫公司的文件庫想要閱讀一份合約，結果底層 API 傳回來的是一份完全由掃描圖片組成的 PDF——AI 需要的是純文字，它看不懂圖片。這時候開發者就必須在 MCP 伺服器端把這些爛泥巴先處理好，例如將 PDF 轉換成 AI 比較友善的 Markdown 格式。

強大的 AI 代理永遠無法取代那些死板但確定性極高的基礎工作流程——不但不能取代，反而還超級依賴它們。必須把底層的地基打得無比堅固，AI 這個靈活的舞者才能在上面跳舞。

實際應用：工作流程編排

資料庫查詢

MCP 可以讓 AI 直接查詢 Google BigQuery 之類的資料庫。開發者只需要建立一個對應的 MCP 伺服器，AI 就能用自然語言下達查詢指令，伺服器背後執行 SQL 並回傳結構化結果。

生成媒體編排

Google 提供了 Genmedia Services 的 MCP 工具，讓 AI 可以操控 Imagen（圖像生成）、Veo（影片生成）、Chirp 3 HD（語音合成）、Lyria（音樂創作）等媒體生成服務。例如 AI 可以自動為行銷活動產生圖片、配音和背景音樂。

工廠物聯網控制

在一個大型製造工廠裡，廠長對著 AI 系統問「為什麼第三生產線今天的良率下降了？」。AI 可以瞬間透過 MCP 連線到生產線的溫度感測器讀取歷史資料，接著呼叫另一個 MCP 工具比對維護日誌，發現某個閥門壓力異常。更厲害的是，AI 可以透過第三個 MCP 介面直接送出指令去微調那個實體閥門的壓力，同時傳送一則警告到維修人員的手機。

行銷活動自動化

只需要下達一個宏觀的指令：「幫我針對上個月的高消費客群舉辦一場 VIP 促銷」。AI 會先透過 MCP 去 CRM 系統撈出名單、分析喜好，接著透過另一個 MCP 呼叫圖片生成模型為每一位客戶產生獨一無二的客製化圖片，然後親自起草專屬的電子郵件，最後再透過郵件系統的 MCP 把信全部發送出去。整個過程完全不需要人類介入。

FastMCP：一行標記搞定整合

在過去，要寫出能完美轉換底層通訊協定的中介軟體，需要整個團隊花上好幾週。但 FastMCP 框架把這些複雜的通訊協定、網路手續、資料封包全部隱藏在幕後。

舉例來說，如果公司裡已經有一段用 TypeScript 寫好的函式，功能是查詢某個客戶的信用評分。開發者現在只需要做一件事——在函式上方加上一行 @tool() 裝飾器：

import { FastMCP } from "fastmcp";

const server = new FastMCP({ name: "My Server" });

server.tool(
  "get_credit_score",
  { customerId: z.string() },
  async ({ customerId }) => {
    // 原有的查詢邏輯
    const score = await queryCreditScore(customerId);
    return { score };
  }
);

FastMCP 會自動去閱讀工程師原本寫在程式碼旁邊的型別宣告和註解，自動把這些給人類看的說明轉譯成 AI 看得懂的嚴格規格表。接著它會自動把這個函式打包放在一個安全的沙盒環境裡執行，等著 AI 來呼叫。

如果是透過 ADK 整合，可以這樣串接 MCP 伺服器：

import { Agent } from "@google/adk";
import { mcp } from "@google/adk/mcp";

const agent = new Agent({
  name: "assistant",
  tools: [
    mcp.server({
      command: "npx",
      args: ["-y", "@modelcontextprotocol/server-filesystem", "/tmp/files"],
    }),
  ],
});

除了 npx，也可以透過 uvx 在隔離的 Python 環境中執行 MCP 伺服器，或直接指定 python3 執行自訂腳本。

安全機制

當系統的整合門檻降到這麼低的時候，安全防護的層級就必須拉到最高。

身份驗證與授權。MCP 要求每個請求都必須經過身份驗證，確認客戶端是誰，以及它是否有權限執行該操作。授權則在伺服器端定義——例如設定 AI 代理只能讀取資料夾，不能寫入或刪除。即使 AI 產生幻覺下達了刪除指令，伺服器也會直接擋下來。

錯誤處理。當 AI 呼叫工具失敗時，伺服器不能只是讓程式崩潰或閃退，必須回傳一段清晰的錯誤報告給 AI——例如「找不到該檔案，請確認路徑」。這樣 AI 才能意識到自己犯了錯，調整策略去嘗試其他路徑。這其實是在教導 AI 如何在失敗中學習，而不是讓整個系統直接停擺。

對 UI/UX 的影響

MCP 對使用者來說，最直接的感受是AI 能做的事變多了，而且不需要每次等新功能上線。

從聊天到做事。 沒有 MCP 的 AI 只能產出文字——寫一封郵件草稿，我們自己複製貼上傳送。有 MCP 的 AI 可以在對話中直接查資料庫、傳送郵件、操作生產線。使用者不再只是跟一個聊天機器人對話，而是在跟一個真正的助手互動。

動態擴充能力。 企業接上新的 MCP 伺服器後，AI 會自動發現新工具，使用者不需要知道系統更新了什麼。上週還不能查 ERP 系統，這週突然可以了——體驗是連續的、無縫的。

失敗的回饋更重要。 當 AI 操作真實系統時，錯誤的後果比「回答不夠好」嚴重多了。刪錯資料、傳錯郵件這些錯誤不是重新產生一次回答就能解決的。這讓錯誤處理的 UX 變得關鍵——AI 需要清楚告訴使用者它做了什麼、成功了還是失敗了、失敗的原因是什麼。

解法

權限分級，使用者不需知道細節。AI 能讀取但不能寫入的資料，使用者在操作時不會感受到這個限制——AI 自然不會提議做它做不到的事。權限控管在後端完成，前端不需要為此多做什麼。
操作結果需要明確回饋。AI 執行完一個工具呼叫後（例如「已查詢資料庫」或「已傳送郵件」），應該在對話中顯示執行結果，讓使用者知道動作已完成。如果失敗，錯誤訊息要讓使用者理解原因並知道接下來可以怎麼做。
安全機制越無感越好。權限檢查、錯誤處理都在 MCP 伺服器端完成，使用者不需要知道這些機制的存在，也不需要操作它們。AI 做得到的事就直接做，做不到的事就明確說做不到。

總結

MCP 的出現不只是一個技術工具的發布，它代表整個科技產業思維的巨大轉變。我們正在打破過去那種各家模型互相封閉、各自為政的孤島生態。未來的 AI 發展將不再只是比拼誰的大腦比較聰明，而是比拼誰能更無縫地編排和排程全世界的數位資源。

我們所熟悉的網際網路，從誕生第一天起就是專為人類的眼睛和滑鼠點選而設計的。但隨著 MCP 這樣的標準化機器通訊協定開始普及，我們可能正在見證一個全新世界的誕生——一個機器專屬的網際網路。當所有的數位服務、手機裡的 App、甚至是政府的公共資料庫，首要的溝通對象不再是我們人類，而是透過 MCP 用毫秒速度在溝通的 AI 代理時——人類在這個未來的網路世界中扮演的角色又會是什麼？

參考資料

第 10 章：模型上下文協定（MCP）