MCP 協(xié)議 2025-06-18 核心更新深度解析：讓 AI Agent 調(diào)用工具終于能“上保險”了

想讓你的 AI Agent 安全地調(diào)用外部工具、自動處理復(fù)雜工作流？MCP（Model Context Protocol）協(xié)議剛發(fā)布的 2025-06-18 版本，直接解決了兩個長期困擾開發(fā)者的核心痛點：工具調(diào)用的數(shù)據(jù)安全和交互流程的智能靈活性。

這次更新不是小修小補，而是兩個足以改變 Agent 開發(fā)范式的重磅特性：結(jié)構(gòu)化數(shù)據(jù)驗證（Structured Data Validation） 和 Elicitation 機制。前者為 Agent 調(diào)用工具提供了首個商用級的安全與可靠性保障，后者則讓工具調(diào)用不再是“單向指令”，而變成了能主動詢問、動態(tài)調(diào)整的智能對話。

本文將結(jié)合實際開發(fā)場景，拆解這兩個特性如何落地，以及它們對構(gòu)建更安全、更智能的 AI Agent 應(yīng)用意味著什么。

一、結(jié)構(gòu)化數(shù)據(jù)驗證：給 Agent 的“手”套上安全手套

痛點回顧

在舊版 MCP 協(xié)議中，Agent 調(diào)用工具時，傳入的參數(shù)本質(zhì)上是一段自由格式的 JSON。這意味著什么？意味著工具的實現(xiàn)方需要自己做大量的參數(shù)校驗、類型檢查、邊界條件處理。一旦 Agent 因為模型幻覺或上下文理解偏差，傳入了一個格式錯誤的參數(shù)（比如把字符串傳給了期望整數(shù)的字段），輕則工具報錯，重則可能觸發(fā)意外操作（比如刪除了不該刪的數(shù)據(jù)）。

對于企業(yè)級應(yīng)用或涉及敏感操作（如金融交易、數(shù)據(jù)刪除）的場景，這種不確定性是致命的。

2025-06-18 的解決方案：JSON Schema 強校驗

新版本在工具定義（Tool Definition）中，正式引入了基于 JSON Schema 的結(jié)構(gòu)化數(shù)據(jù)驗證層。這意味著，工具的輸入?yún)?shù)現(xiàn)在有了一個明確的、可機器驗證的“合同”。

核心變化：
工具的 inputSchema 字段現(xiàn)在必須遵循標(biāo)準(zhǔn)的 JSON Schema 規(guī)范。MCP 協(xié)議層（Server 端）會在工具實際執(zhí)行前，對 Agent 傳入的參數(shù)進行嚴(yán)格校驗。校驗不通過，直接拒絕執(zhí)行并返回明確的錯誤信息，而不是讓錯誤數(shù)據(jù)流入業(yè)務(wù)邏輯。

實際代碼示例：

假設(shè)你正在開發(fā)一個“數(shù)據(jù)庫查詢”工具。在舊版協(xié)議中，你可能這樣定義：

{
  "name": "query_database",
  "description": "查詢指定表的數(shù)據(jù)",
  "parameters": {
    "table_name": "string",
    "limit": "integer"
  }
}

Agent 可能傳入 { "table_name": "users", "limit": "abc" }，你需要在代碼里額外判斷 limit 是不是數(shù)字。

在新版 MCP 中，你可以（也應(yīng)該）這樣定義：

{
  "name": "query_database",
  "description": "查詢指定表的數(shù)據(jù)",
  "inputSchema": {
    "type": "object",
    "properties": {
      "table_name": {
        "type": "string",
        "enum": ["users", "orders", "products"],
        "description": "要查詢的表名，僅限白名單"
      },
      "limit": {
        "type": "integer",
        "minimum": 1,
        "maximum": 1000,
        "default": 100
      }
    },
    "required": ["table_name"]
  }
}

現(xiàn)在，如果 Agent 傳入 { "table_name": "sys_config", "limit": -5 }，MCP Server 會直接攔截并返回：

{
  "error": "validation_failed",
  "details": [
    "table_name: 'sys_config' is not one of ['users', 'orders', 'products']",
    "limit: -5 is less than the minimum of 1"

![配圖](http://www.nhjb.com.cn/usr/uploads/covers/cover_mcp_20260707_081526.jpg)

  ]
}

商業(yè)價值與開發(fā)意義：

1. 安全性躍升：對于涉及資金、權(quán)限、數(shù)據(jù)刪除的操作，你可以通過 Schema 定義嚴(yán)格的枚舉、范圍、格式（如郵箱、UUID），從協(xié)議層杜絕非法輸入。
2. 開發(fā)效率提升：工具開發(fā)者無需再寫冗長的參數(shù)校驗代碼，可以將精力集中在核心業(yè)務(wù)邏輯上。
3. 調(diào)試更友好：結(jié)構(gòu)化的錯誤信息讓 Agent 和開發(fā)者都能快速定位問題，而不是面對一個模糊的“參數(shù)錯誤”。

下一步行動：檢查你現(xiàn)有的 MCP 工具定義，將 parameters 遷移為符合 JSON Schema 規(guī)范的 inputSchema，特別是那些涉及外部 API 調(diào)用或敏感操作的工具。

二、Elicitation 機制：讓工具從“被動執(zhí)行”變?yōu)椤爸鲃釉儐枴?/h2>

痛點回顧

傳統(tǒng)的工具調(diào)用是“一次性”的：Agent 發(fā)出請求，工具執(zhí)行，返回結(jié)果。但如果工具在執(zhí)行過程中發(fā)現(xiàn)信息不足呢？例如，一個“預(yù)訂會議室”工具，Agent 只傳了時間，但沒傳會議室容量和設(shè)備要求。在舊模式下，工具只能返回一個錯誤，然后 Agent 需要重新發(fā)起一次完整的調(diào)用，用戶體驗割裂，且多輪對話的上下文管理非常復(fù)雜。

2025-06-18 的解決方案：Elicitation（啟發(fā)/引出）

Elicitation 是一個全新的交互范式。它允許工具在執(zhí)行過程中，主動向 Agent 或用戶發(fā)起詢問，請求補充信息或確認，然后基于用戶的回復(fù)繼續(xù)執(zhí)行。這本質(zhì)上是將工具從一個無狀態(tài)的函數(shù)，升級為了一個可以參與多輪對話的智能體。

核心流程：

1. Agent 調(diào)用工具，傳入初始參數(shù)。
2. 工具在執(zhí)行中發(fā)現(xiàn)需要更多信息，返回一個 elicitation 類型的響應(yīng)，其中包含一個結(jié)構(gòu)化的“問題”（例如，一個表單或選項列表）。
3. Agent 將這個問題呈現(xiàn)給用戶（或根據(jù)上下文自動決策）。
4. 用戶的回答被包裝成一個 elicitation_response 發(fā)送給工具。
5. 工具收到回答后，繼續(xù)執(zhí)行剩余邏輯，返回最終結(jié)果。

實際場景示例：

一個“智能文件處理”工具，Agent 請求：“幫我整理這個PDF文件。” 工具在解析后，發(fā)現(xiàn)文件包含敏感信息，它可以通過 Elicitation 詢問：

{
  "type": "elicitation",
  "id": "elicit_123",
  "prompt": "檢測到文件包含身份證號碼和銀行卡號。請選擇處理方式：",
  "options": [
    { "id": "redact", "label": "自動脫敏后保存" },
    { "id": "encrypt", "label": "加密保存原文件" },
    { "id": "delete", "label": "直接刪除，不保存" }
  ]
}

用戶選擇“自動脫敏后保存”，工具執(zhí)行脫敏操作并返回結(jié)果。整個過程在一次工具調(diào)用中完成，體驗流暢。

商業(yè)價值與開發(fā)意義：

1. 用戶體驗革命：工具調(diào)用從“命令-執(zhí)行”變成了“對話-協(xié)作”，特別適合需要人工確認、多條件選擇的復(fù)雜場景（如客服工單處理、審批流、數(shù)據(jù)清洗）。
2. 降低開發(fā)復(fù)雜度：開發(fā)者無需在 Agent 端編排復(fù)雜的多輪對話邏輯，工具自身就能引導(dǎo)用戶完成信息收集。
3. 提升 Agent 智能：Agent 可以更專注于高層意圖理解，將需要細化和確認的細節(jié)“委托”給工具通過 Elicitation 處理，分工更清晰。

下一步行動：在你的下一個 Agent 項目中，嘗試為一個需要用戶確認或選擇的工具（如“發(fā)送郵件”、“提交表單”）設(shè)計 Elicitation 流程。使用新版 MCP SDK 中的 elicitation 響應(yīng)類型，測試完整的交互閉環(huán)。

總結(jié)與行動指南

MCP 2025-06-18 更新的這兩個特性，一個解決了“安全底線”，一個打開了“智能上限”。

• 結(jié)構(gòu)化數(shù)據(jù)驗證 是 Agent 應(yīng)用走向生產(chǎn)環(huán)境、企業(yè)級部署的基石。沒有它，你的 Agent 就像在裸奔。
• Elicitation 機制 則是提升 Agent 應(yīng)用復(fù)雜度和用戶體驗的杠桿。它讓工具不再是黑盒，而是可以參與智能交互的伙伴。

你的下一步行動：

1. 立即升級：將你的 MCP SDK 或 Server 實現(xiàn)更新到支持 2025-06-18 規(guī)范的版本。
2. 審計現(xiàn)有工具：為所有工具添加嚴(yán)格的 inputSchema，尤其是涉及 I/O 和敏感數(shù)據(jù)的工具。
3. 重構(gòu)一個場景：選擇一個你現(xiàn)有的、需要多輪交互的 Agent 流程（如“報告生成”、“數(shù)據(jù)查詢”），嘗試用 Elicitation 機制將其重構(gòu)為單次工具調(diào)用，體驗交互流暢度的提升。

協(xié)議的進化，就是為了讓開發(fā)者能構(gòu)建更強大、更可靠的應(yīng)用。現(xiàn)在，工具已經(jīng)就位，就看你怎么用了。