Technology

MCP AI Agent在紅什麼

（比起觀念的了解，如果你想要直接動手，請看：AI Agent 0 到 1: MCP Server with Goose）

Schwannden Kuo

19 Mar 2025 — 10 min read

（比起觀念的了解，如果你想要直接動手，請看：AI Agent 0 到 1: MCP Server with Goose）

故事背景

隨著 ChatGPT、Claude、Gemini 等大型語言模型（LLM）不斷推陳出新、能力越來越強大，AI 的未來究竟會往哪裡發展呢？科技圈重量級人物，如 Andrew Ng、Elon Musk 和黃仁勳都紛紛指出：「AI Agent 將會是下一個重要的里程碑。」那麼，大家口中的 AI Agent 到底是什麼呢？

然而，當越來越多 LLM 廠商提供各種強大的模型與應用時，我們不禁好奇：有沒有一個開放且通用的協議（Protocol），能讓我們自由創造各種 AI Agent，而不用擔心被某個特定平台或廠商綁住呢？

傳統軟體開發通常由後端整合第三方服務，前端負責 UI/UX，確保使用者體驗。但這種方式要求開發者掌握所有邏輯，並自行串接各種服務，以維持完整控制權。隨著生成式 AI（Generative AI）與 AI Agent 的發展，設計思維開始轉變。我們可透過 AI Agent 定義業務邏輯，並透過標準化協議（如 Anthropic 的 Multi-Context Protocol, MCP）管理 AI 與 LLM（大語言模型）的互動。這讓開發者無需關注傳統的後端邏輯與前端開發，而是專注於 AI Agent 的行為設計，讓 AI 自主處理任務。這種模式提升了開發靈活性，特別適用於快速驗證新想法（Prototype）。開發者只需定義 AI Agent 的核心功能，而無需投入大量時間與資源搭建完整的前後端架構，透過 MCP 標準化的互動，即可快速落地應用。

LLM的限制

我們平常用 ChatGPT 或 Claude 這些大型語言模型（LLM）時，通常只能問問題或聊天，但沒辦法讓它們真的「做」什麼事。比如說，你不能直接叫 ChatGPT 幫你訂餐廳、寄 email，或去你家 NAS 裡抓一份報告。

這時候，「AI Agent」就派上用場了。AI Agent 就像是一個貼心的小秘書，不僅能和你對話，還能根據你的需求實際「動手做事」。舉例來說，如果你想知道上個月某個同事最後一次登入公司系統是什麼時候，一般的 LLM 是答不出來的，因為它不懂你公司內部的資料。但是 AI Agent 可以做到，它會直接去呼叫公司內部系統的 API 或查詢資料庫，立刻幫你找到準確的紀錄。

另一方面，LLM 的另一個問題是，它回答問題的能力侷限在自己所學過的知識內。如果碰上了最新發生的新聞，或者你自家的業務資訊，LLM 常常束手無策。為了解決這個問題，我們可能會想到 RAG（Retrieval-Augmented Generation，檢索增強生成），讓 LLM 能夠先去「翻閱」額外的資料再回答問題。不過，RAG 適合的情境是資料相對靜態、變動不頻繁的情況。如果你有些即時的、動態的需求（比如即時查詢某個顧客訂單的出貨進度），用 RAG 不只緩慢，還可能成本太高。

而 AI Agent 就像是幫你跑腿的小助手，你只要給它明確的任務，例如：「幫我確認訂單 12345 現在寄到哪裡了？」它會馬上呼叫你公司物流系統的 API，給出即時又正確的答案。

總結一下：

一般的 LLM 就像「聰明的萬事通先生」，只能提供他知道的答案，而且只動口，不動手。
RAG 就像是「帶著資料庫的百科全書」，但資料庫通常比較靜態，不適合需要即時資料的情境。
AI Agent 則像是「能跑腿、能幫你辦事的小秘書」，根據你提供的特定工具或 API，解決具體、即時的問題。

AI Agent的限制

AI Agent 面臨的第一個限制是「通用性」的問題。隨著越來越多的 LLM 廠商（如 Claude, Gemini, OpenAI 等）湧現，基於這些模型打造的應用程式也越來越多元：從最常見的 Chatbot（如 Claude、ChatGPT）到更複雜的智能 IDE（如 Cursor），我們很難確保自己開發的 AI Agent 能夠無縫地在各種不同的平台或環境中運作。理想上，我們希望有一套標準協議，讓同一個 AI Agent 可以輕鬆地與各個平台整合，不必受限於特定的模型或服務供應商。

AI Agent 面臨的第二個限制，是過去的設計往往只適合讓「人」來使用。使用者指示一步，AI Agent 就執行一步，或者必須按照預先定義好的流程才能運作。這樣的設計對「機器」（例如用戶端應用程式或自動化服務）來說不夠彈性。應用程式難以智能地根據需求動態選用不同的 Agent 工具，更別提自動判斷使用順序。

MCP（Anthropic Model Context Protocol）提供了一個標準化的 Client–Server 架構，完美地解決了這兩個問題。透過 MCP，開發者只需專注於製作各自獨立的功能模組，這些模組稱為 MCP Server，例如發送 Email、管理行事曆或進行圖像辨識等特定任務。另一方面，整合 LLM 的應用程式，例如 Claude Chatbot 或智能 IDE Cursor 等，則扮演 MCP Client 的角色。這些 MCP Client 能夠透過 MCP Server 提供的標準化介面，動態地探索和識別可用的功能與工具，並根據使用者或應用需求智能地排列組合、選擇最合適的工具來完成複雜任務。

透過這種分工與協作的架構，MCP 讓 AI Agent 變得更具通用性，也更加容易被機器理解與自動化整合，使得整個 AI 生態圈能夠更加靈活且高效地運作。

實際的工作流程：

假設今天你透過MCP建立了一個AI客服機器人，它整合了兩個工具：

訂單查詢工具：可以連接你的公司資料庫，根據客戶提供的訂單編號查詢訂單狀態。
優惠券發送工具：當客戶遇到不滿意的情況時，AI能夠動態地決定是否給予折扣優惠券。

一位顧客向AI客服詢問：「我的訂單 #12345 已經兩週了還沒有收到，可以幫我查一下嗎？」
此時MCP Client (例如Claude Chatbot)透過內建的LLM分析使用者需求，知道需要透過工具來完成此任務。它動態地向 MCP Server詢問：「目前有哪些工具可用？」
MCP Server 回傳目前可用的工具清單和使用方式給Client。
AI判斷後，決定先呼叫訂單查詢工具，透過客戶提供的「#12345」查詢訂單狀態。

假設訂單狀態顯示：「出貨延誤，尚未寄出」。

LLM理解顧客可能會因此不滿意，於是動態地決定再透過優惠券發送工具向顧客提供一張優惠券，作為補償。
最終AI客服回覆顧客：「您的訂單因為物流延誤尚未寄出，造成您的不便，我們深感抱歉，特別贈送您一張折扣優惠券以表歉意。」

假設訂單狀態顯示：「尚未付款」。

LLM理解此情境並非出貨問題，而是付款問題，因此不會發送優惠券，而是提醒顧客完成付款。
最終AI客服回覆顧客：「您的訂單尚未完成付款，請您完成付款後，我們將立即為您安排出貨，謝謝！」

在這樣的場景中，注意，我們不需要去提供情境判斷的邏輯，只要透過MCP Server提供兩個工具，LLM自己有辦法依照情境判斷要使用哪些工具解決問題。

常見問題

Q：MCP 是由誰開發的？
A：MCP 是由 Anthropic 公司提出的一套協議，目的是讓 AI 模型能夠更靈活地與外部工具互動。不過 MCP 並不限於 Anthropic 自己的 AI 模型（如 Claude），而是開放且獨立於特定 AI 廠商的標準，因此任何符合 MCP 的模型都能搭配使用。

Q：MCP 的工作原理是什麼？
A：MCP 的工作流程大致如下：

MCP Client（例如 Claude、Goose 等）會先向 MCP Server 發出請求。
MCP Server 會回應並告訴 Client 有哪些工具（tools）、資源（resources）及提示訊息（prompts）可用。
MCP Client 根據 Server 提供的資訊，智慧地判斷該使用哪些 API，並決定要提供什麼樣的資料給 AI 模型，以滿足使用者的需求。

透過這樣的架構，AI 能更靈活地自動選擇、組合不同的工具來完成任務。

Q：MCP 是否一定要搭配 Claude 使用？
A：並不一定。Claude Desktop 雖然是 Anthropic 開發的一款 MCP Client，但 MCP 本身並不侷限於任何單一 AI 廠商或模型。我個人推薦可以嘗試 Goose，它是一個近期非常熱門的 MCP Client 實作，不但可以自由接入各家 LLM API Key，團隊也積極發展 MCP Server 市集（Marketplace），提供豐富的工具與資源。

Q：使用 MCP 會有安全風險嗎？該如何確保 MCP 的安全性？
A：MCP 本身並不會強迫將敏感資料傳送到 AI 模型端，而是完全由 MCP Server 決定資料的傳輸範圍。因此，確保 MCP 安全性的重點在於如何設定與管理 MCP Server，具體包含：