前言¶

Model Context Protocol（MCP）是連接大模型與外部工具、數據源的開放協議。自 2024 年底 Remote MCP 推出以來，它迅速成爲 Agent 工具鏈的事實標準之一——官方博客披露，Tier 1 SDK 每月下載量接近 5 億次，TypeScript 與 Python SDK 累計下載均已突破 10 億。

2026 年 7 月 28 日，MCP 維護團隊正式發佈 2026-07-28 版規範。這是 Remote MCP 上線以來最大的一次協議修訂：協議核心從雙向有狀態模型，改爲無狀態的請求/響應模型，移除了 initialize/initialized 握手與 Mcp-Session-Id 會話頭。對部署 Remote MCP Server 的開發者而言，這意味着服務器可以像普通 HTTP 服務一樣掛在負載均衡後面水平擴展，而不必再維護粘性會話或共享 Session Store。

本文基於 MCP 官方發佈博客、Release Candidate 說明 以及 SEP-2567 原文，梳理這次變更的核心內容與落地影響。

有狀態到無狀態：協議層到底改了什麼¶

在 2025-11-25 版規範中，通過 Streamable HTTP 調用工具需要先建立會話：

POST /mcp HTTP/1.1
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize",
 "params":{"protocolVersion":"2025-11-25","capabilities":{},
           "clientInfo":{"name":"my-app","version":"1.0"}}}

服務端返回 Mcp-Session-Id，後續每次請求都必須攜帶該頭，客戶端因此被「釘」在簽發 Session 的那臺實例上。水平擴展時，網關需要粘性路由，後端往往還要共享 Session 存儲。

2026-07-28 版將同一次工具調用壓縮爲單個自描述請求，任意實例均可處理（SEP-2567、SEP-2575）：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

變化可以概括爲三點：

1. 握手消失：不再要求 initialize/initialized 交換；協議版本、客戶端身份與能力改由每次請求的 _meta 字段攜帶。
2. Session 頭移除：Mcp-Session-Id 從規範中刪除，協議層不再維護會話生命週期。
3. 可選發現：客戶端若需提前瞭解服務端能力，可調用新的 server/discover RPC；不調用也不影響後續請求。

水平擴展：爲什麼這對生產部署很重要¶

Release Candidate 文檔用一句話概括了生產側的直接收益：Remote MCP Server 不再需要粘性 Session、共享 Session Store，以及網關上對 JSON Body 的深度包檢測；普通輪詢負載均衡即可分發流量，網關可按 Mcp-Method 頭路由，tools/list 等列表響應也可按服務端聲明的 ttlMs 緩存。

這與 SEP-2567 的分析一致。舊模型下，tools/list、resources/list、prompts/list 的結果可能隨 Session 變化（例如調用 connect_database 後工具列表纔出現），客戶端無法安全跨 Session 複用緩存。Orchestrator 爲每個子 Agent 重複拉取各 Server 的工具列表，開銷可達 O(子 Agent 數 × Server 數)。Session 移除後，列表與 Session 解耦，配合 SEP-2549 引入的 ttlMs 與 cacheScope 提示，同一 Server 的工具目錄可被緩存並在子 Agent 間複用，複雜度降爲 O(Server 數)。

Streamable HTTP 傳輸還要求請求攜帶 Mcp-Method 與 Mcp-Name 頭（SEP-2243），且必須與 Body 中的 method/name 一致。負載均衡器、API 網關、WAF 可以直接按頭部分流與限流，無需解析 JSON。

無 Session 不等於無狀態應用：顯式狀態句柄¶

移除協議層 Session，並不強制業務邏輯無狀態。SEP-2567 推薦的模式與 HTTP API 常見做法一致：由工具顯式創建並返回狀態標識，模型在後續調用中作爲普通參數傳回。

典型寫法如下——服務端提供 create_basket，返回 basket_id，後續 add_item 攜帶該 ID：

// tools/call → create_basket
{ "name": "create_basket", "arguments": {} }

// ← 結果
{ "structuredContent": { "basket_id": "bsk_a1b2c3" } }

// tools/call → add_item
{ "name": "add_item", "arguments": { "basket_id": "bsk_a1b2c3", "sku": "shoes" } }

官方認爲，相比隱藏在傳輸層的 Session 狀態，顯式句柄對模型更可見：Orchestrator 可以讓多個子 Agent 共享同一個 basket_id，同時爲各自分配獨立的 browser_id，粒度由應用設計決定，而非被「一個 Session 一種作用域」所限制。

服務端主動交互：MRTR 取代長連接¶

無狀態模型仍需支持「工具執行中途向用戶確認」等場景。此前 elicitation/create、sampling/createMessage 等 Server 發起的請求依賴保持打開的雙向流；2026-07-28 引入 Multi Round-Trip Requests（MRTR，SEP-2322） 解決這一問題。

Server 在處理客戶端請求時，可返回 resultType: "input_required" 及待回答的 inputRequests；客戶端收集用戶輸入後，攜帶 inputResponses 與 requestState 重試原調用。相關狀態均在 Payload 中傳遞，任意實例可接續處理，無需持久連接。Supabase 等已在 RC 階段表示，正是 MRTR 使其在無 Session 架構下實現了費用確認、危險操作二次確認等 Elicitation 流程。

擴展框架：MCP Apps 與 Tasks¶

本次發佈還正式確立了擴展（Extensions）機制（SEP-2133）：擴展以反向 DNS ID 標識，在獨立倉庫維護，版本與核心規範解耦。

兩個官方擴展值得關注：

• MCP Apps（SEP-1865）：Server 可提供沙箱 iframe 內渲染的交互式 HTML 界面，Host 可預取、緩存並完成安全審查；UI 操作仍走 JSON-RPC，審計路徑與直接 Tool Call 一致。
• Tasks（SEP-2663）：從實驗性核心能力遷出爲 io.modelcontextprotocol/tasks 擴展，採用基於輪詢的 tasks/get、tasks/update；適合長時運行的 Agent 任務。AWS 貢獻了 Tasks 擴展，並已在 Amazon Bedrock AgentCore 中提供支持。

此外，Roots、Sampling、Logging 三項核心能力被標註棄用（SEP-2577），至少保留 12 個月；舊版 HTTP+SSE 傳輸同樣進入棄用窗口。規範還引入正式棄用策略：功能從 Active 到 Deprecated 再到 Removed，最短間隔 12 個月，便於團隊規劃升級而非被動應對。

授權方面，客戶端須按 RFC 9207 校驗授權響應中的 iss 參數（SEP-2468）；Dynamic Client Registration（DCR）正式棄用，轉向 Client ID Metadata Documents（CIMD），客戶端憑證與簽發方綁定，不可跨 Authorization Server 複用。

SDK 與生態：Tier 1 已對齊，雲廠商 Day Zero 跟進¶

TypeScript、Python、Go、C# 四套 Tier 1 SDK 已支持 2026-07-28，Rust SDK 處於 Beta。官方提供了針對破壞性變更的遷移說明；依賴 Session ID 的集成需要重點改造。

生態側表態密集。AWS 與 Anthropic 稱新版規範已在 Amazon Bedrock AgentCore 可用，MCP Server 可部署在標準可擴展基礎設施上；Netlify 表示無 Session 核心使其平臺託管 MCP 與託管普通 Web 服務同樣簡單；Cloudflare Agents SDK、Google Cloud、Microsoft Foundry、FastMCP 4.0 等也宣佈 Day Zero 或近期支持。

對正在構建 Agent 工具鏈的團隊，可優先評估以下遷移項：

1. 移除對 initialize 握手與 Mcp-Session-Id 的依賴，改爲在 _meta 中傳遞客戶端信息。
2. 網關與可觀測性接入 Mcp-Method / Mcp-Name 頭；列表接口利用 ttlMs 減少重複拉取。
3. 若業務依賴跨調用狀態，設計顯式句柄工具，而非假設 Session 作用域。
4. 若使用 experimental Tasks API，對照擴展版生命週期遷移；關注 MRTR 以支持用戶確認類交互。

小結¶

2026-07-28 版 MCP 把協議核心對齊到現代 HTTP 運維範式：無 Session、可路由、可緩存、可水平擴展。這是自 Remote MCP 推出以來最重要的一次架構修訂，Breaking Change 較多，但配合 12 個月棄用窗口與擴展框架，官方意圖是在此次「乾淨斷代」之後，讓後續演進以可選擴展與小步迭代爲主。

對開發者而言，MCP Server 終於更接近「部署一個 REST 服務」的心智模型；對 Agent 平臺而言，工具目錄緩存、子 Agent 並行、企業級網關治理的成本都會下降。若你已在生產環境運行 Remote MCP，建議對照官方 SDK 遷移文檔與 SEP 原文，儘早啓動適配——這一次不是小版本補丁，而是協議層的換底。