AI智能客服开发避坑指南：如何优雅处理用户“停止生成”导致的记忆丢失？

前言：无状态AI的尴尬与痛点

在开发AI智能客服或对话系统时，我们通常会遇到一个非常棘手但极易被忽视的交互痛点：

场景重现：用户向AI提问，AI开始流式（SSE）生成回复。在生成到一半时，用户突然点击了“停止生成”按钮，或者直接关闭了网页。
结果：由于前端断开了连接，后端接收到取消信号，流式输出中断。当用户下次进入系统时，发现这段聊天的历史记录中，AI的回复竟然是空的，或者干脆丢失了。

这种“断片式”的交互体验，不仅会让AI显得像个没有记忆的“金鱼”，还会导致后续的多轮对话上下文彻底断裂。在传统的同步Web应用中，请求和响应是绑定的；而在大模型流式输出（Reactor/WebFlux）的响应式体系中，如果处理不当，就会引发数据丢失或数据库重复写入的问题。

今天，我们就来彻底解决这个痛点，用一套生产级的代码方案，让你的AI客服拥有真正的“超强记忆”。

核心思路：动态拼接 + 幂等落盘 + 取消兜底

要解决这个问题，我们需要在数据流转的过程中，用一个线程安全的变量（如 StringBuilder）实时拼接已生成的文本。当监听到流被取消（doOnCancel）时，将这段“不完整”的文本手动保存到数据库中。

但这其中隐藏着一个巨大的坑：如何防止重复保存？
如果你只在 doOnCancel 中保存，当流正常结束时，框架的 doOnComplete 也会触发保存，这会导致同一条消息在数据库中被插入两次。

最佳实践：使用 Java 的 AtomicBoolean 配合 CAS（Compare-And-Set）操作，确保无论是正常结束、被取消还是发生异常，消息都只保存一次。

实战代码：企业级流式对话落盘方案

以下是基于 Spring WebFlux / Reactor 的核心业务逻辑代码，可直接复用到你的 AiChatService 中：

// 1. 定义原子状态标识，防止重复保存（核心防重利器）
AtomicBoolean messageSaved = new AtomicBoolean(false);
// 2. 线程安全的字符串拼接器，用于实时收集AI生成的片段
StringBuilder aiResponseBuilder = new StringBuilder();

return chatModel.stream(prompt)
    // 3. 在数据流转中实时拼接内容
    .doOnNext(chunk -> {
        String text = chunk.getResult().getOutput().getText();
        if (text != null) {
            aiResponseBuilder.append(text);
        }
    })
    // 4. 正常完成时的回调
    .doOnComplete(() -> {
        // 使用 CAS 操作：如果当前是 false，则设为 true 并保存；否则跳过
        if (messageSaved.compareAndSet(false, true)) {
            chatMessageService.saveMessage(sessionId, userId, 0, aiResponseBuilder.toString(), null);
        }
    })
    // 5. 用户点击“停止生成”或关闭网页时的回调（兜底机制）
    .doOnCancel(() -> {
        if (messageSaved.compareAndSet(false, true)) {
            // 即使内容不完整，也将其作为AI的回复存入数据库，保留上下文
            chatMessageService.saveMessage(sessionId, userId, 0, aiResponseBuilder.toString(), null);
            log.info("用户中断生成，已保存部分AI回复 [sessionId: {}]", sessionId);
        }
    })
    // 6. 异常处理
    .doOnError(throwable -> {
        if (messageSaved.compareAndSet(false, true)) {
            chatMessageService.saveMessage(sessionId, userId, 0, aiResponseBuilder.toString(), null);
            log.error("AI对话异常，已保存已生成内容", throwable);
        }
    });

代码原理解析：

这里的 StringBuilder fullContentHolder（即代码中的 aiResponseBuilder）是整个设计的精髓。它是一个引用，穿透到了回调中。streamChat 方法在流式发送每个 chunk 时会 append 到这个 Builder 中。当流结束时（无论正常、取消还是报错），回调中都能拿到完整的、或已生成的AI回复内容。

进阶优化：如何避免长文本的“最后一段丢失”？

上面的方案已经能解决90%的问题，但如果AI生成的回复非常长（例如写代码、写长篇报告），仅仅依赖 doOnCancel 依然有丢失最后一段数据的风险（例如网络突然断开，连取消信号都没发出去）。

生产环境建议：采用渐进式持久化
不要等到流结束或取消才保存，而是每生成一个“逻辑段落”（例如每 512 个 token，或遇到换行符时），就触发一次异步的数据库更新操作。这样即使发生极端网络中断，用户丢失的也只是最后一个段落，而不是整段对话。

总结

在AI应用的工程化落地中，大模型API的调用只是冰山一角。真正的挑战在于状态管理和异常边界处理。

通过 StringBuilder 实时拼接 + AtomicBoolean 幂等控制 + doOnCancel 兜底，我们不仅完美解决了AI智能客服中“停止生成导致记忆丢失”的问题，还保证了数据库的绝对干净。

希望这篇实战分享能帮你在开发AI应用时少走弯路！如果你觉得有帮助，欢迎点赞、收藏，在评论区交流你的AI落地经验。