Open Responses WebSocket 传输完整指南：60 分钟连接限制与断线恢复策略-平芜编程栈

【免费下载链接】openresponses

项目地址：https://gitcode.com/gh_mirrors/op/openresponses

Open Responses 是一个多提供商、可互操作的 LLM 接口的开源规范，灵感来自 OpenAI Responses API。从2026-04-24版本起，它在传统 HTTP/SSE 流式之外正式引入了WebSocket 传输，并配套定义了60 分钟连接限制与断线恢复策略。本文用通俗的语言讲清楚：这种新传输方式如何工作、60 分钟到达时系统会发生什么，以及如何选择三种重连恢复模式之一，让长会话无缝继续。

为什么要增加 WebSocket 传输

Open Responses 一直以来的流式输出走的是 HTTP + Server-Sent Events（SSE）：每轮对话一次独立的 HTTP 请求，服务端通过text/event-stream推送事件。这个模型简单可靠，但对长时程会话或双向 agentic 循环（模型调用工具 → 客户端回填结果 → 模型继续推理）来说，每轮都新建 HTTP 连接开销不小，客户端还得手动维护对话链。

WebSocket 传输正是为此而生：服务端 MAY 在同一个/v1/responses资源上打开一条持久 WebSocket 连接，客户端与服务端在这条连接上继续复用同一套语义流式事件——sequence_number序号、item 生命周期、终止事件的语义与 HTTP 流式完全一致。

关键点：WebSocket 只是一个传输模式，并不是另一套响应对象模型。你的数据模型不变，变的只是通道。

WebSocket 上的一轮对话如何进行

用 response.create 开启每一轮

客户端 MUST 以带type: "response.create"的 JSON 对象开始每一轮。其余字段与普通响应创建请求体一致，只有一处差别：

stream、stream_options、background这些 HTTP/SSE 专属字段，MUST NOT出现在 WebSocket 请求里。

一轮开启请求的简化示例：

{ "type": "response.create", "model": "gpt-openresponses-1", "store": false, "input": [ { "type": "message", "role": "user", "content": "Find the bug in fizz_buzz()." } ] }

一条连接同一时间只跑一个响应

单条 WebSocket 连接 MUST 最多同时处理一个 in-flight 响应。服务端 MAY 在同一连接上接受多条response.create消息，但 MUST顺序处理，不允许在一条连接上并行多路复用多个响应。需要并行跑多个响应？规范的建议很直接：开多条 WebSocket 连接。

对话续接：previous_response_id 与连接本地缓存

Open Responses 用previous_response_id表达"接着上一轮继续聊"。在 WebSocket 上语义与 HTTP 相同，但有两个值得注意的细节：

续接请求只需携带新输入（如工具结果、下一条用户消息）加上上一轮的previous_response_id，不必重发整个上下文。
连接本地状态：服务端 SHOULD 把最近的 previous-response 状态保存在活跃 WebSocket 连接的本地内存中。这让续接延迟更低；更重要的是，它让store=false（零数据保留）部署也能在同一个 socket 上继续，无需把响应状态写进持久化存储。

相应的清理规则也很严格：如果某次续接以4xx或5xx失败，服务端 MUST 把该previous_response_id逐出连接本地缓存；之后在同一连接上再从这个 ID 续接，MUST 失败并返回previous_response_not_found。

如果响应链变长、上下文膨胀，可以先调用/responses/compact端点拿到压缩后的输入窗口，再以它作为新一轮的基础input，追加最新的用户或工具 item 继续对话。

60 分钟连接限制：到达时会发生什么 ⏱️

这是 WebSocket 传输客户端必须记住的一条硬规则：WebSocket 连接限时 60 分钟。到达上限时，服务端 MUST 返回一个错误码为websocket_connection_limit_reached的结构化错误，客户端 SHOULD打开一条新的 WebSocket 连接。

也就是说，任何超过 60 分钟的会话都要预设"断开一定会发生"。好消息是：规范给出了三种明确的恢复模式，覆盖了几乎所有场景。

三种断线恢复策略

连接断开（无论是 60 分钟限到还是意外中断）后，按你的状态管理方式选择恢复路径：

场景	恢复策略	关键动作
`store=true`，响应 ID 仍有效	继续旧链	新连接上发`previous_response_id`+ 新输入 item
`store=false`、零数据保留，或收到`previous_response_not_found`	开新响应	省略或将`previous_response_id`置`null`，发送完整输入上下文
上下文已用`/responses/compact`压缩过	用压缩窗口重建	以压缩窗口为基础`input`，追加最新用户/工具 item

策略一：previous_response_id续接。上一轮响应是store=true持久化的、且 ID 仍然有效，重连后直接带上 ID、只发新输入即可，模型"看见"的是完整历史，体验最顺滑。

策略二：开一个全新响应。对store=false、零数据保留部署，或收到previous_response_not_found的情况，旧链已不可续——此时省略previous_response_id（或置null），把下一轮的完整输入上下文重发一遍。略重一些，但语义上最可靠。

策略三：用压缩重建上下文。如果断线前你调用过/responses/compact，就用当时返回的压缩窗口作为新响应的基础input，再追加最新的用户或工具 item。既保留上下文连续性，又控制住了 token 成本。

读懂 WebSocket 错误信封

WebSocket 上的失败一律以 JSONerror信封发送，内含status代码与error.code。规范要求客户端至少处理这两个错误码：

previous_response_not_found—— 引用的 previous response 在连接本地状态中找不到
websocket_connection_limit_reached—— 60 分钟连接限制已到

一个典型错误：

{ "type": "error", "status": 400, "error": { "code": "previous_response_not_found", "message": "Previous response with id 'resp_abc' not found.", "param": "previous_response_id" } }

用合规测试验证你的实现 ✅

官方仓库内置了一整套覆盖 WebSocket 传输的合规测试：单轮响应、顺序处理、续接、断线恢复、缓存逐出、压缩后开新链等都有对应测试用例。本地或 CI 中都可以直接跑：

bun run test:compliance --base-url http://localhost:8000/v1 --api-key $API_KEY --filter websocket-response,websocket-reconnect-store-false-recovery

关键资源

规范正文（WebSocket Transport / Reconnects / Errors 章节）：src/specifications/2026-04-24.mdx
事件 schema 定义（客户端事件与错误信封）：schema/events.tsp
createResponse操作与x-openresponses-websocket扩展：schema/routes.tsp
版本化 OpenAPI 文档：public/openapi/2026-04-24/openapi.json
合规测试实现（WebSocket 会话与恢复测试用例）：src/lib/compliance-tests.ts
版本变更历史（2026-04-24 条目）：CHANGELOG.md

总结

WebSocket 传输为 Open Responses 提供了一条持久、双向的传输通道，其设计精髓在于复用与 HTTP 完全相同的语义流式事件和状态模型，把学习成本压到最低。落地时记住三件事：用response.create开启每一轮；一条连接同一时间只跑一个响应；始终按"60 分钟必到"做预案——只要根据store设定选对恢复策略，长会话就能无感续跑。