小龙虾(OpenClaw)源码分析5：Session机制，如何保证上下文连续
文章目录
AI助手好不好用，关键不只是模型强不强，还得看“会不会记住该记的上下文”。
这一篇就专门聊Session。
为什么Session这么关键
没有会话管理时，常见问题有：
- 每次都像“失忆”，上下文断裂
- 不同用户/群聊串线
- 长会话越滚越大，成本和延迟失控
OpenClaw的做法是把会话当成一等公民：
既要连续，也要可控。
Session的核心职责
我把它总结成4条：
- 确定“这条消息属于哪个会话”
- 管理会话历史读写（持久化）
- 控制上下文窗口（压缩/重置）
- 暴露操作命令（如
/new、/reset、/compact）
session key到底怎么理解
最常见的理解方式：session key = 会话身份，它通常由渠道、发送方、线程等因素组合而成。
这层设计好处是：
- 同一用户对话可连续
- 不同来源天然隔离
- 便于后续按会话做队列和并发控制
前面我们看到队列文档里提到按session:<key>串行执行，其实就是这层在发挥作用。
历史存储不是细枝末节
OpenClaw里会话历史是可落盘的（JSONL思路），这件事很重要：
- 进程重启后还能续上上下文
- 可以做审计和排障
- 为后续压缩策略提供输入
做AI系统时，别小看“日志化历史”，很多线上问题最后都靠它定位。
重置与压缩：不是可选项，是必选项
长期会话一定会遇到上下文膨胀。
因此OpenClaw给了两类机制：
- 显式重置（
/new、/reset） - 会话压缩（
/compact）
简单说就是：
该清空就清空，该提炼就提炼，不要无脑堆历史。
读源码时建议观察的点
你可以重点看下面这些问题：
- session key在什么时候生成
- 会话历史是在哪个阶段拼到模型上下文里
/reset触发后，哪些状态被清掉- 压缩后是否会保留关键事实（而不是全删）
这些问题比“某个函数叫什么”更重要。
小结
这一篇我们明确了：
- Session是上下文连续性的核心基础设施
- 需要在“连续性”和“资源可控”之间平衡
- 会话机制和后续队列/并发策略是联动的
下一篇进入高频痛点：并发消息来了之后，OpenClaw怎么避免串台和打架。
