MCP 規格轉為無狀態架構，Google 說明如何拿掉 Session 綁定
Google Cloud Blog · 2026-08-05
背景
Google Cloud 工程師 Kurtis Van Gent 與產品經理 Alan Blount 於 2026 年 8 月 5 日發文，說明 Model Context Protocol（MCP）在 2026-07-28 版規格中的重大改動：協定本身從有狀態（stateful）轉為無狀態（stateless）。在舊版協定下，客戶端與伺服器必須先完成 initialize/initialized 交握，並透過 Mcp-Session-Id 標頭把後續請求釘死在同一個伺服器實例上。這個設計在單機或長連線環境下沒有問題，但一旦部署到 Cloud Run、Kubernetes 這類會隨時擴縮、重啟 Pod 的環境，session 親和性（sticky session）就變成維運負擔，通常得額外接上 Redis 做 session 儲存。
新版規格把這個負擔整個拿掉。每一次請求都是自我描述（self-describing）的：協定版本、客戶端資訊與能力宣告改成透過請求上的 _meta 欄位隨請求攜帶，而不是只在建立連線時交換一次。這代表任何一個伺服器實例都能獨立處理任何一個請求，不需要記得「這個 session 之前說過什麼」。
核心改動
規格更新拆成幾個具體的 SEP（Spec Enhancement Proposal，MCP 治理流程中用來提案並追蹤規格變更的機制，性質類似其他協定的 RFC）。SEP-2243 針對 HTTP 傳輸做標準化，新增 Mcp-Protocol-Version、Mcp-Method、Mcp-Name 這幾個標頭，讓 代理伺服器、閘道與負載平衡器不需要解析 JSON-RPC 內容本身，光看 HTTP 標頭就能做路由、限流與稽核。一個典型請求長這樣：
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: searchSEP-2322 則處理原本靠長連線維持的「伺服器對客戶端」請求，例如 elicitation（伺服器向使用者要求補充輸入的機制）。做法是把對話狀態序列化成 requestState payload 交還給客戶端保管，客戶端補齊答案後用一般的請求-回應（而非常駐串流）方式送回，由任何一個伺服器實例接手處理，這個模式在 Cloudflare 的實作說明中稱為 Multi Round-Trip Requests（MRTR）。SEP-2663 新增的 Tasks 擴充則讓長時間執行的操作可以立即回傳一個 taskId，實際處理在背景進行，客戶端之後憑 ID 輪詢結果，不必整個請求周期都占著連線。
影響範圍
對 SDK 開發者而言，官方 TypeScript SDK 已釋出對應 v2 版升級指南，Go SDK 也同步提供無狀態版本的範例；GitHub 上的 MCP Server 產品（如 GitHub 官方的 MCP Server）已宣布支援新版規格。授權流程也一併調整：新規格優先使用預先註冊的客戶端，其次是 Client ID Metadata Documents，原本的 Dynamic Client Registration 則被標記為棄用路徑。
這項改動的下游效應在同一週由 Cloudflare 具體示範：其重寫的 MCPv2 讓 MCP Server 可以直接跑在 Cloudflare Workers 上，不再需要靠 Durable Objects 維持 session 狀態，官方 SDK 也新增了 createMcpHandler 這個介面，把原本內建在 Cloudflare Agents SDK 裡的無狀態伺服器樣板收斂進標準 SDK。一個最小化的無狀態伺服器大致如下：
const server = new McpServer({
name: "hello-server",
version: "1.0.0",
});
server.registerTool("hello", {...}, async ({name}) => ({...}));
export default {
fetch(request, env, ctx) {
return createMcpHandler(createServer)(request, env, ctx);
},
}對於既有的 MCP 部署,這代表原本因為 session 親和性而必須維持的黏性負載平衡設定與 Redis session store 可以逐步移除，Pod 重啟或擴縮時的連線也能無縫轉移到其他實例，不會因為某個節點消失而讓進行中的工具呼叫失敗。
Cloudflare Agents Week 總盤點：從 MCPv2 到 Kitesurf 瀏覽器的一週密集發布
Cloudflare Blog · 2026-08-10
背景
Cloudflare 在 2026 年 8 月 3 日至 7 日舉辦「Agents Week」，並於 8 月 10 日發出總結文章，彙整這一週內圍繞「智能代理（Agent）基礎設施」發布的一系列產品與功能。主軸是把 Cloudflare 既有的邊緣運算平台（Workers、Durable Objects、AI Gateway）重新包裝成一套針對 Agent 工作負載設計的完整堆疊，涵蓋運算環境、身分存取、開發流程與商業化元件。
核心改動
週一發布的 @cloudflare/computer 是專為 Agent 設計的新執行環境，能依任務動態選擇合適的沙箱；同時 Workers RPC 打通了 Python 與 JavaScript 之間的跨語言呼叫，Workers/Containers 也補上 TCP 與 gRPC 支援，鎖定即時語音類 Agent 的基礎設施需求。週二的重點是 Agent Development Lifecycle（ADLC），把傳統 SDLC 的概念延伸到「由 Agent 參與開發流程」的場景，搭配同步發布的 Cloudflare Agents 生產平台（含追蹤與人工介入審核機制）與 Workers 本地端追蹤工具。
週三發布的 Agent Access Model 定義了 Agent 存取資源時的權限框架，這與週四的 MCPv2 互相呼應：MCPv2 是 Model Context Protocol 2026-07-28 規格在 Cloudflare 平台上的具體實作，拿掉了原本靠 Durable Objects 維持的 session 狀態，讓 MCP Server 可以直接以無狀態方式部署在 Workers 上。同一天發布的 WriteGuard（私有 Beta）則是針對 MCP Server 的細粒度寫入控制，用來限制 Agent 透過 MCP 工具能執行哪些寫入操作。
- WebMCP（預覽版）：讓一般網站能被 Agent 直接發現並呼叫其功能介面
- Kitesurf：Agent 優先設計的瀏覽器，執行在 Cloudflare Workers 的
V8isolate 中 - Cloudflare AI Search：可直接對檔案與網站建立索引的 Agent 導向搜尋引擎
- Cloudflare Wallets：供 Agent 執行交易的支付機制
影響範圍
週五則把 Workers AI 與 AI Gateway 統一到單一 binding 與控制平面，簡化了原本需要分別設定推論服務與流量閘道的架構。整體來看，這一週發布的項目彼此有明確的依賴關係：MCPv2 提供無狀態的協定基礎，Agent Access Model 與 WriteGuard 在其上疊加權限與稽核層，Cloudflare Agents 平台再把追蹤與人工審核收斂成單一產品介面，Kitesurf 與 WebMCP 則是把這套堆疊延伸到瀏覽器端與一般網站的整合場景。對已經在 Workers 上跑 MCP Server 的團隊，MCPv2 的無狀態部署模型是這波發布中最直接可用的基礎設施變更。
Cosmos DB 啟用 RBAC 後全面 403：五種常見設定錯誤的排查案例
Microsoft DevBlogs (Azure Cosmos DB) · 2026-08-10
原本的問題
Azure Cosmos DB 產品經理 Sudhanshu Khera 與專案經理 Iria Osara 在 2026 年 8 月 10 日發文，整理了開發者在把應用程式從金鑰驗證切換到 Azure RBAC（角色型存取控制）時最常撞到的一類故障：切換後應用程式對 Cosmos DB 的所有存取都回傳 403，而錯誤訊息本身看起來像是「權限完全沒生效」。文章的切入點是釐清一個常被誤解的前提：Cosmos DB 的 RBAC 分成控制平面（control plane）與資料平面（data plane）兩層，兩者用的是完全不同的角色定義，混用是最常見的故障根因。
文章列舉了五種具體的錯誤設定情境。第一種也是最常見的：開發者在 Azure Portal 幫身分指派了 Contributor 這類管理層級的角色，以為這樣就能讀寫資料，但 Contributor 屬於控制平面角色，只能管理帳戶、資料庫等資源本身，完全不涉及資料存取，實際呼叫資料 API 時一樣會被判定為未授權。
採用的方法
第二種情境是角色指派給了開發者自己的身分做本機測試，卻忘了同時指派給應用程式在雲端執行時使用的受控識別（managed identity），於是「本機測試正常、部署到正式環境就壞掉」。排查方式是回頭核對應用程式實際執行時使用的 principalId，確認角色指派的對象與這個 ID 一致。第三種是授權範圍設得太窄：角色只指派在單一容器層級,但應用程式其實會存取同帳戶下多個資料庫或容器，超出範圍的路徑一樣回 403；文章建議除錯期間先把範圍放寬到整個帳戶層級（/），確認邏輯正確後再收斂範圍。
第四種是權限傳播延遲：剛建立的角色指派需要一段時間才會在所有服務節點生效，太快重試會誤判為設定錯誤，文章建議等待 1 到 2 分鐘再測試。第五種也是文章特別強調的陷阱：帳戶層級設定了 disableLocalAuth: true 想強制走 RBAC，但程式碼裡仍有部分路徑使用連線字串或金鑰驗證,這些路徑會直接被拒絕,而且往往只在某些不常跑到的程式碼分支才會觸發，不容易第一時間發現。文章特別指出：403 在這個情境下代表「身分驗證成功、但授權失敗」，也就是系統認得這個呼叫者是誰,只是它沒有做這件事的權限——這和驗證失敗的 401 是完全不同的故障類型,混淆兩者會讓排查方向整個錯開。
實際效果
作者建議的修復流程是分階段進行,而不是一次切換：先用 az cosmosdb sql role assignment create 這類指令為應用程式的身分建立資料平面角色指派（例如內建的 Cosmos DB Built-in Data Contributor，涵蓋容器與項目層級的建立、讀取、查詢、變更摘要讀取等資料操作)；接著把程式碼改用 DefaultAzureCredential 取得的 TokenCredential，而不是連線字串。第三步是在金鑰仍然保留可用的狀態下部署並驗證讀寫功能是否正常，只有在確認以身分為基礎的存取完全運作後,才進到最後一步把 disableLocalAuth 設為 true 正式關閉金鑰驗證。
這個順序的用意是把問題隔離到單一設定層：如果在金鑰仍然開啟時測試就失敗，代表問題出在角色指派或範圍；如果直到關閉金鑰那一步才出錯，代表問題在於程式碼裡還有沒改乾淨的金鑰驗證路徑。相較於把 RBAC 設定與金鑰停用一次做完再回頭大海撈針，這種分階段驗證能把每一種故障情境獨立驗證,對應到文章列出的五種錯誤設定中的哪一種。
原始來源：Microsoft DevBlogs、Azure Cosmos DB Data Plane Security Reference