我的知識庫

AI · 2026-07-06

閱讀時間約 11 分鐘

MCP(Model Context Protocol)在 2026 年 5 月 21 日釋出了史上最大改版的候選規範,版本號 2026-07-28,預計今年 7 月 28 日正式定案。這次改版把協定核心從「有狀態」整個翻新成「無狀態」,直接影響所有正在用 MCP 接工具、接資料源的開發者——包含平常用 Claude 串接各種服務的你我。

這不是小補丁,而是協定誕生以來最大的一次架構重寫。舊版 MCP 每次連線都要先做 initialize 握手、拿到一組 Mcp-Session-Id,之後每個請求都得帶著這組 ID,而且必須固定打到同一台伺服器實例(所謂的 sticky routing)。新版把這套機制整個拿掉,改成「每個請求都自帶完整資訊」,這樣的協定變化背後,其實反映了業界對 AI 工具串接「規模化」與「安全性」的迫切需求。

📖 學(核心)

從有狀態到無狀態:協定怎麼變

舊版流程是:客戶端先送 initialize 請求,伺服器回傳一組 session ID,之後每個 tools/call 都要帶著這個 ID,而且必須路由到當初核發 ID 的那台機器。這代表如果你要水平擴展 MCP 伺服器,就得維護共享的 session store,或是在負載平衡器上做 sticky routing,基礎設施複雜度直接往上疊。

新版規範把 initialize/initialized 握手整個移除,協定版本、客戶端資訊等原本只在連線時交換一次的資料,現在改成放在每個請求的 _meta 欄位裡,隨請求一起送出。Mcp-Session-Id 也一併移除。結果是:任何一個請求都可以落在任何一台伺服器實例上處理,你可以直接用最陽春的 round-robin 負載平衡器來擴展 MCP 伺服器,不用再管 session 黏著的問題。

如果伺服器真的需要跨請求記住狀態怎麼辦?規範給的建議是「顯式代理」模式——比如某個工具呼叫回傳一個 basket_id,之後模型自己把這個 ID 當作參數,傳給下一次的工具呼叫。狀態還是可以維持,只是從協定層藏起來的機制,變成模型看得到、可以主動組合、串接的一個普通參數。MCP 團隊觀察到,這種做法不只是替代方案,反而讓模型能更靈活地在多個工具之間傳遞、推理這些識別碼。

MCP Apps 與 Tasks:從工具呼叫到互動介面

這次改版把「擴充功能」(Extensions)正式升級成規範裡的一等公民,用反向 DNS 命名、獨立版本號管理,不再綁死在主規範的發布節奏上。其中最受矚目的兩個官方擴充是 MCP Apps 與 Tasks。

MCP Apps 讓伺服器可以直接附上互動式的 HTML 介面,由主控端(比如 Claude 這類客戶端)在沙盒 iframe 裡渲染出來。工具會事先宣告好自己要用的 UI 樣板,這樣主控端可以預先抓取、快取,甚至先做安全審查,而不是等到工具真的被呼叫才臨時載入畫面。介面上任何使用者操作都還是走同一套 JSON-RPC 協定,代表每個從 UI 發起的動作,都要經過跟直接呼叫工具一樣的稽核與同意流程,不會有繞過權限檢查的後門。

Tasks 原本在上一版(2025-11-25)是實驗性的核心功能,這次因為正式落地時暴露出太多需要重新設計的地方,索性把它整個搬到擴充框架裡。新的生命週期做法是:伺服器回應 tools/call 時給一個任務代碼(handle),之後客戶端用 tasks/get、tasks/update、tasks/cancel 來追蹤和控制這個長時間執行的任務。原本的 tasks/list 直接被拿掉,因為在無狀態架構下沒辦法安全地限定查詢範圍。

授權機制的強化與淘汰的舊功能

這次規範同時修了六個跟授權(Authorization)有關的提案,讓 MCP 更貼近業界實際部署 OAuth 2.0 與 OpenID Connect 的方式。舉例來說,客戶端現在必須依照 RFC 9207 驗證授權回應裡的 iss 參數,防止一種在「單一客戶端對多個伺服器」場景下特別容易發生的混淆攻擊(mix-up attack)。另外,客戶端在動態註冊時要宣告自己的 application_type,避免桌面或命令列工具被授權伺服器誤判成網頁應用,導致本機的 redirect URI 被拒絕。

同時,規範也正式把三個核心功能列為「淘汰中」(deprecated):Roots(建議改用工具參數或資源 URI 取代)、Sampling(建議直接串接 LLM 供應商的 API)、Logging(建議用 stdio 傳輸下的 stderr,或改用 OpenTelemetry 做結構化觀測)。這些淘汰是「僅標註」等級,方法本身在這一版與往後至少十二個月內都還能正常運作,不會馬上壞掉,但長期趨勢已經很明確。

值得一提的是,規範制定團隊也同步導入了正式的「功能生命週期政策」:任何功能從淘汰到真正移除,中間至少間隔十二個月,而且需要走完整的提案流程。這代表未來 MCP 的版本演進,理論上會比這次溫和許多——這次是少見的「必要的一次性破壞性改版」。

🧠 記

  • MCP 2026-07-28 規範候選版於 2026 年 5 月 21 日公布,正式版預計 7 月 28 日上線,是協定史上最大改版。
  • 核心變化是「無狀態化」:拿掉 initialize 握手與 Mcp-Session-Id,每個請求自帶完整資訊,可用普通 round-robin 負載平衡器水平擴展。
  • 需要跨請求狀態時,改用「顯式代理」模式,例如用 basket_id 這種參數讓模型自己在工具呼叫間傳遞。
  • 新增兩個官方擴充:MCP Apps(伺服器渲染的沙盒互動介面)與 Tasks(長時間任務的生命週期管理)。
  • 授權機制對齊業界 OAuth 2.0/OpenID Connect 實務,新增 iss 參數驗證等六項強化提案,防範混淆攻擊。
  • Roots、Sampling、Logging 三個核心功能被列為淘汰中,至少保留十二個月才會真正移除。
  • 新的功能生命週期政策與擴充框架,讓未來版本更新可以做到不破壞既有實作。

✍️ 實踐

花 10 分鐘做這個練習,實際感受這次改版對你日常用 AI 工具串接的影響:

  1. 打開你目前有在用的任一個 MCP 伺服器設定(例如 Claude Desktop 或其他客戶端裡連接的工具),找出它用的是 Streamable HTTP 還是 stdio 傳輸。
  2. 到 MCP 官方變更日誌頁面(見延伸學習連結),搜尋關鍵字 Mcp-Session-Id,讀一下舊版握手流程的說明,理解你現在用的伺服器背後在做什麼。
  3. 想一想:如果你之後要自己寫一個 MCP 伺服器或工具,遇到「需要記住使用者上一步做了什麼」的情境時,可以怎麼設計一個顯式的 handle(例如訂單編號、任務 ID)讓模型自己傳遞,而不是依賴協定層的 session。寫下一個你會用到的具體情境。

🔗 延伸學習

💬 問 AI

1. MCP 從有狀態改成無狀態架構之後,對於原本已經部署好的 MCP 伺服器,遷移時最容易踩到的坑有哪些?
2. 如果我要自己寫一個需要記住多步驟狀態的 MCP 工具(例如購物車、多步驟表單),用「顯式 handle」模式該怎麼設計比較好?
3. MCP Apps 這種伺服器渲染 UI 的機制,跟一般 Web 應用的 iframe 沙盒相比,安全性上有哪些額外的考量?
4. 這次 MCP 規範把 Sampling 淘汰、建議改成直接串接 LLM 供應商 API,對正在用 Sampling 功能的專案有什麼實際影響?我該怎麼規劃遷移?
5. 幫我用一個簡單的比喻,解釋「協定層無狀態,但應用層仍可以有狀態」這個設計概念。

反向連結