MCP 最大更新：移除眾多伺服器圍繞構建的機制

模型上下文協議（MCP）自發布以來最大的一次更新即將到來。主要維護者已於5月21日凍結了候選版本，最終規範定於7月28日釋出。

乍看之下，變更日誌頗為劇烈：會話和初始化握手將被移除，三項核心功能被棄用。但細看之下，此次修訂實質上是將 MCP 簡化，把熟悉的任務交回已有的基礎設施處理。對運維人員而言，這解決了長期以來的痛點：執行遠端 MCP 伺服器不應需要普通無狀態服務所不需要的專用機制。

MCP 對其使用者徵收的“稅”

要理解這些移除，需審視 MCP 原始設計與實際部署之間的差距。其最早且最廣為人知的形式是透過標準輸入輸出與本地程序通訊的桌面應用，啟動握手在持久連線上開銷低廉。

隨著更多伺服器遷移到遠端水平擴充套件部署，會話成為問題。伺服器生成 Mcp-Session-Id，將客戶端繫結到特定例項。擴充套件時通常需要會話親和性、外部共享會話儲存或解析 JSON 體以確定路由的 MCP 感知閘道器邏輯。一個團隊執行 MCP 伺服器，卻要解決協議自身創造的分散式系統問題。

能力協商增加了第二重成本。能力僅在連線時交換一次，導致不同連線的結果可能不同，使得會話間快取或共享中介難以處理。

維護者的最佳化目標

六項規範增強提案匯聚於一個目標：讓每個請求獨立。協議版本和客戶端能力現透過 _meta 在每次呼叫中傳遞。客戶端應在此包含其身份，新的 server/discover 方法使伺服器能力可獨立查詢。釋出文章將此稱為“按需付費複雜度”原則：核心保持精簡，狀態僅當功能真正需要時才出現。

明顯的異議是許多伺服器確實需要記住事物。主要答案是顯式控制代碼（handle），這是二十年來每個 HTTP 購物車使用的模式。工具建立 basket_id，返回結果，模型在下次呼叫中作為普通引數傳回。賬戶狀態、資源 URI、任務控制代碼和普通資料庫識別符號仍可用於不應走此路徑的任何內容。

控制代碼不僅僅是權宜之計，因為它對模型可見。隱藏在傳輸後設資料中的會話狀態是模型無法推理的，而工具結果中的控制代碼可跨工具組合並在工作流步驟間傳遞。代價是它也會出現在提示、轉錄和日誌中，因此應繫結到已驗證主體並在每次使用時檢查許可權。

開發者實際獲得的好處

對伺服器作者而言，遠端 MCP 伺服器現在可以像傳統無狀態 HTTP 服務一樣執行。三副本輪詢，無需親和性配置，無需執行或恢復協議會話儲存。滾動部署不再使會話失效或讓客戶端滯留於移除的例項，但可能中斷正在進行的請求和訂閱流，由於恢復功能已移除，客戶端以新請求 ID 重新發出。

對平臺團隊，必需的 Mcp-Method 頭部加上 Mcp-Name 表示工具、資源或提示操作，使閘道器可按操作限流或授權，無需檢查請求體。這僅在傳輸驗證規則下成立，後端拒絕頭部與體不一致的請求，策略強制中介拒絕不保證檢查的協議版本。

快取變更值得更多關注。受影響的列表和讀取結果現在必須包含 ttlMs 和 cacheScope，模仿 HTTP Cache-Control，使客戶端可以在宣告的時間間隔內持有目錄而不是重新獲取。草案將 ttlMs 視為新鮮度提示而非資料仍然有效的承諾。伺服器還要求以確定性順序返回工具，草案表示這有助於提高提示快取命中率，在大量使用時可能降低延遲或代幣成本。

一個警告屬於此處而非腳註：協議層的無狀態買來的是可路由性而非確定性。兩個副本接受相同請求而無需協商協議狀態，但如果它們執行不同版本或讀取不同下游資料，仍會返回不同答案。

為何關心擴充套件

生態系統的論證強於任何單個功能。擴充套件現在獲得名稱空間識別符號：官方擴充套件字首 io.modelcontextprotocol，第三方擴充套件使用作者擁有的反向域名，外加獨立的 ext- 倉庫和釋出節奏。任何編寫過 Kubernetes 自定義資源定義的人都會認出這種模式：一個功能在核心釋出週期之外孵化併成熟。

Tasks 是這一點的證明。它作為實驗性核心功能於 2025-11-25 釋出，實際生產使用暴露了設計問題，現已被重新設計為擴充套件。將其移出核心本身是一次破壞性規範變更，但下一次迭代不會如此，因為擴充套件透過能力標誌或設定級版本控制演進，僅在無法避免時才使用新識別符號。MCP Apps 作為擴充套件已經可用，現在位於正式管控的協商框架內，而非之前不存在的流程。

棄用策略帶來的好處

功能生命週期策略為每個功能定義了活躍、棄用和移除狀態，從功能首次被標記為棄用的修訂版起至少 12 個月的視窗。視窗只能因已釋出公告或已記錄利用的活躍安全風險而縮短，即使如此，90 天是硬性下限。公共登錄檔列出已棄用及何時移除。標準跟蹤提案在相應場景落地到符合性套件之前不能達到最終狀態。

對開發者而言，這看起來像內務管理。但對需要向平臺審查委員會證明 MCP 整合合理性的人來說，書面棄用保證比此次釋出中的任何功能都更有價值。

代價

這一切並非免費。任何基於實驗性 Tasks API 構建的人必須遷移到新生命週期；任何向客戶端發出自身請求的伺服器必須轉移到多輪次請求模式，伺服器返回仍需的資訊，客戶端攜帶答案重試。該伺服器還必須驗證任何可能影響授權或業務邏輯的回顯 requestState。一次性工作流仍需自身重放跟蹤。

棄用是遷移方向而非替代品，Sampling 是最尖銳的案例。使用客戶端中介的 Sampling 的伺服器無需提供商憑證，通常不承擔模型賬單；而直接呼叫提供商 API 則使其成為憑證持有者、賬單方和使用者資料的獨立處理器。Logging 也類似：stderr 和 OpenTelemetry 回答運維可觀察性問題，而不給遠端客戶端與之前接收的結構化日誌流等同的功能。

協議不再管理狀態，這並不意味著狀態消失。控制代碼、購物車、任務記錄和冪等鍵仍需駐留某處。協議不再管理狀態，但狀態並未消失。

前路

在協議誕生不到兩年內移除基礎抽象是有計算的風險，維護者明智地設定了 10 周驗證視窗，並提供 Python、TypeScript、Go 和 C# 的 Beta SDK。

他們還定義了遷移路徑：客戶端先使用 server/discover 探測，僅在遇到僅支援舊版本的伺服器時回退到初始化。這是一個有線層面的斷點，但透過協商路徑跨越，而非生態系統的“旗幟日”。

釋出候選視窗是盤點會話依賴並測試的正確時機，生產部署應等待審批完成和穩定 SDK。從個人伺服器作者到平臺團隊再到圍繞它構建閘道器和登錄檔的供應商，其回報是協議層更自然地契合業界已熟悉的運維基礎設施。