在Responses API中使用WebSocket加速代理工作流

# 使用 WebSocket 加速 Responses API 中的智能体工作流 原文：https://openai.com/index/speeding-up-agentic-workflows-with-websockets/ 当你让 Codex 修复一个 Bug 时，它会扫描你的代码库找到相关文件，读取它们以构建上下文，进行修改，并运行测试来验证修复是否生效。在底层，这意味着数十次 Responses API 请求的往返：确定模型的下一步行动、在你的计算机上运行工具、将工具输出结果发送回 API，然后重复这个循环。 所有这些请求加起来可能需要几分钟，用户在这段时间里只能等待 Codex 完成复杂任务。从延迟的角度来看，Codex 智能体循环的大部分时间花在三个主要阶段：在 API 服务中工作（用于验证和处理请求）、模型推理，以及客户端时间（运行工具和构建模型上下文）。推理是模型在 GPU 上运行以生成新 token 的阶段。过去，在 GPU 上运行 LLM 推理是智能体循环中最慢的部分，因此 API 服务的开销很容易被隐藏。随着推理速度越来越快，来自智能体滚动（agentic rollout）的累积 API 开销变得明显得多。 在这篇文章中，我们将解释如何使使用 API 的智能体循环端到端速度提升 40%，让用户体验到推理速度从每秒 65 token 跃升至接近每秒 1000 token 的提升。我们的实现方法包括：缓存、消除不必要的网络跳转、改进我们的安全栈以快速标记问题，以及最重要的是——构建一种与 Responses API 建立持久连接的方式，而不是进行一系列同步 API 调用。 ## 当 API 成为瓶颈时 在 Responses API 中，之前的旗舰模型如 GPT-5 和 GPT-5.2 运行速度大约为每秒 65 个 token（TPS）。为了推出 GPT-5.3-Codex-Spark（一个快速的编码模型），我们的目标是提升一个数量级：超过 1000 TPS，这得益于专门为 LLM 推理优化的 Cerebras 硬件。为了确保用户能够体验到这种新模型的真正速度，我们必须减少 API 开销。 大约在 2025 年 11 月，我们针对 Responses API 发起了一次性能冲刺，对单次请求的关键路径延迟进行了多项优化： - 在内存中缓存渲染后的 token 和模型配置，以跳过多次轮对话中昂贵的分词和网络调用 - 通过消除对中间服务的调用（例如图片处理分辨率）并直接调用推理服务本身，减少网络跳转延迟 - 改进我们的安全栈，以便能够运行某些分类器更快地标记对话 通过这些改进，我们看到了首 token 时间（TTFT）接近 45% 的提升——这反映了 API 的响应速度——但这些改进对于 GPT-5.3-Codex-Spark 来说仍然不够快。即使有了这些改进，相对于模型的速度，Responses API 的开销仍然过大——也就是说，用户必须等待运行我们 API 的 CPU 完成后，才能使用提供模型服务的 GPU。 更深层次的问题在于结构性的：我们将每个 Codex 请求视为独立的，在每次后续请求中处理对话状态和其他可重复使用的上下文。即使对话的大部分内容没有改变，我们仍然要承担与完整历史记录相关的工作。随着对话变长，这种重复处理的开销也越来越大。 ## 构建持久连接 为了收紧设计，我们重新思考了传输协议：我们能否保持持久连接并缓存状态，而不是通过 HTTP 建立新连接并在每次后续请求中发送完整的对话历史记录？这个想法是只发送需要验证和处理的新信息，并在连接的生命周期内将可复用的状态缓存在内存中。这将减少冗余工作带来的开销。 我们考虑了几种不同的方法，包括 WebSocket 和 gRPC 双向流。我们最终选择了 WebSocket，因为作为一种简单的消息传输协议，用户不需要改变他们的 Responses API 输入和输出格式。它对开发者友好，并且与我们现有的架构兼容，几乎不需要进行改动。 第一个 WebSocket 原型改变了我们对 Responses API 延迟可能性的认知。Codex 团队中一位对 API 栈有深厚专业知识的工程师，通过运行一个 Codex 代理通宵攒出了一个原型。 在那个原型中，智能体滚动被建模为一个长时间运行的单个 Response。利用 `asyncio` 特性，Responses API 在采样到工具调用后会异步阻塞在采样循环中，然后 Responses API 会向客户端发送一个 `response.done` 事件。在执行工具调用后，客户端会发送回一个带有工具结果的 `response.append` 事件，这会使采样循环解除阻塞，让模型继续运行。 这里的一个类比是将本地工具调用视为托管工具调用。当模型调用网络搜索时，推理循环会阻塞，调用一个网络搜索服务，并将服务响应放入模型上下文中。在我们的设计中，我们做了同样的事情；但不是调用远程服务，而是通过 WebSocket 将模型的工具调用发送回客户端。当客户端响应时，我们将客户端的工具调用响应放入上下文中，并继续采样。 这个设计极其有效，因为它消除了智能体滚动过程中重复的 API 工作。我们可以一次性完成推理前的工作，暂停等待工具执行，最后在结束时一次性完成推理后的工作。 不幸的是，这是以牺牲 API 的熟悉度和复杂度为代价的。我们希望开发者能够直接引入 WebSocket 支持，而不必围绕新的交互模式重写他们的 API 集成。 ## 保持 API 的熟悉感，同时让栈变为增量式 对于发布版本，我们切换回了一个熟悉的形态：继续使用相同 body 的 `response.create`，并使用 `previous_response_id` 来延续前一个响应状态中的对话上下文。 在 WebSocket 连接上，服务器会维护一个连接范围内的内存缓存，用于存储前一个响应的状态。当后续的 `response.create` 包含 `previous_response_id` 时，我们从缓存中获取该状态，而不是从头开始重建整个对话。 该缓存状态包括： - 之前的 `response` 对象 - 之前的输入和输出项 - 工具定义和命名空间 - 可复用的采样制品，例如之前渲染过的 token 通过重用内存中的前一个响应状态，我们实现了几个重要的优化： - 让某些安全分类器和请求验证器只处理新的输入，而不是每次都处理完整的历史记录 - 维护一个追加式渲染 token 的内存缓存，以便跳过不必要的分词 - 跨请求复用成功的模型解析/路由逻辑 - 将非阻塞的后推理工作（如计费）与后续请求重叠进行 目标是尽可能接近最小开销的原型，同时使用开发者已经理解并构建过的 API 形态。 ## 设定速度新标准 经过两个月的 WebSocket 模式开发冲刺，我们向关键的编码智能体初创公司发布了 alpha 版本，让他们将其集成到自己的基础设施中，并安全地增加流量。Alpha 用户非常喜欢，报告称他们的智能体工作流**提升了高达 40%**[（在新窗口中打开）](https://x.com/aisdk/status/2026031263925039591)。鉴于 alpha 的积极反馈，我们准备公开发布。 发布结果立竿见影。Codex 迅速将其大部分 Responses API 流量切换到 WebSocket 模式，延迟显著降低。对于 GPT-5.3-Codex-Spark，我们达到了 1000 TPS 的目标，并观察到爆发式增长高达 4000 TPS，表明 Responses API 能够在实际生产流量中跟上更快的推理速度。这种影响也迅速在开发者社区中显现： - Codex 迅速将其大部分流量切换到 WebSocket 模式。使用最新模型（如 [GPT-5.3-Codex](https://developers.openai.com/api/docs/models/gpt-5.3-codex)、[GPT-5.4](https://developers.openai.com/api/docs/models/gpt-5.4) 及更高版本）的 Codex 用户都受益于 WebSocket 模式的速度提升。 - Vercel 将 WebSocket 模式集成到 AI SDK 中，延迟**降低高达 40%**[（在新窗口中打开）](https://x.com/aisdk/status/2026031263925039591)。 - Cline 的多文件工作流**提速 39%**[（在新窗口中打开）](https://x.com/cline/status/2026031848791630033)。 - Cursor 中的 OpenAI 模型**提速高达 30%**[（在新窗口中打开）](https://x.com/leerob/status/2026030244407468259)。 WebSocket 模式是自 2025 年 3 月 Responses API 发布以来最重要的新功能之一。通过 OpenAI 的 API 和 Codex 团队的紧密合作，我们仅用了几周时间就从想法走到了生产运行。它不仅极大地改善了智能体滚动的延迟，还满足了构建者日益增长的需求：随着模型推理速度越来越快，围绕推理的服务和系统也需要加速，才能将这些增益传递给用户。