前言¶
Model Context Protocol（MCP）是連接 AI 應用與外部工具、數據源的開放協議。2024 年 11 月由 Anthropic 發佈，2025 年 12 月捐贈給 Linux Foundation 旗下的 Agentic AI Foundation（AAIF），現已成爲 Claude、Cursor、VS Code、ChatGPT 等平臺廣泛採用的集成標準。據 Anthropic 官方數據，MCP SDK 月下載量已突破 4 億次，較年初增長約 4 倍。
2026 年 7 月 28 日，MCP 正式發佈 2026-07-28 規範——這是協議推出以來規模最大的一次修訂。核心變化可以概括爲一句話：協議層徹底無狀態化。initialize 握手、Mcp-Session-Id 會話頭被移除，遠程 MCP 服務器可以像普通 HTTP API 一樣部署在 Serverless、邊緣節點和標準負載均衡之後；MCP Apps、Tasks 畢業爲官方擴展；OAuth 2.0 授權規範同步加固。Claude 全線產品已開始逐步支持新版規範。本文基於 MCP 官方博客、Anthropic 公告及社區討論，梳理這次更新的技術要點與遷移思路。
無狀態核心：告別握手與會話¶
舊模型的問題¶
在 2025-11-25 版本中，通過 Streamable HTTP 調用工具需要先建立會話。客戶端發送 initialize 請求，服務器返回 Mcp-Session-Id，後續每次調用都必須攜帶該頭，請求被「釘」在簽發會話的那臺實例上。生產環境因此往往需要：
- 粘性會話（sticky session）或會話親和路由
- 共享 Session Store（Redis 等）
- 網關在 L7 層深度解析 JSON-RPC body 才能做路由與限流
這對想把 MCP 服務器部署到 Lambda、Cloudflare Workers 或普通 K8s 輪詢負載均衡上的團隊，是不小的運維負擔。MCP 網關/registry 運營方（如 Glama）也在社區反饋中證實，相當比例的兼容性問題與會話狀態持久化有關。
新模型：單次自包含請求¶
2026-07-28 把同一次工具調用壓縮爲一條自包含的 HTTP 請求，任意實例均可處理：
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"}}}}
六項 SEP（Specification Enhancement Proposals）協同完成這一改造：
- SEP-2575：移除
initialize/initialized握手。協議版本、客戶端信息與能力改由每條請求的_meta攜帶；需要提前獲知服務器能力時，可調用新的server/discover方法。 - SEP-2567：移除
Mcp-Session-Id及協議層會話概念。 - SEP-2243：Streamable HTTP 傳輸強制要求
Mcp-Method、Mcp-Name頭，負載均衡器與網關可按操作類型路由，無需解析 body；頭與 body 不一致時服務器應拒絕。 - SEP-2549：
tools/list等列表結果攜帶ttlMs與cacheScope（類似 HTTP Cache-Control），客戶端可安全緩存，減少重複拉取。 - SEP-2260 + SEP-2322：服務端主動向客戶端發起交互（如確認刪除）改爲 Multi Round-Trip 模式，返回
InputRequiredResult，客戶端攜帶inputResponses與requestState重試——全程無持久 SSE 連接。 - SEP-414：在
_meta中標準化 W3C Trace Context（traceparent等），便於 OpenTelemetry 全鏈路追蹤。
無狀態協議 ≠ 無狀態應用¶
協議不再替你管理會話，但業務仍可通過「顯式句柄」跨調用傳遞狀態：服務器在工具返回值中 mint 一個 basket_id 或 browser_id，模型在後續調用中作爲普通參數傳回。官方文檔指出，這種模式往往比隱藏在傳輸層的 session 更靈活——模型可以組合、推理並在多步任務間傳遞這些標識。
擴展框架：MCP Apps 與 Tasks 正式畢業¶
2025-11-25 中擴展缺乏正式治理流程。2026-07-28 通過 SEP-2133 建立 Extensions Track：擴展以 reverse-DNS ID 標識，獨立 ext-* 倉庫維護，版本與核心規範解耦，客戶端/服務器通過 capabilities 中的 extensions map 協商啓用。
MCP Apps（SEP-1865）¶
服務器可聲明交互式 HTML UI 模板，宿主在沙箱 iframe 中渲染。模板可預取、緩存與安全審查；UI 側操作仍走 JSON-RPC，與直接 tool call 共用審計與授權路徑。Claude 已支持 MCP Apps，用戶可在對話內聯操作連接器 UI，無需切 tab。
Tasks 擴展¶
Tasks 在 2025-11-25 曾作爲實驗性核心功能出現；生產實踐表明其生命週期更適合獨立擴展。新版流程適配無狀態模型：
- 服務器對
tools/call可返回 task handle - 客戶端用
tasks/get、tasks/update、tasks/cancel驅動進度 - 任務創建由服務器決定（客戶端僅聲明支持擴展）
tasks/list已移除（無會話時無法安全 scoped）
若你曾對接舊版實驗性 Tasks API，需要按新生命週期遷移。
OAuth 2.0 授權加固¶
六項 SEP 使 MCP 授權更接近企業 IdP（Entra、Okta 等）的實際部署方式，要點包括：
- SEP-2468：客戶端必須校驗授權響應中的
iss參數（RFC 9207），緩解 mix-up 類攻擊；未來版本可能強制拒絕缺少iss的響應。 - SEP-837：Dynamic Client Registration 時聲明 OpenID Connect
application_type，避免桌面/CLI 客戶端被誤默認爲"web"而 localhost redirect 被拒。 - SEP-2352：註冊憑證綁定到授權服務器
issuer，資源遷移時需重新註冊。 - SEP-2207 / SEP-2350 / SEP-2351：補充 refresh token 請求、step-up scope 累積與
.well-known發現後綴說明。
Claude 側已提供 Enterprise-managed auth：管理員在 IdP 中一次性授權連接器，用戶通過現有組繼承訪問，首次登錄即零-touch 接入。
其他值得關注的變更¶
| 變更 | 說明 |
|---|---|
| Roots / Sampling / Logging 棄用 | 分別由工具參數、直連 LLM API、OpenTelemetry 替代；標註棄用，至少保留一年 |
| Tool Schema 升級 JSON Schema 2020-12 | 支持 oneOf、$ref 等；structuredContent 可爲任意 JSON 值 |
錯誤碼 -32002 → -32602 |
資源缺失改用 JSON-RPC 標準 Invalid Params |
| 特性生命週期策略 SEP-2577 | Active → Deprecated → Removed，棄用與移除間隔不少於 12 個月 |
遷移與生產部署建議¶
本次爲 breaking change，官方 RC 於 2026 年 5 月 21 日鎖定，最終規範 7 月 28 日發佈；Tier 1 SDK 預期在十週驗證窗口內跟進。
社區評估（含 Hacker News 討論）普遍認爲：
- 線協議雙向不兼容：僅升級 SDK 往往不夠，服務器與客戶端可能需重構傳輸層與握手邏輯。
- SSE-only 存量仍多：儘管 SSE 已棄用，大量實現仍僅支持舊 Streamable HTTP + 會話模式，遷移週期會拉長。
- 網關價值上升：協議版本並存的過渡期裏，MCP 網關可作爲互操作層，在舊客戶端與新無狀態服務器之間做協議轉換。
若你正在規劃生產 rollout，可按以下順序推進：
- 閱讀 官方 changelog 與 draft specification，對照 SEP 清單評估影響面。
- 移除對
initialize、Mcp-Session-Id的依賴；在每條請求注入_meta與MCP-Protocol-Version頭。 - 爲
tools/list實現ttlMs緩存；在網關層利用Mcp-Method/Mcp-Name做路由與限流。 - 若使用 Tasks 實驗 API 或依賴 Roots/Sampling，按棄用表制定遷移時間表。
- 授權側檢查 AS 是否返回
iss，CLI/桌面客戶端完成 DCRapplication_type聲明。 - 關注所用 SDK 的 Tier 1 支持進度；Claude Connectors 目錄提交需符合新版規範要求。
結語¶
2026-07-28 把 MCP 從「需要會話親和的 Agent 專線協議」推進爲「可運行在 commodity HTTP 基礎設施上的無狀態 workload」。配合擴展框架、正式棄用策略與 OAuth 加固，這是 MCP 走向大規模企業生產部署的基礎性一步。代價是明確的遷移成本——但正如 MCP 維護者在 HN 上所回應的，對於希望把遠程 MCP 服務器部署到 Serverless 的開發者，這是一次期待已久的改變。AAIF 社區已在 7 月 28 日前後舉辦 Release Party，SDK 與 Claude 產品支持仍在滾動發佈中；建議儘早在新規範上驗證你的工作負載，而不是等待舊版會話模型被完全邊緣化。
