Agent推理快到API成瓶颈Responses API WebSocket如何提速40%摘要当模型推理速度从每秒约 65 Token 提升到接近 1000 TokenAgent 不一定同步变快。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 模式最适合长链、强交互、状态复用率高的 AgentCoding Agent 的多轮搜索、编辑和测试浏览器或桌面 Agent 的连续操作数据分析 Agent 的多次查询与校验需要大量本地工具调用的工作流。如果应用只是单轮问答连接维护和重连逻辑可能得不偿失。若每轮都切换模型、工具集合或安全策略缓存命中率也会下降。是否迁移应由真实任务轨迹决定而不是因为 WebSocket 在概念上更“实时”。评测时至少记录完整任务时延、首 Token 时间、每轮 API 开销、工具执行时间、请求轮数、缓存命中、重连次数和任务成功率。只比较 Token 生成速度会遗漏最重要的系统成本。实践建议第一为连接设计明确生命周期。按用户会话或任务绑定连接设置空闲超时和最大持续时间避免无限保留状态。第二处理断线恢复。保存最后确认的 response_id 和客户端工具结果重连时支持幂等重放防止工具被重复执行。第三设置背压。模型产生工具调用、客户端执行和结果回传的速度可能不一致需要限制未完成消息数量和缓存大小。第四保留 HTTP 降级通道。代理、防火墙或企业网络可能限制 WebSocket生产系统应能回退到普通请求模式。第五监控增量状态一致性。工具定义、权限、模型配置发生变化时应显式失效缓存不能继续复用旧路由或旧安全上下文。第六把安全检查留在链路内。性能优化不能通过跳过校验实现应让校验增量化、可并行化并记录异常复核带来的额外延迟。风险与限制持久连接提高了性能也扩大了状态管理责任。连接中断、消息乱序、重复投递和服务端迁移都可能破坏上下文一致性。内存缓存还会增加服务端资源占用并要求更严格的租户隔离和生命周期清理。官方文章主要报告 OpenAI 内部与合作方的结果没有公开统一的负载配置、并发规模和延迟分布。最高 40% 的提速不能直接外推到所有业务。对于工具执行本身占据大部分时间的 Agent传输层优化的总体收益会更小。此外previous_response_id 依赖连接内状态应用需要理解连接失效后的恢复边界。不能把服务端缓存当作唯一持久化来源。结语WebSocket 模式带来的最大启示不是“Agent 应该使用长连接”而是当模型越来越快系统瓶颈会向推理外围迁移。请求校验、上下文重建、安全检查、路由和计费都必须从全量重复转向增量处理。真正优秀的 Agent 基础设施应该让模型、API 和本地工具形成一条连续流水线而不是几十次彼此独立的调用。参考来源OpenAI EngineeringSpeeding up agentic workflows with WebSockets in the Responses APIhttps://openai.com/index/speeding-up-agentic-workflows-with-websockets/