透過 Responses API 中的 WebSockets 加速代理工作流

2026 年 4 月 22 日

透過 Responses API 中的 WebSockets 加速代理型工作流

作者：技術人員 Brian Yu 與 Ashwin Nathan

當你要求 Codex 修復一個錯誤時，它會掃描你的程式碼庫以尋找相關文件，讀取這些文件以建立上下文，進行編輯，並執行測試以驗證修復是否奏效。在底層，這意味著數十次來回的 Responses API 請求：確定模型的下一步行動、在你的電腦上執行工具、將工具輸出傳回 API，然後重複此過程。

所有這些請求累積起來，可能會讓用戶花費數分鐘等待 Codex 完成複雜任務。從延遲的角度來看，Codex 代理循環（agent loop）的大部分時間花在三個主要階段：API 服務工作（驗證和處理請求）、模型推理，以及用戶端時間（執行工具和建立模型上下文）。推理是模型在 GPU 上運行以生成新標記（tokens）的階段。過去，在 GPU 上運行 LLM 推理是代理循環中最慢的部分，因此 API 服務的開銷很容易被掩蓋。隨著推理速度變快，代理型展開（agentic rollout）中累積的 API 開銷變得更加顯著。

在這篇文章中，我們將解釋如何將使用 API 的代理循環端到端速度提升 40%，讓用戶體驗到推理速度從每秒 65 個標記跳升至近 1,000 個標記。我們透過快取、消除不必要的網路跳轉、改進安全堆疊以快速標記問題，以及最重要的——建立一種與 Responses API 建立持久連接的方法，而不是必須進行一系列同步 API 調用。

當 API 成為瓶頸時

在 Responses API 中，之前的旗艦模型如 GPT-5 和 GPT-5.2 的運行速度約為每秒 65 個標記 (TPS)。為了發布 GPT-5.3-Codex-Spark（一款快速程式碼模型），我們的目標是提升一個數量級：達到 1,000 TPS 以上，這得益於針對 LLM 推理優化的專用 Cerebras 硬體。為了確保用戶能體驗到這款新模型的真實速度，我們必須減少 API 開銷。

大約在 2025 年 11 月，我們啟動了 Responses API 的性能衝刺，針對單個請求的關鍵路徑延遲進行了多項優化：

透過這些改進，我們看到首個標記時間 (TTFT) 提升了接近 45%——這反映了 API 的響應速度——但這些改進對於 GPT-5.3-Codex-Spark 來說仍然不夠快。即使有了這些改進，相對於模型的速度，Responses API 的開銷仍然太大——也就是說，用戶在能夠使用服務於模型的 GPU 之前，必須等待運行我們 API 的 CPU。

更深層的問題在於結構：我們將每個 Codex 請求視為獨立的，在每個後續請求中都要處理對話狀態和其他可重複使用的上下文。即使大部分對話內容沒有改變，我們仍然要為與完整歷史記錄相關的工作付出代價。隨著對話變長，這種重複處理變得更加昂貴。

建立持久連接

為了優化設計，我們重新思考了傳輸協定：我們能否保持持久連接並快取狀態，而不是透過 HTTP 建立新連接並為每個後續請求發送完整的對話歷史記錄？這個想法是只發送任何需要驗證和處理的新資訊，並在連接存續期間將可重複使用的狀態快取在記憶體中。這將減少冗餘工作帶來的開銷。

我們考慮了幾種不同的方法，包括 WebSockets 和 gRPC 雙向串流。我們最終選擇了 WebSockets，因為作為一種簡單的訊息傳輸協定，用戶不需要更改其 Responses API 的輸入和輸出格式。它對開發者友好，且能以極小的干擾融入我們現有的架構。

第一個 WebSocket 原型改變了我們對 Responses API 延遲可能性的認知。一位在 API 堆疊方面擁有深厚專業知識的 Codex 團隊工程師，透過讓 Codex 代理運行一夜，整合出了一個原型。

在該原型中，代理型展開被建模為單個長時間運行的 Response。利用 asyncio 特性，Responses API 會在工具調用被採樣後，在採樣循環中異步阻塞，並向用戶端發送一個 response.done 事件。在執行工具調用後，用戶端會傳回一個帶有工具結果的 response.append 事件，這會解除採樣循環的阻塞並讓模型繼續運行。

這裡的一個類比是將本地工具調用視為託管工具調用。當模型調用網路搜尋時，推理循環會阻塞，調用網路搜尋服務，並將服務響應放入模型上下文中。在我們的設計中，我們做了同樣的事情；但我們不是調用遠端服務，而是透過 WebSocket 將模型的工具調用發送回用戶端。當用戶端響應時，我們將用戶端的工具調用結果放入上下文中並繼續採樣。

這種設計極其有效，因為它消除了代理展開過程中重複的 API 工作。我們可以執行一次推理前工作，暫停以等待工具執行，最後在結束時執行一次推理後工作。

遺憾的是，這是以一種較不熟悉且更複雜的 API 格式為代價的。我們希望開發者能夠直接插入 WebSocket 支援，而無需圍繞新的互動模式重寫其 API 整合。

在保持 API 熟悉的同時實現堆疊增量化

對於我們發布的版本，我們切換回了熟悉的格式：繼續使用帶有相同 Body 的 response.create，並使用 previous_response_id 從前一個響應的狀態延續對話上下文。

在 WebSocket 連接上，伺服器會保留一個連接範圍內的記憶體快取，儲存先前的響應狀態。當後續的 response.create 包含 previous_response_id 時，我們會從快取中獲取該狀態，而不是從頭開始重建完整的對話。

該快取狀態包括：

透過重複使用記憶體中的前次響應狀態，我們得以實現幾項重大優化：

目標是盡可能接近最小開銷的原型，但使用開發者已經理解並圍繞其構建的 API 格式。

樹立速度新標竿

在經歷了兩個月的 WebSocket 模式開發衝刺後，我們與幾家關鍵的程式碼代理新創公司啟動了 Alpha 測試，以便他們將其整合到基礎設施中並安全地提升流量。Alpha 用戶非常喜歡它，報告稱其代理型工作流提升了高達 40%⁠。鑑於 Alpha 測試的正向回饋，我們準備好正式發布。

發布結果立竿見影。Codex 迅速將其大部分 Responses API 流量轉移到 WebSocket 模式，延遲得到了顯著改善。對於 GPT-5.3-Codex-Spark，我們達到了 1,000 TPS 的目標，並看到了高達 4,000 TPS 的峰值，這表明 Responses API 能夠在真實的生產流量中跟上更快的推理速度。這種影響也迅速體現在開發者社群中：

WebSocket 模式是 Responses API 自 2025 年 3 月發布以來最重要的全新功能之一。透過 OpenAI 的 API 團隊與 Codex 團隊的緊密合作，我們在短短幾週內就完成了從構思到生產運行的過程。它不僅大幅改善了代理展開的延遲，還支援了開發者日益增長的需求：隨著模型推理變得更快，圍繞推理的服務和系統也需要加速，以便將這些收益傳遞給用戶。

作者

Brian Yu, Ashwin Nathan

致謝

特別感謝致力於建立 WebSocket 模式的 Responses API 和 Codex 團隊。

延伸閱讀

工程 | 2026 年 3 月 11 日

工程 | 2026 年 2 月 13 日

工程 | 2026 年 2 月 11 日