前言¶

Model Context Protocol（MCP）是連接 AI 模型與外部工具、數據源的開放標準。2026 年 7 月 28 日，MCP 正式發佈 2026-07-28 規範——這是協議自誕生以來最大的一次修訂，也是 MCP 的第五次規範發佈。協議現由 Linux Foundation 旗下的 Agentic AI Foundation（AAIF） 託管，Anthropic、OpenAI、Google、Microsoft 等廠商共同參與維護。

根據官方數據，MCP 各 Tier 1 SDK 的月下載量已突破 4 億次，年內增長約 4 倍；Claude 連接器目錄收錄的 MCP 服務器超過 950 個，每天被數百萬用戶使用。這次更新把 MCP 從「雙向有狀態協議」徹底轉向 request/response 無狀態模型，同時落地官方擴展框架與企業級 OAuth 認證，目標很明確：讓 Agent 互聯真正跑在普通 HTTP 基礎設施上。

無狀態核心：從會話綁定到自包含請求¶

舊版（2025-11-25）的工作方式¶

在上一版規範中，通過 Streamable HTTP 調用工具需要先建立會話。客戶端發送 initialize 握手，服務器返回 Mcp-Session-Id，後續每個請求都必須攜帶該會話 ID，客戶端被「釘」在簽發會話的那臺實例上：

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"}}}

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

這意味着生產部署通常需要 sticky session、共享會話存儲，以及網關上對請求體的深度解析——運維成本不低。

新版（2026-07-28）的變化¶

2026-07-28 規範移除了 initialize/initialized 握手（SEP-2575）和 Mcp-Session-Id 會話頭（SEP-2567）。同一個工具調用變成一條自包含請求，任意服務器實例都能處理：

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"}}}}

協議版本、客戶端信息、能力聲明改由每條請求的 _meta 字段攜帶；需要提前瞭解服務端能力時，可調用新的 server/discover 方法。實際效果是：MCP 服務器可以部署在 Serverless、邊緣節點 或普通 round-robin 負載均衡後面，不再需要會話親和性。

無狀態協議，不等於無狀態應用¶

協議層去掉會話，不代表業務不能持有狀態。官方推薦的模式與 HTTP API 一致：工具返回一個顯式 handle（如 basket_id），模型在後續調用中把它作爲普通參數傳回。相比隱藏在傳輸層 metadata 裏的會話狀態，顯式 handle 對模型更透明，也更容易跨工具組合與推理。

路由、緩存與追蹤¶

三個配套改動讓無狀態流量更易運維：

Header 路由（SEP-2243）：Streamable HTTP 傳輸強制攜帶 Mcp-Method 和 Mcp-Name 頭，負載均衡器和網關無需解析 JSON body 即可路由、限流。
可緩存列表（SEP-2549）：tools/list 等列表結果攜帶 ttlMs 和 cacheScope，類似 HTTP Cache-Control，客戶端可按 TTL 緩存，不必靠長連接 SSE 感知變更。
W3C Trace Context（SEP-414）：在 _meta 中標準化 traceparent、tracestate、baggage 鍵名，分佈式追蹤可貫穿 Host → SDK → MCP Server → 下游服務。

多輪交互（MRTR）¶

無狀態協議仍需支持服務端中途向客戶端索要輸入（如確認刪除）。Multi Round-Trip Requests（SEP-2322）用 InputRequiredResult 替代長期持有的 SSE 流：服務端返回 inputRequests 和 requestState，客戶端收集答案後帶着 inputResponses 重發原請求，任意實例都能接續處理。

擴展成爲一等公民¶

2025-11-25 版雖有擴展概念，但缺少正式流程。SEP-2133 補齊了擴展治理：擴展以 reverse-DNS ID 標識，通過 capabilities 中的 extensions map 協商，獨立版本發佈，並有從實驗到官方的 Extensions Track。

本版納入兩個官方擴展：

MCP Apps：服務端渲染 UI¶

MCP Apps（SEP-1865）允許 MCP 服務器提供交互式 HTML 界面，由 Host 在沙箱 iframe 中渲染。工具提前聲明 UI 模板，Host 可預取、緩存和安全審查。UI 與 Host 之間仍走 JSON-RPC 基礎協議，每次用戶操作都經過與直接 tool call 相同的審計與授權路徑。Claude 已支持 MCP Apps，用戶可在對話內直接操作連接器界面，無需切換標籤頁。

Tasks：長時異步任務¶

Tasks 在 2025-11-25 中以實驗性核心功能發佈，生產實踐暴露出需要圍繞無狀態模型重新設計，因此升格爲獨立擴展。新版生命週期：tools/call 可返回 task handle，客戶端用 tasks/get、tasks/update、tasks/cancel 驅動；任務創建由服務端決定。tasks/list 被移除——在無會話模型下無法安全限定範圍。若你基於舊版實驗 Tasks API 開發，需要遷移到新生命週期。

企業級認證加固¶

六個 SEP 強化授權規範，使其更貼近生產環境中的 OAuth 2.0 與 OpenID Connect 部署：

客戶端須按 RFC 9207 校驗授權響應中的 iss 參數（SEP-2468），緩解 MCP「單客戶端、多服務端」部署模式下的 mix-up 攻擊。
Dynamic Client Registration 時聲明 OIDC application_type（SEP-837），避免桌面/CLI 客戶端被錯誤默認爲 "web" 而拒絕 localhost 回調。
註冊憑證綁定授權服務器的 issuer，資源遷移時需重新註冊（SEP-2352）。
補充 refresh token 請求方式（SEP-2207）、step-up 時的 scope 累積（SEP-2350）及 .well-known 發現後綴（SEP-2351）。

Claude 側已提供 Enterprise-Managed Auth：管理員通過 IdP（如 Entra、Okta）一次性授權連接器，用戶通過現有 IdP 組繼承訪問權限，首次登錄即零配置接入。

其他重要變更¶

三項核心能力棄用¶

按新特性生命週期策略（SEP-2577），以下能力標記爲 Deprecated，至少保留一年後纔可能移除：

能力	替代方案
Roots	工具參數、資源 URI 或服務端配置
Sampling	直接對接 LLM 提供商 API
Logging	stdio 用 stderr；結構化觀測用 OpenTelemetry

工具 Schema 升級¶

工具 inputSchema / outputSchema 升至完整 JSON Schema 2020-12（SEP-2106），支持 oneOf/anyOf/allOf、條件分支和 $ref。資源缺失的錯誤碼從 MCP 自定義 -32002 改爲 JSON-RPC 標準 -32602。

演進治理¶

本次包含破壞性變更，但官方強調這不是常態。正式 12 個月棄用窗口、Extensions 框架、以及 Standards Track SEP 須通過一致性測試套件（SEP-2484）才能 Final——未來修訂預期可在不重寫傳輸層的前提下平滑升級。

對開發者的實際影響¶

如果你正在維護 MCP 服務器或客戶端，建議按以下順序排查：

傳輸層：移除對 initialize 握手和 Mcp-Session-Id 的依賴；在請求頭加上 MCP-Protocol-Version、Mcp-Method、Mcp-Name。
有狀態邏輯：把跨調用狀態改爲顯式 handle 參數，由模型在 tool call 間傳遞。
Tasks 用戶：從實驗性核心 API 遷移到 Tasks 擴展的新生命週期。
OAuth 實現：補齊 iss 校驗、application_type 聲明和 issuer 綁定。
SDK 升級：TypeScript、Python、Go、C# 四個 Tier 1 SDK 已支持 2026-07-28，優先升級官方 SDK 再改業務代碼。

Claude 產品側對 2026-07-28 的支持正在逐步 rollout；計劃提交連接器到 Claude 目錄的開發者，可參照官方 Connectors 文檔對齊新規範。

MCP 2026-07-28 把 Agent 互聯做成了「像 Web 一樣」的基礎設施：無狀態、可緩存、可路由、可水平擴展。對已經押注 MCP 的團隊來說，這次更新不是小修小補，而是生產部署範式的一次切換——但也正是這次切換，讓 MCP 從「能跑」走向「能規模化跑」。

MCP 最大版本更新：無狀態核心、官方擴展與企業級認證

前言¶

無狀態核心：從會話綁定到自包含請求¶

舊版（2025-11-25）的工作方式¶

新版（2026-07-28）的變化¶

無狀態協議，不等於無狀態應用¶

路由、緩存與追蹤¶

多輪交互（MRTR）¶

擴展成爲一等公民¶

MCP Apps：服務端渲染 UI¶

Tasks：長時異步任務¶

企業級認證加固¶

其他重要變更¶

三項核心能力棄用¶

工具 Schema 升級¶

演進治理¶

對開發者的實際影響¶

精选优惠券

MCP 最大版本更新：無狀態核心、官方擴展與企業級認證

前言¶

無狀態核心：從會話綁定到自包含請求¶

舊版（2025-11-25）的工作方式¶

新版（2026-07-28）的變化¶

無狀態協議，不等於無狀態應用¶

路由、緩存與追蹤¶

多輪交互（MRTR）¶

擴展成爲一等公民¶

MCP Apps：服務端渲染 UI¶

Tasks：長時異步任務¶

企業級認證加固¶

其他重要變更¶

三項核心能力棄用¶

工具 Schema 升級¶

演進治理¶

對開發者的實際影響¶

精选优惠券

相關文章