问题的由来
Codex agent 执行一个完整任务（扫描代码库、读文件、做修改、跑测试）需要几十次 API 往返。当模型推理速度提升近 15 倍（65 → 近 1000 tokens/s）之后，一个之前被推理延迟掩盖的问题暴露出来：每次请求都在做大量重复工作。
根本原因是 HTTP 无状态设计：「每次 Codex 请求都被当作独立请求处理，每次都要重新处理对话状态和其他可复用的上下文」。具体包括：
- 重新处理完整的对话历史
- 重新渲染 token
- 重新加载工具定义
- 重新跑安全分类（对全量输入）
- 重新解析模型路由逻辑
这些工作大部分在相邻请求之间完全相同，每次都从零开始做是纯粹的浪费。
WebSocket 方案
OpenAI 选择 WebSocket 而非 gRPC 的原因是明确的：不想让开发者重构现有的 API 集成结构。WebSocket 作为「简单的消息传输协议」，可以在不改变开发者请求/响应思维模型的情况下维持持久连接。
核心是 connection-scoped cache（连接作用域缓存），存储上一次 response 的完整状态：response 对象、输入/输出 item、工具定义、已渲染 token。当开发者在后续请求中传入 previous_response_id 参数，服务端直接检索这份缓存，而不是重建。
这套机制的优化覆盖了多个层面：
安全处理：分类器只处理新增输入，而非完整对话历史。
Token 缓存：内存中缓存已渲染 token，消除重复 tokenization 开销。
路由简化：模型解析逻辑直接复用上次成功的决策。
重叠处理：计费等后推理工作与后续请求并行处理，不阻塞主路径。
性能数据
alpha 测试期间，用户的 agentic workflow 端到端速度提升最高 40%。具体指标：
- 端到端加速：Agent 循环整体快 40%
- 首 token 延迟：提升近 45%
- 推理速度落地：用户真实感受到 65 → 近 1000 tokens/s 的跃升
- 峰值吞吐：GPT-5.3-Codex-Spark 峰值达 4000 tokens/s
OpenAI 将这次更新定位为「Responses API 自 2025 年 3 月发布以来最重要的新能力之一」。
对 Agent 开发者的含义
使用方式极简：在 follow-up 请求中传 previous_response_id，服务端自动激活缓存。不需要切换 SDK，不需要修改请求结构，不需要自己管理连接状态。
这个优化对 Codex 类深度 agentic 工作流（多轮、长上下文、频繁 tool call）的提升最显著。单轮对话类应用收益相对有限，因为没有可复用的「上一个请求状态」。