OpenAI 于 2026 年 4 月 22 日发布文章 Speeding up agentic workflows with WebSockets in the Responses API，说明可在 Responses API 上使用 WebSocket 传输：面向 模型—工具 高频往返的 Agent 场景（文中以类似 Codex 的编码代理工作流为例）。

官方口径中的要点

依据该文与平台文档 WebSocket mode 章节：

  • 长连接 — 客户端维持到 /v1/responses 的 WebSocket，每轮发送 response.create，用 仅包含新增内容的 input 配合 previous_response_id 接续会话。
  • 请求形态延续 — 正式版本仍基于熟悉的 response.create 与 previous_response_id；服务端在连接维度缓存 上一则 response 的状态，减少在较长 rollout 上重复处理完整历史的开销。
  • 动机 — 文章称随 推理侧吞吐提升，在长 Agent 循环里 API 服务侧累计延迟 变得更显眼；WebSocket 与相关优化针对该瓶颈。

与 Agent 循环的关系

OpenAI 将典型循环描述为：模型决定动作 → 执行工具 → 将工具结果送回 API → 重复。在 HTTP 下每个 follow-up 可能重复携带大量状态工作；在 WebSocket 上，通过连接内缓存与 previous_response_id，文档说明可降低 长链路上的续写开销。

谁应评估该能力

  • 已在 Responses API 上搭建 重工具 Agent 的团队。
  • 需要按文档约束做 顺序执行 的路由层（单连接 同一时间仅一单在飞）。
  • 使用 store=false 或 ZDR 的部署——文档说明了与缓存/续写相关的限制与错误行为。

上线核对（对照官方文档）

  • 连接行为与限额：例如约 60 分钟 连接时长上限、串行 响应、无多路复用 ——需要并行时准备多条连接。
  • 重连与恢复：连接关闭或触达时限后建新 WebSocket；处理 previous_response_not_found 等文档列出的情况。
  • 错误码：包含 websocket_connection_limit_reached 等，勿仅依赖静默重试。

常见问题

WebSocket 模式下的 Responses API 指什么？

指通过 WebSocket 连接 /v1/responses，按文档发送 response.create（载荷与 HTTP 创建请求对齐，除传输相关字段），并以 previous_response_id 与 增量 input 续写。

是否换了一条产品线？

不是。OpenAI 将其表述为在 熟悉集成形态 下降低长 Agent 续写阶段成本的 传输选项。

权威出处？

动机与架构见 2026-04-22 文章 Speeding up agentic workflows with WebSockets in the Responses API；接入细节、限额、压缩与错误见平台文档 WebSocket mode。

信息来源：OpenAI — Speeding up agentic workflows with WebSockets in the Responses API（技术说明：WebSocket mode）。