OpenAI WebSocket Mode for Responses API
OpenAI · 程式設計
OpenAI 為 Responses API 推出的 WebSocket 模式是一種長連線模式，讓你能透過單一 WebSocket 執行長時間、工具密集的代理工作流程，而不必反覆發出 HTTP 請求。你對 Responses 端點開啟一條連線，接著每一輪只要送出新的輸入項目再加上一個 previous_response_id，就能讓每輪保持輕量。它是為代理式程式開發與協調迴圈而打造，這些情境裡同一個任務會觸發數十次工具呼叫，而且能在隱私敏感的環境中搭配 store=false 運作。
關於 OpenAI WebSocket Mode for Responses API
什麼是 OpenAI 為 Responses API 推出的 WebSocket 模式
OpenAI WebSocket 模式是 Responses API 的一種傳輸選項，不是獨立的產品。Responses API 是 OpenAI 用來打造代理風格應用程式的具狀態基礎元件，也是多數新專案起步時使用的端點。改變的是它底下的管線。就這樣。其他關於提示與工具的部分全都維持不變。
它解決的問題是續接的額外負擔。在標準 HTTP 模式下，每一輪都會重新開啟連線，而你每次都重送不斷長大的脈絡。應付單一問題還沒問題。但對一個連續呼叫工具二十或三十次的代理來說，這些來回傳輸全都会累積起來。WebSocket 模式讓連線持續開著通往 Responses 端點，並讓每次後續只送出差異部分，透過 previous_response_id 串接起來。不是什麼高深技術。只是更好的管線。
最大的限制在於適用範圍。這個模式是為長時間、工具密集的工作流程而設，而非全部情況。OpenAI 自家的指引就說，單次請求與簡短對話應該留在標準 HTTP 的 Responses API 上，因為在那裡最佳化沒什麼效益。連線也有時間上限，所以長時間執行時你得處理重新連線。有點煩，但還應付得來。
開始使用
- 取得 OpenAI API 金鑰，並安裝 WebSocket 用戶端，例如 Python 的 websocket-client 套件。
- 對 Responses 的 WebSocket 端點開啟 socket，並在 Authorization 標頭帶入你的金鑰。
- 用 response.create 事件送出第一輪，內容包含模型、工具與初始輸入。
- 透過送出新的 response.create 來延續對話，其中引用前一輪的 previous_response_id，並只包含新的輸入項目，例如 function_call_output。
- 在伺服器事件串流回來時讀取它們，接著關閉 socket；若碰到連線時間上限就重新連線。
產品資訊
快速了解 OpenAI WebSocket Mode for Responses API 的定價、支援平台與效能。
適合對象
這項工具最適合的使用者、任務與情境。
使用者
- 打造需要低延遲工具迴圈的代理的後端與 AI 工程師，因為這個模式針對的是伺服器對伺服器的流量。
- 執行協調工作負載的平台團隊，這些工作每次上線都會呼叫工具數十次。
- 有隱私限制、需要支援 store=false 與零資料保留之傳輸方式的開發者。
任務
- 代理式程式開發：在單一連線上執行分析、修正、驗證的循環，而不是每一步都重啟 HTTP 呼叫。
- 工具呼叫處理：把 function_call_output 串流回去，讓模型不必重送完整歷史就能繼續。
- 多輪協調：在大量模型與工具的來回之間，讓長時間執行的代理工作階段保持存活又省成本。
情境
- 一個程式開發代理，在活躍的 socket 上反覆進行檔案分析、修補產生與測試執行。
- 一個後端服務，為每個使用者請求協調多次工具呼叫，而每輪延遲很重要。
- 一個想在高流量代理流量上降低額外負擔、又不改動模型或提示的團隊。
主要功能
與 Responses 端點的長連線
WebSocket 模式在許多輪之間讓一條連線持續開著通往 Responses API。你用 response.create 事件驅動它，第一個事件就像一般請求一樣開啟新的一輪。由於 socket 保持開啟，你省下了標準串流 API 每一輪都得付的連線建立成本。那份額外負擔只出現一次時很小。但在長時間的代理執行中就不是了。
以 previous_response_id 傳送增量輸入
每個後續輪次只送出新的輸入項目，再加上一個連回前一輪的 previous_response_id。你不重送整個脈絡，而長時間鏈結中大部分的省下成本正是來自這裡。第一輪的內容等同標準 create 主體，扣掉這裡不適用的傳輸專屬欄位，例如 stream 與 background。所以即使對話變長，請求依然精簡。
為工具密集工作流程加快續接
最亮眼的效益會在流程牽涉大量模型與工具來回時出現。那就是低延遲代理工作流程的世界，而這個傳輸就是為它們打造的。OpenAI 的指引指出，在工具呼叫頻繁的上線流程中有明顯的加速，而增益來自續接路徑，不只是第一個 token，這正是代理反覆繞過同一批工具時最浪費時間的部分。不是每個工作流程都有感。如果你的代理幾乎不呼叫工具，你不會察覺多少。如果它不斷呼叫，那正是重點所在。
支援 store=false 與零資料保留
WebSocket 模式支援 store=false 與零資料保留的設定，如果你不能讓 OpenAI 保留回應狀態，這點就很重要。伺服器在連線存續期間把最近的回應狀態留在記憶體中，所以你仍能享有快速的續接，而不必把各輪內容跨請求保存下來，否則資料會留在伺服器上。對處於受監管或隱私敏感環境的團隊來說，這個組合正是選擇這種傳輸的理由。
串流事件與順序和 HTTP 模式一致
伺服器事件及其順序與現有的 Responses 串流模式相符。如果你已經在 HTTP 上處理串流事件，這些事件的形狀看起來很熟悉，所以你不必從頭改寫用戶端邏輯。差別在傳遞通道，而非訊息格式。那為什麼還要換？為了速度，在速度算數的情境裡。這讓轉換成本保持低廉。
優缺點
優點
- 在工具呼叫頻繁的工作流程中降低續接延遲，而那正是 HTTP 模式最吃虧的地方。
- 只送增量輸入，減少重複傳輸與連線建立成本。
- 支援 store=false 與零資料保留，隱私敏感的團隊也能使用。
- 伺服器事件與順序和 HTTP 串流模式相符，既有的用戶端程式碼容易調適。
- 單一開啟的 socket 比堆疊的 HTTP 請求更適合代理式程式開發與協調迴圈。
缺點
- 只有對長時間、工具密集的工作流程才划算；簡短對話與單次呼叫幾乎沒什麼增益。
- 連線有時間上限，所以長時間執行的代理得建置重新連線邏輯。
- 這種傳輸比單純的 HTTP 呼叫需要管理更多程式碼，提高了用戶端複雜度。
- 你仍得付標準的 API 用量費率；這個模式降低延遲，而非每個 token 的成本。
常見問題
它是一種傳輸模式，對 Responses API 保持一條持久的 WebSocket 連線，而不是每一輪都發新的 HTTP 請求。你只送出新的輸入項目與一個 previous_response_id，藉此降低長時間代理執行中每輪的額外負擔。可以想成是持續待在線路上，而不是掛斷再重撥。
相關內容
探索與 OpenAI WebSocket Mode for Responses API 相關的工具、技能與文章。
OpenAI WebSocket Mode for Responses API 替代方案
Forefront
Forefront · 程式設計Forefront 是一個用來打造開源 AI 的網頁平台。你可以用自己的資料微調主流的開源語言模型、評估它們的表現，再透過 API 執行，或匯出後自行架設。想要封閉式平台的便利、卻堅持要自己擁有模型與資料的開發者，就是這裡的目標客群。
Startkit
StartKit.AI · 程式設計Startkit 是一套用來打造 AI SaaS 與 AI 包裝產品的樣板。可以把它想成一個 AI 新創樣板，把枯燥的部分都先接好了：驗證、Stripe 與 Lemon Squeezy 付款、用量限制、交易型電子郵件，以及一套能與 OpenAI、Anthropic、Groq 或 Llama 溝通的 AI API 啟動套件。你複製儲存庫、設定價格，然後專心在產品中使用者真正願意付費的部分。它建構於 React 與 Tailwind 之上的 Next.js，所以大部分的樣板程式碼對你來說並不陌生。
Testim
Tricentis · 程式設計Testim 是專為網頁、行動與 Salesforce 應用程式打造的 AI 測試自動化平台，用來建立並執行端到端測試。它靠機器學習在介面變動時維持測試穩定，團隊因此少花時間修補壞掉的定位器。對於一款今天就能開始使用的自動化測試工具來說，這表現不算差。你透過在瀏覽器錄製動作來建立測試，需要更多控制時再補上 JavaScript。對忙碌的 QA 團隊來說，這是個可靠的選擇。