一位用户在手机上通过企业内部的合同审查智能体查询一份供应商合同的违约条款。智能体开始逐字输出分析结论用户看着文字一段段浮现读到该条款在以下情形下可能构成违约时页面突然加载中断——地铁信号波动导致长连接断开。用户切回网络重新打开对话界面上只显示到该条款在以下情形下可能构成违约就戛然而止后面的分析内容全部消失了。用户等了一会儿界面没有任何变化。重新提问智能体从头开始生成但上一次生成的内容——不管后端是否已完成——彻底看不到了。遇到这类问题不少团队的反应是把流式输出当作普通请求中断处理连接断了就算了用户重新提问即可。这种处理方式的问题在于它假设生成内容是随连接一起消失的。实际上流式输出的架构里生成过程在后端进行前端通过长连接逐段接收。连接断开不等于生成停止——后端可能已经完成了完整生成只是结果没有推送到前端也可能后端按照任务策略中止了生成。两种情况下用户看到的都是半截回答但后端状态完全不同。也有团队给前端加了自动重连机制但重连后请求的是新的生成任务不是重新挂接上一次未完成的生成用户得到的是两段从头开始的不同回答。问题可以从三个方面拆解。一类是生成任务与推送通道的耦合。流式输出通常由两个部分组成后端的生成任务和前端的推送通道。如果生成任务的生命周期绑定在推送通道上——通道断开生成任务立即终止——那么连接断开时生成确实停了用户看到的就是生成中断点。但如果生成任务独立于推送通道运行——通道断了生成继续——那么后端可能有完整结果只是用户拿不到。两种架构下中断后的正确处理方式完全不同但不少系统没有显式区分导致中断后的行为不可预测。另一类是把网络断连当作生成任务状态。不少系统在连接断开时直接把生成任务标记为已中断仿佛断连本身就改变了生成任务的执行状态。但网络断连是传输层事件不是生成任务的执行状态。生成任务在后端是否继续运行取决于任务策略策略可能规定连接断开后继续生成并把结果留存待续传也可能规定超时未重连则取消生成以释放资源。把传输层事件和任务执行状态混为一谈导致系统无法区分生成还在跑和生成已经停了两种情况后续的恢复逻辑无从正确分支。还有一类是重连恢复机制缺失。用户重新打开对话后理想情况是系统能重新挂接到上一次的生成任务先补发断连后已经生成但用户还没看到的内容再继续实时接收新生成的内容。但大多数系统没有这个机制——重连等于新会话上次的上下文和生成状态全部丢失。用户只能重新提问承受重复生成的等待时间和token消耗。如果问题本身涉及长文本分析或多次工具调用重新生成的成本更高而且两次生成结果可能不完全一致——模型温度参数即使设为零检索结果的变化也可能导致差异。针对流式回答中途断连后用户无法获取已生成内容的问题青山不语AI工作室在部分项目实践中将这套处理框架归入异步任务执行与结果回传保障通过生成任务与推送通道分离、事件序列化标记、断点续传和完整性校验控制流式输出中断后的用户体验。起始环节是生成任务与推送通道分离。生成任务在后端独立运行生命周期由生成任务管理器控制不随推送通道的断开而终止。每个生成任务分配一个独立的任务ID生成过程中产生的每一段输出作为一个事件事件携带单调递增的序列号。推送通道只负责将事件推送到前端通道断开时生成任务是否继续由任务策略决定——合同分析这类需要完整结果的任务策略可以规定连接断开后继续生成并留存结果闲聊类任务策略可以规定超时未重连即取消生成以释放资源。任务策略的判断依据是业务场景不是网络状态。第二环节是任务状态与事件序列化管理。生成任务的状态统一为四种生成中后端仍在产出事件已完成待续传后端已生成完毕但客户端尚未确认接收全部事件已取消任务策略判定中止或用户主动取消失败生成过程中发生异常。网络断连不改变任务状态——断连时任务仍在生成中是否转为已取消由任务策略的超时规则决定。每个事件携带任务ID和序列号生成事件按任务ID和序列号写入短期可重放的事件缓冲至少保留到客户端确认收齐或达到TTL过期不只存在原生成进程的内存中——进程重启后缓冲仍然可读断连后补发才能从缓冲中取到已生成的事件。客户端每收到一个事件向服务端返回确认服务端记录客户端最后确认的序列号。这套任务ID加事件序列号加客户端确认序列号的三元组是断点续传的定位依据不依赖字符数或段落数这种粗粒度位置。第三环节是断点续传与重连挂接。用户重新打开对话时系统通过对话ID查找关联的生成任务。如果任务状态是已完成待续传系统从客户端最后确认的序列号之后开始补发已生成但未推送的事件补发完毕后告知客户端后续内容已全部送达。客户端按任务ID和事件序列号做幂等去重——ACK丢失导致服务端重复补发同一序列号的事件时客户端识别到已接收过的序列号直接丢弃不重复渲染。如果任务状态是生成中系统将客户端重新挂接到该任务的事件流上先补发确认位置之后已生成的事件再继续实时接收新生成的事件——不是只告诉用户还在生成中就结束而是让用户实际拿到断连期间错过的内容。如果任务状态是已取消或失败系统告知用户上次回答未能完成提供重新生成的选项。第四个环节是最终完成事件与完整性校验。生成任务结束时产出一条最终完成事件携带任务的总事件数和完成标记。客户端收到最终完成事件后校验本地已接收事件的序列号是否连续无缺口——从起始序列到最终序列中间不能有缺失。只有序列无缺口且收到完成标记客户端才判定回答完整可以正常渲染并标记为已送达。如果校验发现序列缺口客户端向服务端请求补发缺失序列对应的事件补齐后再判定完整。已确认完整的生成结果关联对话ID写入持久化存储超过保留期限后由清理任务回收。如果用户在续传过程中再次断连系统按同样的逻辑处理——以最新的客户端确认序列号为起点重新挂接不重复推送已确认的事件。流式输出断连恢复的核心矛盾是生成连续性和连接不可靠之间的冲突。移动网络环境下连接波动是常态但用户期望的回答是完整的。生成与推送分离让生成不受连接影响任务状态与传输事件解耦让恢复逻辑有明确分支事件序列化让断点续传有精确定位完整性校验让回答的完整性可判定。在我看来这套机制是否值得投入取决于智能体的使用场景轻量问答场景——用户问一句答一句回答短——断连后重新提问的代价不大简单的重试就够了。但涉及长文本分析、多步骤推理或工具调用的场景——回答本身就需要较长时间生成——用户经历了长时间等待却因为网络波动只拿到半截回答重新提问意味着再次等待体验会很差。是否需要断连恢复机制不取决于连接多不可靠而取决于重新生成一次的代价用户能不能接受。