前言

在建構基於大型語言模型（LLM）的智能助手時，系統需要處理從簡單問答到複雜的 Agent 工作流（如多步驟推理、工具調用和跨代理協作）等不同任務。隨著系統規模擴大和用戶量增長，延遲、連線中斷和資源消耗成為架構上的主要挑戰。因此，客戶端與 LLM 之間的互動模式設計，是決定系統穩定性與效能的關鍵因素。

LLM 互動模式的重要性：從 Infra 挑戰到使用者交互模式

在設計一套系統時，互動模式的選擇是關鍵的架構決策，其核心在於「客戶端選擇如何與後端溝通」。這個選擇不僅僅是技術層面的考量，它將從根本上決定整套系統的設計方向、資源需求，並直接塑造終端使用者的體驗。

前端與後端之間的通訊方式，常見的模式包括傳統的長輪詢（Long Polling））、SSE（Server-Sent Events）以及 WebSocket。

這個重要的選擇會直接決定整套系統的設計與體驗：容量模型、觀測與重試語意、錯誤邊界、以及使用者感知的即時性。

同步互動：直接但缺乏彈性的經典模式

同步模式的運作方式是：客戶端發送請求，然後等待後端處理完成後返回結果。這種模式雖然實現簡單，但在 LLM 應用中，可能導致用戶長時間等待，特別是當任務涉及多輪推理時。

Request-Response 模式：簡單好上手

最常見的互動型態：前端發出一次 HTTP 請求，後端完成計算後 一次性回傳 結果。實作簡單、路徑清晰，但在長耗時任務上容易出現毫無頭緒的空等。

• 優點：實作直接、上手快；沿用標準 HTTP 流程，易於快取、權限與審計。
• 缺點：等待期間缺乏回饋、體驗較差；尾延遲顯著，長任務時使用者只能乾等。
• 適用場景：短任務或非即時需求，如表單查詢、小型工具調用、後台報告生成。

Streaming 模式：提升用戶體驗的關鍵

OpenAI 和 Google 等主流 LLM 服務提供商廣泛採用 Streaming 模式，因為它將等待時間轉化為觀察模型生成內容的過程。透過邊生成邊傳輸，回應延遲可以顯著降低，從而改善用戶體驗。

• 實現技術：通常使用 SSE 或 WebSocket。
  • SSE (Server-Sent Events)：基於標準 HTTP 的單向推送技術。它支援斷線重連（透過 last-event-id），且其無狀態特性適合 LLM 的單向輸出模式。
  • WebSocket：提供全雙工、低延遲的通訊，適合需要即時雙向互動的場景（例如，在對話中即時修改提示）。然而，其維護成本較高，且非標準 HTTP 協議可能被防火牆阻擋。對於典型的問答場景，WebSocket 的功能可能超出實際需求。
• 適用時機：當用戶體驗為首要考量時，例如聊天應用或即時程式碼生成工具，Streaming 能讓用戶感覺到模型正在即時回應。

雖然同步 Streaming 模式能提升用戶體驗，但在長連線情境下，它也對基礎設施的穩定性提出了挑戰。

非同步互動：為大規模擴展設計的解耦模式

當同步模式因長任務而導致客戶端阻塞時，非同步設計提供了解耦方案，使系統更具彈性與可擴展性。

Short/Long Polling：模擬 Streaming 的替代方案

Short/Long Polling 不建立長連線，而是以週期性請求向後端拉取最新進度或增量結果。它在不像維持 SSE/WS 長連線的環境中，提供一種簡化且相容性高的「邊做邊看」替代方案。

• 運作方式：先 POST /jobs 取得 jobId → 以固定/動態間隔輪詢 GET /jobs/{id}；可帶 since=cursor 分段拉取已完成部分，模擬 Streaming。
• 優點：無狀態、冪等性好、易穿越防火牆/CDN；每次請求獨立，負載平衡簡單、擴展性好。
• 潛在問題與緩解：高頻輪詢會推高 RPS、尾延遲受輪詢間隔主導。需添加更多容錯機制，如退避＋抖動、動態調整間隔（伺服器可回 Retry-After）、避免同時喚醒以防「驟發群聚」。
• 適用情境：執行時間不確定的長任務（如複雜 Agent 工作流）、行動或企業網對長連線不友善、或後端未提供串流通道時。前端可在背景輪詢，使用者可繼續操作介面。
• 實作要點（精簡）：以 Idempotency-Key 去重；提供 state/progress/cursor；結果可快取並設定保留期（完成後一段時間 200，逾期回 410 Gone）。

同步 Streaming vs. 非同步：選用心法

在 LLM 互動裡，同步 Streaming追求即時回饋與互動感，非同步則以穩定性、可擴展與成本控制為主。兩者不是對立，而是針對網路環境、任務時長、流量型態與體驗目標的取捨；必要時可混用。

• 何時選「同步 Streaming」
  • 目標是即時體驗（first-token 快、持續回饋）。
  • 任務時長較短或可中途停止；網路相對穩定。
  • 場景：聊天、即時程式碼/內容生成、逐步推理可視化。
• 何時選「非同步」
  • 任務耗時/波動大、要撐高併發或成本敏感。
  • 網路對長連線不友善，或有嚴格的審計/合規需求。
  • 場景：批次生成、報表/匯出、複雜 Agent 流程。
• 常見混合策略
  • 非同步啟動 + 同步串流回傳：先提交任務、就緒後以 SSE/WS 串流內容。
  • 同步啟動 + 非同步回傳：先串流草稿，後台續算高品質版本再通知/覆寫。

實際選型應以 A/B 或金絲雀部署的實測為準，對比 first-token、整體完成時間、P95/P99 延遲、中斷/重連率、客訴/放棄率 與 每請求成本 等關鍵指標。整體而言，非同步設計能帶來服務解耦與更高彈性，是為面對長連線不穩定與流量峰值波動時的穩健基礎。

互動模式如何牽動系統的可靠性與設計？

客戶端的互動模式選擇，會直接影響後端系統的設計以及需要應對的可靠性挑戰：

• 連線管理與資源配置
  • 長連線模式 (WebSocket/SSE)：會長時間佔用伺服器連線與記憶體。因此，後端需要針對性的健康檢查機制，能區分「連線層」的存活與「應用層」的健康狀態。此外，長時間的資源佔用也對系統的擴展性與負載平衡策略帶來更高的要求。
  • 請求-回應模式 (Request-Response)：系統資源主要消耗在請求高峰期的運算能力上。設計上更偏重於快速處理和釋放資源，而非維持大量閒置連線。
• 延遲與使用者體驗
  • 同步請求：對於傳統的請求-回應模式，使用者直接感受到的是操作的延遲。這使得系統對於 P95/P99 尾延遲（Tail Latency）特別敏感，因為少數的慢回應就可能破壞整體體驗。
  • 串流模式 (Streaming)：WebSocket 或 SSE 可以在有資料時立即回饋，提供更流暢的即時體驗。但挑戰在於如何維持穩定、不中斷的長連線，避免因網路抖動造成的體驗下降。
• 錯誤處理與失敗模式
  • 同步請求：錯誤傾向於立即在前台擴散。例如，一個 API 的失敗會直接導致使用者介面的某個區塊載入失敗。因此，常需要搭配更嚴格的逾時控制、重試機制以及斷路器模式，防止單點故障擴散影響整個前端應用。
  • 非同步或長連線：錯誤可以被封裝在後端的工作流程或連線狀態中。例如，一個非同步任務的失敗，可以透過佇列的重試、死信隊列 (Dead-Letter Queue) 與補償流程來處理，對前端的立即影響較小。WebSocket 的斷線也可以在背景進行重連，對使用者更為透明。

長連線的挑戰：客戶端選擇如何牽動系統

同步 Streaming（SSE/WS）依賴長連線。一旦客戶端選擇了這條路，整體系統的可靠性、擴縮與部署節奏都會跟著改變；設計要同時兼顧「能不中斷」與「斷了能順利續上」。

• 客戶端與網路層
  • 行動網路切換、分頁休眠、Wi-Fi/Cell handoff 容易中斷。
  • 緩解：SSE 用 Last-Event-ID、WS 設 cursor/seq＋重放窗口；自動重連需退避＋抖動並去重。
• 基礎設施負擔
  • API Gateway / LB 需維持大量長連線，Autoscaling 時必須優雅排空（connection draining）。
  • 緩解：分離代理層逾時與服務逾時、設定每節點最大連線數與租戶速率限制；長連線失敗時降級為 Long Polling。
• 部署與版本治理
  • 新舊版本並存易出現行為偏差（Prompt/Schema 變更）。
  • 緩解：版本化端點與依版本路由/黏著（sticky-by-version）；採 金絲雀/藍綠/彩虹部署，等流量完全切至新版本再回收無連線實例，必要時提供向下相容輸出。

最新 Streaming 技術的演進：SSE 與 Streamable HTTP

SSE 是目前 LLM Streaming 的主流技術，因其簡單、基於 HTTP 且支援自動重連。然而，它對長連線的依賴在擴展時帶來了挑戰。Streamable HTTP 作為一種演進方案，特別是在 MCP（Model Context Protocol）中被採用。自 2025-03-26 版本起，MCP 從 SSE 轉向 Streamable HTTP，以解決串流恢復、長連線負載和單向通訊的限制。

• Streamable HTTP 的特性：此技術採用無狀態通訊，可根據需要升級為 SSE。它使用單一端點處理 POST/GET 請求，支援多路徑和雙向通訊，資源消耗較低，適合工具調用等 AI 場景。
• 轉變原因：MCP 的 PR #206 中提到，從 HTTP+SSE 的組合轉向 Streamable HTTP，是為了提升協議的兼容性與通訊的穩定性。

技術比較：LLM 應用的適用性

儘管 SSE 在 2025 年仍然是主流選擇，但 Streamable HTTP 代表了未來的發展方向，尤其適用於需要更高穩定性和效率的 Agent 系統。

結論

LLM 的互動模式設計需要在多個維度進行權衡：同步模式提供即時性，非同步模式提供擴展性；Streaming 改善了用戶體驗，但長連線也帶來了架構上的挑戰。從 SSE 到 Streamable HTTP 的技術演進，反映了業界對更高效、更穩定解決方案的追求。

在實際專案中，應從評估需求、開發原型和整合可靠性模式著手。透過合理的設計，不僅能建構出高效能的系統，還能提供優質的用戶體驗。

References：

• https://brightdata.com/blog/ai/sse-vs-streamable-http
• https://procedure.tech/blogs/the-streaming-backbone-of-llms-why-server-sent-events-(sse)-still-wins-in-2025
• https://ai-sdk.dev/docs/foundations/streaming
• https://medium.com/@asharsaleem4/long-polling-vs-server-sent-events-vs-websockets-a-comprehensive-guide-fb27c8e610d0