OpenAI 在“长时间运行、多工具调用”这类复杂多步骤场景中，悄然完成了一次重要升级。此次迭代的核心，是为 Responses API 新增了 WebSocket 通信模式。

简而言之，这一模式专门服务于“模型与工具之间频繁交互”的工作流。例如代码自动化任务，或是需要反复调用外部工具的智能体编排流程——过去执行时总感觉“拖泥带水”，如今终于迎来了更高效的解决方案。

核心改进：从“拨号”到“连麦”

这次改进的本质，在于重塑了模型与工具之间的连接方式。传统的 HTTP 请求模式下，每次交互都必须将完整上下文重新发送一遍。这好比每次打电话都要从头介绍“我是谁、从哪来、要做什么”，效率自然大打折扣。

而 WebSocket 模式则建立起一条持久连接。用户只需传递新输入的内容以及上一次响应的 ID（previous_response_id），大量重复的传输开销便随之消除。

建立连接的方式十分直接：

（代码示例：创建 WebSocket 连接）

后续交互更加轻盈，仅需发送增量数据：

（代码示例：通过增量数据继续对话）

性能提升究竟有多实在？

数据最有说服力。对于涉及 20 次以上工具调用的复杂任务，端到端的执行速度可提升 20% 至 40%。这一提升并非偶然，而是得益于连接级的内存缓存机制——服务器会在内存中保留最近一次响应的状态，下次无需从头再来。

设想一个完整的代码重构流程：分析代码 → 定位问题 → 生成修复方案 → 应用修改 → 验证结果。每一步只需发送增量数据，整个链条自然运行得更加顺畅。

技术细节与边界条件：别忽略这些限制

在技术层面，WebSocket 模式兼容零数据保留（ZDR）以及 store=false 配置，这对隐私敏感场景无疑是个利好。不过需要留意一个硬性限制：连接最长只能维持 60 分钟。超时后需要重新建立连接。

（代码示例：处理连接超时的逻辑）

另一个值得关注的点是：当前该模式不支持多路复用。若你需并行运行多个独立的智能体任务，就不得不为每个任务建立单独的 WebSocket 连接。这一限制在架构设计时需提前纳入考量。

这次更新意味着什么？

此外，一个值得留意的信号是，此次更新与 Open Responses 规范密切相关。Open Responses 是一个开源项目，旨在为不同 LLM 提供商建立统一的 API 标准，目前已获得 Vercel、Hugging Face、Databricks 等公司支持。

从开发者社区的反馈来看，这一功能备受关注，尤其是那些正在构建复杂智能体系统的团队。当然，也有声音指出，这可能是一种增加供应商锁定的策略——毕竟状态管理越好，迁移成本也越高。

话说回来，对于大多数简单的对话场景，该功能或许并非必需。但如果你正在开发需要大量工具调用的智能体——例如代码审查助手、数据分析流水线或复杂的业务流程自动化——那么这次更新绝对值得投入时间深入探索。