当你要求 Codex 修复一个错误时，它会扫描你的代码库以寻找相关文件，阅读这些文件以构建上下文，进行编辑，并运行测试以验证修复是否生效。在底层，这意味着数十次往返的 Responses API 请求：确定模型的下一步操作、在你的电脑上运行工具、将工具输出发回 API，如此往复。

所有这些请求累计起来，可能导致用户在等待 Codex 完成复杂任务时耗费数分钟。从延迟的角度来看，Codex 智能体循环的大部分时间花在三个主要阶段：API 服务端处理（验证和处理请求）、模型推理以及客户端时间（运行工具并构建模型上下文）。推理是模型在 GPU 上运行并生成新 Token 的阶段。过去，在 GPU 上运行大语言模型 (LLM) 推理是智能体循环中最慢的部分，因此 API 服务的开销很容易被掩盖。随着推理速度不断提升，在一次完整的智能体执行过程中，累积的 API 开销变得更加显著。

在这篇文章中，我们将解释如何通过 API 将智能体循环的端到端速度提升 40%，从而让用户切实体验推理速度从每秒 65 个 Token 跃升至近 1,000 个 Token。我们通过缓存、消除不必要的网络跳转、优化安全堆栈以快速标记问题，以及最重要的一点 — 构建一种与 Responses API 建立持久连接的方法，来取代一系列同步 API 调用，从而实现了这一目标。

在 Responses API 中，此前像 GPT‑5 和 GPT‑5.2 这样的旗舰模型运行速度大约为每秒 65 个 Token (TPS)。而在发布专门针对编程优化的快速模型 GPT‑5.3‑Codex‑Spark 时，我们的目标是实现数量级的飞跃：通过针对 LLM 推理优化的特定 Cerebras 硬件，使速度超过 1,000 TPS。为了确保用户能体验到这款新模型的真实速度，我们必须降低 API 开销。

2025 年 11 月左右，我们针对 Responses API 展开了一场性能冲刺 (sprint)，在单次请求的关键路径延迟 (critical-path latency) 方面进行多项优化：

凭借这些改进，首个 Token 生成时间 (TTFT) 缩短了近 45% — 这直观反映了 API 的响应速度。然而，对于 GPT‑5.3‑Codex‑Spark 来说，这些改进依然不够。即便有了这些优化，Responses API 的开销相对于模型的推理速度而言仍然过大。也就是说，用户必须先等待运行 API 的 CPU 完成处理，才能使用运行模型的 GPU。

更深层的问题在于架构：我们将 Codex 的每次请求都视为独立的，在每一次后续请求中都要重复处理对话状态和其他可重用的上下文。即便对话的大部分内容没有变化，我们仍需为处理完整历史记录承担相应的计算开销。随着对话长度增加，这种反复处理的成本也随之增加。

为了进一步优化设计，我们重新构思了传输协议：与其通过 HTTP 建立新连接并在每次后续请求中发送完整对话历史，我们是否可以维持一个持久连接并对状态进行缓存？核心思路是：仅发送需要验证和处理的新信息，并在连接存续期间将可重用的状态保留在内存中。这将有效减少重复工作带来的开销。

我们权衡了几种不同的方案，包括 WebSocket 和 gRPC 双向流。最终我们选择了 WebSocket，因为作为一个简单的消息传输协议，它无需用户更改其 Responses API 的输入和输出结构。它对开发者非常友好，且能以极小的改动接入我们现有的架构。

第一个 WebSocket 原型彻底改变了我们对 Responses API 延迟的认知。一位在 API 堆栈领域拥有深厚专业知识的 Codex 团队工程师，通过让 Codex 智能体运行一整晚，成功构建出了一个原型。

在该原型中，智能体的一次完整执行过程被建模为一个长时间运行的单一响应。利用 asyncio 特性，在采样出工具调用后，Responses API 会在采样循环中进入异步等待状态，并向客户端发送一个 response.done 事件。客户端在执行完工具调用后，会发回一个包含工具结果的 response.append 事件，从而恢复采样循环的执行，让模型继续运行。

这里有一个类比：我们将本地工具调用视作由平台执行的工具调用。当模型调用网页搜索时，推理循环会阻塞、调用搜索服务，并将服务响应放入模型上下文中。在我们的设计中，整体机制是相同的；只不过我们没有调用远程服务，而是通过 WebSocket 将模型的工具调用指令发回给客户端。当客户端响应后，我们将客户端提供的工具调用结果放入上下文并继续进行采样。

这种设计极其高效，因为它消除了智能体在多次完整的执行过程中重复的 API 处理工作。我们只需在开始时进行一次预推理 (pre-inference) 工作，在工具执行期间暂停，并在最后执行一次后推理 (post-inference) 工作即可。

遗憾的是，这种方案的代价是 API 结构变得陌生且复杂。我们希望开发者能够直接接入 WebSocket 支持，而无需围绕全新的交互模式重写其 API 集成逻辑。

在最终发布的版本中，我们回归了开发者熟悉的交互形式：继续使用相同的 response.create请求体，并引入 previous_response_id 字段来承接上一条响应状态中的对话上下文。

在 WebSocket 连接中，服务器会维护一个连接级别 (connection-scoped) 的内存缓存，用于存储之前的响应状态。当后续的 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 团队的紧密协作，我们仅用几周时间就实现了从构思到生产环境上线的飞跃。它不仅大幅降低了智能体任务在完整执行过程中的延迟，还满足了开发者日益增长的需求：随着模型推理速度的提升，其周边的服务和系统也必须同步提速，从而让这些性能提升真正体现在用户体验上。