在開發 AI Agent（智慧體）時，我們常會發現一個有趣的現象：即使模型本身的生成速度（Tokens Per Second, TPS）提升了，使用者感受到的整體回應速度卻不一定有明顯改善。這是因為 Agent 的運作模式與單次對話不同，它是一個不斷循環的過程：模型判斷動作、呼叫工具（Tool Call）、執行本地指令、將結果回傳給模型，如此反覆。
當模型推論速度極快時，原本被忽略的 API 通訊開銷（Overhead）會變成整個系統的瓶頸。OpenAI 最近分享了他們如何透過導入 WebSockets 來優化 Responses API，將 Agent 工作流的整體效能提升約 40% 的實務經驗。
為什麼傳統 API 呼叫會變慢
在標準的 HTTP 請求模式下，每次 Agent 需要下一步指令時，都會發起一次獨立的 API 請求。這會帶來三個主要問題。
首先是重複的上下文處理。由於 HTTP 是無狀態的，每次請求都必須傳送完整的對話歷史。隨著對話變長，系統每次都要重新處理（Tokenization）整段歷史記錄，導致 CPU 負擔增加。
其次是重複的驗證流程。每一次請求，API 伺服器都必須重新執行安全分類器（Safety Classifiers）來檢查內容是否違規，以及驗證請求的合法性。
最後是網路往返延遲。頻繁地建立與斷開 TCP 連線，在需要數十次來回的 Agent 循環中，這些微小的延遲會迅速累積成可感知的等待時間。
利用 WebSockets 建立持久化狀態
為了打破這個瓶頸，OpenAI 選擇導入 WebSockets。WebSockets 是一種在單一 TCP 連線中提供全雙工通訊的協定，讓客戶端與伺服器可以持續保持連線，而不需要每次都重新握手。
在技術實作上，他們將 WebSockets 作為一個狀態快取（State Cache）的載體。當連線建立後，伺服器會在記憶體中保留該次會話的狀態，包括之前的回應物件、輸入輸出項目以及工具定義。
當開發者使用 previous_response_id 延續對話時，伺服器不再從頭重建上下文，而是直接從記憶體快取中擷取狀態。這樣一来，安全掃描只需處理新增的片段，Token 化處理也能省略重複部分，大幅降低了首次 Token 生成時間（TTFT, Time To First Token）。
將本地工具呼叫視為非同步事件
在更進階的原型設計中，OpenAI 嘗試將 Agent 的工具執行過程整合進單次回應循環中。
具體作法是利用 asyncio 進行非同步等待。當模型輸出一個工具呼叫（Tool Call）時，API 不會直接結束請求，而是進入等待狀態並發送一個事件給用戶端。用戶端執行完本地工具後，透過 WebSocket 回傳結果，這會觸發伺服器解除等待並繼續生成 Token。
這種設計將原本多次的 API 請求簡化為一次長時間執行的回應，讓推論前處理（Pre-processing）與後處理（Post-processing）只需執行一次，極大化地利用了 GPU 的推論效率。
實務影響與效能表現
這項優化在高速模型（如 GPT-5.3-Codex-Spark）上效果最為顯著。當推論速度達到每秒 1,000 個 Token 甚至 4,000 個 Token 時，API 的低延遲至關重要。
從實際應用端來看，整合此模式後，Vercel AI SDK 的延遲降低了 40%，Cline 的多檔案工作流速度提升 39%，Cursor 的模型速度也提升了 30%。
對於工程師來說，這給了我們一個重要的啟示：當底層運算單元（如 GPU）的效能發生數量級跳躍時，上層的傳輸協定與狀態管理邏輯必須同步演進。如果依然依賴傳統的無狀態 HTTP 請求，硬體帶來的速度紅利將會被軟體架構的開銷所抵消。
來源：openai.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。