会话管理：如何维护对话状态
AI怎么记住你说过的话？会话ID、状态存储、历史加载...会话管理是让AI「有记忆」的关键。了解会话生命周期、并发处理、会话恢复等核心技术。
你在咖啡店和老板聊天，点了一杯拿铁。五分钟后你又回来，老板还记得你的订单——因为你还在店里，这还是同一个「会话」。
但如果你离开一天再回来，老板就不记得了——会话结束了。
AI系统的会话管理也是一样。它要让AI记住你在同一个对话里说过的所有话，但又要区分不同的对话。这听起来简单，实现起来却有不少细节。
会话（Session）是用户和AI之间的一次连续对话。它有这些特征：
- 1.会话ID：唯一标识一个会话，类似「订单号」
- 2.用户ID：会话属于哪个用户
- 3.对话历史：按时间顺序存储的消息列表
- 4.会话状态：活跃、暂停、结束
- 5.创建时间/更新时间：用于过期清理
一个会话从创建到结束,会经历几个阶段：
创建阶段：用户发送第一条消息时创建会话，分配唯一session_id
活跃阶段：对话持续进行，每次消息更新对话历史和updated_at
暂停阶段：用户暂时离开（超过30分钟无活动），会话进入休眠状态
结束阶段：用户主动结束或超过24小时无活动，会话标记为ended
归档阶段：结束后移至冷存储，7天后永久删除（根据数据保留策略）
会话数据存在哪里？这取决于你的规模和需求：
| 存储方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 内存缓存 (Redis) | 速度快、低延迟 | 容量有限、重启丢失 | 活跃会话缓存 |
| 关系数据库 (PostgreSQL) | 强一致性、支持复杂查询 | 扩展性有限 | 中小规模应用 |
| 文档数据库 (MongoDB) | 灵活Schema、易扩展 | 一致性较弱 | 大规模应用 |
| 对象存储 (S3) | 成本低、无限容量 | 延迟高、不支持实时查询 | 历史会话归档 |
实际生产中，通常采用多层存储架构：
一个棘手的问题：用户快速连续发送多条消息，这些请求可能并发到达，如何保证对话历史的顺序正确？
场景：用户快速发送三条消息
消息A：「你好」
消息B：「在吗」
消息C：「求助」
问题：三条消息可能同时到达服务器，处理顺序可能是A→C→B，导致对话历史错乱！
解决方案：
- •给会话加版本号
- •更新时检查版本是否变化
- •冲突时重试或报错
- •用Redis给会话加锁
- •同一时刻只有一个请求能修改
- •其他请求排队等待
用户暂停对话后，如何恢复？有两种策略：
🔄 自动恢复
用户发送新消息时，自动加载最近一个活跃会话。适合客服、助手类场景。
📋 手动选择
展示历史会话列表，让用户选择要继续的对话。适合长期项目、多任务场景。
核心要点
- ✓会话是一次连续对话，包含ID、用户、历史、状态等要素
- ✓生命周期：创建→活跃→暂停→结束→归档
- ✓存储采用多层架构：Redis缓存 + 数据库存储 + 对象归档
- ✓并发问题用乐观锁或分布式锁解决
- ✓会话恢复支持自动或手动两种策略
第77篇：上下文管理——AI如何记住你在说什么
会话管理解决了「对话归属」问题，但AI能「看到」多少历史？这就涉及上下文管理。下一篇，我们来聊聊上下文窗口、滑动窗口、摘要压缩...这些让AI既能记住关键信息，又不会被历史撑爆的技术。
✏️ 手绘图解 · AI Catch 出品
第 76 篇 / 共 84 篇