MCP 架構：附圖表的完整技術剖析

MCP 架構是使 MCP（Model Context Protocol，模型上下文協定）得以運作的一整套基礎元件及通訊規則。MCP 是一項開源標準，而 MCP 架構則是其運行所依賴的底層基礎設施。

任何 MCP 架構都包含三個核心元件，並以此為基礎構建：主機、用戶端和伺服器。MCP 的通訊框架通常被描述為由數據層和傳輸層組成。數據層是規範訊息格式的一套規則（MCP 請求以 JSON-RPC 2.0 傳送）。傳輸層則負責傳遞這些訊息，對外連接時使用 Streaming HTTP。

MCP 架構是實作 Model Context Protocol 的伺服器框架。Model Context Protocol 是一項開放標準，用於將 AI 模型連接至工具、數據庫等資源，以及擴展輸入上下文的提示。這些統稱為「基元」（primitives）。歸根究柢，MCP 架構讓 LLM 能夠發現有哪些可用工具並執行工作流程，而用戶端無需定期更新。

MCP 架構示意圖：AI 應用程式與 MCP 伺服器互相交換請求，而 MCP 伺服器提供工具、資源和提示。

自 Anthropic 推出以來，MCP 架構已廣泛應用於 AI 工作流程。這主要是因為它能取代維護負擔較重的系統（例如圍繞多個 API 連接構建的系統），而且不會犧牲效能。由於所有可用功能均位於 MCP 伺服器之後，因此只需一個連接，而更新及新增的功能亦可即時供用戶端應用程式使用。

MCP 讓 LLM 能夠發現並調用可用的工具、提示和資源，這些工具、提示和資源可以位於主機應用程式的本機系統上，亦可來自外部供應商。

就提供外部功能存取的工具而言，發現過程是由主機向 MCP 伺服器發出 tools/list 調用，以找出有哪些可用工具。然後，LLM（在某些情況下則是主機）便可讀取可用工具的說明，並按需要請求使用。提示和資源亦採用類似的流程。

MCP 架構元件示意圖：包含 LLM、編排器和用戶端的主機分兩個步驟連接至 MCP 伺服器（先是發現，然後是請求），而 MCP 伺服器則公開工具、資源和提示。

這與一直以來在軟件開發中屬於常態、度身訂造的 API 架構形成對比。在這種架構下，應用程式以外的功能必須透過專用連接，並以格式精確的請求來調用。

主機應用程式是核心的編排平台，並會連接至 LLM。Perplexity 和 Claude Desktop 等知名工具都可以在 MCP 系統中擔任主機。

在簡單的工作流程中，用戶透過聊天介面提出問題。主機的編排器元件隨即為問題加入上下文，告訴 LLM 有哪些 MCP 基元可用，並附上其功能說明。

用戶端是 AI 應用程式中的軟件元件。MCP 提供標準介面，讓用戶端根據主機或 LLM 的指示，與內部及外部 MCP 伺服器通訊。它的工作是建立連接、格式化 JSON-RPC 訊息、傳送請求及接收回應。

「MCP 主機」和「MCP 用戶端」這兩個詞有時會互換使用。不過，區分兩者很有用，因為主機（例如 Perplexity）可能會同時編排多個 MCP 用戶端。一個複雜的 AI 工作流程可能需要存取數十甚至數百個獨立的 MCP 伺服器，而每個伺服器都會使用獨立的連接。

示意圖：MCP 主機（例如 Perplexity）編排三個 MCP 用戶端，每個用戶端各自連接至自己的 MCP 伺服器，例如數據庫、檔案或外部 API。

伺服器會公開以 AI 為基礎的工具可使用的所有工具。從架構角度來看，MCP 伺服器負責解讀傳入的請求，並在有需要時連接至所請求的基元。

MCP 伺服器可提供三類基元的存取：

工具：這些基本上是外部軟件功能。以傳統的 API 方式為例，網站分析應用程式可能會透過向外部伺服器發出格式化請求來擷取數據。在 MCP 架構中，供應商的所有第三方功能都可透過單一連接使用，而請求則按照標準格式規則建立。
資源：資源是提供唯讀上下文的數據來源，數據庫結構描述（schema）就是一個好例子。MCP 伺服器會公開主機可使用的各種資訊來源。如果主機查詢數據庫（例如使用由 LLM 生成的 SQL 搜尋），則會被視為工具請求。
提示：這些是可重用的提示範本，幫助 LLM 執行特定任務。用戶或主機會調用提示而非工具，是因為完成任務需要現成的指示。主機應用程式中的預設任務（例如「審查程式碼」或「分析數據」選項）通常會儲存為提示，供用戶選擇。

另外值得注意的是，MCP 與 API 並非互相排斥的技術。MCP 伺服器可以公開 API 調用，以回應發現請求。關鍵在於，維護這些 API 調用的責任在於 MCP 供應商，而非用戶端。

MCP 架構中的數據層是一套規則，用於定義請求、回應和通知的格式。訊息的標準語言是 JSON-RPC。

所有 MCP 架構都遵循一個基本流程：(1) 由主機進行初始化和發現；(2) 由 MCP 伺服器回應；(3) 由主機發出調用（有時由 LLM 決定）。每個階段都代表一則獨立的 JSON 訊息。

MCP 數據層示意圖：用戶向主機應用程式傳送提示，LLM 在主機應用程式中與 MCP 用戶端協作；用戶端向 MCP 伺服器（工具、資源、提示）傳送請求並接收結果，然後主機向用戶傳回回應。

讓我們透過兩個例子，看看工具發現如何運作（這些例子同樣適用於資源或提示）：

在 LLM 生成前發現工具：主機啟動 MCP 用戶端，由用戶端發出 tools/list 請求（即 MCP 伺服器的可用工具清單）。LLM 在生成過程中會審視這份清單，並判斷是否需要某個特定的工具、資源或提示。
讓 LLM 可選擇執行搜尋：在代理式系統中，主機會在上下文輸入中加入發現選項，例如 search-tools，讓 LLM 在需要時可以要求執行搜尋。

工具大致上是外部應用程式的功能，通常由 LLM 或主機選擇。資源和提示則通常應用戶要求或由主機請求。

以下是一個虛構的筆記應用程式向 MCP 伺服器發出的 tools/list 請求：

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

在這個例子中，“id”:101 使用 ID 識別請求，讓用戶端可以配對回應；而 “params” 欄位則包含有關用戶端的額外資訊，例如用戶端名稱（notes-app-client）和功能。

作為回應，MCP 伺服器會傳回工具定義，當中包括可用工具的名稱及相關詳情。例如，清單中可能包括一個 add-task 工具，讓筆記應用程式在已連接的任務管理或日曆應用程式中建立任務，並為每項任務指定標題和優先次序。

請求可能如下所示：

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

“method” 欄位告訴 MCP 伺服器這是一個工具調用，“name” 指定要調用哪個工具，而 “arguments” 則提供所需的輸入。

如果說數據層是用戶端與 MCP 伺服器之間連接的「甚麼」，那麼傳輸層就是「如何」。它定義訊息傳遞的方式，即特定的通道，以及規管請求和回應如何傳送的規則。

MCP 有兩種傳輸路徑：

標準輸入/輸出：當 MCP 伺服器與主機應用程式在同一本機環境中運行時，便會使用此方式。用戶端將 JSON 請求寫入伺服器的標準輸入。伺服器讀取請求、執行所請求的操作，然後將回應寫入標準輸出。
Streamable HTTP：當 MCP 伺服器在主機應用程式外部運行時，MCP 用戶端會使用 HTTP POST 向伺服器傳送請求。伺服器會以單一 JSON 訊息回應，或以 Server-Sent Events (SSE) 串流回應。這種串流是一個持續「聆聽」的通道，讓伺服器可以隨時間傳回多則訊息。

MCP 多租戶架構是一種可同時為多個用戶（租戶）提供服務的實作方式。

在這裡，租戶可以是個人、一群人或一個機構。實作方式可以是為每個租戶運行獨立的 MCP 伺服器、提供單一共用伺服器的存取，或將一組伺服器置於中央閘道之後。使用閘道時，閘道會根據用戶身分或請求性質，將請求轉送至正確的端點。

它的基本原理與標準 MCP 架構相同，但每個用戶的請求都在各自的工作空間中運作（即使當中涉及共用資源），並會分別進行驗證。這種架構在企業場景中很常見，而且通常會傾向使用共用資源，因為運行多個 MCP 伺服器會產生不必要的成本。

端對端 MCP 請求在實際運作中是怎樣的？當中有八個核心階段，每個階段都涉及一個不同的架構元件。

端對端 MCP 請求的八步流程圖：工具發現、用戶輸入、模型處理、工具選擇、請求、工具執行、結果及答案生成。

以下沿用先前連接至任務管理服務的筆記應用程式例子，說明 MCP 工具調用在實際運作中的情況：

工具發現：筆記應用程式（主機）使用其 MCP 用戶端，透過 tools/list 請求向伺服器查詢可用工具。伺服器會傳回這些工具的名稱、說明和預期輸入，包括 add-task 工具的相關資訊。這可能在你提交提示之前便已發生。
用戶輸入：你透過應用程式內的聊天機械人，向以 LLM 為基礎的筆記應用程式提交請求，例如：「在我的日曆中建立一項任務，以中等優先次序審閱我的新草稿。」
模型處理：主機將你的請求及相關工具定義傳送給 LLM。
工具選擇：LLM 生成結構化的工具請求，指定工具及其輸入：add-task，並附上 title: Review the draft 和 priority: Medium。主機會檢查該操作是否獲准，然後將請求傳遞給 MCP 用戶端，再由用戶端傳送 JSON-RPC 訊息。
請求：MCP 用戶端向其 MCP 伺服器傳送 tools/call 請求。
工具執行：MCP 伺服器調用任務管理應用程式的 API，以指定的標題和優先次序建立新任務。
傳回結果：伺服器將結果傳回 MCP 用戶端，再由用戶端傳遞給主機。主機會將結果加入提供給 LLM 的資訊中。
生成答案：LLM 使用該結果為用戶生成答案，例如：「我已建立一項任務，以中等優先次序審閱草稿。」

MCP 與傳統 API 架構經常被混淆，但兩者其實是互補的技術。MCP 專為以 AI 為基礎的應用程式而設計，解決了實作及管理多個硬編碼 API 連接所帶來的沉重維護負擔。

MCP 為主機應用程式提供每個功能供應商或內部資源各一個連接，有助解決上下文輸入過於臃腫（列出所有 API）或以 API 為基礎的應用程式腳本受限的問題。

相反，MCP 可以將 API（或者更準確地說，調用 API 的功能）公開為其工具清單的一部分。每當供應商更新其應用程式並推出新的 API，或文件有所更改時，他們只需更新 MCP 伺服器即可。主機應用程式一方無需更改任何程式碼。

MCP 的安全性自推出以來一直備受爭議。雖然它普遍被視為安全的技術，但仍存在若干安全風險，其中不少在複雜的架構實作中更為明顯。

MCP 架構存在以下潛在弱點：

提示注入：用戶將惡意提示插入外部數據中，而 AI 模型會將其誤解為指示。
權限過大的存取：MCP 伺服器有可能向 AI 模型公開大量工具，這可能會增加出現安全問題的可能性（即影響範圍）。
意外數據外洩：配置不當的實作可能會導致敏感資訊（例如 API 金鑰或數據庫憑證）被傳遞給 LLM。
本機系統操控：本機 MCP 伺服器與其他應用程式一樣，容易受到惡意腳本等本機系統問題影響，而且還有一個額外問題：它們可能會對代理式 AI 系統造成下游的有害影響。

這些問題沒有一個是無法克服的。通常，只需採取既定措施，便足以確保系統安全。讓人類參與其中、對敏感數據實施嚴格管控，以及防範伺服器攻擊等措施，都是常見的做法。

MCP 已證明是一項對開發人員實用且廣受歡迎的開放標準。它解決了以 LLM 為基礎的應用程式中硬編碼 API 的許多問題，並大幅減輕開發人員的編程負擔。

展望未來，MCP 的底層主機和伺服器架構幾乎肯定會維持不變。未來的創新將集中於跨多步驟工作流程的進階代理能力。

此外，隨著這些代理功能的實作，需要更強大的安全防護措施；而隨著 AI 系統變得更龐大、更複雜，亦需要可擴展的架構，尤其是在傳輸層方面。

甚麼是 MCP 架構？

MCP 架構元件：主機、用戶端和伺服器

主機

用戶端

伺服器

MCP 架構中的數據層是甚麼？

MCP 架構中的傳輸層是甚麼？

甚麼是 MCP 多租戶架構？

MCP 架構圖：逐步解說

MCP 架構與傳統 API 架構有何不同？

MCP 架構安全嗎？

MCP 架構的下一步是甚麼？