模型層 開放閱讀

MCP Client

MCP Client

概念 ID
mcp-client
更新時間
2026-05-29
來源數量
待補

MCP Client

1. 3秒看懂

MCP Client 是執行在AI大型模型（或應用）側的一個協議執行模組。它遵循開放協議（MCP），讓大型模型能像人類使用外掛一樣，安全、標準化地呼叫外部工具、資料和應用程式，是實現AI Agent能力的關鍵“手和腳”。

2. 3分鐘產業解釋

想像一下，一個頂級的AI大腦（大型模型）被禁錮在一個玻璃房裡。它很聰明，但無法操作任何外部工具——不能上網查即時資訊，不能讀取本地檔案，也不能呼叫你的日曆或郵件。

MCP Client 就是為這個大腦接上的一套標準化“神經系統和四肢”。

  • 傳統方式：每個工具（如搜尋引擎、計算器）都需要一個定製化的“介面卡”來連線大型模型。工具一多，開發、維護、安全管理就變成一團亂麻。
  • MCP 協議：定義了一套全球統一的“通訊協議”（類似USB-C標準）。工具提供方只需實現一次“MCP Server”，所有遵守該協議的大型模型（通過其內建的 MCP Client）都能即插即用地安全呼叫它。

這帶來了產業層面的鉅變：

  1. 降低整合成本：工具開發者無需為每個AI平台（如Claude、GPT、國產大型模型）單獨做適配。
  2. 增強安全性與可控性：MCP協議內建了嚴格的權限管理，模型只能在使用者授權下，通過標準化介面呼叫，避免了“肆意操縱”的風險。
  3. 催生新生態：一個“即插即用”的AI工具市場成為可能。開發者專注於造“最好的工具”，模型提供商專注於造“最聰明的大腦”，分工協作。

核心價值：它不是另一個大型模型，而是讓現有大型模型“外接能力”標準化、規模化的關鍵基礎設施。

3. 15分鐘專家深入

深入來看，MCP Client 是 AI Agent 架構中的執行層核心。在典型的 AI Agent 系統中（如 “大腦” -> “規劃” -> “記憶” -> “工具使用”），MCP Client 正是 “工具使用”模組的標準化實現。

其架構定位與工作流：

  1. 意圖識別與呼叫決策：大型模型（如Claude 3 Opus）基於使用者指令和上下文，決策需要呼叫哪個工具（例如，“獲取今日股價”需要呼叫get_stock_price工具）。
  2. 協議封裝：MCP Client 接收這個決策，將其按照 MCP 協議規範，封裝成一個標準化的 JSON-RPC 2.0 請求訊息。請求中包含：工具名稱、引數、會話標識、權限令牌等。
  3. 通訊與執行：MCP Client 通過預定義的傳輸層（如HTTP/SSE，或本地程序間通訊）將請求傳送給對應的 MCP Server（工具服務方）。Server 驗證權限、執行操作（如查詢API）、並返回結果。
  4. 結果解析與反饋：MCP Client 接收返回結果，將其解析並反饋給大型模型，供其整合資訊或進行下一步推論。

一個關鍵的技術優勢是“狀態管理與權限邊界”：

  • MCP 協議為每個會話（Session）維護狀態，使得複雜的、多步驟的互動（如“幫我訂機票”）可以分步完成，且上下文連貫。
  • 權限模型是核心。工具的能力通過初始化時的能力（capabilities）交換及後續的tools/list等方法動態宣告，使用者（或系統）在會話開始時可以細粒度地授權（例如，只允許讀取特定資料夾，禁止寫入）。MCP Client 在發出每個請求前，都必須檢查並攜帶相應的授權資訊。這從協議層面杜絕了模型越權操作的風險。

4. 技術原理

MCP 協議棧可大致分為三層，MCP Client 是上層協議的實現主體：

+-------------------------------+
|        Application           |  (大型模型 / 使用者介面)
+-------------------------------+
|         MCP Client           |  <-- 我們討論的主角
|  (協議引擎、會話管理、權限代理) |
+-------------------------------+
|         Transport Layer      |  (如 HTTP+SSE, stdio, Unix Socket)
+-------------------------------+
|        Network/IPC           |
+-------------------------------+
|         MCP Server           |  (工具服務實現)
+-------------------------------+

關鍵機制詳解：

  1. 服務發現：

    • MCP Client 如何知道有哪些工具可用？通過 “能力發現” 機制。
    • 在初始化連線時，MCP Client 與 MCP Server 交換 capabilities，協商支援的協議功能和傳輸方式。
    • 之後，Client 可通過呼叫 tools/list 等 JSON-RPC 方法，動態獲取 Server 當前提供的工具列表、資源列表和提示模板及其引數描述。

  2. 通訊協議：

    • 核心採用 JSON-RPC 2.0 進行方法呼叫和響應。
    • 主要呼叫型別：
      • tools/call: 呼叫一個具體的工具（如 get_weather）。
      • resources/read: 讀取一個受控的資料資源（如本地檔案、資料庫條目）。
    • 對於需要即時流式輸出的場景（如流式程式碼生成、即時日誌），支援使用 SSE (Server-Sent Events) 作為傳輸擴充套件。

  3. 權限與安全模型（最核心的機制之一）：

    • 最小權限原則：通過“範圍”(Scopes) 來精確控制。MCP 協議在初始化時通過 capabilities 欄位宣告支援的高階功能（如工具、資源等），但細粒度的權限範圍（例如只允許讀取資料夾 /project/A）並不在協議層定義。實際的權限控制由 MCP Client 實現：當工具需要敏感操作時，客戶端會發起使用者同意流程，明確請求特定操作權限（如讀寫 /project/A），獲得使用者授權後才生成令牌並執行呼叫。
    • 使用者同意流程：當 MCP Client 首次嘗試呼叫一個需要新權限的工具時，會中斷呼叫，彈出授權請求，明確告知使用者“該操作需要訪問您的 /project/A 資料夾，是否允許？”。使用者同意後，Client 才能攜帶對應的令牌完成呼叫。
    • 令牌與會話繫結：授權令牌與特定會話繫結，無法跨會話或跨使用者濫用。

  4. 上下文與狀態管理：

    • 每個對話被分配一個 sessionId。MCP Client 在該會話內維護上下文，使得工具呼叫可以引用之前的互動結果，支援多輪複雜任務。

一個簡化的資料流示例（虛擬碼）：

# 概念性展示，非實際實現
class MCPClient:
    def __init__(self):
        self.server_capabilities = {} # 儲存已知 Server 的能力描述
        self.session_permissions = {} # 當前會話已獲授權

    def discover_server(self, server_endpoint):
        # 通過 capabilities 交換和 tools/list 等方法發現能力
        capabilities = exchange_capabilities(server_endpoint)
        tools = call_method(server_endpoint, "tools/list")
        self.server_capabilities[server_endpoint] = {
            'tools': tools,
            # 可能還有其他資源列表
        }

    def call_tool(self, tool_name, args, server_endpoint):
        # 1. 檢查本地是否已獲得該工具所需權限
        tool_info = self.server_capabilities[server_endpoint]['tools'].get(tool_name)
        required_scope = tool_info['required_scope'] if tool_info else None
        if required_scope and required_scope not in self.session_permissions:
            # 2. 發起使用者同意流程
            user_consent = prompt_user_consent(required_scope)
            if user_consent:
                self.session_permissions[required_scope] = generate_token()
            else:
                return PermissionDeniedError()

        # 3. 建置併發送 JSON-RPC 請求
        request = {
            "jsonrpc": "2.0",
            "method": "tools/call",
            "params": {
                "name": tool_name,
                "arguments": args,
                "scope_token": self.session_permissions.get(required_scope)
            },
            "id": generate_id()
        }
        response = send_to_server(server_endpoint, request)

        # 4. 解析並返回結果給模型
        return parse_response(response)

5. 技術演進史

MCP Client 的概念並非一蹴而就，它是AI工具呼叫技術演進到標準化階段的產物：

  • 第一階段：硬編碼與內嵌工具（~2022年前）
    • 代表：早期的 AI 助手，如 Siri、小愛同學。其“技能”完全由開發者硬編碼，無法擴充套件。
  • 第二階段：外掛與函式呼叫（2022-2023）
    • 代表：ChatGPT Plugins、Google Bard Extensions。各大廠商推出各自私有的外掛/函式呼叫規範。開發者需為每個平台單獨適配，生態割裂。
  • 第三階段：開放協議與Agent架構興起（2023-2024）
    • 行業意識到私有規範的弊端。同時，LangChain、AutoGPT等Agent架構湧現，它們內部實現了多種工具的適配邏輯，但架構本身又成為新的“適配層”。
    • 核心痛點：工具整合依然複雜，缺乏統一標準，安全模型各異。
  • 第四階段：MCP協議釋出與標準化（2024年）
    • Anthropic 率先發布 MCP 開放協議，並提供了首個開源的 MCP Client 和 Server SDK 參考實現。這標誌著行業從“架構競爭”邁向“協議標準競爭”。MCP 的目標是成為AI領域的“USB-C”，提供一種廠商中立、安全優先的連線標準。

6. 技術路線對比

特性MCP 協議 (MCP Client)OpenAI 函式呼叫 (Function Calling)LangChain Tools (架構內建)私有外掛系統 (如早期ChatGPT Plugins)
標準化程度開放協議，跨廠商廠商私有規範，但事實標準架構私有，繫結架構平台私有，完全封閉
安全模型協議級，細粒度權限，使用者同意流程平台級管理，權限控制依賴平台依賴開發者自定義平台稽核與沙箱
解耦性強，模型與工具徹底解耦中，模型與平台繫結弱，工具與架構強耦合極弱，與特定平台繫結
開發複雜度低，遵循協議開發一次，多處複用中，需學習平台特定規範中，需學習架構API高，需滿足平台特定稽核與規範
主要場景企業級、跨平台、高安全要求的AI Agent平台內嵌的、受控的工具呼叫快速原型開發、研究特定平台生態內的應用擴充套件
狀態/會話管理內建，支援複雜多步互動無原生支援，依賴上下文傳遞架構提供，方式各異平台支援

核心差異總結：MCP 是自下而上的開放協議，致力於建立通用標準；其他方案更多是自上而下的平台或架構附屬功能。

7. 上下游

上游（依賴方）：

  • 大語言模型：MCP Client 的指令來源。模型的推論能力決定了“何時呼叫”和“如何組合”工具。
  • AI 應用/Agent 架構：如各類智慧助手、自動化工作流平台，它們整合 MCP Client 來擴充套件能力。
  • 作業系統/雲端環境：提供底層的網路、程序間通訊能力。

下游（工具方）：

  • MCP Server 開發者：任何想讓自己的服務被AI呼叫的開發者或企業。例如：
    • 資料服務：資料庫查詢、API 閘道器。
    • 生產力工具：日曆、郵件、文件管理。
    • 專業軟體：CAD、ERP、金融終端。
    • 硬體裝置：物聯網裝置、機器人。

產業鏈角色：

  • 協議制定與生態推動者：如 Anthropic（首發者），以及未來可能加入的其他大廠、標準組織。
  • MCP Client 實現方：通常是大型模型提供商（如 Anthropic 自身）、AI 應用開發商。
  • MCP Server 提供方：SaaS廠商、企業IT部門、開源社群。
  • 開發者：連線上下游，為具體場景開發Server。

8. 關鍵指標

評估一個 MCP Client 實現或生態健康度的指標：

  1. 協議相容性：支援的 MCP 協議版本、傳輸層（HTTP/SSE, stdio等）數量。
  2. 工具呼叫成功率/時延：封裝、通訊、執行、返回的全鏈路成功率和平均耗時。這是最直接的可用性指標。
  3. 安全合規性：權限模型的完備性、是否通過第三方安全審計、加密傳輸支援情況。
  4. Server 生態豐富度：已接入的、高質量的 MCP Server 數量和類別覆蓋度。
  5. 開發者體驗：SDK 的易用性、文件完整性、除錯工具支援、社群活躍度。
  6. 併發與可擴充套件性：支援的同時會話數、吞吐量，能否滿足企業級部署需求。

9. 供需與市場資料

當前階段（2024年）：MCP 生態處於早期採用和標準推廣期。

  • 供給側：
    • MCP Client：主要來自 Anthropic 的開源參考實現，以及部分初創公司和雲端廠商的整合。
    • MCP Server：數量正在快速增長，主要集中在開發者工具（如GitHub、GitLab）、檔案操作、基礎API呼叫等場景。高質量、企業級的伺服器仍較少。
  • 需求側：
    • 早期採用者：以技術驅動型公司、研究機構、開發者個人為主。他們被降低整合成本、探索前沿Agent能力所驅動。
    • 企業客戶：持觀望態度，重點關注安全性、可靠性、可控性以及與企業現有IT系統的整合難度。
  • 市場資料：尚無權威的獨立市場規模報告。其增長緊密綁定於 “AI Agent 應用市場” 的發展。當前生態的GMV（總工具呼叫量）和活躍Server數量可作為先行指標。

10. 代表公司與資本對映

  • 協議發起與核心推動者：
    • Anthropic：MCP 協議的提出者和主要推動者。Anthropic的Claude桌面應用或API平台集成了 MCP Client，是當前生態的“錨點”。
  • 生態潛力受益方：
    • 大型模型廠商：OpenAI、Google、Meta、百度、阿里等。若MCP成為事實標準，他們將必須整合，否則其Agent生態將封閉落後。
    • 雲端服務與AI平台廠商：AWS、Azure、GCP、阿里雲端、騰訊雲端。他們有強烈的動機將MCP管理作為一項服務提供，整合進其AI開發平台。
    • 企業軟體/SaaS公司：Salesforce、ServiceNow、用友、金蝶等。他們的產品通過實現MCP Server，可以無縫被AI Agent呼叫，開闢新的智慧化互動模式。
    • 開發者工具與基礎設施公司：如提供API閘道器、身份認證、監控的服務商，可能圍繞MCP安全通訊和管理推出新產品。
  • 資本對映邏輯：投資於 “協議層”（Anthropic等）、“關鍵基礎設施層”（提供MCP管理、安全、測試的平台）以及 “殺手級應用層”（利用MCP建置出強大通用Agent的公司）。協議的成功會帶動全產業鏈的價值重估。

11. 投資邏輯

看多邏輯：

  1. 範式轉移賭注：如果“AI Agent”是AI應用的終極形態，那麼標準化、安全的工具呼叫協議就是其“神經系統”。MCP 有潛力成為這個關鍵基礎設施層，享受行業增長紅利。
  2. 生態網路效應：協議一旦形成規模，會產生強大的網路效應。工具越多，接入MCP的模型/應用越強大；模型/應用越多，工具開發者越有動力開發Server。早期主導者有望獲得生態主導權。
  3. 降低行業總成本：標準化直接降低全產業鏈的整合與維護成本，符合技術發展的長期趨勢，具備可持續性。

風險與不確定性：

  1. 標準之爭：MCP 並非唯一標準。OpenAI、Google等大廠是否會聯合推出或力推自己的標準？“多協議並存”或“某傢俬有標準成為事實標準”的可能性存在。
  2. 商業化路徑模糊：協議本身可能是開源的，如何圍繞它建置可持續的商業模式？是依靠雲端服務、增值工具、還是諮詢與技術支援？
  3. 安全與合規挑戰：在醫療、金融等強監管行業，基於MCP的工具呼叫面臨嚴格的資料隱私和操作審計要求，協議需要證明其足夠安全可靠。

12. 常見誤讀糾偏

誤讀1：MCP Client 就是聊天機器人的外掛系統。

  • 糾正：這是最嚴重的誤讀。MCP Client ≠ 聊天外掛。聊天外掛（如早期GPT外掛）通常侷限於對話場景，且是平台私有的。MCP Client 是一個通用協議引擎，可以驅動任何AI模型（不僅是對話模型）去呼叫任何工具（不僅是聊天工具），實現如“自動寫程式碼並除錯”、“自動處理Excel報表”、“操控智慧家居”等複雜任務流，其應用場景和架構複雜度遠超聊天外掛。

誤讀2：MCP 就是另一種“函式呼叫”(Function Calling)。

  • 糾正：這混淆了協議層次。函式呼叫是模型層面的一種能力，指模型能輸出結構化呼叫指令。而 MCP 是這套指令如何被安全、標準化地送達並執行的一整套協議規範。類比：函式呼叫是“你決定要打電話（的意圖）”，MCP則是“你使用什麼電話網路（電信協議）、撥號規則、身份驗證來確保這通電話能打通且安全”。OpenAI的函式呼叫需要結合其私有的平台實現，而MCP旨在成為一套獨立、開放的“電信協議”。

13. 學習路徑

  1. 入門理解：閱讀 Anthropic 官方部落格關於 MCP 的介紹文章，理解其初衷和解決的問題。
  2. 動手實踐：
    • 安裝官方開源的 MCP SDK (Python/TypeScript)。
    • 執行一個最簡單的 MCP Server 示例（如一個返回時間的Server）。
    • 使用一個整合MCP Client的應用或指令碼（如Claude桌面客戶端、或基於SDK的測試程式）連線並呼叫該Server。
  3. 深入協議：仔細閱讀 MCP 協議規範文件 (RFC)，理解JSON-RPC訊息結構、能力宣告、權限模型等細節。
  4. 研究參考實現：閱讀官方SDK中Client和Server的原始碼，理解其狀態管理、傳輸層實現和安全模組。
  5. 探索生態：瀏覽 GitHub 等平台上社群開發的 MCP Server 專案，瞭解實際應用場景。
  6. 進階思考：研究MCP與其他AI標準（如OpenAPI, JSON Schema）的關係與整合可能性。

14. 一句話總結

MCP Client 是讓大型模型從“思考的巨人”進化為“行動的巨人”的標準化手腕，它通過一個開放、安全的協議棧，將AI的智慧無縫連線至物理與數字世界，是建置下一代可信AI Agent的基石性元件。

15. 延伸閱讀與來源

  1. 官方協議與文件：
    • Anthropic MCP 官方站點及協議規範 (Model Context Protocol)。
    • GitHub 上的 modelcontextprotocol 組織倉庫，包含協議規範、SDK 及參考實現。
  2. 技術深度分析：
    • 各大技術媒體對MCP協議的架構解析文章。
    • 對比MCP、OpenAI Function Calling、LangChain等不同技術路線的深度評測。
  3. 生態與市場報告：
    • Gartner, Forrester 等機構關於“AI Agent”、“AI工具市場”的分析報告（可間接推斷MCP潛力）。
    • 知名風險投資機構（如 a16z, Sequoia）在AI基礎設施領域的投資趨勢分析。
  4. 社群與動態：
    • 關注 modelcontextprotocol GitHub 倉庫的更新、Issues 和 Discussions。
    • 開發者論壇（如Reddit r/MachineLearning, Hacker News）上關於MCP的討論。

相關推薦

同產業鏈：cloud

同產業鏈 · 相關公司

阿里巴巴BABA / 9988.HK百度BIDU / 9888.HKGoogle AlphabetGOOGL騰訊0700.HK亞馬遜 AWSAMZN字節跳動未上市Anthropic未上市CoreWeaveCRWV

相關概念

3D 高斯潑濺3D 生成Adapter TuningAgent 通訊協議Ahead-of-Time 編譯 (AOT)Attention With Linear Biases音訊 TokenAutogen
source: 公開揭露與公開資料整理 本頁僅用於產業鏈學習、資訊檢索和研究輔助；不構成投資建議，不預測漲跌，不提供買賣、部位或目標價建議。
完整概念頁 複盤 13 節結構 公司投研頁 沿產業鏈找到受益公司 投資課 把概念轉成可跟蹤模型