MCP 史上最大規格更新：無狀態核心、全新授權框架，企業級AI代理的基礎已就位

模型上下文協議（Model Context Protocol，MCP）——連結AI代理與工具、資料及服務的開放標準——週一發布了2026-07-28版規格，是這項協議自原始推出以來最大幅度的架構變革。此次更新全面移除了自始以來制約MCP部署的有狀態會話模型，引入支援複雜代理工作流程的多輪往返通訊，強化了授權安全性，並為擴展生態系統建立了正式的治理架構。在每月SDK下載量突破4億次、全年增速達4倍的背景下，MCP已成為AI代理的事實配線標準——而這次發布的目的，正是為下一階段的規模化做好準備。

核心變革：邁向無狀態

2026-07-28版最具決定性意義的技術變革，是徹底廢除協議層面的會話（session）機制。在舊版MCP中，客戶端與伺服器在連線開始時需交換初始化握手，建立包含Mcp-Session-Id標頭的共享會話上下文，並維持整個連線生命週期。這使MCP本質上是有狀態的：客戶端被綁定到特定的伺服器實例，在不使用黏性會話（sticky session）和共享儲存的情況下，幾乎無法部署於標準負載均衡器之後。

新規格中，這個會話機制徹底消失。每個請求現在在_meta封包中攜帶自身的協議版本、客戶端身份與能力資訊。新的server/discover方法讓客戶端可以按需獲取伺服器能力，而無需在連線初期一次性完成。結果是：MCP伺服器成為無狀態服務，可在普通輪詢負載均衡器後運行，無需協調即可水平擴展，重啟也不會中斷客戶端連線。

對於在Kubernetes叢集內以微服務形式運行MCP伺服器的企業部署而言，這是協議從「需要精心運維」到「與現代HTTP API無異」的本質飛躍。無狀態化同樣為跨資料中心的全球分散式MCP部署掃清了技術障礙。

多輪往返請求（MRTR）

無狀態協議面臨一個特定挑戰：伺服器如何在執行過程中向客戶端發問？在舊模型中，MCP的持久連線使伺服器主動發起請求變得直接可行。在無狀態世界裡，已不存在可以利用的開放連線。

2026-07-28版的解決方案是多輪往返請求（Multi Round-Trip Requests，MRTR）。當伺服器在完成工具調用的過程中需要客戶端補充資訊時——例如在執行破壞性操作前請求確認，或請求尚未獲得的憑證——可以返回帶有resultType: "input_required"的回應，說明所需資訊。客戶端在inputResponses載荷中附帶答案後重試原始請求，協議自動處理後續流程。

這一模式使過去只能透過複雜帶外協調才能實現的工作流程成為可能：AI代理調用工具、在執行中途被要求提供補充資訊、提交後獲得最終結果——整個過程在乾淨的無狀態請求-回應週期內完成。對於需要人工審核節點和條件執行的企業級代理AI，MRTR具有重要意義。

授權安全強化

2026-07-28版對MCP授權模型進行了重大收緊，解決了資安研究人員在企業部署中指出的一系列弱點。

主要變更包括：針對授權伺服器強制執行RFC 9207發行方驗證（防範多租戶環境中的混淆代理攻擊）；在動態客戶端註冊（Dynamic Client Registration）期間正式支援application_type（為開發工具的本地端重定向提供安全處理）；憑證現在綁定至其發行授權伺服器而非自由流通；以及以客戶端ID元資料文件（CIMD）取代動態客戶端註冊，提供更具可稽核性的憑證供應模型。

尤其值得關注的是，原始MCP傳輸層——舊版HTTP+SSE傳輸——在此版本正式宣告棄用，並提供最短12個月的過渡期，讓現有部署有時間遷移。新版HTTP串流傳輸和MCP stdio傳輸成為唯一持續支援的傳輸路徑。

擴展框架與任務管理

本次規格將原本臨時性的擴展機制正式化。擴展現在採用io.modelcontextprotocol/{name}的版本化命名空間格式，並附帶明確的生命週期管理，包括新的12個月棄用政策。

在此框架下首個從實驗性晉升為穩定狀態的擴展是Tasks（io.modelcontextprotocol/tasks）。Tasks現在採用基於輪詢的模型（tasks/get和tasks/update方法），變更通知通過subscriptions/listen機制傳遞。這使AI代理能夠發起長時間運行的後台操作、查詢狀態並接收更新——無需保持開放連線，是生產規模異步代理工作流程的基礎。

三個現有協議功能——Roots、Sampling和Logging——同步宣告棄用，同樣提供12個月過渡期。

可快取的清單列表

一個較小但在運維層面頗具意義的變更：工具、提示詞和資源的清單列表現在包含ttlMs（快取存活時間）和cacheScope（快取範圍）元資料。客戶端可以快取可用工具和資源列表，而無需在每次請求時重新獲取，顯著降低了反覆調用同一組工具的代理的往返開銷。對於每個會話發出數百乃至數千次工具調用的代理而言，這是有實質意義的效能提升。

cacheScope維度允許將清單標記為全局可快取（跨所有會話一致）、會話範圍（在單個代理會話內保持一致）或請求範圍（每次調用可能有所不同），為伺服器作者提供了清晰表達工具可用性是靜態還是動態的方式。

基於標頭的路由

新規格下的HTTP請求現在包含Mcp-Method和Mcp-Name標頭，在無需解析JSON請求體的情況下，標識正在調用的協議方法和目標工具或資源。這使API閘道、網路應用防火牆和負載均衡器能夠僅在標頭層面，按方法和資源類型對MCP流量進行路由和計量。

在企業環境中，API閘道負責執行速率限制、套用身份驗證中介層，並根據操作類型將請求路由至不同的後端資源池。這些基於標頭的元資料，是MCP流量從對基礎設施工具「不透明」到「完全可觀察、可控制」的分水嶺。

治理架構與SDK支援

代理AI基金會（Agentic AI Foundation，AAIF）作為Linux基金會的定向基金，現正式治理MCP規格。白金成員包括Anthropic、OpenAI、Block、Google和微軟——這五家組織的AI代理，合計產生了全球絕大多數的真實MCP流量。治理結構建立了提交、審查和批准規格變更的正式流程，取代了早期由Anthropic主導的非正式機制。

TypeScript、Python、Go和C# SDK均已更新至2026-07-28版；Rust SDK目前以測試版提供。Java和Swift SDK的更新預計在60天內跟進。

對現有MCP整合進行升級的開發者，需要處理三項破壞性變更：從請求處理中移除會話識別符、從動態客戶端註冊過渡至CIMD憑證模式，以及從已棄用的HTTP+SSE傳輸遷移。規格更新日誌包含一份遷移指南，SDK作者在發布前已對此進行審閱，測試期間早期採用者的反饋也實質改善了升級路徑。

對於今天正在構建代理AI系統的開發者而言，2026-07-28版規格實際上是一個新的起點——以犧牲有狀態協議的運維便利性為代價，換取生產級企業AI系統所需的可擴展性、安全性和可組合性。