OpenAI 针对其响应 API 引入了基于 WebSocket 的执行模式，旨在提升编码代理和实时 AI 系统中使用的代理工作流的性能。这一变更将传统的 HTTP 请求-响应模式替换为客户端与服务器之间的持久化双向连接，可以解决多步骤推理工作流中的延迟和协调开销问题。据 OpenAI 称，早期生产环境的使用数据显示，在高并发场景下，延迟降低了多达 40%，吞吐量也得到了提升。

本次更新解决了代理系统中日益突出的瓶颈问题。此前，工作流中的每个步骤（例如工具调用、中间推理和后续查询）都需要单独的 HTTP 请求。随着推理速度的提升，这些多次反复的网络往返时间逐渐成为延迟和运维复杂性的主要来源。

传统 HTTP 流程（图片来源：OpenAI 博客）

基于 WebSocket 的执行模式利用了长期存在的双向连接，不用重复握手就可以进行持续的数据交换。这可以支持流式响应、更快的工具执行以及多步骤工作流的高效协调。这种设计符合分布式系统中的事件驱动设计模式，通过跨交互维护状态来提升响应速度和吞吐量。这一变更体现了对代理系统传输层的更广泛关注——正如“AI 代理传输层”一文中所讨论的，通信模式和连接管理会影响整体性能。

Vibe Coder Ofek Shaked 将这一变更描述为：

将 WebSockets 用于代理状态管理，是一个显而易见的重大优势。从此，冷启动再也不会让你的多工具链瘫痪了。

OpenAI 报告称，在早期生产环境应用中，延迟降低了多达 40%，同时保持了约 1000 次/秒的持续吞吐量，峰值吞吐量可达 4000 次/秒。这些结果表明，除了模型层面的改进外，传输层面的优化也显著影响了端到端 AI 系统的性能。

OpenAI DX 工程师 Gabriel Chua 表示：

你可以先发送系统提示和工具定义来预热连接。该功能兼容零数据保留（ZDR）标准。

开发工具和编码代理平台迅速采纳了这一技术。Vercel 将其 WebSocket 模式集成到了 AI SDK 中，并报告称延迟降低了多达 40%。Cline 发现，多文件工作流的性能提升了 39%，而 Cursor 则报告称性能提升高达 30%。从这些结果可以明显看出，模型本身之外的系统级优化正日益影响着现实世界中 AI 的性能表现。

基于持久会话的代理工作流演进（图片来源： OpenAI 博客）

从实现角度来看，开发人员通过用单个持久会话取代多个 HTTP 调用来集成 WebSocket 模式。这减少了重复建立连接的过程，并简化了多步骤工作流中的协调逻辑，此外还增强了对流式处理用例的支持，例如增量代码生成和交互式推理。在这些场景中，部分输出可以在生成后立即被使用。

微软工程师 Kevin Cho 指出，这种方法反映出：

回归到原始软件栈的问题。WebSockets 和有状态连接。

这次转变引入了新的系统设计考量，包括连接生命周期管理、高并发下的背压以及分布式系统的可靠性，这些设计均与成熟的有状态系统模式相契合。

经过为期两个月的测试，OpenAI 已经向包括 Codex 在内的部分合作伙伴发布了该功能的 Alpha 版本。此后，Codex 已经将大部分 Responses API 流量迁移至 WebSocket 模式，这表明该功能已经具备投入生产环境的条件。

原文链接：https://www.infoq.com/news/2026/05/openai-websocket-responses-api/