AI 流式输出断线后怎么续接：事件游标、重复片段与最终状态核对

线上客服把模型回答逐字推给用户时，最麻烦的不是首字节慢，而是连接在回答到一半时断掉：前端已经显示了半句，服务端却不知道断点在哪里，重试很容易把前半段再发一遍。解决这类问题，关键不是“再请求一次”，而是把每个流事件当成有顺序的账本，保存已确认的前缀，再用最终事件判断这次响应到底收没收尾。

断线续接先核对 response_id 和 sequence_number，再做已展示前缀去重；只有看到 response.completed 或明确的终止状态，才把回答标记为完成。

先把一次流式回答拆成三本账

以 OpenAI Responses API 为例，stream: true 返回的是一串服务器发送事件，而不是一个可以一次性解析完的 JSON。实际落库时建议把三类信息分开：身份账记录 response_id，顺序账记录事件的 sequence_number，展示账记录已经交给浏览器的文本前缀。

{
  "response_id": "resp_demo_42",
  "last_sequence": 17,
  "shown_text": "订单已经进入仓库，",
  "terminal_status": null
}

这里的 last_sequence 不是文本长度。一个事件可能是输出增量，也可能是响应创建、工具调用或完成通知，所以不能用字符数猜下一个位置。事件顺序和正文增量要分别记录，排查时才能知道是漏事件还是重复展示。

断线发生时，先判断能不能安全续接

断线后先读取本地账本。如果客户端只是 SSE 连接被代理切断，且最后一条事件已经持久化，可以把同一个响应的状态交给恢复流程；如果账本只有请求开始记录，没有可靠的响应身份，就不能假设新请求会从上一次的位置继续。

能确认响应身份：按事件序号过滤

恢复流程收到事件后，先校验响应 ID，再比较事件序号。小于等于 last_sequence 的事件只记为重复，不再次推给前端；大于它的事件才进入展示缓冲区。持久化顺序应是“写入事件账本、更新最后序号、提交展示结果”，不要先把文字发给浏览器再补写账本。

function acceptEvent(state, event) {
  if (event.response?.id !== state.responseId) return { kind: "foreign" };
  if (event.sequence_number 

示例只表达接纳边界，生产代码还要对未知事件保留原始类型和载荷摘要。这样 API 新增事件时，恢复程序不会因为只认识文本增量而悄悄丢掉顺序信息。

没有可靠断点：不要把重试当续接

如果 response_id 没落库、最后序号写入失败，或者上游已经返回了不可恢复的错误，就把这次请求标记为“结果待核对”。新建请求前先走服务端查询或人工补偿流程，并携带业务幂等键。重复提交同一个用户问题，可能产生两条都看似成功的回答，前端再怎么去重也无法证明哪一条才是原响应。

重复片段怎么去掉，才不会误删正常内容

恢复时常见的错误是用“新片段是否包含在旧文本里”做全局搜索。回答里可能自然重复一个词，这种算法会误删。更稳的做法是只比较已确认前缀的尾部和新片段的头部，找到最长重叠后追加剩余部分。

function appendWithoutOverlap(prefix, incoming) {
  const max = Math.min(prefix.length, incoming.length);
  for (let n = max; n > 0; n--) {
    if (prefix.slice(-n) === incoming.slice(0, n)) {
      return prefix + incoming.slice(n);
    }
  }
  return prefix + incoming;
}

这一步只处理展示文本，不替代事件序号校验。序号缺口仍然要报警；文本恰好能拼起来，并不能证明中间没有丢失一条工具事件或状态事件。

以终止事件关闭状态，不以网络状态收尾

连接关闭只是传输层现象。收到 response.completed 时，再读取其中的最终响应状态，把 terminal_status、完成时间和最后序号一起写入结果表；如果是取消、失败或不完整，也要保留对应原因，方便业务决定是否重试。

验收时至少检查四件事：事件序号没有倒退；最后一次提交的文本与展示缓冲区一致；终止状态与业务状态映射一致；同一个幂等键没有同时存在两条“已完成”记录。对于工具调用链，还应记录工具事件类型和调用结果摘要，不能只看最终几行文字。

线上排查的回滚与告警边界

恢复程序连续遇到序号缺口时，先停止向用户追加内容，把响应置为待核对；不要为了让页面动起来而跳过缺口。若最终查询确认响应已完成，可以从完整结果重新生成展示内容；如果状态是不完整，则把已展示前缀标成部分结果，并明确告知用户重新提交。

告警可以按三类打：短连接断开但最终完成，属于传输质量；出现序号缺口或跨响应事件，属于账本一致性；同一幂等键出现多条终止记录，属于重试控制。三类告警的修复方向不同，混成一个“AI 请求失败”会让值班人员误判。

相关问题

只保存最终文本，不保存流事件可以吗？

只能支持重新拉取完整结果，不能可靠判断断点和漏事件。需要用户看到增量内容时，至少保存响应身份、最后序号和已提交前缀。

网络断开后直接重新调用模型为什么不稳？

新调用会产生新的响应身份和新的生成过程，内容可能变化，也可能把已展示的部分重复返回。它应是明确的补偿策略，不应伪装成原流续接。

什么时候可以把结果标记为完成？

当终止事件已经落库、最终状态可解释、事件账本没有缺口，并且幂等键没有冲突时再完成收口。

收尾检查

流式输出的可靠性不在于把连接永远保持住，而在于断开之后仍能回答三个问题：这是哪一次响应、我已经确认到哪里、最终结果是什么。把这三项写进账本，再把文本去重限制在已确认前缀范围内，重连就从“碰运气重试”变成了可以审计的恢复流程。