OpenAI 把 Responses API 提速 40%：为什么 Agent 时代，API 本身成了瓶颈？

OpenAI 最新发布了一篇工程博客，讲了一件容易被忽视的事：当模型推理越来越快，API 框架本身反而成了 Agent 工作流的最大瓶颈。他们的解法是给 Responses API 加上 WebSocket 模式，端到端提速 40%，并让 GPT‑5.3‑Codex‑Spark 真正跑出 1000 TPS、峰值 4000 TPS 的体验。
https://openai.com/index/speeding-up-agentic-workflows-with-websockets/

问题是怎么浮现的
一次 Codex 修 Bug，背后是几十次 Responses API 的来回：决定下一步动作 → 在用户机器上执行工具 → 把结果回传 → 再次推理。整个 Agent loop 的耗时主要分三段：API 服务处理、模型推理、客户端工具执行。

过去 GPU 推理慢，API 的开销被自然掩盖。但 GPT‑5/5.2 时代约 65 TPS，新一代 Codex‑Spark 借助 Cerebras 专用硬件目标是 1000+ TPS，推理快了一个数量级，API 那点"固定成本"就被无情放大。用户在等的，不再是 GPU，而是跑在 CPU 上的 API 框架本身。

第一轮优化：挤掉单次请求的水分
25.11 起，他们做了几件常规但关键的事:
· 把已渲染的 token、模型配置缓存在内存，跳过多轮对话里重复的 tokenization 和网络调用
· 砍掉中间服务的网络跳数 (如图像处理)，直接调推理服务
优化安全栈，让分类器更快标记问题对话

结果：首 token 时间 (TTFT) 改善了约 45%。但对 Codex‑Spark 来说，还是不够。

真正的结构性问题
每次 Codex 请求都被当作独立请求处理，即使对话大部分没变，服务端仍然要把完整历史重跑一遍验证、处理和上下文构建。对话越长，这种重复成本越贵——这是协议层面的浪费，不是某个组件能调优解决的。

WebSocket：把 Agent rollout 当作一次"长 Response"
他们重新思考传输层：能不能保持长连接、把可复用状态缓存在内存里，只传增量？在 WebSockets 和 gRPC 双向流之间，选了 WebSockets——简单、对开发者友好、不需要改动现有的 Responses API 输入输出结构。

第一版原型很激进：把整个 Agent rollout 建模成一个长时间运行的 Response。
工作方式类比 hosted tool call：模型调 web search 时，推理循环会阻塞、等服务返回、再继续 sample。WebSocket 模式下，本地工具调用走的是同一套机制——只是"远程服务"换成了通过 WebSocket 连接的客户端。模型发出 response.done，客户端执行工具后回 response.append, sampling loop 解除阻塞继续推理。

效果立竿见影：整个 rollout 只做一次预处理、一次后处理，中间的工具往返不再重复消耗 API 框架开销。

最后的取舍：激进设计 vs 开发者熟悉的形状
原型虽好，但 API 形态变了，开发者要重写集成。正式版做了折中：保留 response.create 原有 body，继续用 previous_response_id 串上下文，但底层在 WebSocket 连接生命周期内维护一份连接级内存缓存，包括:
· 上一个 response 对象
· 历史输入输出 items
· 工具定义和命名空间
· 已渲染 token 等可复用 sampling 产物

带来的具体优化：
· 安全分类器和请求校验只处理新增输入，不再扫全历史
· 已渲染 token 增量追加，跳过重复 tokenization
· 模型路由结果跨请求复用
· 计费等非阻塞后处理与下一个请求重叠执行

最终结果
· Codex 大部分流量已切到 WebSocket 模式
· Codex‑Spark 稳定 1000 TPS、峰值 4000 TPS
· Vercel AI SDK 集成后延迟下降最多 40%
· Cline 多文件工作流提速 39%
· Cursor 上的 OpenAI 模型快了最多 30%