架構

WebSocket 與 SSE 用於代理通訊：MCP 為何兩者皆不選

作者：IdeaBosque最後更新：2026年9月11日

關鍵要點

MCP 2026-07-28 規範棄用了 HTTP+SSE 並以 Streamable HTTP 取而代之 —— 而非 WebSocket —— 因為無狀態伺服器可以使用標準 HTTP 基礎設施（WAF、負載平衡器、認證代理）而無需管理持久連線（MCP specification）。
A2A 使用 JSON-RPC 2.0 over HTTP 配合 SSE 進行任務輸出串流傳輸 —— 傳輸是管道工程；協定語意（任務生命週期、INPUT_REQUIRED 狀態）才是使代理間通訊有效運作的關鍵（A2A protocol）。
CVE-2026-16496（CVSS 10.0）在 Terraform MCP 中利用了有狀態 SSE 傳輸模式 —— 被竊取的工作階段 ID 讓攻擊者可以使用其他使用者的憑證執行工具呼叫。無狀態傳輸在架構層面消除了攻擊面，而非在修補層面（NVD）。
WebSocket 可作為自訂 MCP 傳輸使用，但增加了規範作者刻意避免的工作階段管理複雜性 —— 協定是傳輸無關的，但標準傳輸（stdio、Streamable HTTP）覆蓋了生產場景（MCP specification）。
2026年9月17日 AGNTCon+MCPCon Europe 的「Stateless: The Future of MCP Transports」會議是無狀態傳輸方向的首次大型會議驗證 —— 由 Google 和 Hugging Face（MCP Transport Working Group 維護者）主講（Linux Foundation）。

傳輸問題聽起來像是基礎設施管道工程，確實如此 —— 但這個選擇在生產環境中會產生安全、可擴展性和維運方面的後果。當 Model Context Protocol 在2026年7月28日棄用 HTTP+SSE 並以 Streamable HTTP 取而代之時，規範作者做出了一個深思熟慮的工程決策：無狀態伺服器優於持久連線，標準 HTTP 優於自訂協定，單一端點優於雙端點 SSE 模型。他們沒有選擇 WebSocket，儘管 WebSocket 是雙向的而 SSE 不是。原因並非 WebSocket 是錯誤的 —— 而是對於 MCP 所服務的特定工作負載（代理和資料源之間的工具呼叫），雙向能力不值得其工作階段管理開銷。

本文將三種傳輸選項 —— SSE、WebSocket 和 Streamable HTTP —— 映射到使用它們的兩個代理協定（MCP 和 A2A），並提供建議的 B2B 代理部署決策矩陣。9月17日的 AGNTCon 會議使時機變得具體：無狀態傳輸正從規範走向會議驗證，而執行棄用 SSE 傳輸的團隊有一個12個月的遷移窗口，其中兩個月已經過去。

三種傳輸方式及其功能

SSE（Server-Sent Events）—— 被棄用的預設選項

SSE 是單向協定：伺服器通過長生命週期的 HTTP 連線向客戶端推送資料，客戶端無法通過同一連線發回訊息。每個客戶端操作 —— 取消生成、在任務中途引導代理、批准工具呼叫 —— 都需要單獨的 HTTP POST 請求（WebSocket.org）。

MCP 在其 2024-11-05 規範中使用 SSE 作為遠端伺服器的傳輸方式。該模型需要兩個端點：一個用於伺服器到客戶端訊息的 SSE 端點和一個用於客戶端到伺服器訊息的單獨 POST 端點。伺服器在兩個連線之間維護工作階段狀態。三個限制推動了棄用：不支援可恢復串流、需要長生命週期高可用連線，以及伺服器訊息僅通過 SSE 交付（MCP specification PR #206）。

A2A 仍在其串流傳輸模式中使用 SSE。SendStreamingMessage 方法將任務更新作為 SSE 事件交付 —— token 增量、工件區塊、狀態轉換。這對 A2A 是正確的選擇，因為串流傳輸是單向的（伺服器到客戶端），客戶端的控制訊息（取消、訂閱）通過單獨的 JSON-RPC 呼叫（A2A protocol）。SSE 簡單，基於標準 HTTP 工作，對於本質上是伺服器推送的工作負載不需要 WebSocket 的工作階段管理。

WebSocket —— MCP 未標準化的雙向選項

WebSocket 提供客戶端和伺服器之間的持久雙向連線。在 HTTP 升級握手後，連線保持開啟狀態，雙方可以隨時發送訊息。這是需要單一通道上真正雙向通訊的應用的正確原語：聊天、協作編輯、多人遊戲、交易面板（Ably）。

對於 AI 代理，雙向場景是真實存在的。代理工作流在執行期間需要客戶端到伺服器的訊息：取消生成、在任務中途引導代理、批准或拒絕工具呼叫、發送後續上下文。使用 SSE 時，每個這些都是單獨的 HTTP 請求。使用 WebSocket 時，它們搭載在與 token 串流相同的連線上（WebSocket.org）。

MCP 規範未標準化 WebSocket。它可作為自訂傳輸使用 —— 規範說「客戶端和伺服器可以實現額外的自訂傳輸機制」，只要它們保留 JSON-RPC 訊息格式 —— 但標準傳輸是 stdio（用於本地伺服器）和 Streamable HTTP（用於遠端伺服器）（MCP specification）。一個 GitHub issue（#493）提議將 WebSocket 新增為標準傳輸以簡化 HTTP 模型；它在未被採納的情況下關閉，規範轉向了 Streamable HTTP（GitHub）。

MCP 未標準化 WebSocket 的原因是維運性的，而非技術性的。WebSocket 要求伺服器維護持久連線、管理工作階段健康、處理重連邏輯並處理斷開連線。這與使 SSE 成為負擔的有狀態連線負擔相同。MCP 作者想要無狀態伺服器 —— 任何實例可以處理任何請求，沒有共享工作階段儲存，簡單的輪詢負載平衡 —— 而 WebSocket 的持久連線模型與該目標背道而馳。

Streamable HTTP —— MCP 的替代選擇

Streamable HTTP 是 MCP 規範對 SSE 與 WebSocket 問題的回答。伺服器暴露單一 HTTP 端點（例如 https://example.com/mcp），同時處理 POST 和 GET。客戶端將每個 JSON-RPC 訊息作為 POST 發送。伺服器可以用普通 JSON 正文回應，或者如果結果是長時間執行的，則將回應升級為 SSE 串流。關鍵設計選擇：伺服器不需要維護持久連線。每個請求都是自包含的（MCP specification）。

這使 MCP 獲得 SSE 的串流傳輸能力而無需長生命週期連線要求，並獲得 WebSocket 的雙向能力而無需工作階段管理開銷。客戶端通過 POST 發送訊息（標準 HTTP），伺服器通過可選 SSE 串流傳輸回應（標準 HTTP），伺服器可以是無狀態的（標準 HTTP 基礎設施）（Bright Data；Auth0）。

安全論點是具體的。Auth0 的分析：使用 Streamable HTTP，「我們可以在每個信封上蓋一個標準的 `Authorization: *** 頭。郵件室檢查每條訊息上的印章，而不僅僅是第一條。」使用舊的 SSE 傳輸時，認證令牌在連線時建立一次，持久連線承載所有後續訊息 —— 包括來自竊取工作階段 ID 的攻擊者的訊息（Auth0）。

決策矩陣

標準	SSE（已棄用）	WebSocket（自訂）	Streamable HTTP（MCP 標準）
方向	僅伺服器 → 客戶端	雙向	客戶端 → 伺服器通過 POST；伺服器 → 客戶端通過可選 SSE
連線模型	長生命週期，持久	長生命週期，持久	按請求（無狀態）
伺服器狀態	有狀態（每連線一工作階段）	有狀態（每連線一工作階段）	無狀態（請求間無工作階段）
負載平衡	需要黏性工作階段	需要黏性工作階段	簡單輪詢
擴展	有限（每客戶端一連線）	有限（每客戶端一連線）	高（任何 HTTP 基礎設施）
認證	連線時	握手時	按請求（每個 POST 上 Bearer）
可恢復性	否	否	否（但無狀態意味著沒有需要恢復的工作階段）
基礎設施	需要 SSE 感知代理	需要 WebSocket 感知代理	標準 HTTP（WAF、LB、CDN、認證代理）
安全面	工作階段 ID 竊取（CVE-2026-16496）	持久連線上的工作階段劫持	傳輸層無（無工作階段可竊取）
MCP 狀態	已棄用，12個月日落期	自訂傳輸（未標準化）	自 2026-03-26 起標準遠端傳輸
A2A 狀態	用於串流傳輸模式	未使用	未使用（A2A 使用 JSON-RPC over HTTP + SSE）
最適合	簡單伺服器推送（A2A 任務串流傳輸）	真正雙向（聊天、協作）	代理到工具呼叫（MCP）

該表回答了大多數 B2B 團隊提出的問題：如果你的代理需要呼叫遠端 MCP 伺服器上的工具，使用 Streamable HTTP。如果你的代理需要將任務輸出串流傳輸到另一個代理，使用 A2A 的 SSE 串流傳輸模式。如果你正在建構一個客戶端與伺服器發送訊息頻率相同的即時協作介面，WebSocket 是正確的原語 —— 但它是自訂傳輸，不是協定標準。

三種傳輸方式的比較：

安全維度 —— 為什麼無狀態很重要

驗證無狀態傳輸選擇的 CVE 是 CVE-2026-16496，這是 HashiCorp Terraform MCP Server 中一個 CVSS 10.0 的授權繞過漏洞。該漏洞影響了有狀態 streamable-HTTP 傳輸模式：取得其他使用者 MCP 工作階段 ID 的使用者可以使用該使用者的 Terraform 憑證執行工具呼叫。攻擊向量存在僅僅是因為伺服器持有攻擊者可以竊取和重用的工作階段狀態。無狀態伺服器沒有可竊取的工作階段（NVD；The Hacker News）。

這是有狀態傳輸模式是安全責任的生產證據，不僅僅是維運複雜性。SSE 的12個月棄用窗口現在是一個安全期限，而不僅僅是維運期限。仍在執行棄用 HTTP+SSE 傳輸的 1,227 個伺服器是受影響最嚴重的群體 —— 也是承載工作階段劫持攻擊面的群體。

關於無狀態協定和替換伺服器端工作階段狀態的顯式句柄模式的更深入處理，請參見 MCP 2026-07-28：無狀態協定對 B2B 代理部署意味著什麼。

A2A 有何不同 —— 以及為何有效

A2A 使用 SSE 進行串流傳輸，而不是 Streamable HTTP。區別在於工作負載。MCP 工具呼叫是短的請求/回應操作 —— 查詢資料庫、取得記錄、執行計算。伺服器處理請求並返回結果。串流傳輸是可選且罕見的。A2A 任務是具有顯式生命週期管理的長時間執行操作 —— 一個耗時兩分鐘的定價評估，一個耗時一小時的合規檢查。串流傳輸是進度更新，不是結果本身。

A2A 的 SSE 串流傳輸僅是伺服器推送，這對任務進度是正確的方向：處理任務的代理向呼叫代理發送更新。呼叫代理的控制訊息（取消、訂閱更新）通過單獨的 JSON-RPC 呼叫。串流傳輸通道上不需要雙向通訊，因為控制通道是單獨的標準 HTTP 請求（A2A protocol；Google Developers Blog）。

這就是為什麼傳輸問題是管道工程，不是架構。MCP 和 A2A 使用不同的傳輸因為它們有不同的工作負載，但兩者都基於標準 HTTP。協定語意 —— MCP 的無狀態工具呼叫和 A2A 的有狀態任務生命週期 —— 才是使代理通訊有效運作的關鍵。傳輸承載訊息；它不定義訊息。

完整的協定級比較（範圍、傳輸、認證、狀態、人機互動），請參見 A2A vs MCP：為代理通訊選擇正確的協定。

何時 WebSocket 是正確的答案

WebSocket 不是錯誤的。它是 MCP 和 A2A 未標準化的特定工作負載的正確傳輸：

即時協作介面，客戶端與伺服器發送訊息頻率相同 —— 多個操作員同時引導同一代理的共享代理面板。
高頻雙向通訊，其中每條訊息的 HTTP 請求開銷過高 —— 在同一通道上接收市場資料並發送訂單的交易代理。
自訂 MCP 傳輸，標準傳輸不適合 —— 規範明確允許自訂傳輸，只要它們保留 JSON-RPC 訊息格式和生命週期要求（MCP specification）。

權衡是維運複雜性。維護長生命週期雙向連線需要針對工作階段健康、重試、斷開連線和訊息協定的顯式邏輯（Nimble Way）。對於大多數 B2B 代理部署 —— 一個呼叫 NetSuite 的代理，一個委託給定價代理的採購代理 —— 這種複雜性不被工作負載所證明。

無狀態趨勢

行業方向是明確的。MCP 於2026年7月28日轉向無狀態。A2A 使用有狀態任務機但無狀態傳輸（HTTP + SSE，伺服器上無持久工作階段）。9月17日的 AGNTCon+MCPCon Europe 會議 —— 「Stateless: The Future of MCP Transports」，由 Kurtis Van Gent（Google）和 Shaun Smith（Hugging Face，MCP Transport Working Group 維護者）主講 —— 是第一個專門致力於無狀態傳輸方向的大型會議會議（Linux Foundation；sched.com）。

Shaun Smith 還將在同一會議上發表主題演講：「Getting to Stateless MCP: In Production」—— 這標誌著無狀態傳輸正從規範轉向生產部署指導。對於執行棄用 SSE 傳輸的團隊，12個月遷移窗口（到2027年7月結束）是維運期限。安全期限更早：伺服器執行有狀態 SSE 傳輸的每一天都是它承載 CVE-2026-16496 所利用的工作階段劫持面的一天。

WebSocket vs SSE 的問題，對於代理通訊，有一個明確的答案：都不是，如果你基於 MCP 建構。使用 Streamable HTTP。如果你在串流傳輸 A2A 任務輸出則使用 SSE。僅當工作負載是真正雙向的且維運複雜性被證明時才使用 WebSocket。傳輸是管道工程。協定語意 —— 無狀態工具呼叫、有狀態任務生命週期、顯式句柄、人機互動狀態 —— 才是使代理系統在生產中有效運作的關鍵。