在開發以大語言模型驅動的 Agent 時，我們經常會面臨一個效能瓶頸：當工作流程涉及大量的模型與外部工具來回溝通（例如程式碼自動編寫或複雜的編排迴圈），每一次 HTTP 請求的建立與龐大上下文的傳輸，都會不斷疊加通訊延遲。為了解決這個痛點，OpenAI 在其 Responses API 中推出了全新的 WebSocket 模式，透過建立持久連線與增量輸入（incremental inputs），專門為這類需要長時間運作且頻繁呼叫工具的場景提供更流暢的解決方案。
揮別冗長傳輸：增量輸入與記憶體快取機制
傳統的 HTTP 模式在每一次對話回合中，都需要重新傳送完整的歷史上下文，這不僅耗費頻寬，也增加了伺服器解析的負擔。WebSocket 模式的運作邏輯大不相同。一旦建立連線，伺服器會在連線局部的記憶體中快取最近一次的回應狀態。這意味著在後續的對話回合裡，開發者只需要傳遞上一次的 previous_response_id 以及全新產生的內容（例如工具的執行結果或使用者的最新訊息）即可。因為省略了重複傳遞與處理冗長歷史記錄的過程，整體的端到端延遲得以顯著降低。根據官方數據，在執行超過 20 次工具呼叫的複雜任務中，這種增量輸入的機制可以讓整體執行速度提升大約 40%。
實作細節與隱私兼顧：請求預熱與零資料保留
在實作上，開發者可以透過傳送 response.create 事件來啟動對話。值得一提的是，這個模式支援透過設定 generate: false 來進行請求狀態的「預熱（warm-up）」。如果你已經預先知道接下來會用到的工具或指令，可以先發送預熱請求，它雖然不會立刻產生模型的文字輸出，但會回傳一個 ID 讓你能在後續流程中無縫銜接，進一步加快首次生成的回應速度。
此外，由於上下文狀態是存放在連線的短期記憶體中，而非寫入硬碟，這項技術完全相容於零資料保留（Zero Data Retention, ZDR）政策以及 store=false 的設定，在提升效能的同時也兼顧了對隱私與資安要求較高的應用場景。
架構設計考量：連線限制與中斷恢復
雖然 WebSocket 模式帶來了極大的效能優勢，但在系統架構的設計上仍有幾個必須納入考量的限制與應對機制。
首先，單一連線目前採循序執行，尚不支援多工處理（multiplexing），若需要平行執行多個任務，就必須建立多條獨立的 WebSocket 連線。其次，為了維持伺服器的資源平衡，每條連線的生命週期最高限制為 60 分鐘，一旦超時、發生斷線，或是在中途發生 4xx/5xx 錯誤，系統就會清除該連線記憶體中的快取。遇到這種情況，開發者必須具備重建連線的重試機制。
若你的應用程式有搭配上下文壓縮（compaction），在伺服器端自動壓縮的情況下可以直接於原連線繼續操作；但如果是透過獨立的 HTTP 端點進行手動壓縮，則必須帶著壓縮後的新上下文，重新建立一條 WebSocket 連線並啟動全新的回應鏈。
整體來說，OpenAI 推出的 WebSocket 模式精準打擊了複雜 Agent 應用的效能痛點。透過持久化連線與狀態快取的設計，它改變了以往笨重且高重複性的通訊方式，讓開發者在打造高度自動化、需要頻繁互動的 AI 產品時，能夠以更低的延遲提供更即時的使用者體驗。
