Codex 原生 WebSocket 支持是什么？
使用 Codex 时，一个任务可能包含多次模型交互：理解需求、读取代码、调用工具，再根据工具结果继续处理。因此，连接能否顺利承载后续交互，是接入体验的重要部分。
小北科研 API 支持 Codex 原生 WebSocket 链路，并将其作为核心支持能力。 本文解释这一能力的含义，以及选择和使用时应关注什么。
WebSocket 与流式输出有什么区别？
流式输出描述的是内容逐步返回的方式。HTTP 也可以通过 SSE 传递流式事件，因此，看到文字逐渐出现，并不能据此判断使用了 WebSocket。
WebSocket 提供持久的双向连接。OpenAI 的 Responses WebSocket 模式允许通过持续连接创建回复，并使用响应标识和新增输入续接后续交互，适用于多次模型与工具往返的工作流。协议说明见 OpenAI 官方 WebSocket 文档。
| 关注点 | HTTP 流式输出 | Responses WebSocket 模式 |
|---|---|---|
| 内容能否逐步返回 | 可以 | 可以 |
| 后续请求如何发送 | 另行发起 HTTP 请求 | 可在已建立的连接中发送事件 |
| 选择时需要确认什么 | 接口格式、流式事件与模型兼容性 | 还需确认连接保持、多轮续接和工具交互支持 |
为什么 Codex 用户会关注原生链路？
编程任务往往需要连续处理上下文，并在模型与工具之间多次往返。连接方式和协议兼容性，会影响这些交互能否按客户端预期完成。
对用户来说，值得关注的是完整过程：开始任务后能收到输出，工具执行后能继续处理结果，下一轮交互也能正常完成。
WebSocket 为这类持续交互提供连接基础。具体响应速度仍取决于模型、任务长度、工具执行时间和网络条件，不能仅凭协议名称判断一次任务会快多少。
BeiAPI 的原生 WebSocket 支持包括什么？
我们将 Codex 作为一等公民，围绕配置与链路适配提供专门支持。
在支持该能力的 Codex 通道上，BeiAPI 提供原生 WebSocket 接入。已有验证覆盖同一连接上的多轮交互、增量续接，以及工具调用后提交结果并继续响应的流程。
这些验证用于确认链路能够承载连续任务。实际使用时，客户端版本、配置、模型和通道需要相互匹配；其他模型或接口的兼容范围应分别确认。
如何开始使用？
初次接入时，建议使用 CodexBei 一键配置，由工具完成密钥、地址和模型配置，然后重新打开客户端并新建任务。
收到回复后，可以在控制台确认请求记录。如果需要进一步确认某次请求是否使用 WebSocket，应结合客户端连接日志或联系售后排查；单凭输出效果无法确定协议。
需要手动配置、切换模型或恢复原配置，可以查看 CodexBei 完整图文教程。
常见问题
支持 WebSocket，是否代表所有请求都会走 WebSocket？
实际连接方式由客户端、配置和所选通道共同决定。服务端支持 WebSocket，并不意味着普通 HTTP 请求会自动改用 WebSocket。
WebSocket 能保证任务不中断吗？
连接仍可能受到网络、超时或上游状态影响。遇到异常时，保留错误提示和发生时间，查看服务状态，再结合错误与排查或售后支持处理。
不熟悉协议，也可以使用吗？
可以。日常接入按一键配置教程完成操作即可。理解链路的区别，主要是为了在选择服务和排查异常时更有依据。
继续了解小北科研 API 的五个优势，或直接进入快速开始。