AI 的 Type-C 時刻: MCP 如何反轉控制釋放應用生態系統

Model Context Protocol 如何重塑 AI 工具生態系統，讓模型成為指揮家而非 API 調用者。瞭解 MCP 的架構、優勢及其與 Function calling 的關鍵區別。

Photo by Marcus Urbenz on Unsplash

❏ 引言

嘿 ~ 大家上週過的好嗎？驚蟄的一聲春雷，震醒了大地，是否也震醒了沈睡中的你呢？

上週偶然在滑 Youtube 的時候看到一個影片在介紹 Cline 這個工具 [1]，Cline 的 Github 頁面斗大的字樣 “Cline – #1 on OpenRouter” 引起了我的興趣 ¹。

帶著這個好奇，我一頭跳進了 Cline 和 MCP (Model Context Protocol) 的世界裡。雖然 MCP 在去年 11 月就問世了，不過那時候沒有引起我更進一步的關注 (那時候各家大廠還在拼命爭奪模型能力的寶座)。

一直到了現在 — AI agent 元年，市場開始將目光轉向整合與自動化的時候，我才發現原來 MCP 短短五個月已經走了這麼遠。今天，就來和大家分享 MCP 到底是什麼？依賴反轉原則和生態系的構築，如何成為一個聰明的商業手段。

.

📚 文章目錄

1. Context, Context, Context
2. MCP 是怎麼做到的
3. 這和 Function calling 有什麼區別
    a. 互動模式：從「靜態介面」到「動態協議」
    b. 工具發現機制：從「人工編排」到「自主感知」
    c. 上下文管理：從「孤島式呼叫」到「連貫工作流」
4. 當 AI 工具生態的「電力時代」來臨

🔍 工人智慧猜你也喜歡

• 《企業導入 LLM 的資安藍圖: 風險, 框架與對策》

• 《微服務架構：敏捷與明確介面的平衡藝術》

請確認您已訂閱，以便每週都能收到新的文章，
並考慮與您認為可能會喜歡的朋友或同事分享 ...

每天早上我也會快速發布一個 podcast 紀錄昨日最印象深刻的一個學習，
不想錯過最新消息的朋友，歡迎在各大平台關注《🎙️知識快充》

❏ Context, Context, Context

Context (上下文) * 3，因為很重要，所以念三遍。

在《解構AI Agent: 人工智慧的關鍵突破?》那期，我提到了 “Agentic workflow” 的概念：能進行複雜的「推理」、能善用「工具」、能相互「協作」。

「推理」仰賴的是模型自身的能力 (也可以說是內部的 context)，而「工具」和「協作」需要的是對外部 Context 的掌握：

• 「工具」需要模型對其他服務整合知識的掌握。

• 「協作」需要模型在任務之間消息傳遞的掌握。

沒有 MCP 時，模型雖能理解語言，卻難以真正觸及現實世界的複雜脈絡。

例如：當你想透過 AI「整理上週交易記錄並分析銷售趨勢」，你需要手動或用程式碼串接：先將交易記錄匯出，然後再傳入模型，接著下提示請模型進行整理與分析。

為了讓模型等 AI 應用使用我們的資料，要麼複製貼上，要麼上傳下載，非常麻煩。

.

MCP 就像為 AI 裝上「環境感知神經系統」通過協議層 將工具能力轉化為可理解的語義描述 (例如「此服務可掃描本地 PDF 並提取表格」)，讓模型能像人類一樣根據手上的任務去參考工具箱裡面的可用工具，自行決定應該如何選擇與使用。

當使用者說「對比 Q3 財報和客戶反饋」，MCP 自動關聯企業資料庫（提取財務資料）、郵件伺服器（抓取客戶郵件關鍵詞）和 BI 工具（生成對比圖表），將原本分裂的「資訊孤島」編織成連貫的決策圖譜，最終輸出洞察時，AI 已不再是機械執行指令，而是真正融入了業務場景的「上下文生態」。

.

用軟體開發的術語來說的話，MCP 以前的世界是 Stateless 的，每一次與模型的互動，都是獨立的，需要有明確的 I/O 編排才能使 Multi-Step 或 Multi-Agent 組織起來。

MCP 以後的世界是 Stateful 的，模型可以根據任務拆解步驟，也能知道怎麼選擇相應的工具去完成這些步驟。

~

❏ MCP 是怎麼做到的

MCP architecture | Anthropic

大致上講一下 MCP 的架構，細節可以參考 [2, 3, 4]：

• MCP 採用 Client/Server 架構，也就是服務使用方(Client) 與 服務提供方(Server)。例如：你希望讓你的 AI 應用去讀取 Notion 裡面的資料，那麼這個 AI 應用當中就需要啟動一個 MCP Client 去使用那個透過 MCP Server 包裝過的 Notion 服務。

• 一個 AI 應用在處理任務的時候，可以結合使用多種服務。
  例如：「查詢行事曆上今天的所有會議，並在每個會議的前 30 分鐘發聊天訊息給與會者」，這個任務可能會用到 Calendar 和 Slack 兩個服務。
  這個應用就稱作 MCP Host，一個 Host 可以啟動多個 MCP Client。以上述例子來說，需要用到兩個服務所以會啟動兩個 MCP Client 分別與 Calendar 和 Slack 兩個 MCP Server 溝通。

• MCP Protocol 定義了 MCP Server 該如何將「資源」、「工具」和「提示」expose 出來讓 MCP Client 知道如何與之互動：

  • Resources (資源)：API response (遠端服務) 或者是檔案內容 (本地服務)。

  • Tools (工具)：模型可以呼叫的 function。

  • Prompts (提示)：預編寫的提示詞範本。

MCP Client, MCP Protocol 與 MCP Server 的關係 [5]

簡單來說，就是將 What (有什麼工具)、How (這工具該怎麼用)、Why (什麼情境用比較好) 的溝通方式給定義好。那麼 Client 就可以知道 Server 有哪些能耐以及什麼場合要派他上場最合適 (相當於拿到一本工具使用說明書)。

~

❏ 這和 Function calling 有什麼區別

Function calling vs. MCP [5]

咦？這不就是把服務再包一層 API 給模型調用嗎？為什麼還需要搞一層 MCP Server，讓模型直接整合這些周邊服務的 API 不就好了嗎？

我一開始也有這個困惑，來看看 MCP Server 和 Function calling 的區別：

1. 互動模式：從「靜態介面」到「動態協議」

• 傳統 API 封裝
  例如將 GitHub API 封裝為統一 RESTful 介面，模型需預先學習固定路徑 (如 GET /repos/{owner}/issues) 和參數格式。呼叫時模型必須嚴格按照文件生成 request，類似機械的 HTTP 客戶端。

  例如：當 API 新增參數 (如 filter=recent)，模型需重新訓練或重新編碼才能應用。

• MCP Server
  通過協議層動態聲明工具能力。例如 GitHub MCP Server 啟動時，會向客戶端傳送工具列表 (如 search_repositories、create_issue)，並附帶自然語言描述和參數示例。模型無需記憶介面細節，而是基於語義匹配動態呼叫。

  例如：參考內容中 Cursor 呼叫 排行榜 MCP Server 時，僅需通過參數範圍(sources=[1,2,3...])，模型即可理解「排行榜」概念並自動設定參數。

.

2. 工具發現機制：從「人工編排」到「自主感知」

• 傳統 API 封裝
  開發者需手動編寫整合程式碼 (例如為每個 API 編寫整合層)，並將工具列表硬編碼到 Agent 系統中，模型只能呼叫預先定義的工具。

  侷限性：當新增工具 (如股票查詢 API) 時，需修改 Agent 程式碼並重新部署。

• MCP Server
  支援執行階段動態註冊工具。例如在排行榜應用中，使用者啟動 mcp-hotnews-server 後，Cursor 客戶端自動獲取到新增的「排行榜查詢」工具，模型立即具備該能力。

  技術實現：通過 ListToolsRequestSchema 協議，MCP Server 主動向客戶端廣播可用工具列表，實現「即插即用」。

.

3. 上下文管理：從「孤島式呼叫」到「連貫工作流」

• 傳統 API 封裝
  每次呼叫均為獨立事務。例如模型先呼叫「網頁抓取 API」獲取資料，再呼叫「資料分析 API」處理結果，需顯式傳遞中間資料 (如將 HTML 內容存入臨時變數)。

  典型問題：跨 API 的上下文傳遞依賴開發者硬編碼，難以處理多步驟任務 (如「抓取資料→清洗→生成報告」)。

• MCP Server
  通過協議層維護跨工具上下文。例如在 GitHub Issue 處理任務上，模型呼叫 search_repositories 後，MCP Server 自動保留搜尋上下文，後續呼叫 search_issues 時可關聯同一倉庫，無需重複指定參數。

  底層機制：MCP 協議支援會話級狀態管理 (如 session 對象)，工具呼叫結果可作為後續呼叫的隱式輸入。

.

Function calling vs. MCP

MCP Server 不僅僅是簡單的介面封裝，而是通過協議層實現了兩方面的範式升級：

1. 工具抽象化：將工具從「程式碼級介面」提升為「語義級能力」，模型通過自然語言描述而非硬編碼路徑呼叫工具。

2. 生態協作化：建構開放的工具市場 (參考 GitHub 上的開源 MCP Server)，任何開發者均可發佈工具，而模型無需修改即可接入，類似「USB 裝置即插即用」的體驗。

.

當 AI 工具生態的「電力時代」來臨

MCP 市集 (就像 Docker Hub 一樣，你可以基於別人的 MCP Server 進行開發)。source: https://pulsemcp.com

前期《AI 導入難題: 從慣性到突破的轉型之路》內容中曾提到：

歷史經驗告訴我們，當變革性的底層技術出現，價值會由底層向上擴散

而 依賴反轉，經常是捕獲/釋放這種價值的殺招：

高階模組不應該依賴於低階模組。兩者都應該依賴抽象

ChatGPT Plugins 乃至 n8n, Make, etc… 等自動化流程編排工具「讓 AI 學會使用特定工具」，而 MCP 則採取依賴反轉「讓工具學會被 AI 通用化使用」。模型一舉躍升成為高階模組，不再需要為了低階模組的介面而奔波 (其實是人在奔波 XD)。

未來的 MCP Marketplace (Cline 還真的有 Marketplace) 將上演「樂高式創新」：

一位開發者發佈一個「財報 PDF 解析器」工具 (包裝成 MCP Server 上架到 Markertplace)，另一位開發者就能快速將其納入與「資料視覺化」MCP Server 組合，創建一個 “財報視覺化洞察” 的 AI 應用。

我在 threads 上面寫下這段驚嘆：

實際體驗了 Cline + MCP 以後，我覺得對於工具的「語義理解」會是自動化流程能夠舉一反三的關鍵。當然，模型是不確定性的，但我們能夠透過反饋和模型迭代出一套正確的流程，然後讓這套流程成為之後的範本，而且是活的範本。

如果您覺得我這周寫的文章有用，請「讚」或「分享」這篇文章。
幫助其他可能覺得這篇文章同樣有用的人免費看到它 🫶

❏ 結語

MCP 正在重新定義 AI 工具間的互動方式。當我們回顧技術演進的歷史，標準化協議總是在關鍵時刻出現，為創新開闢道路。無論是 HTTP 如何解放網際網路，還是 USB 如何統一硬體連接，MCP 正在 AI 領域扮演類似的角色。

這不僅是技術上的進步，更是思維模式的轉變。從「讓 AI 學會使用特定工具」到「讓工具學會被 AI 通用化使用」，依賴反轉原則在此展現出驚人的威力。MCP 讓模型成為真正的指揮家，而不只是個別 API 的機械調用者。

在 AI Agent 元年，我們正站在工具生態「電力時代」的浪潮上。未來，開發者能專注於打造專精的工具，企業可輕鬆組合這些工具解決複雜問題，而 AI 模型則能自動理解並協調這一切。「語義理解」讓自動化流程不再是死板的腳本，而是能夠舉一反三的靈活系統。

你覺得 MCP 這種標準化協議會如何重塑 AI 應用的開發模式？在這個新興的生態系統中，價值會如何重新分配？無論如何，對於想要在 AI 時代保持競爭力的開發者和企業來說，MCP 無疑值得更多關注與探索。

~

🦥 parting thoughts 🦥

• 最近開始嘗試每日 Podcast《知識快充》，歡迎大家到各大平台訂閱收聽。

• Coffee chat：如果想和我聊聊，歡迎預約《非正式閒聊》。無論是技術創新、團隊管理，或是個人成長 方面的話題，期待透過輕鬆愉快的對話，與各位交流分享、互相學習 🥳。

---

🔖 參考資料

[1] Cline + MCP = 公眾號文章編寫大師 -

[2] 大模型上下文協議——MCP詳解 - https://zhuanlan.zhihu.com/p/19707405738

[3] Model Context Protocol (MCP) Quickstart - https://glama.ai/blog/2024-11-25-model-context-protocol-quickstart

[4] MCP 終極指南 - https://guangzhengli.com/blog/zh/model-context-protocol/

[5] https://x.com/mattpocockuk/status/1897742389592440970

1. 沒聽過 OpenRouter 的朋友可以參考前期《AI 神器: TypingMind + OpenRouter》。它是我用來即時擼各家大廠模型的省錢法寶。而 Cline 是 OpenRouter 裡面消耗 token 排行榜第一名。