MCP：想做 AI 界 USB-C 的協議

June 7, 2026 · mcp, model-context-protocol, ai-infrastructure, usb-c, anthropic, llm, tools, 實讀 3 min read

MCP：想做 AI 界 USB-C 的協議

你大概已經聽過這個比喻了。有人把 MCP——Model Context Protocol——叫做「AI 的 USB-C」，這個說法就這樣流傳開來。跟很多令人印象深刻的科技比喻一樣，它在某個程度上確實很貼切。USB-C 統一了充電、傳輸、8K 視訊輸出，一條線搞定一切。在那之前，每件電子產品都有自己專屬的線、專屬的接頭、專屬的充電器。MCP 承諾的是類似的事情：用一個標準化的方式，讓 AI 模型跟它們真正需要用到的工具、資料來源和服務溝通。

不過這個比喻也就到此為止。USB-C 是一個你根本不會多想的硬體標準。MCP 是一個協議——一組軟件跟軟件之間溝通的規則——而無論你是開發者還是只是用 ChatGPT 或 Claude 的一般用戶，它正悄悄成為你依賴的基礎設施。

那麼 MCP 到底是什麼？為什麼會存在？你有必要關心嗎？

它要解決的混亂

在 MCP 出現之前，每次要把 AI 模型接到外部工具，都是一次性的定制工程。假設你想建一個聊天機械人，能查公司庫存、搜尋知識庫、發 Slack 訊息。你需要為每個連接寫專屬的接駁程式碼——搞清楚認證方式、定義 endpoint、處理錯誤、把數據格式調到模型剛好能理解。每一次工具整合都是一次性的。

然後把這個問題乘以所有想加入 AI 功能的應用程式。結果就是工程師所說的 N×M 整合問題：N 個 AI 模型 × M 個工具，每一對都需要自己專屬的橋接。規模根本撐不起來。小型團隊負擔不起建構那麼多整合的資源。大公司最後得到的是脆弱、難以維護的意粉式程式碼。

MCP 把這個問題壓縮了。為 Slack 建一個 MCP Server，為 Salesforce 建一個，為你的日曆建一個。現在任何兼容 MCP 的 AI 應用——Claude、ChatGPT、Gemini，或者你自己建的系統——都可以全部使用。這叫 N + M 而不是 N × M。數字很殘酷：如果你有 5 個 AI 應用和 10 個工具，整合數量從 50 個降到 15 個。

這個設計深受 Language Server Protocol (LSP) 的啟發——LSP 大約十年前對程式碼編輯器做了類似的事情。在 LSP 之前，每個編輯器都需要為每種程式語言寫專屬的插件。LSP 給了編輯器一個統一協議。一個 Language Server 可以同時在 VS Code、Neovim、JetBrains 和 Emacs 上運作。MCP 是 LSP 的精神繼承者，只不過對象從編輯器和程式語言換成了 AI 和工具。

MCP 實際上怎麼運作

MCP 採用簡單的三層架構：Host、Client 和 Server。

當你問 AI 助手「查一下上季的銷售數字」，背後發生的事是：Host 把你的請求傳給 Client，Client 路由到對的 Server，Server 完成工作後把結果傳回來，模型再把結果編織進它的回覆裡。

MCP Server 暴露三種能力：

  1. Resources — 模型可以讀取的數據。檔案、資料庫記錄、API 回應。可以理解為「讀取」操作。
  2. Tools — 模型可以觸發的動作。發送電郵、更新記錄、執行計算。這些涉及副作用，大部分實作在執行前都需要使用者確認。
  3. Prompts — 常見任務的可重用模板。Server 可以提供預建的 prompt，用於「總結這份文件」或「提交一個 bug 報告」之類的場景，省得每次都寫長長的指令。

Server 可以用兩種模式運行。STDIO mode 把 Server 當作本機子程序運行——快速、安全、無網絡暴露。你的數據留在你的機器上。Streamable HTTP mode 讓 Server 在遠端運行，你可以透過 OAuth 2.1 授權在網絡上呼叫它。這讓 MCP 的彈性足以應對從本機腳本讀取日曆到雲端企業帳單服務的各種場景。

如果你是開發者，MCP SDK 支援 TypeScript、Python、Java、Kotlin、C#、Go、PHP、Perl、Ruby、Rust 和 Swift。基本上你合理會選用的語言都有支援。

誰在推動這件事

MCP 最初是 Anthropic 的項目，但很快就不是了。2024 年 11 月，Anthropic 將它作為開放標準發佈。到 2025 年 12 月，他們把這個協議捐贈給 Linux Foundation 新成立的 Agentic AI Foundation (AAIF)。訊息很清楚：這不是 Anthropic 自己玩的東西。這是行業基礎設施。

AAIF 的創始成員讀起來像科技界的名人錄：Anthropic、Block 和 OpenAI 是共同創始人。然後是 Amazon Web Services、Bloomberg、Cloudflare、Google 和 Microsoft 作為白金會員。對——OpenAI 和 Google 都加入了。這些正在競相開發互相競爭的 AI 模型的公司，同意在協議層面合作。這跟託管 Linux kernel、Kubernetes 和 Node.js 的治理結構如出一轍。

採用數據很難造假。截至 2026 年初，MCP SDK 每月被下載 9700 萬次。超過 10,000 個公開的 MCP Server 存在，涵蓋從檔案系統和資料庫到 GitHub、Slack、Notion、Google Maps 和 Spotify。2026 年 4 月，第一屆 MCP Developer Summit 在紐約舉行，吸引了約 1,200 名參加者。對一個十八個月前還不存在的協議來說，這是一個有意義的信號。

MCP 實際上能做什麼

抽象的架構講完了，但 MCP 運作起來是什麼樣子？以下是具體例子。

你自己的知識庫。 這跟本網站的關係最密切。像 OpenViking 知識庫——一個為你的個人筆記、文件和研究而設的語義搜尋引擎——可以作為 MCP Server 運作。你的 AI 助手可以直接查詢你自己的數據：「找到那篇關於 GRPO 訓練不穩定性的論文」或者「HKO 預報分析的關鍵發現是什麼？」模型進入的是一個結構化的資料庫，而不是它的訓練數據，所以答案是具體的、根基於你實際工作的。

Claude Code。 Anthropic 自家的程式碼助手內部使用 MCP。當 Claude Code 讀取你的項目檔案、跑測試、做 git commit 時，它使用的是 STDIO mode 的 MCP Server——本地、快速、無網絡呼叫。程式碼從不離開你的機器。

企業聊天機械人。 這才是真正的主戰場。企業正在建構內部 AI 助手，透過 MCP 連接自己的 Salesforce 實例、Jira 看板、人力資源系統和知識庫。與其在公司數據上訓練模型（昂貴、緩慢、難以保持最新），他們透過 MCP Server 給模型即時存取權限。模型保持通用性；數據保持新鮮度。

個人助手。 能夠檢查電郵、加入日曆事件、控制智能家居設備、或者調出上週購物清單的工具——全部透過 MCP Server。如果你曾經想過要一個真正能「做事」而不只是「說做事」的 AI，這就是實現的方式。

令人不滿意的部分

MCP 並非一切都順利。有兩個批評不斷出現。

安全性

給予 AI 模型在現實世界觸發動作的能力，本身就帶有風險。有三個攻擊向量不斷被提及：

安全研究人員已經示範了實際的攻擊，MCP 規格文件本身也記錄了這些風險。協議包含了緩解措施——STDIO mode 把 Server 沙箱化為本機程序，Streamable HTTP 要求透過 OAuth 2.1 加 PKCE 進行明確的使用者授權，而 2025 年 6 月的規格更新禁止了 token passthrough 並加入了 resource indicators。大部分安全團隊建議以最低權限運行 MCP Server、在連接前審計 Server、以及永遠不要在沒有人工批准的情況下授予寫入權限。

「我們真的需要這個嗎？」

第二個批評更偏哲學層面。一些開發者認為 MCP 在解決一個已經有足夠解決方案的問題。例如 OpenAI 的 Function Calling 已經能讓模型用結構化參數呼叫外部 API。REST API 已經存在。Webhooks 已經存在。為什麼要多加一層？

反駁的論點是，那些方案全部都是一次性的整合。Function Calling 在你用 OpenAI 時管用。如果你明天換到 Claude 或 Gemini，你就得重寫你的整合。MCP 是那個讓你的工具跟模型無關的抽象層。寫一個 MCP Server，任何兼容的 Host 都能使用。這個取捨是否值得帶來的額外複雜度，取決於你問誰。

這種懷疑有一定道理。如果你只需要一個 AI 應用跟一個工具對話，MCP 增加了複雜度卻沒有帶來好處。這個協議在大規模時才有意義——多個應用、多個工具、多個團隊——但對單一用途的整合來說，直接的 API 呼叫更簡單。

採用也不均勻。大型科技公司已經加入，但較小的工具開發者和開源項目並非全部都參與。有些人認為對簡單整合來說，MCP 的開銷不值得。協議還很年輕，這種雄心勃勃的標準需要數年才能塵埃落定。

MCP 與替代方案

MCP 並非這個領域唯一的協議。有兩個值得了解：

A2A (Agent-to-Agent) 是 Google 的方案。2025 年發佈的 A2A 是為 Agent 跟 Agent 對話而設計的，而不是 Agent 跟 Tool 對話。Google 的觀點是，專門的 Tool 協議和 Agent 間協議解決的是不同的問題。MCP 處理工具存取；A2A 處理 Agent 協調。兩者是互補而非競爭關係——MCP 負責「模型怎麼接觸我的數據？」，A2A 負責「這個 Agent 怎麼委派給那個 Agent？」。Google 是 MCP 的白金會員，所以他們認為兩者都有價值。

REST API 和 Function Calling 不會消失。它們是現有的方案。MCP 不是取代 REST——它是包裝它。很多 MCP Server 只是在現有 REST API 上的薄層，負責在協議和實際服務之間做轉換。MCP 帶來的價值是，你不需要為每種模型和工具的組合手寫那個轉換層。一個 REST API 可以用任何格式返回任何東西。一個 MCP Server 遵循 Tools、Resources 和 Prompts 的標準 schema，這意味著任何 MCP Client 都能在事先不知道 API 結構的情況下發現和使用任何 MCP Server。

對非開發者的使用者來說，實際的差別是：一個有 MCP 的世界意味著你的 AI 助手能開箱即用地配合更多工具。你不需要等每個應用自己建 AI 插件。他們建一個 MCP Server，到處都能用。

為什麼你應該關心

基礎設施協議有一個特點：運作良好的時候，你根本不會注意到它們。你載入網頁時不會想到 HTTP。你發電郵時不會想到 SMTP。你只是點一下，它就運作了。

MCP 正在走向那種隱形。如果它成功了，你每天使用的應用會獲得更好的 AI 功能，而你不需要知道為什麼。你日曆應用的 AI 助手會檢查你的電郵、查航班時間、建議會議時間——而底層模型是來自 OpenAI、Anthropic 還是 Google 根本不重要。協議處理了所有的管道工作。

這也意味著你可能會有更多控制權。因為 MCP Server 是模組化的，你可以運行自己的——一個住在你機器上的個人資料 Server，把你的檔案、筆記和日曆暴露給你選擇的任何 AI 助手。你的數據留在本地。模型來找數據，而不是反過來。MCP 在設計上是開放和去中心化的。

想想 USB-C 成為標準之後發生了什麼。突然間你可以用同一個充電器給筆電、手機、耳機和平板電腦充電。配件變便宜了。旅行變簡單了。這個標準讓整個生態系統對所有人都更好，不只是設計接口的工程師。MCP 的目標是為 AI 工具做同樣的事。

當協議成熟且被廣泛採用後，以下是會發生的改變：

確實有合理的顧慮——安全性、複雜度、協議可能永遠無法達到臨界規模。但方向是明確的。AI 行業正在從只能產出文字的模型，走向能採取行動的模型。MCP 是迄今最認真的一次嘗試，試圖建構把這些行動連接到現實世界的管道。

AI 的 USB-C 這個比喻不只是行銷口號。它準確地捕捉了這個協議試圖成為的東西：一個讓一切協同運作的通用連接器。我們拭目以待它能否到達那裡。但這是業界第一次真正嘗試達成共識，選擇同一個標準。