前言¶

Model Context Protocol（MCP）是連接 AI Agent 與外部工具、數據源的開放標準。自 Anthropic 於 2024 年 11 月發佈以來，它已迅速成爲 Agent 工作流的事實性「連接層」——Anthropic、Google Cloud、Microsoft、AWS、Cloudflare 等廠商均將其視爲 Agent 基礎設施的關鍵組件。

2026 年 7 月 28 日，MCP 維護團隊在 Linux Foundation 旗下 Agentic AI Foundation（AAIF） stewardship 下，正式發佈 2026-07-28 版規範。這是 MCP 自遠程 MCP 上線一年多以來最重要的一次升級：協議核心從雙向有狀態模型轉向 無狀態請求/響應 架構，同時硬化 OAuth 授權、確立正式擴展框架，並將 MCP Apps、Tasks 等能力畢業爲官方擴展。

據 MCP 官方博客，Tier 1 SDK（TypeScript、Python 等）月下載量已接近 5 億次，TypeScript 與 Python SDK 累計下載均突破 10 億。Anthropic 同期披露 MCP SDK 月下載量超 4 億，年內增長約 4 倍。VentureBeat 援引聯合維護者 David Soria Parra 的說法，SDK 周下載量已達約 2.5 億。這組數字背後，是大量企業正把 MCP 從試點推向生產。

本文基於 MCP 官方發佈說明、Anthropic Claude 產品博客及 VentureBeat 採訪，梳理本次更新的核心變化、對開發者的實際影響，以及遷移時需要留意的 breaking changes。

爲什麼要有無狀態核心¶

在舊版設計中，MCP 客戶端必須與特定服務端實例維持持久會話。客戶端需完成 initialize/initialized 握手，並通過 Mcp-Session-Id 頭標識會話。在 Kubernetes、Serverless 等現代雲環境中，計算節點隨時擴縮，負載均衡器後端的實例並不固定——一旦持有會話狀態的 Pod 下線，Agent 的工作就可能中斷。

聯合維護者 Den Delimarsky 在接受 VentureBeat 採訪時直言：「以前你需要 session store 來管理 session ID，某個 compute pod 掛掉後請求就會失敗。新版本里這不再是問題。」AAIF 執行董事 Mazin Gilbert 則將其類比爲 Web 本身的無狀態設計——瀏覽器無需「粘」在某臺服務器上，才能訪問任意網站。

2026-07-28 規範正式廢棄協議級握手與會話頭（SEP-2575、SEP-2567）。每個請求自描述，在 _meta 中攜帶協議版本、客戶端身份與能力；任意請求均可落在負載均衡器後的任意實例上，無需共享存儲或 sticky routing。若客戶端希望提前瞭解服務端能力，可調用可選的 server/discover RPC，但並非強制。

需要強調的是：協議層無狀態，並不強制應用層無狀態。若工具調用間需傳遞上下文，服務端可顯式返回 handle，由模型在後續調用中作爲參數傳回——狀態由開發者按需管理，而非隱藏在傳輸層。

無狀態請求長什麼樣¶

官方博客給出了 Streamable HTTP 下的典型請求示例：

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

{"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. 無 Mcp-Session-Id：每個 POST 獨立完整，可路由到任意後端。
2. Mcp-Method 與 Mcp-Name 頭（SEP-2243）：網關、WAF、限流器可直接按頭路由與鑑權，無需解析 JSON body。
3. MCP-Protocol-Version: 2026-07-28：顯式聲明協議版本，便於多版本共存與灰度。

對部署而言，這意味着 MCP Server 可以像普通 HTTP 服務一樣跑在 Cloudflare Workers、AWS Lambda、Netlify Edge 等無狀態基礎設施上——Google Cloud、Cloudflare、Netlify 等已在發佈當日宣佈 Day Zero 支持。

MRTR：無狀態協議下的交互式調用¶

完全無狀態後，一個棘手問題是：工具執行到一半需要用戶確認或補參怎麼辦？舊版依賴服務端發起的 elicitation/create、sampling/createMessage 等請求，並要求保持雙向長連接。

新版引入 Multi Round-Trip Requests（MRTR，SEP-2322）：服務端返回 resultType: "input_required" 及待回答的請求列表，客戶端在原調用上附帶 inputResponses 重試。Supabase 產品負責人 Inian Parameshwaran 在官方 testimonial 中提到，MRTR 使其能在無狀態架構下支持「創建項目前確認費用」「刪除數據前確認」等 elicitation 流程。

Roots、Sampling、Logging 等舊能力已正式 deprecate（SEP-2577），至少保留 12 個月；新實現不應再採用它們。Legacy HTTP+SSE 傳輸同樣進入棄用軌道。

可緩存的列表響應¶

tools/list、prompts/list、resources/list、resources/read 的響應現攜帶 ttlMs 與 cacheScope（SEP-2549）。客戶端可據此制定緩存策略，減少重複拉取；列表順序確定性也有助 prompt cache 在重連後保持穩定。對高頻調用工具目錄的 Agent 客戶端，這是直接的性能收益。

正式擴展框架：MCP Apps 與 Tasks¶

2026-07-28 將擴展機制正式鎖定。除核心協議外，能力以版本化擴展獨立演進，避免核心規範臃腫。

MCP Apps 允許服務端在對話中渲染交互式 UI——表單、儀表盤、可視化等，而不僅是文本輸出。Figma、Netlify 等已在探索將設計稿、生成結果直接嵌入 Agent 對話界面。

Tasks（io.modelcontextprotocol/tasks 擴展，SEP-2663）從實驗性核心畢業，面向長耗時異步任務：服務端返回 durable task handle，客戶端可斷開、重啓後通過 poll 型 tasks/get 與 tasks/update 繼續跟蹤。AWS 貢獻了 Tasks 擴展，Amazon Bedrock AgentCore 已支持在新規範下部署 MCP Server。變更通知從舊 HTTP GET 端點遷移至客戶端按類型 opt-in 的 subscriptions/listen 流。

Enterprise Managed Authorization（EMA） 則與 Okta 等身份提供商協作，使企業 IdP（如 Entra、Okta）成爲 MCP 訪問的統一門禁——管理員一次授權，用戶通過現有 IdP 組繼承權限，Claude 等產品已實現 zero-touch 連接器配置。

OAuth 2.0 硬化與企業級授權¶

維護者坦言，授權集成是 MCP 落地最耗時的環節之一。2026-07-28 在 OAuth/OIDC 對齊上邁出幾步：

1. RFC 9207 iss 校驗（SEP-2468）：授權服務器返回 issuer，客戶端兌換 code 前必須驗證，封堵 mix-up 類攻擊。維護者強調這是預防性加固，並非響應已發生漏洞。
2. 客戶端憑證綁定 issuer（SEP-2352）：禁止跨授權服務器複用憑證。
3. DCR 正式 deprecate，轉向 CIMD（Client ID Metadata Documents）：Dynamic Client Registration 仍向後兼容，但未來版本將移除；CLI/桌面客戶端的 localhost redirect 問題亦通過 application_type 等 SEP-837 變更緩解。

VentureBeat 將「12 個月棄用策略 + 開放標準 + 無狀態擴展性」稱爲企業信任的三條腿——對 Fortune 500 而言，安全與可預期性有時比無狀態本身更關鍵。

12 個月棄用窗口¶

規範首次寫入 正式棄用政策：任何被 deprecate 的特性，至少保留 12 個月方可移除。維護者與 Google、Microsoft、Amazon 等諮詢後選定該窗口；遙測顯示多數生態在 6–8 個月內完成升級。Roots、Sampling、Logging、HTTP+SSE 等均在此政策保護下逐步退場。

SDK 與生態現狀¶

Tier 1 SDK——TypeScript、Python、Go、C#——均已支持 2026-07-28，並提供 breaking changes 遷移說明；Rust SDK 處於 beta。Claude 連接器目錄已收錄超 950 個 MCP Server，新規範支持正逐步 rollout 至 Claude 各產品面。

AAIF 自 2025 年 12 月成立以來，成員已從約 40 家增至 240 家；Anthropic 在貢獻佔比上已低於一半。聯合維護者團隊橫跨 Anthropic、Microsoft、OpenAI、Google、Amazon 等，核心決策通常一致通過——VentureBeat 將此視爲 MCP 從單一廠商項目走向中立開放標準的關鍵節點。

對開發者的遷移建議¶

若你維護 MCP Server 或 Client，建議按以下順序評估：

1. 檢查是否依賴 session ID 或 initialize 握手——這是本次最大 breaking change，官方 SDK 會吸收大部分改動，但自定義傳輸層需手動適配。
2. 評估長連接交互——elicitation、sampling 等應遷移至 MRTR 模式。
3. 更新 OAuth 集成——啓用 iss 校驗，規劃從 DCR 向 CIMD 過渡。
4. 利用緩存頭——在 Client 側爲 list 響應實現合理 TTL，降低冷啓動開銷。
5. 長任務改用 Tasks 擴展——避免爲批處理作業維持 fragile 長連接。

Soria Parra 表示，多數基於官方 SDK 的項目遷移成本可控，「世界上任意一個模型大概都能 one-shot 幫你改完」——這本身也反映了維護者對 AI 輔助升級路徑的設計考量。

小結¶

2026-07-28 不是增量補丁，而是 MCP 向 企業級 Agent 基礎設施 的架構性躍遷：無狀態核心解決規模化部署瓶頸，MRTR 與 Tasks 擴展覆蓋交互與異步場景，OAuth 硬化與 EMA 回應生產環境的安全訴求，12 個月棄用策略則給出可預期的演進節奏。

對正在構建 Agent 工作流的團隊而言，現在是用官方 SDK 對齊新規範、在標準 HTTP 棧上部署 MCP Server 的合適窗口。協議仍在快速演進——AAIF 已預告 Agent Gateway 等項目——但正如 Gilbert 所類比：HTTP 用了三十年才成爲無人察覺的基礎設施；Agent 互聯網的「 plumbing」，或許正從這一次無狀態轉向開始真正承重。

參考來源

• The 2026-07-28 Specification | MCP Blog
• Bringing MCP 2026-07-28 to Claude | Anthropic
• MCP just got its biggest update ever | VentureBeat