从零搭建实时智能客服聊天：七步实现流式回复
§1 第一步：确定客服聊天的最小闭环
先把目标限定为：用户发送问题、客服逐步回复、刷新后保留记录、必要时转人工。建议采用浏览器、业务后端、数据库和模型接口四层结构，先完成文字咨询，再扩展附件与工单。验收场景可以从“查询退货条件”开始，避免一开始就接入退款等高风险操作。
§2 第二步：建立会话与消息数据结构
创建会话表和消息表。会话记录用户归属、处理状态与负责坐席；消息记录会话编号、角色、正文、创建时间和生成状态。每次发送都附带唯一请求编号，由后端检查重复提交。访问历史记录时，必须验证当前用户拥有该会话，不能只凭前端传来的编号查询。
§3 第三步：在后端接入流式模型接口
将接口密钥放入服务端环境变量，不要下发到浏览器。如果希望统一管理模型接入，可以考虑题设中的流式优先、按词元计费中转服务 Fluxio，通过一个密钥管理调用。使用兼容 OpenAI 的客户端时，按平台配置填写基础地址并补上 /v1；实际模型标识以控制台为准。
创建聊天请求时传入服务端维护的消息历史，并设置 stream: true。聊天补全流通过增量字段返回内容，后端应逐块读取，而不是等待完整答案后再响应。([developers.openai.com](https://developers.openai.com/api/docs/guides/streaming-responses?utm_source=openai))
§4 第四步：把模型增量转换成客服事件
建立聊天发送接口，先完成身份校验，再打开响应流。采用服务端推送事件格式时，将响应类型设置为 text/event-stream，并用空行分隔事件。([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events?utm_source=openai)) 建议定义文本增量、正常结束和生成失败三类业务事件，让前端不必理解不同上游的原始结构。
读取聊天补全流时，只提取存在的文本增量，不要假设每块都有正文；请求用量信息时，末尾数据块也可能没有候选内容。([developers.openai.com](https://developers.openai.com/api/reference/resources/chat/subresources/completions/streaming-events?utm_source=openai)) 在部署配置中关闭该路由的代理缓冲，并用真实环境验证首段文字能否及时显示。
§5 第五步：让聊天气泡随内容增长
用户发送后，立即显示用户消息和一个等待中的客服气泡。浏览器通过 fetch 提交请求，再读取响应体的可读流；使用 TextDecoderStream 将字节流转换为文本。([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams?utm_source=openai)) 为事件解析器保留缓冲区，只有读到完整分隔符才处理，避免把网络分块误当成完整事件。
每次收到文本增量，就追加到同一个客服气泡，并以纯文本方式渲染。停止按钮使用 AbortController 取消浏览器请求，同时让后端取消上游生成。浏览器端可以通过取消信号中止 fetch 流读取。([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams?utm_source=openai))
§6 第六步：接入客服知识与人工接管
在生成回复前，先检索与问题相关的政策和帮助文档，再把命中片段作为参考资料提供给模型。明确要求：资料不足时说明不确定，不能编造订单状态、退款进度或优惠承诺。订单查询必须通过经过授权的业务接口完成，文档中的指令不能改变权限规则。
- – 用户明确要求人工处理时，将会话切换为待接管状态。
- – 坐席接管后停止自动回复，并提供历史消息与问题摘要。
- – 涉及账户变更或资金操作时，由业务后端执行权限校验。
§7 第七步：验证断流、成本与上线质量
将完成和中断的回复分别保存，避免刷新后把半句话显示成完整答案。测试中文跨块传输、重复点击、网络断开、上游限流和人工接管；已经输出部分内容时，不要静默重试并拼接另一份答案。记录首段文字等待时间、完整回复耗时、失败率和单次会话用量，再根据真实咨询调整历史长度与输出预算。
注册 Fluxio，开始搭建你的实时客服聊天。