OpenAI 这次更新，表面上是在 Responses API 上加入 WebSocket 支持，实质上是在给 agent 产品补一块过去常被忽略的短板：模型已经越来越快，真正拖慢体验的却常常是模型外面的那一圈系统开销。

如果把前一阶段的重点概括成“把模型做成能力平台”，那这一步更像是在争另一个入口：谁能把调用链路、工具回路和多轮状态处理做得更薄，谁就更接近真实工作流的主入口。对开发者来说，这比一次单纯的模型升级更有现实意义。

发生了什么：Responses API 还是那个 API，但底层传输换了

OpenAI 没把 Responses API 改成一套陌生接口。开发者熟悉的 response.create + previous_response_id 仍然可用，主要变化发生在连接内部：高频多轮调用不再反复走一次次 HTTP 请求，而是放到 WebSocket 长连接里处理。

这带来几件很具体的变化：

  • 连接作用域内可以缓存 previous_response_id 对应状态
  • 后续请求只需要处理新增输入，而不是每轮都重建更多上下文
  • response 对象、工具定义、已渲染 tokens、部分路由结果可以在连接内复用
  • 一些后处理步骤可以和后续请求重叠，减少链路空转

官方给出的性能锚点有三个：

  • 单次请求的 TTFT 优化后提升接近 45%
  • WebSocket 模式在 agent 工作流里，端到端延迟最高可降约 40%
  • 背景速度对比是，旧一代旗舰模型约 65 tokens/s，而 GPT-5.3-Codex-Spark 的目标已指向超过 1000 TPS，突发可到 4000 TPS

这些数字里，最值得看的不是“快了多少”，而是为什么现在要做这件事。模型提速之后，外围系统的摩擦开始被放大了。

为什么重要：瓶颈已经从推理转到编排和工具回路

WebSocket 本身不是新技术。真正新增的信息，是 OpenAI 明确把 agent 延迟问题拆开来看：当模型输出速度快速上升，决定用户体感的越来越不是 token 吐得快不快，而是请求校验、重复 tokenization、上下文组装、路由、工具调用往返这些碎开销。

这比单次模型升级更能解释很多产品里的真实体验。用户看到的是“助手怎么还在等”，但那段等待时间里，模型未必在慢慢想，更多时候是在等系统层的一连串小动作完成。

这也让旧判断更清楚了一步：图像生成、编程助手、自动化 agent 这些产品，竞争不再只是模型能力的横向比较，而是在抢工作流入口。入口不只是谁功能全，还是谁能把一条任务链跑得更顺。模型会算，只是起点；链路薄不薄，决定它像不像工具。

铁路提速后，卡住运力的往往变成调度和装卸；云计算性能上去后，拖后腿的常常是网络、存储和编排。今天的 agent 也到了类似阶段。模型速度越来越高，系统摩擦就从边角问题变成主问题。

谁最受影响：编程和工作流 agent 是直接受益者

这次更新最相关的，不是普通单轮聊天用户，而是高频多轮、频繁调工具的 agent 产品。

OpenAI 在案例里提到，受益最直接的是 Codex、Vercel AI SDK、Cline、Cursor 这类编程和工作流工具。公开给出的数字包括：

  • Vercel AI SDK 报告延迟最高降约 40%
  • Cline 的多文件工作流快了 39%
  • Cursor 中的 OpenAI 模型最高快了 30%

这些更像方向证明，不是统一基准，也不能直接当成任何团队接入后的默认收益。因为 agent 延迟高度依赖任务形态：工具调用密度、上下文大小、会话长度、客户端本地执行时间，都会把结果拉开。

真正适合优先评估这套优化的团队，通常有两个特征：

  • 一轮任务里要多次调用模型、工具和外部系统
  • 任务时间里，模型生成只占一部分，剩下不少时间耗在状态传递和工具往返上

如果你的产品还是普通单轮聊天，这次更新就不该被夸大。没有太多多步状态复用，也没有那么多工具回路，长连接带来的改善通常不会接近 agent 场景里的数字。

这对开发者的现实含义：优化重点要从“换模型”转向“减重复劳动”

对开发者来说，最现实的变化不是立刻重构整套架构，而是先重新看自己的延迟账单。

优先检查三件事：

  • 是否每轮都在重复传大段历史和上下文
  • 是否每次都重复做工具定义、校验、路由和 tokenization
  • 是否模型已经足够快，但时间仍耗在工具执行前后的空转上

这会影响接下来的工程取舍。有些团队会继续追更强模型；也有些团队会先压系统开销，因为用户感知的是总等待时间，不是模型榜单名次。

OpenAI 这次的取舍也说明了一个方向：它没有为了极限速度，把开发者接口彻底改型。原文提到过另一条路——把整个 agent rollout 视为一个长生命周期 response——那样可能更快，但开发者心智和迁移成本更高。现在落地的是兼容式优化：接口尽量不动，底层尽量增量。

这很务实。因为眼下真正阻碍 agent 落地的，往往不是模型不够强，而是工程收益和迁移成本算不过来。

接下来该观察什么：能否撑住更长会话和更复杂生产流量

这次更新补强了一个重要判断，但还不是 agent 延迟问题的总解。

写代码 agent 最慢的时候，常常不是模型生成，而是本地工具执行、文件搜索、测试、依赖安装、沙箱运行环境本身。客户端跑工具、读本地文件、构建上下文，这些时间不会因为接入 WebSocket 自动消失。

所以后面更值得看的，是两个更硬的变量：

  • 连接级缓存和增量处理，能不能稳定撑住更长会话、更复杂的生产流量
  • 生态会不会继续跟进做更激进的增量式编排，而不只是把模型继续提速

如果前者撑不住，提速容易停在演示层；如果后者跟不上，模型速度再高，用户拿到的也只是“账面性能”。

对 agent 产品来说，下一阶段的竞争会更像系统工程竞争。模型能力当然还重要，但真正拉开差距的，可能是链路厚度、缓存策略、工具调度和状态管理这些过去不太上台面的东西。