LLM 流式输出中断时怎么保存可恢复的对话状态

流式回答一断线就从头生成，通常不是模型“不会续写”，而是应用没有保存已经确认的增量。更稳妥的做法是：为每次生成分配 generation_id，把每个增量写入带递增序号的事件日志，客户端重连时从最后一个序号回放；提交对话时再用幂等键去重。

要恢复的是“客户端没有收到的已生成内容”，不是凭空保证模型从任意 token 继续生成。上游请求已经消失时，应明确标记未完成，再决定继续原任务或重新生成。

先把“断线”拆成三个不同问题

排查时先问清楚是哪一层断了。浏览器到服务端的 SSE 连接断开，只代表用户暂时没收到字节；服务端到模型的上游连接断开，才涉及生成是否还在继续；服务端进程重启，则要求恢复日志和生成状态本身是持久的。

状态记录可以长这样：status 使用 running、completed、failed、incomplete 等有限值；last_seq 表示已经持久化的最后序号，不要把“已经写入”和“已经显示”混成一个字段。

每个增量都要能重放，也要能去重

增量落库时，唯一键应至少包含 generation_id 和 seq。服务端先写事件，再向连接发送同一个 id，这样即使发送动作重复，也不会产生两条逻辑事件。下面的代码是一个最小的内存接口，生产环境把 EventLog 换成带唯一约束的数据库表或持久化日志。

type DeltaEvent struct {
    GenerationID string // 标识一次生成，不能用用户 ID 代替
    Seq          int64  // 同一生成内单调递增
    Text         string // 本次增量，不直接覆盖累计答案
}

func AcceptDelta(log EventLog, event DeltaEvent) (bool, error) {
    // 先用 generation_id + seq 幂等写入，重复事件直接视为已接受
    inserted, err := log.InsertIfAbsent(event.GenerationID, event.Seq, event.Text)
    if err != nil {
        return false, err // 持久化失败时不要向客户端确认
    }
    return inserted, nil // false 表示重试写入，不是新的增量
}

这里的关键不是“每个 token 都必须落库”，而是要定义检查点粒度。可以按字符片段、句子或固定字节数合并，但合并后仍要保留顺序和边界。若只保存一份不断覆盖的全文，重连时无法判断客户端缺了哪一段，也无法安全丢弃重复数据。

重连时只回放最后确认点之后的事件

SSE 事件可以带 id。浏览器重连时会把最后事件 ID 作为 Last-Event-ID 传回；不能依赖单个连接对象保存进度，因为连接对象在断线后已经不存在。服务端应按请求头读取游标，并从日志查询更大的序号。

func Stream(w http.ResponseWriter, r *http.Request, log EventLog) {
    // Last-Event-ID 缺失时从 0 开始；也可用受保护的 since 参数兼容非浏览器客户端
    after := parseSeq(r.Header.Get("Last-Event-ID"))
    events, err := log.After(r.Context(), r.PathValue("generation_id"), after)
    if err != nil {
        http.Error(w, "replay unavailable", http.StatusServiceUnavailable)
        return
    }
    w.Header().Set("Content-Type", "text/event-stream")
    for _, event := range events {
        // id 与数据来自同一条已持久化记录，客户端可按 seq 幂等合并
        fmt.Fprintf(w, "id: %d\\ndata: %s\\n\\n", event.Seq, event.Text)
    }
}

客户端合并时也要防御重复：收到的序号小于等于本地游标就丢弃，序号跳跃则先标记“缺片段”，不要把后来的文本直接拼接。对需要严格顺序的回答，宁可短暂等待回放补齐，也不要展示一段看似完整但中间缺字的内容。

模型上游中断后，状态要诚实地落在边界上

如果服务端仍持有上游任务并能继续消费，状态可以保持 running；如果上游已经返回错误或任务句柄失效，就把状态改成 incomplete，保存错误码和最后 seq。重新发起模型请求时使用新的生成 ID，并把已确认的回答作为上下文，而不是伪造“从第 N 个 token 接着生成”。

最后一个坑在业务提交：用户点击“保存回答”可能因重连被发送两次。为提交请求生成稳定的 Idempotency-Key，服务端将键与会话、结果摘要和处理状态绑定；相同键返回第一次结果，不要再次创建消息。

常见问题

只把累计文本存到 Redis 可以吗？

可以作为短期缓存，但它不能天然告诉你缺失区间。至少同时保存最后序号和可回放的增量，或把 Redis Stream 等日志结构设置为明确的保留窗口。

WebSocket 断线也要用 Last-Event-ID 吗？

不一定。Last-Event-ID 是 SSE 语义；WebSocket 应在应用消息中自行传递恢复游标，核心仍是“客户端游标 + 服务端事件日志 + 幂等合并”。

每个 token 都写数据库会不会太慢？

高并发下通常会合并增量或批量刷盘。重要的是先确定可接受的丢失窗口：刷盘前断电可能丢最后一小段，但不能让已经确认的序号重复或乱序。

可恢复流的最小闭环可以收敛成四个检查点：生成身份唯一、增量顺序稳定、事件先持久化后确认、业务提交使用幂等键。这样即使网络和上游分别出问题，用户看到的状态也能解释、重放和继续处理。