为什么更快的智能体循环很重要
OpenAI表示，它已经重构了支撑 Responses API 的底层架构，以显著加快类智能体工作流，目标是在复杂任务中减少用户在工具、模型和 API 调用之间来回切换时的等待时间。
在4月22日发布的一篇技术文章中，该公司描述了像 Codex 这样的系统可能需要数十次顺序请求才能完成单个任务：模型决定下一步做什么，工具在客户端运行，结果再发送回 API，然后循环重复。这种模式会让哪怕很小的开销也迅速累积。
OpenAI表示，随着推理本身变得更快，这个性能问题变得更加明显。该公司称，Responses API 早期的旗舰模型速度约为每秒65个 token。对于 GPT-5.3-Codex-Spark，OpenAI 通过 Cerebras 硬件将目标设定为每秒超过1,000个 token。一旦模型生成速度快到这个程度，循环中较慢的部分就不再容易被掩盖。
从推理瓶颈到 API 瓶颈
OpenAI将智能体延迟分为三个大阶段：API 服务工作、模型推理以及客户端时间。客户端时间仍然重要，因为工具需要执行，且上下文需要组装，但该公司表示，API 层本身已经成为一个有意义的瓶颈。
这一变化迫使其采用不同的优化策略。OpenAI表示，与其只关注 GPU 吞吐量，不如开始消除请求路径上的摩擦。大约在2025年11月，该公司启动了其所谓的 Responses API 性能冲刺。相关工作包括将渲染后的 token 和模型配置缓存到内存中，通过更直接地调用推理服务来减少额外的网络跳转，以及加快安全栈的部分环节，以便某些对话能够更快地被分类。
据该公司称，这些变化将首个 token 的响应时间提升了近45%。但 OpenAI表示，这仍不足以完全释放其更新版推理栈的速度优势。
WebSocket 转变
更大的变化是架构层面的：用通过 WebSocket 连接到 Responses API 的持久连接，取代一系列独立的同步 API 调用。实际上，这意味着客户端和 API 可以在整个智能体循环中保持连接，而不是不断拆除并重建请求状态。
OpenAI表示，持久化会话使它能够将有用信息附着在连接本身上。这减少了重复的初始化工作，并帮助系统在不同轮次之间更高效地复用上下文。该公司称，结果是端到端智能体循环速度大约提升了40%。
对用户来说，其意义很直接。如果一个编程或研究智能体需要大量工具调用才能完成任务，那么从每个循环中削减开销，其效果可能比仅加快某一个环节更大。原本在动作之间显得停滞的工作流，会更接近实时交互的体验。
OpenAI优化了什么
- 连接范围缓存，以避免重复昂贵的初始化工作。
- 减少 API 服务与推理服务之间不必要的网络跳转。
- 加快审核与分类流程部分环节的安全检查。
- 使用持久化 WebSocket 通道，降低多轮工具使用的成本。
OpenAI将这项工作描述为对更广泛行业变化的回应：推理速度正在快到足以让周边系统越来越决定产品的感知质量。在这种环境下，模型或许能够快速思考，但如果编排层跟不上，体验仍然会显得缓慢。
这不仅关乎 Codex
尽管 OpenAI用 Codex 来说明这一问题，但其影响适用于任何使用工具的智能体。企业助手、客户服务系统、研究副驾驶和软件智能体都依赖许多小型交互，而不是一次长时间的模型生成。因此，持久化会话和更低的编排开销，可能与原始基准性能同样重要。
这篇文章也让人看到竞争格局正在变化。模型供应商多年来一直强调更强的推理能力和更大的上下文窗口。但如今，它们也在系统工程上竞争：吞吐量、响应速度、安全延迟，以及模型与外部工具保持联动的效率。
OpenAI传达的信息是，模型周围的基础设施如今本身就是产品特性。如果推理速度继续提升，这一点很可能会更加明显。
更深层的信号
更深一层的结论不只是 WebSocket 比重复同步调用更快。更重要的是，智能体产品正在成熟为实时软件系统，其性能取决于 API、缓存、安全层和工具运行时之间的协同。
这让这次更新不只是工程脚注。它表明，AI 可用性的下一波提升，可能来自减少模型步骤之间的摩擦，而不仅仅是让每一步本身更聪明。随着智能体系统承担越来越长、越来越复杂的任务，这一区别可能决定它们究竟是显得仍在试验阶段，还是已经可以投入实际运行。
本文基于 OpenAI 的报道。阅读原文。
Originally published on openai.com