SSE Token 流的可恢复性工程实践：断线续传、取消与多设备同步

当我们从同步交互模式转向异步 Agent 架构时，传输层面临根本性挑战。传统 SSE（Server-Sent Events）实现看似简单，但在处理 LLM Token 流时，可恢复性、取消操作和多设备同步等问题变得尤为复杂。本文将深入探讨这些工程挑战的具体实现方案。

Token 流与 API 响应的本质差异

在实际工程中，LLM 返回的 Token 与 API 响应结构存在显著差异。以 Vercel AI SDK 为例，一个完整的响应包含多种事件类型：text-delta 携带实际的文本片段、tool-call-delta 用于工具调用、finish-message 标记完成状态。Anthropic API 同样遵循这一模式，通过 content_block_delta 逐块传递文本内容。关键问题在于，每个事件行承载的元数据远超过实际的文本增量 ——Anthropic 的单个 content_block_delta 事件可能包含 125 个字符来传递仅 5 个字符的文本。这个比例决定了存储策略的设计基线。

传统架构下，客户端发起 POST 请求后保持连接打开，等待 SSE 流中的响应 Token。流完成后服务器将完整响应存入数据库，会话历史仅用于页面刷新时的状态恢复。这种模式在单设备、单连接场景下运行良好，但当连接中断时，in-progress 的 Token 流将完全丢失，用户必须等待完整响应写入数据库后才能看到结果。

可恢复流的实现机制

SSE 规范提供了基于 Last-Event-ID 的流恢复机制。核心思路是为每个事件分配唯一标识符，客户端跟踪已接收的最后一个事件 ID，断线后可重新连接并告知服务器从该位置继续推送。

具体实现需要考虑以下工程要点。首先是事件 ID 的单调性设计：每个响应分配唯一前缀（如响应 ID），后续 Token 依次编号，形成 abcxyz:0、abcxyz:1 的递进结构。这种设计便于精确追踪和 gap 检测。其次是持久化存储策略：由于现代应用通常采用无状态水平扩展架构，任何服务器副本都可能处理客户端请求，因此必须将每个 Token 写入数据库或 Redis Stream 等持久化存储，确保重新连接时被路由到不同副本时仍能获取历史数据。

这种方案引入了显著的写放大问题。对于成功完成的请求，Token 级别的存储数据实际上从未被使用 —— 只有当连接断开需要恢复时才派上用场。更关键的是，一旦响应完成，完整文本立即成为权威数据，单独的 Token 失去了存在价值，此时还需执行清理操作将历史 Token 替换为完整响应。在工程实践中，建议为 Token 设置合理的 TTL（例如 5 分钟），超时的未完成响应自动标记为失败，避免数据库膨胀。

服务器端的核心参数配置包括：每个事件必须包含 id 字段、reconnect 时正确解析 Last-Event-ID 头、从持久化存储中读取并回放缺失事件。客户端则需要在内存和 localStorage 中同时维护 Last-Event-ID，确保页面刷新后仍能从断点恢复。

取消信号的跨副本传递

实现可恢复流后，取消逻辑需要重新设计。过去的假设是客户端连接断开即代表取消，但现在连接断开可能只是网络波动，客户端随时可能携带 Last-Event-ID 重新连接请求恢复。因此，取消操作必须通过显式的信号机制实现。

工程实现上，需要提供独立的 POST /cancel/{response_id} 端点。该端点写入取消标记到共享存储（与 Token 存储使用同一数据库或 Redis），Agent 进程在处理每个 Token 之间检查该标记。若发现取消标记，立即中止上游 LLM 调用。由于处理推理请求的副本与接收取消请求的副本可能不同，共享存储成为跨副本传递取消信号的唯一可靠通道。

这种方案的响应延迟取决于检查频率 —— 建议在每处理 10 到 20 个 Token 后检查一次取消标记，平衡响应性与额外开销。对于实时性要求更高的场景，可考虑使用 Redis Pub/Sub 实现更快速的信号传递，但需处理订阅关系的生命周期管理。

多设备状态同步的两种困境

多设备支持实际上包含两个独立问题，解决方案各不相同。第一个问题是已生成 Token 的多设备共享 —— 由于已经将每个 Token 持久化存储，第二设备请求同一会话时可以直接获取历史 Token 流以及任何进行中的响应。这部分在实现可恢复流时已同步解决。

第二个问题更为棘手：当设备 A 发送新提示并开始接收 Token 流时，设备 B 如何感知到新响应正在进行并实时渲染？简单的轮询方案存在明显缺陷：低频率轮询导致高延迟，高频率轮询则严重增加服务器负载。传统的长轮询只是轮询的变体，并未本质解决问题。

对于多设备实时同步，更优的方案是引入发布 / 订阅通道机制。Pub/Sub 通道的生命周期与单个客户端连接解耦 —— 服务器持续向通道发布 Token，即使客户端断开连接，消息也不会丢失。多个客户端可订阅同一通道获取完全相同的 Token 流，通道自动处理重连、消息回填和历史记录。对于需要简化恢复逻辑的场景，可在通道层面实现 Token 压缩：追赶进度的客户端直接获取完整响应消息，而非逐个 Token 重放。

工程实践参数清单

基于上述分析，以下是生产环境部署的关键参数建议。事件 ID 设计采用 response_id:sequence 格式，其中 sequence 为自增整数。Token 存储建议使用 Redis Streams 或专用表，TTL 设置为 5 分钟并配合完成后的自动清理任务。取消检查频率建议为每 15 个 Token 判定一次，超时阈值根据 LLM 提供商的限制设置。多设备场景下优先考虑专用传输层（Ably 等），或基于 Redis Pub/Sub 构建自建方案，通道命名采用 conversation:{conversation_id} 格式。

这些工程实践表明，SSE 确实能够实现可恢复、可取消、多设备同步的 Token 流，但实现难度远超「简单」二字。HTTP 作为传输层在构建异步 Agent 应用时存在天然局限，在高性能场景下应评估专用实时传输方案的适配性。

参考资料

• How to make SSE token streams resumable, cancellable, and multi-device — /dev/knill（https://zknill.io/posts/everyone-said-sse-token-streaming-was-easy/）
• Resume tokens and last-event IDs for LLM streaming — Ably（https://ably.com/blog/resume-tokens-last-event-id-llm-streaming-reconnection）

web