OpenAI 又发了一条很容易被标题党写歪的更新：不是模型换代，也不是功能秀肌肉，而是 Responses API 加了 WebSocket 支持。

如果只看表面，这像一次底层工程优化；如果看它瞄准的场景，就知道不是小修小补。OpenAI 明说了，目标是 agentic workflows，尤其是 Codex 这种多轮工具调用、长上下文续接、反复 request-response 的工作流。官方和合作方给出的数据也很直接：端到端延迟最高可降约 40%，首 token 时间此前也已提升接近 45%。

这条新闻最值钱的地方，在于它把一个行业现实摆上台面：模型提速到一定程度后，用户等的已经不是 GPU 那几百毫秒，而是接口层还在不在拿“续集”当“首集”重拍一遍。

OpenAI 这次到底改了什么

核心变化有两件。

  • 传输层.Responses API 增加 WebSocket 持久连接
  • 状态层.在连接生命周期里做 connection-scoped in-memory cache

表面上看，大家会先盯住 WebSocket。真正起作用的，反而更像后者：缓存和状态续接。

OpenAI 现在的做法是，开发者仍然可以沿用 response.create 这套接口心智，再配合 previous_response_id 去续接上一次结果。这样一来，服务端不必每轮都把整段上下文当成全新会话重建一次。

少掉的不是一丁点样板活，而是过去每轮都会重复付费的系统动作：

  • 重复校验请求
  • 重建会话历史
  • 重新 tokenization
  • 重新路由到推理栈
  • 部分安全处理只看新增内容，而不是整段重跑

OpenAI 还提到，它此前已经做过一轮单请求优化，比如减少中间服务跳转、缓存已渲染 token、加快安全分类器。这次再往前推，等于把“单次调用提速”延伸到了“整条 agent loop 提速”。

这不是概念升级，是把 API 收费站拆掉一部分。

谁会先吃到红利，谁其实感知不强

最先受益的，不是普通聊天用户，而是两类人：

  • 做 AI 编程助手和代理型产品的团队
  • 已经在 OpenAI Responses API 上跑多轮工具调用的开发者

OpenAI 点名的场景很集中：Codex、Cline、Cursor、Vercel AI SDK 这类需要连续调用模型、调用工具、再把结果回传给模型的链路。公开数据也说明了受益面：Vercel AI SDK 提到延迟最多下降 40%，Cline 的多文件工作流快了 39%，Cursor 里 OpenAI 模型最高快了 30%。

如果你只是偶尔发一次单轮问答，请求发出去，等答案回来，体感不会像 agent 产品那么夸张。真正会对这次更新叫好的，是盯着任务完成时间、工具往返次数、每轮状态重建成本的产品负责人和工程团队。

这点很重要。很多 AI 新闻喜欢把“速度提升”说成全体用户统一受益，实际不是。这里受影响最深的是工作流密集、轮次多、上下文长的产品。普通用户不是没收益，只是没那么强。

旧问题没消失，只是瓶颈换了位置

我之前对这类产品的判断一直很简单：默认更强，不等于默认可用。放到今天，要再补一句：模型默认更快，也不等于产品默认更顺。

这次 WebSocket 更新，其实是给这个判断补上了更硬的证据。

行业过去一年有个很偷懒的共识：只要模型能力继续涨，agent 体验自然会变好。现在看，这话最多只对一半。模型当然重要，但很多系统把每轮工具调用都按全新请求处理，本质上是在拿基础设施缺陷吃掉模型进步。

模型生成一次工具调用，客户端执行工具，再把结果发回去；服务端又从头校验、组装、分词、路由。周而复始。模型越快，这些非模型开销就越刺眼。所谓“末大必折”，今天可以反着看：主干越强，边角越不能烂。

这很像铁路提速后的老问题。火车头功率上去了，站台调度、检票系统、信号协同没跟上，旅客感受到的不是“时代飞跃”，而是“怎么还是卡”。AI 也一样。很多产品宣讲时爱拿 token/s、benchmark、模型排名说事，用户最后记住的却是按钮按下去以后要不要等、工具调完以后会不会断、任务做一半会不会重来。

火箭赢了半场，客户输了整场。

这次做对了，但别把它吹成终局

OpenAI 这次做得对，而且是少见地对在了工程落地上。

原因不复杂。它没有强迫开发者接受一套特别怪的新 API 形态，而是保留 response.create 和 previous_response_id 这类已有心智，再用持久连接和缓存去减掉重复开销。技术上未必最漂亮，兼容性上却更聪明。

新线索里还有一个细节很关键：OpenAI 原型阶段，曾尝试把整个 agent rollout 当成一个长生命周期 response。模型遇到工具调用就暂停，客户端把工具结果 append 回来，再继续采样。这样性能很好，但会逼开发者改很多现有集成。正式版没有一路冲到底，说明它接受了一个工程现实：最优方案如果改造成本太高，最后常常输给次优但能大规模落地的方案。

丘吉尔那句老话放在工程世界也适用：完美是进步之敌。API 不是论文，能迁移、能排障、能被团队接住，才算数。

但也别高兴太早。现在还看得到几道后账：

  • 长连接下的状态一致性怎么保证
  • 连接级缓存出错后，故障恢复会不会更麻烦
  • 计费、审计、安全分类在长连接里是否仍然透明
  • 开发者为了 30% 到 40% 的提速，要不要接受更复杂的运行心智

这些问题没一个是装饰性问题。agent 产品最怕的不是慢一点，而是快了之后更难 debug、更难追责、更难解释账单。天下熙熙，皆为利来；开发者愿不愿意换，最后还是看收益能不能盖过运维和排障成本。

真正该盯的，不是 WebSocket 三个字

我不太买账的一种写法，是把这事概括成“OpenAI 拥抱 WebSocket，所以 AI agent 进入新阶段”。这话太轻飘了。

WebSocket 只是表层名词。更值得盯的是三件更朴素的事：

  • API 层有没有把重复计算砍掉
  • 状态有没有被当成一等公民来管理
  • agent 产品的瓶颈是否开始从推理成本转向系统编排成本

如果这三件事成立，那接下来各家比的就不只是模型聪不聪明，还包括谁能把工具调用、上下文续接、安全处理、计费和可观测性做成低摩擦系统。Anthropic、Google 以及一堆 agent 框架，其实都在朝这个方向卷。OpenAI 这次不是宣布自己已经赢了，而是明确承认：战场已经往基础设施后移。

这对做产品的人是个很现实的提醒。如果你的 agent 现在还是每轮都全量重放上下文、每次都从零建会话、每次工具返回都走一遍完整冷启动，那就别急着吹模型升级。用户不为 benchmark 付钱，用户为任务完成付钱。

一句话，问题不在模型不够快，而在系统太习惯做废功。