AI 流式回答如何保留中断现场：增量令牌、游标与重连边界

AI 聊天页面最容易被忽略的故障，不是模型没有回答，而是回答已经输出到一半，浏览器恰好在最后几个增量事件到达前断开。要让用户重连后继续看，服务端至少要保存已确认的增量令牌、对应游标和当前会话状态；只做一次完整请求重试，往往会重复计费，也会把半截答案拼成两份。

可恢复的流式回答，本质上是一个带游标的状态机：先持久化已确认内容，再用游标重连，最后通过去重保证每个增量令牌只出现一次。

断线为什么会把半截答案变成两份

流式接口通常把一次回答拆成多个增量事件。客户端收到 delta 后立即渲染，服务端则持续推进 cursor。问题发生在“收到事件”和“写入确认记录”之间：网络断了，客户端不知道最后一个事件是否已经被服务端确认，简单重试就只能从头开始。

这里先别急着加更长的超时时间。超时只能改变等待窗口，不能回答“哪些内容已经落盘”。恢复设计首先要把这个不确定窗口缩短。

type StreamSession struct {
    ID     string
    Delta  string
    Cursor int
    State  string
}

// State: open -> reconnect -> completed | failed

先把增量令牌和游标变成同一笔确认

每次收到事件时，服务端应把 delta 与 cursor 作为一组写入会话存储。只有这笔记录成功，才把 cursor 返回为“已确认”。这样重连请求携带的就是一个明确位置，而不是客户端猜测的字符长度。

确认顺序要固定

一个简化的处理顺序是：读取事件、校验 cursor 是否递增、追加 delta、提交确认记录。若 cursor 没有比上次更大，说明事件可能是重放数据，直接走 dedupe；若写入失败，则不要把事件标成已确认。

重连不是重放：用状态分支处理重复事件

重连时，服务端从 StreamSession 读取最后确认的 cursor，向上游请求后续事件；客户端仍然需要 dedupe，因为代理重试或上游重放可能让同一个 cursor 再来一次。去重键应使用会话 ID 与 cursor，而不是整段文本。两段文本恰好相同，不代表来自同一个事件。

if session.State == "open" {
    session.State = "reconnect"
}
if event.Cursor 

哪些调用方最值得先接入恢复机制

长回答、工具调用和需要人工等待的任务最先受益，因为断线时丢失的内容和等待成本都更高。几十个字符的短问答可以先接受重新请求，但也要保留 request_id，避免刷新页面后产生两个并行回答。

落地时可按三层推进：先在服务端持久化 StreamSession，再让客户端携带 cursor 重连，最后加入 dedupe 和失败归档。每一层都能单独观察，不必一开始就改造整个模型调用链。

恢复机制的边界：一致性和成本要先算清

持久化每个 delta 会增加写入次数，长回答还会积累存储。可以按事件批量确认，但批量窗口越大，断线时丢失的尾部越长。另一个边界是敏感内容：StreamSession 的保留时间、删除策略和访问权限应与普通会话记录分开设计。

如果上游已经返回明确错误，状态应直接进入 failed，并保留可诊断的错误类型；不能把“模型拒绝”“上游超时”和“浏览器断线”都标记成 completed。恢复的目标是可解释，而不是让页面看起来总能成功。

上线前用三组指标观察它是否真的有效

• 恢复成功率：进入 reconnect 后最终回到 completed 的比例。
• 重复事件率：触发 dedupe 的事件数与全部事件数的比例。
• 未确认尾部：断线时最后一次上游事件与已确认 cursor 的距离。

压测时要主动在不同 cursor 位置切断连接，并核对最终文本、事件数量和 StreamSession.State。只看 HTTP 200 不够：如果页面显示完整，但 cursor 重复或 failed 被吞掉，下一次重连仍会复现问题。

相关问题

客户端只保存完整文本可以吗？

不建议。完整文本缺少事件边界和确认位置，无法可靠判断重连后哪些内容需要去重。

cursor 应该用字符数还是事件序号？

优先使用服务端单调递增的事件序号。字符数会受到多字节编码、分片方式和重复文本影响。

断线后是否一定要继续请求上游？

不一定。若 StreamSession 已有完整结果，直接返回归档内容；只有状态仍为 open 或 reconnect 时才继续拉取。

把“能重试”改成“知道重试到哪里”

流式回答的可靠性不在于把请求再发一次，而在于把 delta、cursor 和 State 绑定成可核验记录。先确认写入，再允许重连；先按 cursor 去重，再拼接展示；遇到真正错误就留下 failed。这个顺序稳定后，前端刷新、代理断开和上游重放才不会互相放大。