流式输出中断后如何恢复未完成的模型响应

模型流式输出到一半断开时，最容易犯的错是立刻重发原请求，然后把新文本接到旧文本后面。这样做可能重复展示片段，也可能把一次生成误记成两次。更稳妥的做法是：先用业务层保存的 request_id、事件序号和幂等键恢复已经收到的内容；只有确认存在未覆盖的生成缺口，才按供应商明确支持的 continuation 能力或“带上下文重试”策略继续。

故障表象：屏幕停在半句话，服务端却不知道停在哪里

一次生成至少有三种状态：请求是否已创建、哪些增量已经持久化、模型侧是否已经结束。只保存一个不断增长的全文字段，无法判断断线前最后一段是否已经写入，也无法识别重连时收到的重复事件。SSE 的事件格式本身支持 id 和 retry 字段，但“能重连 HTTP 流”与“能恢复模型内部生成”是两回事。

排障时先记录四个值：request_id 关联一次用户请求，event_id 标识一个增量，status 区分进行中与终态，idempotency_key 约束重试只对应一个业务任务。

先把一次生成拆成请求、事件与存储三层

网关负责把上游事件转成统一格式，模型适配器只负责对接不同供应商，事件存储负责留下可重放的事实。不要让浏览器自己猜“当前文本长度就是游标”，因为中文、表情和分词边界都可能使字符数不能代表事件位置。

断线重连为什么不能直接把文本再拼一次

重连请求可以带上最后确认的 last_event_id。服务端从重放窗口找出更大的事件序号，经过去重判断后再返回给前端。若事件已经进入终态记录，就应该直接结束恢复；若本地没有对应事件，才进入“缺口处理”，而不是无条件把同一 prompt 再发一次。

下面是一个不绑定具体厂商 SDK 的服务端骨架。eventStore 和 modelAdapter 都是抽象依赖，示例重点是游标与幂等边界，而不是声称它已经连接某个模型。

async function recoverStream(requestId, lastEventId, idempotencyKey, send) {
  // 先校验幂等键，避免同一业务请求被并行恢复两次。
  const record = await eventStore.getRequest(requestId);
  if (!record || record.idempotencyKey !== idempotencyKey) {
    throw new Error("request identity mismatch");
  }

  // 只重放游标之后的事件；重复事件不会再次写入浏览器。
  const replay = await eventStore.after(requestId, lastEventId);
  for (const event of replay) {
    if (event.seq 

根因修复：把“已显示”和“已确认”分开

前端可以先显示内存中的增量，但服务端确认写入事件存储后，才把序号推进为可恢复游标。恢复接口返回事件时，客户端按 event_id 去重，而不是按文本前缀比较。文本前缀比较遇到重复标点、结构化输出或多候选内容时很脆弱。

上线前的检查清单

至少验证四个边界：重复点击恢复按钮不会产生第二个任务；同一个 event_id 重复到达只显示一次；终态之后再来的增量会被拒绝；重试失败时能保留原请求和错误原因。还要给重放窗口设置上限，窗口过期后明确返回“只能重新生成”，不要静默拼接一份看似完整的答案。

常见问题

流式接口断了，能不能从上次 token 继续？

只有供应商明确提供 continuation token、响应句柄或等价能力时才能这样做。业务层保存的事件游标只能恢复已收到的内容，不能凭空恢复模型内部状态。

为什么不能只保存完整文本？

完整文本缺少事件边界和确认位置，无法判断断线前的最后一段是否重复写入。保存增量事件与终态记录更容易重放、去重和审计。

重试时幂等键应该放在哪里？

它应绑定一次业务请求，并由服务端持久化校验。不要只放在浏览器内存里，否则刷新页面后同一请求可能被重新创建。