關鍵概念和術語

在深入瞭解模型上下文協議（MCP）之前，理解構成 MCP 基礎的關鍵概念和術語至關重要。本節將介紹構成協議的基本思想，併為在整個課程中討論 MCP 實現提供一個通用詞彙表。

MCP 通常被描述為“AI 應用程式的 USB-C”。就像 USB-C 為將各種外設連線到計算裝置提供了標準化的物理和邏輯介面一樣，MCP 為將 AI 模型連線到外部功能提供了統一的協議。這種標準化使整個生態系統受益：

• 使用者享受 AI 應用程式中更簡單、更一致的體驗
• AI 應用程式開發者可以輕鬆整合日益增長的工具和資料來源生態系統
• 工具和資料提供商只需建立一次即可與多個 AI 應用程式配合使用的單個實現
• 更廣泛的生態系統受益於互操作性、創新和碎片化減少

整合問題

M×N 整合問題指的是在沒有標準化方法的情況下，將 M 個不同的 AI 應用程式連線到 N 個不同的外部工具或資料來源所面臨的挑戰。

沒有 MCP（M×N 問題）

如果沒有像 MCP 這樣的協議，開發者將需要建立 M×N 個自定義整合——每個 AI 應用程式與外部功能的可能配對都需要一個整合。

每個 AI 應用程式都需要單獨與每個工具/資料來源整合。這是一個非常複雜且成本高昂的過程，給開發者帶來了很多障礙，並導致高昂的維護成本。

一旦我們有了多個模型和多個工具，整合的數量就會變得難以管理，每個整合都有其獨特的介面。

使用 MCP（M+N 解決方案）

MCP 透過提供一個標準介面，將此問題轉化為 M+N 問題：每個 AI 應用程式只實現一次 MCP 的客戶端，每個工具/資料來源只實現一次伺服器端。這極大地降低了整合複雜性和維護負擔。

每個 AI 應用程式實現一次 MCP 的客戶端，每個工具/資料來源實現一次伺服器端。

核心 MCP 術語

既然我們理解了 MCP 解決的問題，那麼接下來讓我們深入瞭解構成 MCP 協議的核心術語和概念。

元件

就像 HTTP 中的客戶端-伺服器關係一樣，MCP 也具有客戶端和伺服器。

• 主機 (Host)：終端使用者直接互動的面向使用者的 AI 應用程式。示例包括 Anthropic 的 Claude Desktop、AI 增強型 IDE（如 Cursor）、Hugging Face Python SDK 等推理庫，或使用 LangChain 或 smolagents 等庫構建的自定義應用程式。主機發起與 MCP 伺服器的連線，並協呼叫戶請求、LLM 處理和外部工具之間的整個流程。

• 客戶端 (Client)：主機應用程式內的一個元件，負責管理與特定 MCP 伺服器的通訊。每個客戶端與單個伺服器保持 1:1 連線，處理 MCP 通訊的協議級細節，並充當主機邏輯和外部伺服器之間的中介。

• 伺服器 (Server)：透過 MCP 協議公開功能（工具、資源、提示）的外部程式或服務。

功能

當然，您的應用程式的價值是它所提供功能的總和。因此，功能是您應用程式最重要的部分。MCP 可以與任何軟體服務連線，但有一些常見功能用於許多 AI 應用程式。

能力	描述	示例
工具	AI 模型可以呼叫的可執行函式，用於執行操作或檢索計算資料。通常與應用程式的用例相關。	天氣應用程式的工具可能是返回特定位置天氣的函式。
資源	提供上下文而無需大量計算的只讀資料來源。	研究助手可能擁有一個用於科學論文的資源。
提示	預定義模板或工作流，指導使用者、AI 模型和可用功能之間的互動。	一個摘要提示。
取樣	伺服器發起的請求，要求客戶端/主機執行 LLM 互動，從而實現遞迴操作，使 LLM 能夠審查生成的內容並做出進一步的決策。	一個寫作應用程式審查其自己的輸出並決定進一步完善它。

在下面的圖表中，我們可以看到應用於程式碼代理用例的集體功能。

此應用程式可能以下列方式使用其 MCP 實體：

實體	名稱	描述
工具	程式碼直譯器	一個可以執行 LLM 編寫的程式碼的工具。
資源	文件	包含應用程式文件的資源。
提示	程式碼風格	一個指導 LLM 生成程式碼的提示。
取樣	程式碼審查	一個允許 LLM 審查程式碼並做出進一步決策的取樣。

結論

理解這些關鍵概念和術語是有效使用 MCP 的基礎。在接下來的章節中，我們將在此基礎上探索構成模型上下文協議的架構元件、通訊協議和功能。

< > 在 GitHub 上更新