MCP 不再像一個廠商的插件接口，它開始像一條公共管道。管道會更結實，但也會更沒脾氣。

文章作者、來源：0x9999in1，ME News

簡而言之

2026 年 7 月 28 日，MCP 發布第五版規範 2026-07-28，官方定性為協議誕生以來最大規模的一次修訂。核心動作只有一個：刪掉協議層的會話。
initialize/initialized 握手没了，Mcp-Session-Id 请求头没了。每个请求自带协议版本、客户端身份和能力声明，写在 _meta 里。任何请求可以落在任何一台实例上，一个普通的轮询负载均衡就够。
這不是性能優化，是架構認錯。黏性會話和共享 session 儲存，曾經是 MCP 伺服器上規模時最貴的那部分帳單。
狀態並未消失，而是從傳輸層移至工具參數中，稱為「顯式句柄」。模型可以看見它，因此也能夠控制它。
交互界面（MCP Apps）和長任務（Tasks）已正式納入版本化擴展框架，核心協議不再為新功能增加負擔。身份驗證向真實世界的 OAuth 2.0 和 OIDC 靠攏，企業級託管授權擴展同日轉為穩定版。
代價是真金白銀的：這是一次 breaking change。Roots、Sampling、Logging 與舊的 HTTP+SSE 傳輸集體進入棄用期，官方提供了至少 12 個月的過渡窗口。
一句判斷：MCP 不再像廠商的插件接口，它開始像一條公共管道。管道會更結實，但也會更沒脾氣。

一、被刪除的那兩行，才是這次改版的重點

先說一個反直覺的事實。

這次被稱為「史上最大改版」的更新，最重要的部分不是增加了什麼，而是刪除了什麼。

initialize 和 initialized 這對握手，自 MCP 2024 年 11 月誕生之日起便存在。Mcp-Session-Id 這個請求標頭，是遠端 MCP 落地後所有部署方案的基礎。7 月 28 日，這兩樣東西被一併移除。

新的請求長什麼樣？很樸素。

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

方法名和工具名被抬到 HTTP 头上。網關、限流器、WAF 不用再拆開 JSON 包體去猜這次調用要幹什麼，看頭就行。協議版本、客戶端資訊、能力聲明，全部塞進 _meta 隨請求走。想提前問伺服器有什麼本事？新加了一個 server/discover，但它是可選的，不是必須的。

這意味著什麼？這意味著 MCP 伺服器終於變成了一個普通的 HTTP 工作負載。

根據 Netlify 應用 AI 副總裁 Sean Roberts 的說法，無狀態核心讓 MCP 成為一等公民的 HTTP 負載，無需繞過會話管理。Cloudflare 的表述更為直接，稱這一版本讓 Agent 基礎設施開始像 Web 的其他部分一樣運作：無狀態、可快取、可路由、可全球擴展。

聽起來像標準的廠商宣傳話術。但這次不太一樣，因為它們說的是同一件具體的事：會話消失了，所以 Lambda 能跑，Workers 能跑，邊緣節點能跑。

二、黏性會話，是 Agent 規模化路上真實的天花板

為什麼要下這麼大的狠手？

因為舊模型有一個無法避免的物理限制：會話被釘死在處理握手的那台實例上。

於是所有人都被迫做同樣一件事：要麼開啟黏性會話，讓負載均衡器記住每個客戶端該連接到哪台機器；要麼架設一層 Redis 之類的共享存儲，將 session 狀態儲存起來供所有實例讀取。

這兩條路都能走通，但都要付一筆隱形的稅。

黏性會話意味著擴縮容變得難看。一台實例要下線，掛在上面的會話就得斷。流量突增時新拉起的實例接不到老會話，負載永遠歪的。共享存儲那條路更貴，你為一個本質上只是「記住客戶端叫什麼」的需求，引入了一個有狀態中間件，還得為它做高可用。

規模小時這不叫問題。規模上來了就叫問題。

看一組數字就明白規模是怎麼變的。2025 年 12 月，MCP 誕生一週年時，SDK 月下載量是 9700 萬次。到 2026 年 7 月這次發布，Anthropic 給出的數字是月下載量超過 4 億次，官方博客的說法是「接近五億」，年內增長四倍。TypeScript 和 Python 兩個 SDK 的累計下載量各自越過了十億次門檻。

Anthropic 自家的 Claude 連接器目錄中，現已列出超過 950 個 MCP 伺服器。可觀測性廠商 Honeycomb 的數據更能說明 Agent 已經在真實運作：他們每月全部互動式查詢中，接近 20% 是由 Agent 發起的。

半年四倍。在這種曲線下，任何架構上的「隱形稅」都會被放大成明帳。

因此，官方的說法是「開發者呼声最高的功能之一」。不是我們想改，是跑在生產環境裡的人已經受不了了。

三、狀態沒有消失，它被移到了模型眼前

這裡有個必須講清楚的誤解。

協議無狀態，並不等於你的應用無狀態。

規範給出的替代方案叫顯式句柄。你的工具需要跨調用保留狀態？那就讓工具返回一個標識符，比如 basket_id，然後由模型把這個 ID 當參數帶回下一次調用。

在官方博客中，我認為這句話是整份文件中最有趣的一句：他們發現，這樣比將狀態隱藏在傳輸層中效果更好，因為模型能看見這個句柄，也能在工具之間將其串聯起來。

停一下想想這句話的分量。

過去的設計邏輯是：狀態是基礎設施的事，模型不該操心。現在的邏輯反過來了：狀態是模型推理鏈條的一部分，藏起來反而讓模型判斷失準。

隱藏狀態會讓模型變傻。這個結論不是從架構美學推出來的，而是從一年半的生產事故中總結出來的。

同樣的思路也應用於伺服器主動發起請求的路徑上。過去工具執行時需要向用戶詢問「確認刪除這 3 個文件嗎？」，依賴一條持續連接的 SSE 流將請求推回客戶端；無狀態化之後，這條流被取消，取而代之的是多輪請求（Multi Round-Trip Requests，簡稱 MRTR）。

機制並不複雜。伺服器返回一個「需要輸入」的結果類型，附上它要問的問題，再附上一段 requestState。客戶端收集完答案，帶著 inputResponses 和原封不動的 requestState 重新發送一次原始調用。由於所有續接所需資訊都包含在 requestState 中，即使這次重試落在另一台機器上，也能繼續進行。

Supabase 產品負責人 Inian Parameshwaran 說了句實在話：支援 elicitation 在他們的路線圖上掛了很久，但因為 Supabase MCP 本來就是無狀態運行的，一直無法實現。MRTR 之後就可以了，工具能在建專案前先確認成本，能在刪資料前先問一句。

這裡我要提一個規範文件沒重點講、但工程上一定會遇到的點：requestState 由客戶端保管並回傳，它天然處於信任邊界之外。伺服器若將其當作可信輸入直接反序列化，等於給自己開了一個缺口。簽名、加密、設置過期時間，這三件事我認為會很快成為社區的標準做法。這是我的判斷，而非規範要求。

四、擴展框架：協議開始學會「不長胖」

The second real bet is that the expansion framework has evolved from convention into system.

反向 DNS 命名、通過 extensions 映射做能力協商、獨立的 ext-* 倉庫配授權維護者、版本獨立於核心規範。聽起來很枯燥，但它解決的是所有成功協議都會遇到的病：核心越來越肥。

The two extensions have now been officially formalized.

MCP Apps 讓伺服器將互動介面直接傳送至對話中。不是純文字，也不是結構化 JSON，而是運行在沙箱 iframe 中的完整 HTML 介面。圖表、表單、選擇器都可以。關鍵設計在於工具需提前聲明 UI 模板，以便客戶端能預取，並在渲染任何內容前進行安全審查。介面上的操作仍透過普通的工具調用 JSON-RPC 通道進行。

任務：處理耗時任務。它從實驗性功能升級為官方擴展，生命週期已重新設計為無狀態：tools/call 傳回一個任務句柄，客戶端使用 tasks/get 進行輪詢，並搭配新的 tasks/update 和 tasks/cancel。

值得注意的是 tasks/list 已被刪除。理由很直接：沒有會話時，「列出所有任務」這個操作不再安全，你無法界定「所有」屬於誰。

這個擴展由 AWS 貢獻。Amazon 的 Agentic AI 副總裁 Swami Sivasubramanian 表示，新規範和無狀態核心已進入 Bedrock AgentCore。在微軟方面，Foundry 工程副總裁 Tina Schuchman 表示，MCP 讓他們從數十個整合擴展至數千個，Foundry toolbox 透過一個統一的 MCP 端點將工具聚合起來，集中管理治理、身份和可觀測性。

一個協議同時被 AWS、微軟、Google Cloud、Cloudflare 拿來當地基往上砌東西。這已經不是某家公司的插件規範了。

五、真正的痛點從來不是連接，是身份

官方博客中有一句誠實的自述：過去一年與實現者溝通下來，授權是他們花時間最多的地方。

This version adds six SEP authorizations, all unglamorous but necessary. The authorization server must return the iss parameter as per RFC 9207, and the client must verify it before exchanging the code—this closes the authorization server confusion attack. During dynamic registration, the client must declare application_type, and localhost callbacks for desktop and CLI applications are no longer arbitrarily rejected. Credentials are bound to the issuer that issued them and cannot be reused across authorization servers.

更具信號意義的是：動態客戶端註冊（DCR）已被正式棄用，方向指向客戶端 ID 元數據文檔（CIMD）。DCR 目前仍可使用，並保留向後兼容性，但未來版本將移除。

同一天，企業級託管授權擴展（EMA）轉為穩定版。這件事對企業 IT 的意義可能比無狀態還大。

在舊模型下，每位員工需為每台伺服器單獨授權一次。入職時需手動逐一連接各項服務。安全團隊無法執行統一策略，權限由每位使用者自行點選，缺乏集中控制與審計追蹤。更糟糕的是，工作帳號與個人帳號混用，沒有機制強制使用企業身份。

EMA 將企業自己的身份提供商轉變為決策方。底層採用 IdP 在單點登錄時簽發的 ID-JAG 断言，客戶端用它來交換 MCP 伺服器授權伺服器的存取權杖。用戶全程無需經過任何單一伺服器的同意頁。

Okta 是首個支援的 IdP，採用其 Cross App Access。客戶端側的 Claude 全系列和 VS Code 都已接入。伺服器側的 Asana、Atlassian、Canva、Figma、Granola、Linear、Supabase 已支援，Slack 正在進行中。Linear 工程負責人 Tom Moor 的評價頗為可愛：只需登入一次，所有 MCP 連接器便自動設定好，這實在太魔幻了。

魔幻的部分不在體驗，在治理。訪問決策終於回到了 IdP 管理台裡，一條審計鏈貫穿所有連接器。

但我必須把話說完整：無狀態和 EMA 解決的是身份與規模，不是 Agent 安全的全部。思科《2026 年 AI 安全現狀》報告裡那兩個數字一直掛在那兒，83% 的組織計劃部署 Agent 能力，只有 29% 覺得自己準備好了。提示注入、工具描述投毒、Agent 被當作橫向移動跳板，這些問題不會因為協議刪掉了會話而消失。

好消息是，Mcp-Method 和 Mcp-Name 上線後，網關執行策略的成本降低了。規範還要求伺服器拒絕標頭與主體不一致的請求，這堵住了此類路由與安全錯配的問題。這是防禦態勢的實質改善。但也就到此為止。

六、代價：這是一次破壞性變更，賬單已經開出

我不喜歡只講收益不講賬。

這一版屬於 breaking change 級別。Roots、Sampling、Logging 三個特性集體進入棄用狀態。舊的 HTTP+SSE 傳輸也已正式棄用。規範同時制定了一項正式的特性生命週期政策：Active 到 Deprecated 到 Removed，每一階段至少 12 個月。

還有些細碎但會咬人的：工具的輸入輸出 schema 現在支援完整的 JSON Schema 2020-12 詞彙表，oneOf、anyOf、條件都能用；而"資源未找到"的錯誤碼從自訂的 -32002 改成了標準 JSON-RPC 的 -32602。你要是把 -32002 硬編碼在程式碼裡，這行必須改。

遷移成本最重的地方，官方自己點明了：依賴會話標識符的開發者。

因此，時間表值得重述一遍。候選版於 5 月 21 日鎖定，至 7 月 28 日正式發布，中間留出整整十週供 SDK 維護者和客戶端實現者進行驗證。四個 Tier 1 SDK（TypeScript、Python、Go、C#）當天全部支援新版本，Rust SDK 為 beta。

十週的公開驗證窗口 + 12 個月的棄用過渡期 + 標準化 SEP 必須先在一致性測試套件裡有對應場景才能定稿。這三條加起來才是我眼裡這次改版最專業的部分。

它不是將破壞性變更粉飾過去，也不是把破壞性變更扔給社區自己扛。

一致性要求尤其關鍵。今後若想將新功能納入標準軌道，請先撰寫可測試的場景。這是將「設計意圖」與「實現事實」綁定在一起的做法，許多協議都是在吃過大虧後才學會的。

有意思的是，遷移居然還帶出了正向收益。開源框架 mcp-use 背後的 Manufact 首席技術官 Enrico Toniato 給了組具體數字：基於新的 SDK v2 做客戶端與伺服器拆分，包體積砍掉了大約 83%，速度快了 25%。

一次架構瘦身，順手把包也瘦了。這種事不常有。

七、我的判斷

那麼，怎麼看這次改版？

我的第一個判斷是：這是一次認錯，而且是漂亮的認錯。

MCP 最初的雙向有狀態設計，是圍繞本地場景長出來的。你的編輯器連著一個跑在本機的伺服器，握手一次維持一條連接，完全合理。問題出在遠程 MCP 起來之後，這套模型被拖進了雲環境，然後所有人開始為它打補丁。黏性會話是補丁，Redis 存 session 是補丁，為了 elicitation 掛一條長連接也是補丁。

當補丁多到一定程度，就該改地基了。協議共同發明人 David Soria Parra 表示，這一版收錄了過去 18 個月的教訓。核心維護者 Nick Cooper 講得更貼切：MCP 一歲半，正在吸收數十年 web 協議設計的經驗，變成一個更成熟的協議。

第二個判斷：這次改版真正的分水嶺意義，在於治理而不在技術。

時間線值得再核對一遍。2024 年 11 月 25 日，Anthropic 開源 MCP。2025 年 12 月 9 日，MCP 被捐贈給 Linux 基金會下新成立的 Agentic AI Foundation，這是一個定向基金，由 Anthropic、Block、OpenAI 共同發起，Google、微軟、AWS、Cloudflare、彭博提供支持。八個月後，第一個大版本落地。

一個由單一廠商發明的協議，在被交出去之後完成了它最痛的一次手術，而不是在交出去之後陷入委員會僵局。這件事本身就是對開放治理有效性的一次驗證。

從生態平台名單也能看出重心變了。Figma 講的是設計與代碼打通，Intuit 講的是要給一億消費者和企業客戶交付可信的財務智能體驗，Zoom 講的是把會議智能安全地送進 AI 平台。這些都不是開發者玩具的語言，是產品線的語言。

第三個判斷，也是我覺得最該說出口的：協議成熟是要付代價的，代價叫「沒脾氣」。

無狀態、可路由、可緩存、可追蹤。W3C Trace Context 現在透過 _meta 裡固定的鍵名傳遞，開箱即用，與 OpenTelemetry 分佈式追蹤相容。這些詞你曾在 HTTP、REST、gRPC 的演進史中全部見過。

MCP 正在變成一條你不會去談論的管道。就像沒人會討論今天的 TCP 有多激動人心。

這算好事嗎？我覺得算。數據層面的勝利從來不屬於最驚艷的那個設計，而屬於最不容易壞的那個。會話被刪除的那一刻，MCP 放棄了一部分優雅，換來了在輪詢負載均衡後面橫向擴展的能力。

代理的規模化，卡住的從來不是模型有多聰明，而是那些沒人想聊的問題：對話存哪裡、身份如何繼承、斷線後任務還在不在、一萬名員工連接一千台伺服器要點多少次同意按鈕。

這一版把這幾件事往前推了一大截。

至於興奮感，管道並不負責提供興奮感。它只負責在你不看它的时候，別漏。

Reference Source

Model Context Protocol 博客，《2026-07-28 規範》，2026 年 7 月 28 日。https://blog.modelcontextprotocol.io/posts/2026-07-28/
Model Context Protocol 博客，“企業管理授權：MCP 的零接觸 OAuth”，2026 年。https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/
Anthropic 的 Claude，"將 MCP 2026-07-28 帶入 Claude"，2026 年 7 月 28 日。https://claude.com/blog/bringing-mcp-2026-07-28-to-claude
MCP Servers 博客，《2026-07-28 MCP 規範：無狀態、可擴展的未來》，2026 年。https://blog.mcpservers.org/posts/mcp-spec-2026-07-28
Linux Foundation，"Linux Foundation 宣布成立 Agentic AI 基金會"，2025 年 12 月 9 日。https://linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
Anthropic，「捐贈模型上下文協議並成立具代理能力的人工智慧基金會」，2025 年 12 月。https://anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
Cisco，《State of AI Security 2026》，2026 年。https://blogs.cisco.com/ai/cisco-state-of-ai-security-2026-report
IT之家，《自問世以來最大更新：MCP 2026-07-28 規範發布，轉向「無狀態」核心》，2026 年 7 月 29 日. https://www.ithome.com/0/983/102.htm