Session 到底是什么

你可以把 Session 想象成一个笔记本。每次你跟 AI Agent 开始一段连续对话，系统就打开一本新笔记本，把你说的话、AI 的回答、中间调用工具产生的结果（比如搜索到的网页内容），以及这轮对话消耗了多少 Token，全部记在里面。

在 OpenClaw 中，这本"笔记本"最终会被保存成一个 .jsonl 文件。每次你发新消息，OpenClaw 就把这个文件里的历史记录打包发给大模型，模型才能基于上下文给你连贯的回复。

换句话说，Session 就是 Agent 此刻"记得谁"、"正在聊什么"的边界。超出这个边界的内容，模型看不到。

两层地址：Key 和 ID

OpenClaw 把 Session 拆成了两个层次来管理：

  • Session Key（路由键）：相当于一个固定的信箱地址。它根据你的渠道（飞书、Discord 等）和 dmScope 配置自动生成。只要你的身份不变，这个地址就不会变。
  • Session ID（对话实体）：相当于信箱里具体的一叠信件，也就是前面说的 .jsonl 文件。当系统触发重置时，旧的 ID 会被归档，但不会被删除——文件还在磁盘上，只是 Agent 不再主动去读它了。系统会为同一个 Key 关联一个全新的 ID。

这个设计意味着：重置不等于丢失，只是 Agent 换了一本新笔记本。

对话为什么会"失忆"

OpenClaw 默认在凌晨 4 点重置会话，但这里藏着一个容易踩坑的细节：重置是惰性的。

系统并不会在 4:00 准时清理。它会等到你在 4:00 之后发送第一条消息时，才去对比当前时间，然后决定是否重置。而因为重置发生在新消息到达的一瞬间，系统来不及把旧 Session 的内容转存到任何地方。

结果就是：昨晚你和 AI 讨论了一个复杂方案，今早你一句"早上好"，Agent 就已经换了一本空白笔记本，之前的讨论全部隔断。

上下文快满了怎么办

当对话的 Token 数量接近模型的上下文窗口上限时，OpenClaw 有两道自动化防线协同工作：

第一道：Compaction（自动压缩）

系统启动摘要模式，把较早的对话内容总结成一段精华摘要，只保留最近几轮的原始消息。这样在有限的窗口内尽量保住对话逻辑，防止 Agent 因为上下文溢出而彻底崩溃。

第二道：Session Pruning（上下文剪枝）

这是专门为 Anthropic 的提示缓存（Prompt Caching）设计的省钱策略。大段的工具返回结果（比如读取一份长文档）会迅速吃掉缓存的 TTL 时间。系统会智能地剪掉过时的工具结果，只保留头尾摘要。

不过有一条保护规则：最近 3 条助手消息之后的工具结果永远不会被剪掉，确保模型正在处理的任务不会因为上下文突然缺失而报错。

跨 Session 的记忆体系

为了跨越每次重置带来的记忆断层，OpenClaw 构建了三层记忆梯队：

层级 载体 特点
短期记忆 Session ID（.jsonl 文件） 包含最详尽的对话细节，但随重置断开
长期核心记忆 MEMORY.md 永久记忆，系统每次启动时必读
语义记忆 memory/*.md 永久记忆，基于向量搜索按需召回

这里面有一个精巧的机制叫 Memory Flush（记忆刷新）：在触发压缩之前，系统会静默发起一次内部调用，让模型把当前值得记住的事实写入 memory/ 目录下的文件。这个过程会消耗少量 Token，而且只在压缩前自动触发。

这意味着如果你手动重置 Session，系统不会自动帮你保存记忆。所以在手动重置前，最好先引导 AI 做一次总结，确保重要信息被写入长期记忆。

实操建议

理解了这套机制，日常使用中可以抓住几个要点：

  • 防止失忆：在重置前主动发送 /compact 命令触发记忆固化，或者手动编辑 MEMORY.md 把关键信息写进去。
  • 多用户隔离：如果你的 Agent 要服务多个用户，务必配置 dmScope: per-peer，避免不同用户的对话混在同一个信箱里。
  • 长期偏好注入：把你的永久偏好写在 USER.md 中。这是 Agent 每次"醒来"都会阅读的出厂设定，不受 Session 重置影响。

Session 机制本质上是在"记忆容量"和"使用成本"之间做平衡。搞懂了这个平衡点，你就能让 Agent 在该记住的时候记住，该省钱的时候省钱——这对于一个人运营 AI 工作流来说，既是技术问题，也是成本问题。