MCP 2026-07-28：無狀態協定對 B2B 代理部署的意義

為什麼這次發布改變了部署的算式

模型上下文協定（MCP）是一個用於將 AI 代理連接到外部系統的開放標準。在 2026 年 7 月 28 日，它推出了自問世以來最大的一次修訂——一個候選發布版，讓協定層變成無狀態、引入一級的擴充（extensions），並棄用了三個在正式環境中增加了複雜度卻沒有帶來相應價值的功能。

對於在 B2B 代理系統背後部署 MCP 伺服器的團隊來說，實際影響很具體：你不再需要黏性會話、共享會話儲存，或具備會話感知能力的負載平衡器。代理在多次工具呼叫之間所需的狀態，變成一個明確的 handle——對模型可見、可在日誌中稽核，並可被中介層快取。本文將逐一說明這些對 B2B 部署至關重要的變更，以及它們如何對應到我們已經在交付的 MCP 模組模式。

無狀態的協定層

最引人注目的變更：initialize / initialized 交握以及 Mcp-Session-Id 標頭被移除了。請求現在是自足的。協定版本、客戶端資訊和能力（capabilities）都在每次請求的 _meta 中傳遞，而不是放在伺服器必須記住的協商會話裡。

這在 B2B 部署中消除了什麼：

• 黏性會話負載平衡器。 遠端 MCP 伺服器可以放在單純的輪詢（round-robin）負載平衡器後面。任何伺服器實例都能處理任何請求，因為解讀請求不需要任何伺服器端狀態。
• 共享會話儲存。 如果你今天要水平擴展，每個 MCP 伺服器實例都需要存取相同的會話狀態——通常是 Redis 或資料庫。無狀態協定移除了這個依賴。
• 會話重播基礎設施。 當會話在工作流程進行到一半時中斷，客戶端必須重新初始化並重新建立上下文。無狀態協定沒有可中斷的會話；每次請求都帶著它所需的一切。

部署的樣貌變得更簡單：一組無狀態的 MCP 伺服器實例放在負載平衡器後面，實例之間沒有共享狀態層。這與任何無狀態 HTTP API 的樣貌相同——久經考驗、可觀測，且擴展成本低廉。

有狀態工作流程的明確 handle 模式

無狀態並不代表狀態消失。跨越多次工具呼叫的工作流程——一次 RFQ 收單、一次報價協商、一次庫存保留——仍然需要連續性。候選發布版以明確 handle 模式取代隱藏的會話狀態：一個工具鑄造出一個 handle（一個 order_id、一個 quote_id、一個 basket_id），模型在後續呼叫中把它當作一個普通參數傳回。

對 B2B 部署而言，這是一項有意義的轉變，原因有三。

狀態對模型可見。 今天，會話狀態存在於 LLM 從未看見的傳輸中繼資料裡。有了明確 handle，模型會在其推理中持有並引用該 handle。當模型呼叫 get_quote(quote_id="q-7f3a") 時，它知道自己正在操作哪一份報價。這提升了多步驟工作流程中工具選擇的準確度。

狀態可在日誌中稽核。 每次請求都在請求主體中攜帶其 handle，而不是在應用程式日誌器會剝除的標頭裡。稽核軌跡只要讀取請求參數，就能在任何時間點重建完整的工作流程狀態——不需要與會話儲存日誌做關聯比對。

狀態可被中介層快取。 因為 handle 是請求的一部分，閘道或快取層可以用它作為鍵。列表與資源結果帶有 ttlMs 與 cacheScope 欄位，因此帶有穩定 handle 的目錄查詢可以直接從快取提供，而不必觸及上游系統。

這如何對應到一個 RFQ 工作流程

設想一個橫跨五次工具呼叫的報價工作流程：建立請求、搜尋目錄、產生報價、保留庫存、套用定價層級。在以會話為基礎的協定下，這五次呼叫共享一個伺服器端會話。在明確 handle 模式下：

1. create_request(buyer_id, line_items) → request_id="r-1042"
2. search_catalog(request_id="r-1042", query="industrial pump 220V")
3. generate_quote(request_id="r-1042", supplier_ids=["s-12", "s-19"])
       → quote_id="q-7f3a"
4. hold_availability(quote_id="q-7f3a", hold_duration="48h")
       → hold_id="h-3391"
5. apply_pricing_tier(quote_id="q-7f3a", tier="volume-3")

每次呼叫都攜帶它所需的 handle。沒有任何伺服器在呼叫之間記住任何東西。如果負載平衡器把第 4 次呼叫路由到與第 3 次不同的實例，它照樣運作——handle 就在請求裡。如果稽核團隊一週後需要重建這個工作流程，請求參數中的 handle 就能講出完整的故事。

擴充：一級且獨立版本控管

候選發布版將**擴充（extensions）**引入為一級概念。擴充擁有反向 DNS 識別碼（例如 com.example.workflow）、擁有自己的 ext-* 儲存庫、有委派的維護者，並獨立於核心協定進行版本控管。

前兩個擴充很具體：

• MCP Apps — 在沙箱化 iframe 中交付的伺服器渲染 HTML UI。MCP 伺服器可以隨附一個由客戶端渲染的 UI，讓人在迴路（human-in-the-loop）的核准介面成為可能，而客戶端不必自建前端。
• Tasks — 帶任務 handle 的長時間執行工作。工具可以立即回傳一個任務 handle，客戶端再輪詢完成狀態，而不必讓連線保持開啟數分鐘。

對 B2B 部署而言，MCP Apps 在人必須先核准某筆交易、代理才能繼續進行的場景中很重要——超過門檻的採購訂單、帶有非標準折扣的報價。核准介面可以隨 MCP 模組一起交付，而不需要另一套獨立的前端。Tasks 則對超過單次請求逾時的工作流程很重要：一份需要 90 秒才能產生的供應商報價、一次執行數分鐘的目錄同步。

棄用：Roots、Sampling、Logging

三個功能被棄用（12 個月內僅標註；移除需要另一套標準流程）：

• Roots → 由工具參數與資源 URI 取代。Roots 原本是讓客戶端告知伺服器檔案系統位置的一種方式；相同的意圖現在改以讀取檔案的工具參數來表達。
• Sampling → 由直接整合 LLM 供應商 API 取代。需要進行 LLM 呼叫的伺服器改為直接向供應商發出呼叫，而不再請求客戶端執行一次採樣往返。
• Logging → 由 stderr 與 OpenTelemetry 取代。伺服器日誌改用標準行程輸出與分散式追蹤，而非 MCP 的日誌通道。

Logging 的棄用對 B2B 部署最為相關。稽核日誌模式——每次工具呼叫都記錄請求、回應、延遲與結果——現在與 OpenTelemetry 對齊，而非某個協定專屬的日誌通道。這意味著 MCP 伺服器日誌能與既有的可觀測性管線（Datadog、CloudWatch、Honeycomb）整合，而不需要自訂傳輸。

可路由、可快取、可追蹤

三項影響正式環境營運的新增功能：

• Mcp-Method 與 Mcp-Name 標頭讓閘道路由無需檢視主體。閘道可以在標頭層級依方法與工具名稱路由——路由層不必解析 JSON。
• **列表／資源結果上的 ttlMs 與 cacheScope**為中介層提供了標準的快取契約。一個目錄列表回應可以宣告 5 分鐘的 TTL，路徑上的任何閘道都能遵守。
• W3C Trace Context 傳播已為 OpenTelemetry 相容性提供文件。由代理客戶端啟動的追蹤會穿過 MCP 伺服器並進入上游系統呼叫，因此單一 RFQ 工作流程會以一條追蹤的形式，貫穿它所觸及的每一個系統。

對於一個為 NetSuite、HubSpot 和某個供應商目錄運行 MCP 伺服器的 B2B 部署而言，這意味著：閘道可以依工具名稱路由而不必解析主體、可以在宣告的 TTL 內快取目錄回應，並可在單一 span 樹中，把一次報價請求從代理追蹤到 ERP、再追蹤到供應商 API。

針對一對多樣貌的授權強化

候選發布版針對 B2B 代理系統實際採用的部署樣貌，改進了 OAuth 與 OpenID Connect：一個客戶端（代理）連接到多個伺服器（NetSuite、HubSpot、BigCommerce、某個供應商目錄）。權杖刷新、範圍（scope）管理和多伺服器憑證處理都在規格中加以處理，而非留給每個整合各自獨立解決。

這很重要，因為 B2B 代理系統並不只連接一個系統。一個典型的 RFQ 代理會連接到 ERP（NetSuite）、CRM（HubSpot）、電商平台（BigCommerce），以及兩三個供應商目錄——每個都有自己的 OAuth 流程、權杖存續期與範圍集合。協定現在為管理這種複雜度提供了標準模式，而不是由每個 MCP 模組各自實作自己的憑證生命週期。

對既有 MCP 模組會有什麼改變

如果你已經在交付 MCP 模組——例如那個 38 個工具的 RFQ 處理器模式，其中工具透過 MCP_CONFIGURATION 註冊，領域 mixin 在共享的 GraphQL 客戶端之上組合——無狀態協定改變的是部署，而不是模組程式碼。

模組的工具註冊、輸入輸出 schema、速率限制與稽核日誌都維持不變。改變的是：

• 啟動時不再有會話初始化。 模組不再參與 initialize 交握。它接收帶有 _meta（攜帶協定版本與能力）的請求，並回應。
• 有狀態的工具鑄造 handle。 如果某個工具今天依賴伺服器端會話來追蹤多步驟工作流程，它應該鑄造一個明確 handle 並回傳。客戶端在下一次呼叫時把它傳回。對一個 RFQ 處理器而言，request_id、quote_id 與 hold_id 本來就是 handle——這個模式對該領域來說很自然。
• 日誌改用 OpenTelemetry。 如果模組透過 MCP 日誌通道記錄，請遷移到 stderr 與 OpenTelemetry span。稽核內容（請求、回應、延遲、結果）維持不變；改變的是傳輸。
• 快取是宣告式的。 列表與資源端點可以在其回應上宣告 ttlMs 與 cacheScope，讓中介層不必猜測就能快取。

對 B2B 團隊的結論

無狀態協定減少了以 MCP 為基礎的代理部署所需的基礎設施。你用請求參數中的明確 handle 換掉了黏性會話與共享會話儲存——這是一筆讓系統更容易擴展、更容易稽核、並在標準工具中更可觀測的交易。

如果你的團隊正在為一項以 MCP 為基礎的代理部署劃定範圍，7 月 28 日的候選發布版就是應該鎖定的版本。從一開始就為明確 handle 做設計，可以避免日後從以會話為基礎的狀態進行遷移。

---

一家運行 NetSuite、BigCommerce 和三個供應商目錄的經銷商，會得到一個代理：它透過電子郵件或入口網站接收 RFQ，對照目錄圖譜解析產品與替代品，依客戶層級定價，以到期時限保留庫存，並把已接受的報價寫回 NetSuite——每一步都有日誌記錄。該建置屬於四步方法中的第 2-3 階段，通常在 5 到 8 週內上線。

申請一個劃定範圍的建置。 為期一週的探索。你會得到一份系統盤點、工作流程地圖與固定範圍——無論你最終是否與我們一起建置。