Grok Responses WebSocket怎么用？连续对话、内存状态与断线恢复

代理连续调用模型与工具时，每轮重建连接会有额外开销。Grok Responses支持在一个长连接上发送多轮response.create，并从上一响应继续。本文说明握手、增量输入和恢复规则，不把它与Grok语音WebSocket混淆，也不声称自己的应用已经测得公告中的延迟提升。

第一步：明确连接与状态策略

地址是wss://api.x.ai/v1/responses，认证由服务端Authorization提供。不要把API密钥放公开网页前端。官方说明单个连接串行处理多轮，不提供同一连接上的真正多路并行；需要并行时另开连接，并由应用隔离用户与任务状态。

每条链先选store策略，理解团队ZDR设置。连接内缓存可使store=false或ZDR场景在当前连接上增量续接，但不意味着断线以后仍有持久历史可读取。本地仍需保留恢复所需的完整输入及响应状态。

第二步：发送一轮可辨认的练习消息

import WebSocket from "ws";

const socket = new WebSocket("wss://api.x.ai/v1/responses", {
  headers: {Authorization: `Bearer ${process.env.XAI_API_KEY}`}
});
socket.on("open", () => socket.send(JSON.stringify({
  type: "response.create", model: "grok-4.7", store: false,
  input: [{type: "message", role: "user",
           content: [{type: "input_text", text: "练习：记住代号为星河。"}]}],
  tools: []
})));
socket.on("message", data => {
  const event = JSON.parse(data.toString());
  console.log(event);
});
socket.on("error", error => console.error(error.message));
process.on("SIGINT", () => socket.close());

这是基于ws的Node.js连接观察示例，保存为.mjs并在已配置依赖与认证的受控环境使用；本文未运行付费调用。它打印事件用于理解协议，不是生产级自动恢复客户端。真实业务避免记录敏感完整输出，且必须根据完整事件与结束状态判断这一轮是否成功。

第三步：只在当前轮结束后发送增量

每轮发response.create，字段与Responses创建请求相近，但不加入stream或background等传输字段，服务端会通过Socket流式返回事件。等当前轮结束并取得实际最新响应ID，再用previous_response_id与新增input继续，不把虚构ID或尚未完成响应拿来续接。

后续请求形状：
{"type":"response.create","model":"grok-4.7","store":false,"previous_response_id":"替换为本轮真实最新响应ID","input":[{"type":"message","role":"user","content":[{"type":"input_text","text":"刚才的练习代号是什么？"}]}],"tools":[]}

续接只发新用户消息或实际工具结果，不重复全部旧input。若没有真实tool_call，就不编造function_call_output。验证第二轮能正确回答代号，并在客户端记录每轮状态；模型说记住了不等于状态已经可靠保存。

第四步：区分断线恢复的两条路径

官方当前单连接最长59分钟，到期需要新连接；网络中断也可能发生。store=true且响应ID仍有效时，可在新连接续接；store=false或ZDR下无法从持久存储恢复，应去掉previous_response_id，发送下一轮所需完整上下文建立新链。

previous_response_not_found表示连接缓存没有且无法从存储读取，不能靠无限重发同一ID解决。一次失败也可能清除相应连接缓存。收到websocket_connection_limit_reached应按连接上限处理，不误判成账号永久无权限。

第五步：验证恢复与业务幂等

在无敏感信息练习中分别验证正常续接、断线、错误ID和本地历史重放。连接恢复不保证外部工具操作没有执行过，涉及写入时需独立任务编号、状态与幂等控制，不能因为没看到最终事件就再次创建同一订单或发送消息。

完成标准是每轮顺序清楚、实际结束状态已读、当前ID与新增输入匹配，并且断线后按存储策略恢复。只测到Socket连接成功或收到第一个事件，不足以证明连续对话和恢复流程已经可用。

若已知接下来需要的工具和指令，可按官方文档用generate:false预热，它准备连接状态但不运行模型生成正文，仍会提供可续接的响应ID。先完成正常路径再评估是否需要预热，不为了追求速度增加难以恢复的状态。测性能时区分握手、首个正文与整轮结束的耗时，用同样输入和条件比较，不能把内部基准直接当成你的实测。

官方资料

资料核对日期：2026年11月9日。

• xAI：WebSocket Mode
• xAI：Responses API reference