Codex WebSocket 与普通 Responses 的区别

应该选哪一种

OpenAI 官方建议在 20 次以上工具调用的长流程中评估 WebSocket，并给出约 40% 端到端提速的参考；实际收益仍取决于网络、工具耗时、模型和代理链路。

普通 HTTP 配置

model_provider = "tidba"
model = "gpt-5.6-sol"
model_reasoning_effort = "xhigh"

[model_providers.tidba]
name = "TiDBA API"
base_url = "https://sub.tidba.com"
env_key = "TIDBA_API_KEY"
wire_api = "responses"
requires_openai_auth = false

这是兼容性最好的基线。先确保短请求和流式输出稳定，再开启 WebSocket。

开启 Responses WebSocket v2

在同一 Provider 上增加 supports_websockets，并启用客户端功能开关。

model_provider = "tidba"
model = "gpt-5.6-sol"
model_reasoning_effort = "xhigh"

[model_providers.tidba]
name = "TiDBA API"
base_url = "https://sub.tidba.com"
env_key = "TIDBA_API_KEY"
wire_api = "responses"
requires_openai_auth = false
supports_websockets = true

[features]
responses_websockets_v2 = true

Base URL 仍填写 HTTPS 地址，不需要手工改成 wss://。Codex 会按 Provider 能力建立相应连接。

连接内发生了什么

1. 首轮发送与普通 Responses 相同的模型、指令、工具和输入。
2. 服务器通过 WebSocket 持续返回事件。
3. 模型请求工具时，客户端执行工具。
4. 客户端在同一连接发送新的 response.create，携带新工具结果和 previous_response_id。
5. 最近响应状态保留在连接内存中，减少后续轮次的设置工作。

限制与错误处理

previous_response_not_found

连接内无法解析旧响应状态。使用完整输入重试，并把 previous_response_id 置空。

websocket_connection_limit_reached

连接达到当前时限。新建 WebSocket 连接后继续，不能无限复用同一连接。

代理拒绝 Upgrade 或频繁断连

先关闭 responses_websockets_v2 回到 HTTP 基线。如果 HTTP 稳定，问题范围就在 WebSocket 客户端、代理升级或长连接保活。

HTTP 和 WebSocket 都报 502

这通常不是连接模式单点问题。保留 Request ID，按 502 排查步骤检查上游错误和上下文。

如何验证切换有效

1. 先分别运行相同的短任务，确认两种模式结果一致。
2. 再运行包含多轮工具调用的真实任务。
3. 比较 TTFT、总耗时、断连率和失败重试次数。
4. 不要只比较一次请求；至少观察一组同类任务的 P50 和 P95。

测量方法见 首 Token 耗时 TTFT 指南。如果只是聊天或单次生成，保持 HTTP 通常更简单。