用 Responses API 中的 WebSockets 加速 agentic 工作流

2026年4月22日

作者：Brian Yu 和 Ashwin Nathan，Technical Staff 成员

正在加载…分享当你要求 Codex 修复一个 bug 时，它会扫描你的 codebase，查找相关文件，读取这些文件以构建 context，进行编辑，并运行测试来验证修复是否生效。在底层，这意味着要进行数十次来回的 Responses API 请求：确定模型的下一步 action，在你的计算机上运行一个 tool，将 tool output 发回 API，然后重复这一过程。

所有这些请求加在一起，可能会让用户等待数分钟，直到 Codex 完成复杂任务。从 latency 的角度看，Codex agent loop 的大部分时间花在三个主要阶段：API services 中的处理（用于验证和处理请求）、model inference，以及 client-side time（运行 tools 并构建 model context）。Inference 是模型在 GPU 上运行以生成新 token 的阶段。过去，在 GPU 上运行 LLM inference 是 agentic loop 中最慢的部分，因此 API service overhead 很容易被掩盖。随着 inference 变得更快，agentic rollout 中累积的 API overhead 就明显得多。

在本文中，我们会解释如何让使用 API 的 agent loops 端到端提速 40%，让用户能够感受到 inference speed 从每秒 65 个 token 提升到接近每秒 1,000 个 token 的变化。我们通过 caching、消除不必要的 network hops、改进 safety stack 以快速标记问题，以及——最重要的是——构建一种与 Responses API 建立 persistent connection 的方式来实现这一点，而不是必须发起一系列 synchronous API calls。

当 API 成为瓶颈时在 Responses API 中，之前的旗舰模型如 GPT‑5 和 GPT‑5.2 的运行速度约为每秒 65 个 token（TPS）。为了发布 GPT‑5.3‑Codex‑Spark 这个快速 coding model，我们的目标是实现数量级提升：超过 1,000 TPS，这由针对 LLM inference 优化的专用 Cerebras hardware 支持。为了确保用户能够体验到这个新模型的真实速度，我们必须降低 API overhead。

大约在 2025 年 11 月，我们围绕 Responses API 启动了一轮 performance sprint，为单个请求的 critical-path latency 落地了许多优化：

通过这些改进，我们看到 time to first token（TTFT）提升了接近 45%——TTFT 反映的是 API 给人的响应速度——但这些改进对 GPT‑5.3‑Codex‑Spark 来说仍然不够快。即便有这些改进，相对于模型速度，Responses API overhead 仍然过大；也就是说，用户在使用服务模型的 GPU 之前，必须等待运行我们 API 的 CPU。

更深层的问题是结构性的：我们把每个 Codex 请求都当作独立请求来处理，在每个后续请求中都处理 conversation state 和其他可复用 context。即使大部分 conversation 并未改变，我们仍然要为与完整历史相关的工作付出成本。随着 conversation 变长，这种重复处理会变得更加昂贵。

为了收紧设计，我们重新思考了 transport protocol：能否保持一个 persistent connection 并缓存 state，而不是每次后续请求都通过 HTTP 建立新连接并发送完整的 conversation history？思路是只发送任何需要验证和处理的新信息，并在连接生命周期内将可复用 state 缓存在内存中。这样可以减少冗余工作带来的 overhead。

我们考虑了几种不同方案，包括 WebSockets 和 gRPC bidirectional streaming。最终选择 WebSockets，是因为它作为一种简单的 message transport protocol，用户不需要改变 Responses API 的 input 和 output 形状。它对开发者友好，并且能以很小的扰动适配我们现有的架构。

第一个 WebSocket prototype 改变了我们对 Responses API latency 可能性的判断。Codex 团队中一位对 API stack 有深厚经验的工程师，通过让 Codex agent 运行了一整夜，搭出了一个 prototype。

在那个 prototype 中，agentic rollouts 被建模为一个长期运行的 Response。借助 asyncio 特性，Responses API 会在 tool call 被采样后，在 sampling loop 中异步阻塞，并向 client 发回一个 response.done event。在执行 tool call 之后，clients 会发回一个带有 tool result 的 response.append event，从而解除 sampling loop 的阻塞，让模型继续运行。

这里可以类比为把本地 tool call 当作 hosted tool call 处理。当模型调用 web search 时，inference loop 会阻塞，调用 web search service，并把 service response 放入 model context。在我们的设计中，我们做了同样的事情；但不是调用 remote service，而是通过 WebSocket 将模型的 tool call 发回 client。当 client 响应后，我们将 client 的 tool call response 放入 context，并继续采样。

这个设计非常有效，因为它消除了 agent rollout 中重复的 API 工作。我们可以只做一次 preinference work，在 tool execution 时暂停，并在最后只做一次 postinference work。

遗憾的是，这带来的代价是 API 形状不那么熟悉，也更复杂。我们希望开发者能够直接加入 WebSocket support，而不必围绕新的交互模式重写他们的 API integration。

在最终发布的版本中，我们切回了熟悉的形状：继续使用带有相同 body 的 response.create，并使用 previous_response_id 从前一个 response 的 state 继续 conversation context。

在 WebSocket connection 上，server 会维护一个 connection-scoped、in-memory cache，用于保存 previous response state。当后续 response.create 包含 previous_response_id 时，我们会从 cache 中获取该 state，而不是从头重建完整 conversation。

这个 cached state 包括：

通过复用 in-memory previous response state，我们得以落地几项主要优化：

目标是在保持开发者已经理解并围绕其构建的 API 形状的同时，尽可能接近 minimal-overhead prototype。

经过两个月构建 WebSocket mode 的 sprint 后，我们与关键 coding agent startups 一起发布了 alpha，以便他们将其集成进自己的 infrastructure，并安全地逐步提升 traffic。Alpha 用户很喜欢它，并报告其 agentic workflows 最高提升了 40%⁠（在新窗口中打开）。鉴于 alpha 反馈积极，我们已经准备好发布。

发布结果立竿见影。Codex 很快将其大部分 Responses API traffic 切换到 WebSocket mode，并看到显著的 latency improvements。对于 GPT‑5.3‑Codex‑Spark，我们达到了 1,000 TPS 的目标，并观察到最高 4,000 TPS 的突发，表明 Responses API 能够在真实 production traffic 中跟上快得多的 inference。影响也很快出现在开发者社区中：

WebSocket mode 是 Responses API 自 2025 年 3 月发布以来最重要的新能力之一。通过 OpenAI 的 API 和 Codex 团队紧密协作，我们在短短几周内从想法走到 production 运行。它不仅显著改善了 agent rollout latency，也支持了 builders 日益增长的需求：随着 model inference 变得更快，围绕 inference 的 services 和 systems 也需要加速，才能把这些收益传递给用户。

Brian Yu，Ashwin Nathan

特别感谢参与创建 WebSocket mode 的 Responses API 和 Codex 团队。

Engineering 2026年4月27日

Engineering 2026年3月11日

Engineering 2026年2月13日