一、多轮对话背景为什么上下文这么重要1.1 单轮 vs 多轮的本质区别维度单轮对话多轮对话上下文❌ 每次独立✅ 保留历史消息用户体验金鱼脑聊两句就失忆老朋友能聊一整天Token 消耗低只看当前问题高每次都带历史实现复杂度简单中等要理会话状态典型场景翻译、摘要、抽取客服、辅导、AI 助手1.2 现实场景为什么离不开多轮如果只有单轮第 2 轮用户就不知道我是谁了AI 只能干瞪眼。多轮对话的核心让 AI 记住前面聊过什么。二、多轮对话的工作原理2.1 大模型本身没有记忆任何大模型GPT、Qwen、DeepSeek…都是无状态的所以多轮不是模型的能力而是调用方你的程序的责任。2.2 多轮 把历史消息打包一起发关键结论多轮对话 每次都把完整对话历史发给模型。2.3 多轮对话系统的三件套三、多轮对话的入门案例手写一个最小可运行版本3.1 用 Python 字典模拟不依赖任何外部存储✅能跑但重启就丢数据。生产环境必须用持久化存储 → 这就是 Redis 登场的原因。四、Redis 对多轮对话消息的存储4.1 为什么选 Redis 而不是 MySQL多轮对话的消息读写非常频繁每发一条都要读 追加用 Redis 性能更优。4.2 数据结构设计Key-Value 约定设计要点用:分隔的层级结构方便按前缀查询和清理。4.3 Redis 客户端初始化Python4.4 消息的存储格式每条消息用JSON 字符串存到 Redis Listensure_asciiFalse是关键 —— 不然中文会被转成\u4f60\u597d调试时很难看。4.5 常用 Redis 操作一览五、创建会话与会话列表5.1 接口设计5.2 创建会话完整代码5.3 查询会话列表5.4 一个细节自动用首条消息更新标题效果用户发了帮我优化一份 Python 后端简历后会话标题自动变成帮我优化一份…。5.5 前端效果六、发送消息与查询消息6.1 完整流程图6.2 发送消息接口6.3 查询消息接口6.4 为什么要跳过第 0 条第 0 条是system prompt给模型看的不该给用户看返回给前端时从LRANGE 1 -1跳过它即可七、多轮对话优化你会遇到的所有坑7.1 坑 1消息越长调用越慢、越贵必须做上下文管理否则用户聊到 50 轮就崩了。7.2 坑 2JSON 解析失败导致整条消息丢失7.3 坑 3Redis 内存无限增长会话和消息没有过期时间 → 用久了内存爆炸。7.4 坑 4并发写入冲突两个用户同时发消息 →LRANGERPUSH之间可能丢数据。方案用 Redis 事务或分布式锁。7.5 坑 5异步任务阻塞 HTTP 请求send_message同步等大模型返回 → 客户端 HTTP 超时。方案 1让前端用异步轮询方案 2用 WebSocket 或 SSE 推结果八、滑动窗口 历史压缩上下文管理的两把利剑8.1 为什么需要上下文管理大模型的context window上下文窗口是有限的超过这个长度模型要么报错要么忘记最早的内容。现实业务中我们不可能让用户聊到上限才动手必须提前压缩。8.2 滑动窗口保留最近 N 条最简单粗暴只保留最近的 10 条消息。优点实现极简、速度快。缺点前 N-10 条的上下文彻底丢失AI 会突然失忆。8.3 历史压缩让大模型自己总结更聪明的做法 ——让大模型把早期对话压缩成一段摘要再和最近的消息一起发给模型8.4 效果对比只滑动窗口8.5 进阶三级压缩策略效果聊到几百轮也几乎不丢上下文。8.6 压缩策略选型表九、把整套流程串起来9.1 完整系统架构9.2 完整调用链路一次 send_message9.3 一次完整会话的 Redis 数据演变十、总结一张图看懂多轮对话学习路径一句话总结多轮对话 每次把历史 messages 一起发给模型会话和消息存 Redis长了用滑动窗口 历史压缩控制成本。附录常见坑排查清单