OpenAI 升級 Responses API：加長連線支援，智慧體呼叫提速 40%

以前大家用 AI 寫程式碼，覺得慢總怪大模型生成太肉。現在情況倒過來了：底層的模型跑得飛快，反而是外層包著的那層 HTTP 介面在拖後腿。

OpenAI 宣佈給 Responses API 正式加入 WebSocket 支援。這一改動把 Agent 工作流的端到端延遲砍掉了最多 40%，首字生成時間（TTFT）縮短了約 45%。

為什麼以前的 API 成了絆腳石

像 Codex 這樣的程式設計 Agent 幹起活來，並不是一次性問答。它要先掃一遍程式碼庫、讀檔案、改程式碼、跑測試，反反覆覆來回幾十輪。

過去走普通的 HTTP 請求，每一次輪次都要重新建連，把整段聊天記錄、工具定義、上下文全部打包重新傳過去。OpenAI 的伺服器也得從頭做一遍解析、分詞和安全稽核。

以前 GPT-5 和 GPT-5.2 的生成速度大概只有每秒 65 個 token，網路和服務的這點開銷很容易被漫長的 GPU 推理時間掩蓋過去。但隨著搭載 Cerebras 專用硬體的 GPT-5.3-Codex-Spark 登場，模型生成速度直接飆到了每秒 1000 個 token，峰值甚至能衝到 4000。這時候，使用者等模型的時間反而沒有等 API 解析的時間長。

用長連線留住狀態，避免從頭算起

OpenAI 最終選擇了 WebSockets，而不是更底層複雜的 gRPC 雙向流，核心目的是不想讓開發者大改程式碼結構。

在新的 WebSocket 模式下，客戶端和伺服器之間維持一條長連線。服務端會直接在記憶體裡快取上一輪的狀態，包括上一輪的響應物件、工具定義，以及已經生成好的 token。

當 Agent 發起下一輪呼叫時，只需要帶上一個引數 previous_response_id，系統就會直接從記憶體提取舊資料，只對新增的內容做安全掃描和處理。同時，他們還砍掉了影像處理等中間服務的跳轉延遲，並把計費等不阻塞主流程的操作挪到了後臺並行跑。

實際效果非常直接。Vercel 把它接進了 AI SDK，延遲直接降了 40%；Cline 的多檔案處理流程提速了 39%；Cursor 跑 OpenAI 模型的速度也提升了最高 30%。

為什麼重要

這篇技術復盤背後透露出一個關鍵變化：AI 基礎設施的瓶頸，正在從模型權重和 GPU 算力，轉移到周圍的工程配套與傳輸層。

對於每天高頻使用 Cursor、Cline 或 Codex 的開發者來說，這種底層協議的改動是最實打實的提速。以前跑複雜任務動輒等上幾分鐘，現在端到端直接壓縮掉三到四成的時間，Agent 反饋更接近即時互動，寫程式碼時的打斷感會明顯減少。

OpenAI 這步棋走得很剋制也很聰明。他們原本搞過一套類似事件阻塞的原型，效能極高，但介面形態大改；團隊最終選擇退回熟悉的 response.create 配合引數標記，就是為了讓社群生態能零成本接入。在推理硬體越來越快的背景下，我們認為像 Anthropic 和 Google 等對手也必須跟進重寫自己的 Agent 傳輸架構，否則單憑模型算力提速，使用者在客戶端根本感知不到差別。