HTTP 终于成了 AI Agent 的绊脚石。
就在刚刚，OpenAI 宣布 Responses API 正式支持 WebSocket 模式。
这听起来像是个枯燥的技术更新，但如果你正在构建复杂的 AI Agent，这可能是目前最激动人心的消息——
在包含 20 次以上工具调用的长链条任务中，端到端执行速度直接提升了 40%。
为什么？因为以前的 AI 对话像是在寄信，每次都要把厚厚的一叠历史记录塞进信封寄出去；
而现在，它终于学会了打电话。
HTTP 的“失忆症”终于有救了
说实话，HTTP 协议在这个 AI 时代显得有点“老派”。
以前我们调用 API，每一次请求都是独立的。哪怕你只是想让 AI 连续执行 10 步操作，每一步它都得把之前所有的上下文重新打包、重新发送。这不仅浪费带宽，更致命的是浪费了宝贵的时间。
OpenAI 这次引入的 WebSocket 模式，逻辑非常简单粗暴：建一条持久连接，状态保存在内存里。
这意味着什么？
在 WebSocket 模式下，你只需要发送 previous_response_id 和新的输入内容，服务端就能在连接本地的内存缓存中找到上一轮的状态。
这种模式避免了每轮对话的重复开销，对于那些需要频繁调用工具的智能体工作流来说，简直是量身定做。
所谓的“提速”，提的到底是什么速？
有意思的是，OpenAI 并没有掩饰这种新模式的适用场景。
它不是给你用来聊天的，它是给“机器”用的。
如果你只是简单的问答，HTTP 和 WebSocket 差别不大。
但一旦你的 Agent 进入了所谓的“Orchestration Loops”，比如自动写代码、自动调试、反复调用搜索工具，这种需要几十次甚至上百次模型与工具交互的场景，WebSocket 的优势就出来了。
保持连接，增量输入。
这八个字就是核心。你不必每次都把几万字的上下文重新扔给服务器，服务器也不必每次都重新初始化状态。
不过，这里有个坑得注意。
这种“记忆”是暂时的。OpenAI 明确表示，这个 previous_response_id 的状态只存在于连接本地的内存缓存中，不会写入磁盘。
一旦你设置了 store=false 或者开启了零数据保留（ZDR），如果连接断了或者缓存失效，你就再也找不回那个 ID 了。这时候系统会冷冷地抛出一个错误：previous_response_not_found。
评论区里的“人间清醒”
老实讲，技术指标很漂亮，但开发者们似乎并不都在鼓掌。
在 X (Twitter) 的评论区，我看到了一些更尖锐的声音。
一位名叫 ejae_dev 的开发者直言不讳：
“WebSocket 确实解决了往返开销，但在 20+ 工具调用的 Agent 中，真正的瓶颈往往是上下文窗口膨胀，而不是网络延迟。大多数 Agent 失败是因为模型丢失了状态，而不是因为 HTTP 太慢。”
这话虽然刺耳，却点出了一个尴尬的现实：现在的 AI 应用，很多时候不是跑得慢，而是跑着跑着就“傻”了。
还有一位 DesiBuzzFeed 的评论更是直接戳中了商业模式的痛点：
“没人发现这其实是一种通过状态绑定来增加供应商锁定的策略吗？”
个人觉得，这个观点非常有洞察力。当你的 Agent 状态依赖于 OpenAI 的内存缓存，甚至为了追求那 40% 的性能不得不维持长连接时，迁移成本就在无形中增加了。
想用这个“加速器”？得加条件
OpenAI 这次也没把话说死，给了很多限制条件。
首先，单个 WebSocket 连接时长限制为 60 分钟。时间一到，连接断开，你得重连。
重连之后怎么办？
如果你的上一条响应是持久化存储的（store=true），那你还可以拿着 ID 继续续杯；但如果你是为了隐私开了 store=false，那不好意思，你得从头开始，把完整的上下文重新发一遍。
这就像是你正在通电话办业务，讲到一半突然断线了。如果业务员记性好（存了档），你打过去还能接着聊；如果业务员不记事（没存档），你就得把身份证、户口本重新报一遍。
此外，现在的 WebSocket 模式不支持多路复用。你想并行跑多个任务？那就得多开几个连接。
协议升级背后的野心
撇开那些吐槽不谈，OpenAI 这一步棋走得很有深意。
从 HTTP 到 WebSocket，本质上是在为 Agent 的“自主性”铺路。
以前的 AI 是被动的工具，你戳一下它动一下；未来的 Agent 是主动的执行者，它需要在后台长时间、高频率地自我迭代。
HTTP 这种无状态的协议，确实已经配不上这种新型的工作流了。
虽然现在还有 60 分钟的限制，还有上下文膨胀的瓶颈，甚至还有被锁定的风险，但方向已经很明显了：
AI 基础设施正在从“服务人类对话”向“服务机器协作”进化。
参考链接：
https://x.com/OpenAIDevs/status/2026025368650690932