OpenAI 给 Responses API 加了 WebSocket 模式，为什么 Agent 能快 40%？

前两天刷推看到 Cursor 的 AI 教育负责人 Lee Robinson 发了条推：

All OpenAI models in Cursor are now up to 30% faster! We’ve upgraded all users to WebSockets with their Responses API.

Cursor 里所有 OpenAI 模型快了 30%，原因是接入了 WebSocket 模式。

这不是模型推理变快了，而是 传输协议换了。

先说结论

OpenAI 官方文档给出的数字：

For rollouts with 20+ tool calls, we have seen up to roughly 40% faster end-to-end execution.

20 轮以上的工具调用，端到端快 40%。Cline 团队的独立测试也验证了这个数字：简单任务快 15%，复杂多文件编码接近 40%。

但如果只是普通 chat（单轮问答），几乎没区别。

所以关键问题是：这 40% 到底从哪省出来的？

HTTP 模式：每轮都从零开始

传统的 Responses API 走 HTTP + SSE（Server-Sent Events）。每次工具调用的流程是：

客户端 → TCP 三次握手 → TLS 握手 → 发送完整 HTTP 请求（含全部对话历史）→ 等流式响应 → 连接结束
客户端 → TCP 三次握手 → TLS 握手 → 发送完整 HTTP 请求（含全部对话历史）→ 等流式响应 → 连接结束
...重复 N 次

每一轮都有两类开销：

1. 连接开销

• TCP 三次握手：1 个 RTT
• TLS 1.3 握手：1 个 RTT（首次 2 个）
• HTTP 请求/响应头：几百字节到几 KB

2. 数据开销

这是更大的瓶颈——每次请求都要重传完整的对话上下文。一个 Agent 在编码过程中调用了 15 次工具，到第 15 轮时，请求体里包含了前 14 轮的全部内容。上下文越长，重传越慢。

WebSocket 模式：一次握手，增量传输

客户端 → TCP 握手 → TLS 握手 → HTTP Upgrade → WebSocket 连接建立
       → response.create（首次请求，含完整输入）
       ← 流式响应 + response_id
       → response.create（仅 previous_response_id + 新的工具输出）
       ← 流式响应 + response_id
       → response.create（仅 previous_response_id + 新的工具输出）
       ← 流式响应
       ...连接保持，直到任务完成

两个核心优化：

1. 连接复用

握手只做一次。后续所有消息在同一条 TCP 连接上双向传输，零额外握手开销。

2. 增量传输

这是真正的杀手级优化。后续每轮只需要发送：

• previous_response_id：告诉服务器"接着上次继续"
• 新增的输入（工具返回值、用户新消息）

服务器端在连接级内存缓存中保持了最近一次 response 的状态，不需要客户端重传完整上下文。

量化对比

假设一个典型的 Agent 编码任务有 15 轮工具调用，客户端到 OpenAI 的 RTT 约 80ms：

仅握手开销就省了 2.24 秒。加上上下文不再重传（到后面几轮，上下文可能有几十 KB），以及服务端内存缓存省掉的恢复时间，总提速 30-40% 完全合理。

还有两个巧妙设计

Warmup 预热

可以发送 generate: false 的请求，预加载工具定义和 system instructions，但不触发生成。返回一个 response_id，后续真正的请求可以直接 chain 上去——第一轮响应也能享受缓存加速。

和 Compaction 配合

当上下文超过 token 限制时，可以调用 /responses/compact 端点做服务端压缩。压缩后的上下文作为新起点继续，不需要客户端自己做截断。

什么时候用 WebSocket，什么时候不用

限制：

• 连接最长 60 分钟，超时需重连
• 单条连接串行执行，不能多路复用
• 缓存只保留最近一次 response，store=false 下旧 ID 无法恢复

总结

WebSocket 模式不是什么黑科技，而是一个工程上非常务实的优化——把 N 次独立的 HTTP 往返，变成 1 条持久连接上的 N 次消息交换。

核心收益来自两处：

1. 省掉 N-1 次 TCP/TLS 握手
2. 增量传输替代全量重传（客户端和服务端都省）

这也解释了为什么"普通 chat 就算了"——单轮对话 N=1，没有增量可省。但对于 Cursor、Cline 这类每个编辑动作都可能触发 API 调用的工具来说，N 可以轻松到 20+，40% 的提速就是实实在在的体感改善。

参考链接：

• OpenAI 官方文档：WebSocket Mode
• H2S Media：OpenAI WebSocket API Cuts Agent Workflow Latency by Up to 40%
• MarkTechPost：Beyond Simple API Requests
• OpenAI Developer Community 讨论