Agent推理快到API成瓶颈：Responses API WebSocket如何提速40%
Agent推理快到API成瓶颈：Responses API WebSocket如何提速40%
摘要
当模型推理速度从每秒约 65 Token 提升到接近 1000 Token，Agent 不一定同步变快。Coding Agent 会在“模型决策、客户端执行工具、回传结果”之间往返数十次，重复的请求校验、状态重建、分词和网络跳转会累积成显著延迟。OpenAI 在 Responses API 中引入 WebSocket 模式，通过持久连接和连接内状态缓存，让 Agent 工作流端到端最高提速约 40%。本文从协议设计、状态复用、增量安全检查和工程落地角度，分析为什么推理越快，模型外围系统越不能沿用传统单请求架构。
背景：Agent 延迟不是一次模型调用的延迟
一个典型 Coding Agent 修复 Bug 时，需要搜索文件、读取代码、修改实现、运行测试，再根据结果决定下一步。每个工具调用都形成一次循环：
- API 判断模型下一步动作；
- 客户端执行本地工具；
- 工具结果发送回 API；
- 模型继续推理。
OpenAI 将一次 Agent 循环的时间拆成三部分：API 服务处理、模型推理、客户端工具执行与上下文构建。过去模型推理最慢，API 开销容易被隐藏；当专用硬件把生成速度提高一个数量级后，CPU 上的校验、路由和状态重建反而开始挡住 GPU。
这类瓶颈有一个典型特征：单次额外延迟看起来很小，但在几十轮工具调用中不断累积，最后影响的是完整任务的分钟级等待时间。
技术要点一：先优化单请求，但结构性重复仍存在
OpenAI 先对单次请求的关键路径做了三类优化：
- 缓存已渲染 Token 和模型配置，减少重复分词与网络调用；
- 移除不必要的中间服务跳转，直接访问推理服务；
- 调整安全检查，使部分分类器更快标记问题。
这些改动让首 Token 时间接近改善 45%。但面对 GPT-5.3-Codex-Spark 超过 1000 TPS 的目标，仍然不够。
根本原因是每个后续请求都被当成独立请求处理。即使大部分对话历史没有变化，系统仍要重复解析状态、处理工具定义和准备上下文。对话越长，重复成本越高。因此，继续压缩单请求只能缓解症状，真正需要改变的是连接与状态生命周期。
技术要点二：持久连接把“完整重建”改成“增量追加”
团队评估了 WebSocket 和 gRPC 双向流，最终选择 WebSocket，主要原因是它只改变传输方式，不要求开发者重写 Responses API 的输入输出结构。
早期原型把整段 Agent 运行建模为一个长时间 Response。模型生成工具调用后，服务端暂停采样并发送事件；客户端执行工具，再通过连接追加结果，随后恢复采样。这样可以只做一次推理前处理和一次最终处理，但 API 形态变化太大。
正式方案保留熟悉的 response.create，并继续使用 previous_response_id 串联上下文。区别在于，同一 WebSocket 连接内，服务端保存上一轮 Response 的内存状态；后续请求只发送新增信息，不再从头重建完整历史。
连接缓存包括：
- 上一个 Response 对象；
- 之前的输入与输出项；
- 工具定义和命名空间；
- 已渲染 Token 等可复用采样产物。
这是一种增量状态机，而不是简单把 HTTP 换成 WebSocket。真正的收益来自“连接内状态可复用”。
技术要点三：安全、路由与计费也必须增量化
仅缓存对话文本还不够。OpenAI 进一步让安全分类器和请求验证器只处理新增输入；将已渲染 Token 追加到内存缓存；复用上一轮成功的模型解析与路由结果；并把计费等非阻塞后处理与下一次请求重叠执行。
这里体现了关键工程原则：Agent 延迟优化不能只盯网络传输。认证、风险分类、模型路由、分词、计费和日志都可能进入关键路径。只要其中一层仍按完整历史重复处理，推理提速就无法完整传递到用户。
官方报告称，WebSocket 模式让 Agent 工作流最高提速约 40%。GPT-5.3-Codex-Spark 达到目标的 1000 TPS，并在生产流量中出现最高约 4000 TPS 的短时峰值。OpenAI 同时强调，这些收益来自端到端系统配合，而不是 WebSocket 协议本身自动带来的性能。
研发视角：该优化适合什么场景
WebSocket 模式最适合长链、强交互、状态复用率高的 Agent：
- Coding Agent 的多轮搜索、编辑和测试；
- 浏览器或桌面 Agent 的连续操作；
- 数据分析 Agent 的多次查询与校验；
- 需要大量本地工具调用的工作流。
如果应用只是单轮问答，连接维护和重连逻辑可能得不偿失。若每轮都切换模型、工具集合或安全策略，缓存命中率也会下降。是否迁移应由真实任务轨迹决定，而不是因为 WebSocket 在概念上更“实时”。
评测时至少记录：完整任务时延、首 Token 时间、每轮 API 开销、工具执行时间、请求轮数、缓存命中、重连次数和任务成功率。只比较 Token 生成速度，会遗漏最重要的系统成本。
实践建议
第一，为连接设计明确生命周期。按用户会话或任务绑定连接，设置空闲超时和最大持续时间，避免无限保留状态。
第二，处理断线恢复。保存最后确认的 response_id 和客户端工具结果，重连时支持幂等重放，防止工具被重复执行。
第三，设置背压。模型产生工具调用、客户端执行和结果回传的速度可能不一致，需要限制未完成消息数量和缓存大小。
第四，保留 HTTP 降级通道。代理、防火墙或企业网络可能限制 WebSocket，生产系统应能回退到普通请求模式。
第五，监控增量状态一致性。工具定义、权限、模型配置发生变化时，应显式失效缓存，不能继续复用旧路由或旧安全上下文。
第六，把安全检查留在链路内。性能优化不能通过跳过校验实现，应让校验增量化、可并行化，并记录异常复核带来的额外延迟。
风险与限制
持久连接提高了性能，也扩大了状态管理责任。连接中断、消息乱序、重复投递和服务端迁移都可能破坏上下文一致性。内存缓存还会增加服务端资源占用，并要求更严格的租户隔离和生命周期清理。
官方文章主要报告 OpenAI 内部与合作方的结果，没有公开统一的负载配置、并发规模和延迟分布。最高 40% 的提速不能直接外推到所有业务。对于工具执行本身占据大部分时间的 Agent，传输层优化的总体收益会更小。
此外，previous_response_id 依赖连接内状态，应用需要理解连接失效后的恢复边界。不能把服务端缓存当作唯一持久化来源。
结语
WebSocket 模式带来的最大启示，不是“Agent 应该使用长连接”，而是当模型越来越快，系统瓶颈会向推理外围迁移。请求校验、上下文重建、安全检查、路由和计费都必须从全量重复转向增量处理。真正优秀的 Agent 基础设施，应该让模型、API 和本地工具形成一条连续流水线，而不是几十次彼此独立的调用。
参考来源
- OpenAI Engineering：Speeding up agentic workflows with WebSockets in the Responses API
https://openai.com/index/speeding-up-agentic-workflows-with-websockets/