想象一下：你让 AI 助手帮你写一个程序，它需要查阅文档、搜索代码、多次调试，整个过程可能要调用几十次工具。如果每次交互都要"从头开始"介绍任务，效率会有多低？

OpenAI 最新推出的 WebSocket 模式，正是为了解决这个痛点。

在 WebSocket 模式出现之前，开发者与 OpenAI API 的交互主要依赖 HTTP 请求。每次 AI 需要调用工具、等待结果、再继续执行时，客户端都要重新建立连接，把之前的对话历史、工具调用的完整上下文全部重新发送一遍。

这就好比每次你和朋友说话，都要先把之前的聊天记录全文朗读一遍，然后再提出新问题。对于涉及几十次工具调用的复杂任务，这种"重复叙述"带来的开销会显著拖慢整体响应速度。

WebSocket 模式的核心思路就是：保持连接，不要重复。

当开发者首次建立 WebSocket 连接后，这个连接会一直保持打开状态。AI 执行过程中需要继续对话时，客户端只需发送增量信息，再加上一个标识符（previous_response_id）告诉服务器"接着上次继续"。

这种设计带来两个关键优势。首先是延迟降低：服务器已经在内存中缓存了上次的响应状态，不需要重新加载历史上下文，处理速度自然更快。其次是带宽节省：每次传输的数据量大幅减少，网络开销显著降低。

OpenAI 的测试数据显示，对于包含 20 次以上工具调用的工作流，WebSocket 模式可以实现约 40% 的端到端执行速度提升。

为什么这个改进对 AI 代理非常重要？

一个典型的 Agent 工作流程可能是这样的：用户让 AI"帮我搭建一个网站"，AI 先搜索最佳框架，接着编写后端代码，然后调用测试工具检查，测试失败后修正代码，再次测试……整个过程可能涉及数十次工具调用和结果反馈。

在传统 HTTP 模式下，每一次"调用工具—返回结果—继续执行"的循环都要经历完整的连接建立和上下文传递流程。而在 WebSocket 模式下，这些循环可以在同一条连接上顺畅进行，每次只传递必要的增量信息。这不仅是速度的提升，更是工作流体验的根本改善。

在实际应用中，开发者需要注意几个关键限制。

单个 WebSocket 连接一次只能处理一个响应，不支持并行多任务处理。如果需要同时运行多个任务，需要建立多个连接。每条连接的存活时间上限为 60 分钟，超时后需要重新建立连接。

另外，如果某次请求失败，服务器会清除与该失败响应相关的本地缓存，防止后续复用过期或错误的状态信息。

当 AI 助手能够更快速、更连续地完成复杂任务时，开发者可以更放心地让 AI 承担更复杂的自动化工作。用户也会感受到 AI 回复更加即时、对话更加连贯。

这种底层技术的改进，最终会转化为更优质的 AI 应用体验。

参考资料：https://developers.openai.com/api/docs/guides/websocket-mode