設想一個場景,老闆突然丟了個任務:「幫我整理一下上個月所有客戶意見」
但這些資訊分散在 Gmail 裡的客戶郵件或 Slack 的對話訊息中
你滿懷希望地打開 AI 先請它協助:「幫我整理一下上個月的客戶回饋」
結果 AI 卻回你:「我沒有取得你的應用程式的權限,但你可以貼上相關的內容後我再來協助你…」
於是我們開始了漫長的複製貼上之旅:打開 Gmail 複製、切換到 Claude 貼上、再打開 Slack 複製、再貼上...
兩小時過去了,手指快抽筋了,心裡只有一個念頭:
為什麼 AI 不能直接去讀這些資料?明明就在雲端上啊!
這就是今天要討論的主題 **MCP(Model Context Protocol)**要解決的問題
還記得以前每個裝置都有不同的充電線嗎?iPhone 一條、Android 一條、相機又是另一條,出門要帶一整包線
直到 USB-C 出現,一條線解決了所有問題
而 MCP 就是 AI 世界的 USB-C
它是一個開放的標準協議,讓 AI 工具可以安全地連接到各種資料來源,不用每次都自己重新發明輪子
更棒的是,MCP 是開源的,不是某家公司獨佔的技術。就像 USB-C 是大家共同遵守的標準,任何開發者都能拿來用
在 MCP 出現之前,我們面臨一個很頭痛的狀況
假設有 3 個 AI 工具想連接 4 個服務:
需要開發的整合數量 = 3 × 4 = 12 個
同時每個 AI 工具的開發團隊都要:
更慘的是,當某個服務更新 API 時,12 個整合都要跟著改
對於 user 來說:
有了 MCP 之後,遊戲規則變了:
需要開發的整合數量 = 3 + 4 = 7 個
邏輯很簡單:
對我們的實際好處是什麼?
✅ 更多服務會快速加入:開發一次就能被所有支援 MCP 的 AI 用
✅ 功能更新更快:不用等每個 AI 各自慢慢做
✅ 整合品質更穩定:大家遵循同一套標準
✅ 不會被綁死在一個 AI 工具:資料整合是共通的
簡單來說,就是從「各自為政」變成「統一標準」
技術原理聽起來可能有點抽象,我們用「餐廳點餐」來比喻看看
MCP 的世界裡有三個主要角色:
整個架構設計得很直覺:開發者可以選擇做 Server(提供資料)或做 Client(連接資料),各司其職
來看看實際上是怎麼運作的:
步驟 1:我們提出需求
對 Claude 說:「幫我找上週的會議記錄」
步驟 2:Claude 理解意圖
Claude 分析後發現,欸,這需要去 Google Drive 找東西
步驟 3:Client 發送請求
MCP Client 用標準格式向 Google Drive Server 說:「嘿,我要找某個時間範圍的會議記錄」
步驟 4:Server 處理請求
Google Drive Server 在我們的雲端硬碟裡搜尋
步驟 5:回傳資料
Server 把找到的檔案資訊傳回來
步驟 6:Claude 整合資訊
Claude 收到資料後,用它的理解能力產生有用的回應
步驟 7:我們看到結果
螢幕上出現整理好的會議記錄摘要
整個過程幾秒內完成,而且最重要的是——我們完全不用離開 Claude 去複製貼上
這就是 MCP 的核心價值:讓 AI 能夠自己去取得需要的資料,而不是把我們當成「人肉搬運工」
今天會稍微講到一些比較深入的概念,不過對於非技術的人來說,只需要先記得最簡單的一個概念就好: