一文讀懂 MCP 的 Sampling（採樣），賦予 MCP 服務端智能能力！

MCP 服務端在實現其功能時，是否可藉助 LLM 的能力？本文介紹了 MCP 的一項核心內容：Sampling（採樣）。

本文的主要內容：

爲什麼需要 Sampling
Sampling 的流程步驟
請求消息格式與參數
最佳實踐建議

爲什麼需要 Sampling

Sampling（採樣）是 MCP 的一項核心功能，它允許服務端通過客戶端請求 LLM 生成內容，實現複雜的智能體行爲，同時兼顧安全性和隱私性。具體來說，即服務端可主動向客戶端發起 LLM 生成請求。這種 “反向調用” 機制讓服務端無需直接訪問模型 API，即可利用客戶端的 LLM 能力。

讀者可能會有疑問：根據 MCP 協議，客戶端可直接與 LLM 交互，爲什麼要讓服務端向客戶端發起請求，客戶端再將請求轉發到 LLM（服務端 -> 客戶端 -> LLM）？爲什麼不是讓客戶端直接向 LLM 發起請求（客戶端 -> LLM）？Sampling 的這種調用請求機制（服務端 -> 客戶端 -> LLM），主要基於以下設計邏輯的：

MCP 服務端是整合多源數據的協調者，將多個工作處理步驟編排，形成一個特定的功能服務暴露給客戶端（服務形式可以是工具、資源、提示模板等）。MCP 服務端在實現其功能時，可能需要藉助 LLM 的能力，以增強其處理能力。因此，當服務端在功能實現過程中需要藉助 LLM 的能力時，由服務端作爲請求的發起者（服務端 -> 客戶端 -> LLM），是合理的。
根據 MCP 的設計理念，服務端提供外部的工具或資源服務，並不直接與 LLM 交互。因此，服務端需要將請求發給客戶端，客戶端再將請求轉發到 LLM（服務端 -> 客戶端 -> LLM）。

通過 Sampling 機制，MCP 在賦予服務端智能能力的同時，將最終控制權保留在用戶手中（客戶端），實現了安全性與功能性的平衡。這種設計特別適用於醫療、金融等對數據隱私要求極高的領域：

🛡️ 安全隱私保護
- 允許服務端請求 LLM 生成內容，但實際執行權在客戶端。
- 戶可審查 / 修改所有請求和輸出，防止敏感數據泄露。
🧑💻 人在迴路（Human-in-the-loop）：客戶端（用戶）成爲關鍵決策節點。
🧠 上下文管理：客戶端決定了哪些上下文（如果有的話）最終會被實際包含在發送給 LLM 的提示中。這確保了用戶隱私和上下文信息的安全共享。上下文範圍控制有三個參數選項：none（不共享任何上下文）、thisServer（僅當前服務器上下文）、allServers（跨服務全上下文共享）。
⚖️ LLM 模型選擇
- 服務端可建議模型（如 "claude-3"），但客戶端掌握最終決定權。
- 客戶端根據成本 / 速度 / 性能優先級動態選擇最合適的模型。

Sampling 的流程步驟

服務端發送 sampling/createMessage 請求
客戶端審查並可選修改請求
客戶端調用 LLM 生成內容
客戶端審查生成結果
返回最終結果給服務器

在上述的流程中，客戶端可以對以下內容進行控制。控制權掌握在用戶手中，實現了安全性與功能性的平衡。

sLJmy3

請求消息格式與參數

請求消息格式：

{
  messages: [
    {
      role: "user" | "assistant",
      content: {
        type: "text" | "image",

        // For text:
        text?: string,

        // For images:
        data?: string,             // base64 encoded
        mimeType?: string
      }
    }
  ],
  modelPreferences?: {
    hints?: [{
      name?: string                // Suggested model name/family
    }],
    costPriority?: number,         // 0-1, importance of minimizing cost
    speedPriority?: number,        // 0-1, importance of low latency
    intelligencePriority?: number  // 0-1, importance of capabilities
  },
  systemPrompt?: string,
  includeContext?: "none" | "thisServer" | "allServers",
  temperature?: number,
  maxTokens: number,
  stopSequences?: string[],
  metadata?: Record<string, unknown>
}

參數：

role: 消息發送者角色。
- user: 代表用戶消息。
- assistant: 代表助理（LLM）消息。
content: 消息內容，文本或圖像。
模型偏好（modelPreferences ）：服務端向客戶端表達其對模型選擇的偏好，但最終決定權在客戶端。客戶端最終根據這些偏好、自身可用模型列表、用戶設置和策略來選擇實際使用的模型。
- hints (數組，可選): 模型名稱建議列表，客戶端可用於選擇模型。數組中的多個提示按順序評估優先級（索引 0 優先級最高）。
- 優先級值 (0-1 標準化，可選): 客戶端在權衡選擇時應考慮的偏好權重，分別有 costPriority (成本優先級）、speedPriority (速度優先級）、intelligencePriority (智能 / 能力優先級） 三項可選。
systemPrompt: 服務端可以請求使用特定的系統提示詞（System Prompt）來指導 LLM 的行爲（如角色設定、輸出格式要求等）。客戶端可能修改或完全忽略此提示詞。用戶或客戶端策略可能會覆蓋此設置。
includeContext：指定服務端希望客戶端在生成請求時包含哪些額外的 MCP Context 信息，有 none（不共享任何上下文）、thisServer（僅當前服務器上下文）、allServers（跨服務全上下文共享）三項可選。
parameters（可選）：設置向 LLM 請求的溫度、最大 tokens 數等參數。

Sampling 的最佳實踐建議

💬 提供清晰、結構化的提示：始終設計邏輯嚴謹、目標明確的提示詞，確保模型理解任務意圖。
🖼️ 妥善處理文本與圖像內容：支持多模態輸入（如 Base64 編碼圖像），並驗證內容格式兼容性。
⏳ 設置合理的令牌限制：通過 maxTokens 參數控制生成長度，避免資源浪費或截斷風險。
🌐 通過 includeContext 包含相關上下文：按需選擇上下文範圍（none/thisServer/allServers），提升生成準確性。
🔍 使用前驗證響應內容：檢查響應完整性及潛在偏見，過濾敏感信息後再交付。
⚠️ 優雅處理錯誤：實現超時重試、降級回退等機制，避免單點故障影響系統。
🚦 考慮對採樣請求限流：基於業務優先級配置速率限制（如 Token Bucket 算法），防止資源過載。
📝 文檔化預期的採樣行爲：明確記錄模型兼容性、上下文依賴等約束，降低集成成本。
🧪 用不同模型參數測試：調整 temperature、stopSequences 等參數，驗證生成穩定性。
📊 監控採樣成本：記錄模型調用頻次與令牌消耗，優化資源分配策略。

以上是 MCP Sampling 的相關介紹。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Zc5qWjvOK8hjkwAEWZlMEA

爲什麼需要 Sampling

Sampling 的流程步驟

請求消息格式與參數

Sampling 的最佳實踐建議

猜你喜歡