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。從個人服務器作者到平台團隊再到圍繞它構建網關和註冊表的供應商，其回報是協議層更自然地契合業界已熟悉的運維基礎設施。