# OpenAI 给 Responses API 加了 WebSocket，让 Codex 这类 agent 跑起来更快

> 原标题：Speeding up agentic workflows with WebSockets in the Responses API

- 来源：OpenAI News
- 发布时间：2026-04-22T10:00:00.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/8624
- 原文：https://openai.com/index/speeding-up-agentic-workflows-with-websockets

## 摘要

OpenAI 发现，当模型推理速度从每秒 65 个 token 飙到近 1000 个 token 时，API 本身的处理开销反而成了拖慢 agent 循环的瓶颈。他们给 Responses API 加上了 WebSocket 支持，思路是把多次独立的 HTTP 请求换成一个长连接，在连接存活期间缓存住对话状态和可复用的上下文，只传新的工具调用结果，省掉...

## 推荐理由

这是 OpenAI 面向开发者的系统层更新：用 WebSocket 长连接加连接级缓存，把 agent 循环里反复建连、重复请求的开销压下去。HKR 三项都踩中了，但正文没给出延迟降了多少、吞吐多大、适合什么负载，所以只能算中等偏上的 featured，不能拉满。真正值得盯的是长连接怎么省掉往返成本，这不是换模型，是工程侧省钱省时间的优化。

## 锐评

这条更新解决的是一个很实际的工程问题：模型推理从每秒 65 个 token 飙到近 1000 个 token 后，API 自身的请求处理开销反而成了拖慢 agent 干活的主因。OpenAI 的思路是把多次独立的 HTTP 请求换成一个 WebSocket 长连接，连接存活期间缓存对话状态和可复用上下文，后续只传新的工具调用结果，省掉重复的验证、token 化和网络跳转。他们提到通过缓存、减少中间服务跳转、优化安全分类器，单次请求的首 token 延迟已经降了约 45%，但依然不够快，所以才动传输层。

文章说端到端快了 40%，但没给出具体场景下的延迟对比、并发数或工作负载条件，也没提 WebSocket 方案在连接断开重连时的状态恢复策略。这更像是一次传输层优化，不是新模型发布。对做 agent 产品的团队来说，如果你们的瓶颈确实在 API 往返开销上，这个改动值得跟进；但如果瓶颈在模型推理或工具执行本身，收益就没那么大。