模型上下文協定 (Model Context Protocol, MCP)：企業級 Agentic AI 的關鍵
模型上下文協定 (MCP) 是一個重要的概念，但許多人可能沒有充分理解其意義。現在許多人關注如何使用 Agentic 功能增強桌面應用程式，但若要像專業人士一樣在工作中使用 Agentic AI 應用程式，則需要更廣闊的視野。
理解 MCP 的運作方式
為了理解 MCP 的重要性，首先需要了解其運作方式。將 MCP 比喻為 AI 應用程式的 USB-C 可能沒有幫助，反而會造成混淆。
LLM 的基本運作
從外部角度來看，大型語言模型 (LLM) 的基本運作方式是：你提供一個提示 (prompt)，LLM 會回覆一個回應。
Agentic AI 的需求
這個回應通常只是文字，如果只需要文字，那沒有問題。但是，如果希望 AI 執行某些動作，這就是 Agentic AI 的重點。 Agentic AI 旨在讓 AI 能夠在現實世界中產生影響，執行動作或調用工具。此外，AI 還需要比核心基礎模型更及時或更廣泛的資訊。
整合外部資源
為了讓 LLM 能夠訪問外部資源，通常會使用 API。
檢索增強生成 (Retrieval Augmented Generation, RAG)
有時會使用檢索增強生成 (RAG) 模式來整合外部資訊。雖然有些人認為 RAG 已經過時，但在企業環境中，RAG 仍然是一種有效的模式，可以用於將企業資料導入 LLM 可以處理的上下文中。
多樣化的外部資源
無論是否使用 RAG，模型都需要訪問各種外部資源，例如：
-
檔案
-
二進位檔案
-
資料庫
-
Kafka 主題中發生的事件
這些資源包含代理 (agent) 需要知道的資訊，但這些資訊不會存在於基礎模型中。
MCP 的架構
MCP 的核心是建立一個代理 (agent)，可以將其視為一個微服務。
主機應用程式 (Host Application)
在 MCP 術語中，該代理稱為主機應用程式。主機應用程式使用 MCP 客戶端函式庫來建立客戶端的實例。
MCP 伺服器 (MCP Server)
需要建立一個 MCP 伺服器。這個伺服器可能是現有的，可以利用其功能將 Agentic 功能導入服務中，也可能需要自行建立伺服器。
伺服器內部元件
伺服器內部包含：
-
工具 (Tools)
-
資源 (Resources)
-
提示 (Prompts)
-
伺服器提供的功能
伺服器會向外部世界描述這些工具、資源和功能。
客戶端與伺服器之間的通訊
客戶端和伺服器之間的連接可以使用：
-
標準輸入/輸出 (Standard I/O)：適用於在本機運行的程序。
-
HTTP 和伺服器發送事件 (Server Sent Events)：訊息以 JSON RPC 格式交換。
伺服器可以向客戶端發送非同步通知，客戶端可以向伺服器宣告自身。
MCP 的工作流程範例
假設要建立一個用於安排約會的服務。
建立約會所需的工具和資源
這需要：
-
建立日曆邀請
-
日曆 API 整合
-
查看日曆空閒時間
-
取得對方日曆的存取權限（如果有的話）
-
了解會議地點（餐廳、咖啡廳等）
-
預訂餐廳
這些工具和資源可以整合到代理中，但這會限制其可重用性。 MCP 的目標是將這些功能放在伺服器中，使其可插拔和可發現。
工作流程
- 使用者輸入提示，例如「下週想和 Peter 喝咖啡」。
- 主機應用程式 (客戶端) 查詢代理的功能。
- 客戶端取得資源列表，其中包括每個資源的文字描述。
- 客戶端使用 LLM 判斷是否需要這些資源，例如：「這裡是用戶的請求，這裡是一個資源列表：資源一、資源二、資源三。我需要這些嗎？」
- LLM 回覆說：「是的，你需要資源二 (附近的咖啡廳列表)。」
- 客戶端向 MCP 伺服器請求資源二的詳細資訊。
- 客戶端將資源資料附加到下一個提示，並詢問：「這裡是用戶的提示，這裡的資源資料，我應該做什麼？」
- 客戶端使用 LLM 幫助其解釋資源。
- 對於工具，基礎模型 API 允許將工具的描述包含在 API 呼叫中。
- LLM 回覆是否應調用工具，並提供參數。
- 客戶端決定是否調用該工具。
MCP 的優點
-
可插拔性 (Pluggability)： 無需了解工具的細節即可使用它。
-
可發現性 (Discoverability)： 可以發現代理提供的功能。
-
可組合性 (Composability)： 伺服器本身可以是另一個伺服器的客戶端，例如，使用 Confluent MCP 伺服器來消耗 Kafka 主題中的資料。
結論
MCP 不僅僅是增強桌面應用程式的工具， 它是構建企業級 Agentic AI 的關鍵。 MCP 具有可插拔性、可發現性和可組合性，為構建真正的 Agentic AI 應用程式提供了一個途徑。