GitHub 率先擺脫 MCP session：遠端 server 擴容唔使再綁死同一部機

GitHub MCP Server 已經率先支援預定 7 月 28 日推出嘅新版 MCP。對用家嚟講，撳掣嗰刻未必會見到大分別；對負責架遠端 MCP server 嘅團隊，改動就相當實際：協定唔再要求 server 記住上一個請求由邊部機處理，擴容時可以少一層 session 基建。截至 7 月 24 日，新規格仍然係 release candidate，正式版預定 2026 年 7 月 28 日發布。

舊版點解愈多機愈麻煩

舊版 Streamable HTTP 流程要由 client 先送出 initialize，同 server 交換協定版本、能力同實作資料。server 可以回傳 Mcp-Session-Id，之後每次工具呼叫都要帶住呢個 ID。當服務得一部機，做法唔算難搞；一加到幾部，負載平衡器就要用 sticky session，確保同一個 client 繼續搵返原本嗰部，或者每部機共用 Redis 一類 session store。就算加到機，部署同維護工作亦會跟住增加。

舊版流程： client → initialize → server A 回傳 session ID → 後續請求帶 ID → 固定交畀 server A，或者由各部 server 查共用 session store。

新版每個請求都可以獨立處理

2026-07-28 版刪走 initialize／initialized 握手同 Mcp-Session-Id。協定版本改放入 HTTP header，client 資料同支援能力就跟每個請求送出；client 想預先知道 server 有咩能力，可以另外呼叫 server/discover。Mcp-Method 同 Mcp-Name header 亦畀 gateway 直接睇到呼叫類型，毋須先拆開整個 JSON payload。結果係同一個 client 嘅相鄰請求，可以輪流交畀 server A、B 或 C。

新版流程： client → 帶齊版本、能力同呼叫資料嘅請求 → 普通 round-robin 負載平衡 → 任一 server instance 處理。協定層毋須 sticky session，亦毋須為咗 MCP session 額外架一個共用資料庫。不過登入權限、業務資料同 rate limit 呢類應用層內容，照樣要由服務本身妥善處理，無狀態核心唔會自動解決晒成套系統設計。

GitHub 實裝慳走咗邊幾層

iThome 報道提到，GitHub 配合新版刪走用 Redis 保存 session 嘅做法。GitHub 官方再講得具體啲：初始化嗰次資料庫寫入冇咗，每次工具呼叫原本要做嘅 session 讀取亦一併移除。GitHub 形容反應會爽快啲，但官方冇公開 benchmark，所以暫時唔應該估快咗幾多。可以肯定嘅係，請求少咗資料庫操作，團隊亦少一個要監察、備援同擴容嘅元件。

GitHub 仲可以直接由新 header 取得記錄同 secret scanning 所需資料，唔使喺 SDK 接手前先解析完整請求。原有 URL 登入流程亦改用新版 multi round-trip request：server 要用家登入或確認操作時，每一步都係獨立 HTTP 請求，client 會連同 requestState 再送返原本呼叫。咁下一步交畀另一部 server 都處理得到，唔使長開 SSE 連線等同一部機接手。

無狀態唔代表工具唔准記住嘢

購物籃、瀏覽器自動化、長時間任務呢類功能，本身就要跨多次呼叫保存狀態。新版冇禁止呢啲設計，只係協定唔再暗中代管。server 可以喺建立資源時回傳 basket_id、browser_id 或 task handle，之後由 client 或模型當普通工具參數傳返。狀態屬於邊個、幾時失效同可唔可以跨用家共用，會變得清楚啲；代價係現有工具如果一直偷用 session ID 綁住背景狀態，就要改 API 同儲存方式。

向後相容有條件，第三方實作要自己驗

GitHub 話 Tier 1 官方 SDK 已經推出新版 beta 支援，亦保留舊協定相容路徑；GitHub MCP Server 用嘅官方 Go SDK，由 v1.7.0 起同時列出 2026-07-28 同多個舊版本。呢個安排令新版 client、舊版 client 同 GitHub server 之間有空間逐步轉換，GitHub 現有用家毋須即刻做設定。不過呢句只涵蓋有實作雙版本處理嘅 SDK 同服務，唔代表所有自製 client 或第三方 server 都會自動相容。

自己維護 MCP 實作嘅團隊要檢查幾樣嘢：有冇硬性呼叫 initialize、有冇依賴 Mcp-Session-Id、gateway 會唔會補齊同驗證新 header、server-to-client 互動有冇改用 multi round-trip request，仲有應用狀態係咪已經變成明確 handle。官方 conformance suite 可以幫手驗證協定行為。規格正式出爐後，最值得先測嘅係新舊版本交叉連線同登入流程，呢兩處最容易出現「各自運作正常，接埋就失敗」嘅問題。

參考來源

• iThome — GitHub搶先支援無狀態MCP，遠端服務擴充免再綁定工作階段 — original report
• GitHub MCP Server supports the next MCP specification — GitHub 官方公告，確認 Redis、請求解析、URL elicitation 同相容安排。
• The 2026-07-28 MCP Specification Release Candidate — MCP 官方解說，確認 RC 狀態、正式發布日期、請求流程同 breaking changes。
• SEP-2575: Make MCP Stateless — 刪走 initialize／initialized 握手嘅原始規格提案。
• SEP-2567: Sessionless MCP via Explicit State Handles — 移除協定 session、改用明確狀態 handle 嘅原始提案。
• MCP Go SDK — 官方 Go SDK 版本相容表，核對 GitHub 採用 SDK 嘅新舊規格支援。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。