MCP 為什麼改成無狀態？2026-07-28 規格逐項拆解，以及它和 A2A 的分工
Model Context Protocol（MCP）在 2026 年 7 月 28 日發布的規格版本，做了一件範圍很大的事：把整個協定改成無狀態。initialize 握手被移除，協定層的 session 與 Mcp-Session-Id 標頭一起被拿掉，每一個請求從此自我完備、彼此獨立。
這不是一次相容性修補，是協定核心的置換。官方版本頁把 2026-07-28 標為目前的 current，並註明帶握手的舊版是 2025-11-25 以前的版本。本文逐項整理這一版改了什麼、代價落在哪裡，以及它在整個 Agent 協定版圖（含 A2A）裡的位置。
規格細節我們已回查 MCP 官方的 Versioning 與 2026-07-28 Key Changes 兩頁核對；實務觀察與踩坑經驗來自六支公開技術影片，出處與證據強度見文末。
一、被移除的是什麼：兩個提案，一個結構性改變
官方 changelog 的兩項主要變更如下：
SEP-2575：移除 initialize / notifications/initialized 握手。協定版本與客戶端能力改由每一個請求自己攜帶。同一提案還新增 server/discover，伺服器必須實作，用來公告支援的協定版本、能力與身分。
SEP-2567：移除協定層 session 與 Mcp-Session-Id 標頭。tools/list、resources/list、prompts/list 這些清單端點不再隨連線而異；伺服器若需要跨呼叫的狀態，改用「伺服器發出的明確 handle」，當成一般的工具參數傳遞。
為什麼要改：舊設計在水平擴充下會結構性失敗。 舊流程是客戶端先送 initialize，伺服器產生一組 session ID 回傳，後續每個請求都要帶著它。問題在於那組 session 存在某一台機器的記憶體裡——一旦前面掛了負載平衡器、後面跑兩個以上的實例，下一個請求輪到另一台，那台沒聽過這個 session，直接回 400 session not found。同樣的失敗也發生在 pod 被回收、autoscaler 縮容的時候。
業界既有的兩種解法——sticky session、或拉一個共用 Redis 存 session——都有效，但兩者本質上都是基礎設施在替一個協定決策做補償：多一層黏著、多一次網路往返、多一筆帳單。新規格的做法是不再要求補償。
改完之後：負載平衡器回到最普通的輪詢，任何實例都能回答任何請求；某台掛了換下一台，客戶端不會察覺。在 Cloudflare Workers、Google Cloud Run 這類環境裡，伺服器不需要撐著連線 24 小時不睡，沒有流量時可以縮到零。Better Stack 引述 Cloudflare 的說法是「MCP 不再需要 Durable Objects 才能講這個協定」——此句為轉述，要引用請回查 Cloudflare 官方公告。
二、最常見的誤讀：無狀態協定不等於無狀態應用
這一版最容易被讀錯的地方，是把「拿掉 session」讀成「不需要儲存」。
被移除的是協定層的 session，不是狀態本身。 一個要查訂單、跑部署的 MCP server 本來就有應用狀態，那些不會消失。新規格的處理方式是：伺服器發一個明確的 handle（例如 project_id），存進共用儲存，由模型在每一次呼叫時把它當成一般工具參數帶回來。
差別在於誰在記、記得明不明講：以前是傳輸層隱式地幫你記，換一台機器就沒了；現在是應用層顯式地存、顯式地傳。照字面把共用儲存也一起刪掉，會刪到還需要的東西。
三、代價：相容性，以及斷掉就沒了的串流
無狀態不是免費的，這一版有兩筆明確的成本。
第一筆是串流可恢復性。 SSE 串流的 Last-Event-ID 與 event ID 被整組移除，訊息重送機制不再存在。以前串流斷掉還能接回去，現在斷了就是掉了——客戶端必須用一個新的 request ID 重送整個請求。續傳的責任從協定推回給客戶端。
第二筆是向後相容性，而這一筆比較貴。 Theo（t3.gg）在影片中指出，新規格不向後相容：舊的客戶端實作預期的是一條綁定的有狀態連線，新規格正好相反。他的判斷是，MCP 原本的價值就在於「一個簡單、大家都支援的標準」，而現在兩個都宣稱「支援 MCP」的東西，可能完全接不起來。
Atef Ataya 撞到的是同一件事的實務版：新版 SDK 的客戶端預設仍走舊方言，必須自己加一行設定才會走新規格。他說這是刻意的——生態正在轉換期，SDK 不想弄壞舊伺服器。代價是他第一次執行就失敗，花了一小時才定位。
實務上的順序建議：先確認客戶端在哪一版，再處理伺服器。 伺服器有棄用窗口保護，客戶端沒有。
四、人類確認的機制被重寫：從長連線改成多回合請求
舊規格裡，一個危險工具（例如「部署到正式環境」）要向使用者取得確認時，伺服器得撐著一條線去問。這個設計有一個明確的失效模式：線斷掉的時候，等於沒有人否決。
在 Atef Ataya 的示範裡，斷線的結果是那次部署在沒有任何人確認的情況下執行了，記錄上寫著 confirmed_by_user: false。一條死掉的連線被讀成了一聲「好」。
新規格以 MRTR（Multi Round-Trip Requests，SEP-2322） 取代：伺服器回傳一個 resultType 為 input_required 的結果，把需要補的東西放在 inputRequests 裡，然後關閉連線；客戶端取得答案後，帶著 inputResponses 重送同一個請求。沒有連線需要一直開著，也沒有問題會在斷線時消失。
舊版由伺服器主動發起的 roots/list、sampling/createMessage、elicitation/create，全部被這一個模式收掉。
這一項的意義不在效能，在於把「沉默等於同意」這個預設從架構裡拔掉。
五、棄用時程：哪些有窗口，哪些直接消失
官方在這一版同時採用了「功能生命週期與棄用政策」，明訂棄用窗口至少十二個月。
Deprecated，有十二個月以上窗口：Roots、Sampling、Logging（SEP-2577）
Deprecated，重新歸類：HTTP+SSE 傳輸（SEP-2596）
直接移除，沒有窗口：ping、logging/setLevel、notifications/roots/list_changed（SEP-2575）
注意最後一項與第一項的差別：被棄用的是 Logging 這個能力，被直接拿掉的是 logging/setLevel 這個方法，兩者分屬不同提案。日誌層級改為每個請求以 _meta 的 io.modelcontextprotocol/logLevel 指定。
其餘變更中，兩項對維運與閘道層有直接影響：Streamable HTTP 的 POST 請求現在必須帶 Mcp-Method 與 Mcp-Name 標頭（SEP-2243），閘道、rate limiter 與防火牆不必再拆開整包 JSON 才知道這是什麼請求；清單型回應則必須帶 ttlMs 與 cacheScope（SEP-2549），前者是新鮮度提示，後者標明 public 或 private，決定共用中介是否可以快取。
六、MCP 只是三類協定的其中一類：A2A 在哪個位置
把視野拉大一層。Google AI/ML 總監 Saurabh 在 GleanGo 2026 受訪時，把目前幾乎每週都在冒出來的 Agent 協定分成三類：
連接工具與其他 Agent — A2A 與 MCP。他的說法是，這兩個是「活下來的那兩個」。
內容層／程序知識 — OpenAI 的 AGENTS.md、Anthropic 的 Skills 這一類，負責把「該怎麼做」餵給 Agent。
Agent 連接外部系統 — 支付、商務、UI 等，這一類最雜也最大。
他的結構性判斷是這些協定會收斂。他舉的例子是——依他的說法——IBM 原本有一個與 A2A 對等的協定，後來兩邊合併並捐給了 Linux Foundation（此節屬受訪者口述，我們未獨立查證）。他預期這種合併會愈來愈多，但「協定版圖穩定下來還要一段時間」。
同一場訪談裡他點出的落地瓶頸更值得記：傳輸層其實已經解決得差不多了，卡住多 Agent 落地的是語意層。 你的 Agent 對「客戶」的定義，可能和另一個 Agent 不一樣；兩邊認證正常、API 互通、對話順暢，最後答案還是錯的。這需要各自的本體論（ontology）能對得起來，不是換一個協定能解決的問題。
MCP 與周邊機制怎麼分工，IBM Technology 在 9 月初的影片用一個網頁噴 500 錯誤的情境切得很清楚：
Skill 給步驟與判斷：先看錯誤率、再看最近的部署、什麼時候該停手交給人。
MCP 給對外的手：讓 Agent 真的連得到日誌與儀表板，把錯誤率讀出來。
RAG 給查得到的知識：這個系統平常長什麼樣、依賴哪些服務。
記憶給累積的經驗：以前出過什麼事。
Skill 會叫 Agent 去看錯誤率，但沒有 MCP，它碰不到那個儀表板。四者不互相取代。
七、分析：協定變簡單了，成本歸因沒有
以上都是協定層的進展。但對實際在付帳單的團隊來說，這一版沒有碰到另一個更急的問題。
KliqueAI 在一支討論 LLM Gateway 的影片裡做了一個值得記的區分：閘道不是控制平面。 在模型呼叫前面放一個 gateway，解決的是「六個端點變一個」「金鑰集中管理」——這些都是真實的價值。但它留下三個問題沒解：
gateway 自己又發了一套 API key，於是有兩套身分要管；
預算只算得到「租」來的模型，算不到自己買的機器；
而且沒有任何機制強迫大家一定要走它。
該片對現況的歸納是：每一種公司資源都有天花板——運算有配額，儲存有配額，雲端帳號有預算和告警；Token 有的是一張信用卡和一個希望。 它描述的失效場景是：一個自主 Agent 在週六進了迴圈，每一輪都在燒 token，燒了兩天沒有人看；帳單三十天後才到，財務問「誰花了什麼」而沒有人答得出來——因為架構裡從來沒有一個地方，是設計來回答這個問題的。
一句話總結該片的判斷：大家都在做路由，幾乎沒有人在做決定。
這兩件事的時間尺度不同，值得分開處理。 無狀態化把 MCP 變回一個普通的 HTTP 服務，是工程債的清償，有至少十二個月的窗口；A2A 與三類協定如何收斂，是未來一兩年的事。但「誰在花錢、花在哪個模型上」是今天就會寄帳單過來的問題，而它不會因為協定變簡單而自己變透明——前者是別人幫你修好的，後者要自己在架構裡留一個位置。
FAQ
Q1：MCP 改成無狀態之後，既有的 server 會馬上壞掉嗎？
不會馬上。官方功能生命週期政策訂的是「至少十二個月」的棄用窗口。但 ping、logging/setLevel、notifications/roots/list_changed 是直接移除，不在窗口保護範圍內。另外要注意順序：依 Atef Ataya 的實測，新版 SDK 的客戶端預設仍走舊方言，要自己加一行設定；Theo（t3.gg）則指出新規格不向後相容，兩個都宣稱「支援 MCP」的工具可能完全接不起來。真正該先確認的是客戶端在哪一版。
Q2：A2A 和 MCP 是競爭關係嗎？該選哪一個？
依 Saurabh 在 GleanGo 2026 的說法，兩者同屬「連接工具與其他 Agent」這一類，有重疊但回答的問題不同，而且他預期協定版圖會逐步收斂。務實的做法是不要為了押寶單一協定把系統寫死，把對外整合抽成可替換的一層。
Q3：多 Agent 架構最大的坑是什麼？
同一場訪談指出是語意層，不是傳輸層。兩邊認證正常、API 互通，但對同一個名詞的定義不同，最後答案仍然是錯的。這需要各自的本體論能對得起來。
Q4：已經有 LLM Gateway 了，還需要別的東西嗎？
閘道是必要的第一步，這一步不能跳——先把多個端點收成一個、把用量與交易明細變成查得到的東西。跳過它直接談治理，會發現連要治理的那個數字都還沒生出來。第二步才是控制平面：要能回答「誰花了多少」，關鍵是每一次模型呼叫都帶著公司原本就在用的身分，而不是 gateway 自己另外發的一把 key。差別在於歸因是架構的副產品，還是一個要另外做的專案。
Q5：這篇的資訊可以直接當成規格依據嗎？
規格細節（版本編號、SEP 編號、新增與棄用清單）我們已回查 MCP 官方規格的 Versioning 與 2026-07-28 Key Changes 兩頁，內容一致。但影片作者的示範情境、實作細節與 Cloudflare 相關轉述，我們未獨立重現。要動到正式架構決策前，請直接讀官方規格與各雲端供應商自己的公告。
資料來源聲明
本文為官方規格文件與多支公開影片的綜合整理與重新論述，非任一支影片的逐字翻譯。
官方規格（2026-09-08 查閱）：
MCP 規格版本頁（確認 2026-07-28 為 current、2025-11-25 以前為握手版）：https://modelcontextprotocol.io/specification/versioning
MCP 2026-07-28 Key Changes（SEP-2575／2567／2322／2549／2577／2596／2243、Mcp-Method 與 Mcp-Name 標頭、ttlMs 與 cacheScope、至少十二個月棄用窗口）：https://modelcontextprotocol.io/specification/2026-07-28/changelog
影片素材（觀看數為 2026-09-08 素材篩選當下的擷取值，同日稍後重抓略有增減，以下一律採篩選當下的數字，並取小數點後一位、無條件捨去）：
《MCP Was Wrong From The Start (They Just Fixed It)》— Better Stack，2026-08-08，約 17.2 萬次觀看。https://www.youtube.com/watch?v=f4mI3d-nTrI
《MCP Just Went Stateless. Your Server Is Now Legacy.》— Atef Ataya，2026-08-16，約 16.6 萬次觀看。https://www.youtube.com/watch?v=8UC0C-IJZ7U
《Did Anthropic finally fix MCP?》— Theo - t3․gg，2026-08-08，約 10.3 萬次觀看。https://www.youtube.com/watch?v=gVfEtktkvnE
《Agentic AI Stack: Where Google, Glean, MCP and A2A Are Heading》— The Ravit Show，2026-08-29，約 4.5 萬次觀看。受訪者為 Google AI/ML 總監 Saurabh。https://www.youtube.com/watch?v=CPrQutbsqGc
《Skills vs MCP vs RAG vs Memory: What AI Agents Need to Know》— IBM Technology，2026-09-03，約 9.8 萬次觀看。https://www.youtube.com/watch?v=X4FVEEegCbk
《LLM Gateway vs AI Control Plane (Explained)》— KliqueAI，2026-08-16，約 3.2 萬次觀看。https://www.youtube.com/watch?v=0tVweBmCgkc
聲明： 規格細節已回查上列官方文件；影片作者的示範、實作細節與轉述內容（含 Cloudflare 相關說法）我們未獨立重現，A2A 與協定收斂的判斷屬受訪者個人觀點。本文為技術趨勢整理，不構成採購建議或效能承諾。
延伸閱讀
立即行動
想先把第一步做完？到 AI Token King 看方案——用同一把 key 接多家模型，用量、餘額與交易明細三者皆可查詢與匯出。
留言