昨晚还聊得好好的。
你跟 OpenClaw 一起梳理方案、记待办、定步骤，甚至已经把今天要继续的事都铺好了。结果第二天早晨你一开口，它来一句：像什么都没发生过。
很多人碰到这里，第一反应都是一样的：完了，记忆坏了。
但啧，真相往往没那么复杂。
大多数时候，锅不在 MEMORY，也不在 QMD，更不在 embedding。真正更常见的元凶，是 session.reset。
更狠的是，这个坑还很像“记忆系统故障”，所以特别容易误诊。你会去查向量检索、查长期记忆、查模型上下文，折腾半天，最后才发现：原来只是 OpenClaw 在凌晨按默认策略把会话切走了。
如果你把 OpenClaw 当个人助手用，这个默认配置非常容易把体验直接打废。
先说我的结论：
个人助手场景下，不要默认用
session.reset.mode = "daily"。更稳的方案，是改成idle，再按dm / thread / group分类型设置。
这不是玄学优化。
这是最影响“它到底像不像一个连续工作的助手”的配置之一。
这坑到底是怎么来的
OpenClaw 官方文档其实写得很直白。
它的会话会按重置策略复用，直到过期。而 daily reset 默认按 Gateway 主机本地时间凌晨 4 点判断。一旦过期，下一条消息到来时，就会创建新的 sessionId。
翻成人话就是：
你昨天晚上聊的那一段，到了今天早晨，可能已经不在同一个会话桶里了。
所以你第二天看到的典型症状会是这样：
- 它接不上你昨晚的话
- 你说“按昨天那个方案继续”，它一脸茫然
- 你开始怀疑长期记忆是不是挂了
但这里要先分清两个概念。
1）Session 不是长期记忆
session 更像是“这一段连续对话”。
它负责保存最近这段聊天的上下文，决定模型这一轮能不能自然接着上一轮往下说。
2）Memory 才是长期记忆
MEMORY.md、memory/*.md、QMD 这套，更接近“长期笔记”和“可检索事实”。
它们能帮助手段性地找回过去的信息，但那种“像昨天还在同一个聊天里”的连续感，主要还是靠 session。
所以很多人说“OpenClaw 第二天失忆”，严格讲，很多时候并不是长期记忆没了，而是短期会话连续性断了。
这俩不是一回事。
为什么 daily 对个人助手特别伤
如果你做的是客服机器人、值班机器人、工单机器人，那 daily 其实不难理解。
它的优点很明确：
- 每天自动切新会话，边界干净
- 更容易审计
- 不容易把前一天的上下文脏东西带进今天
- 对成本和上下文膨胀更保守
问题在于，个人助手不是这么用的。
你对私人 AI 助手的期待，通常不是“它每天凌晨帮我切干净”，而是：
- 昨天说到一半的事，今天还能接着说
- 我不用每天重新讲背景
- 我一句“按昨天那个继续”，它就该听得懂
而 daily 这套默认逻辑，跟这种预期几乎是反着来的。
它不是错。
只是特别不适合“个人助理”这个场景。
最佳配置方案：别按天切，按空闲时长切
如果你问我，OpenClaw 在个人助手场景下，session.reset 最值得推荐的默认方案是什么，我的答案很直接：
全局别再用
daily，改成idle。然后按不同会话类型分别设置。
推荐配置如下：
session: { |
如果你主要只在私聊里用 OpenClaw，甚至可以再更简单一点：
session: { |
但更推荐的，还是前面那版按类型拆开。
因为它更接近真实使用场景。
我为什么认为这是“最佳默认方案”
不是因为它最激进，也不是因为它参数最大。
而是因为它在连续性、干净程度、成本控制之间，平衡得最好。
私聊：该长就长
个人助手最核心的体验，几乎都发生在私聊里。
而私聊一旦隔夜就断，会特别难受。
你前一天才刚定好的任务、方案、取舍，第二天要重新铺一遍背景，这体验基本就废了。
所以 DM 最应该保连续性。
我建议默认先给 7 天 idle，原因很简单：
- 足够跨天
- 足够覆盖多数人一周内的连续工作流
- 又没有长到完全放飞
如果你是重度个人助理用户，也可以把私聊拉到 30 天：
dm: { |
但对大多数人来说，7 天已经够舒服了。
线程：保一天，通常最顺手
thread、topic 这种东西，本质更像“围绕某个任务临时开出来的上下文容器”。
它不是永久办公室，更像项目讨论间。
所以这里我不建议拉太长。
1 天 idle 是个很顺手的值：
- 今天没聊完，明天还能接上
- 如果已经冷掉，就让它自然结束
- 不会积一堆陈年上下文
比起“每天凌晨固定 4 点切一刀”，这个策略更贴近人的实际工作节奏。
群聊：短一点才稳
群聊最容易脏。
消息多、话题乱、噪音高，还容易串上下文。
所以群聊没必要像私聊一样保很久。
2 小时 idle 是个比较稳的起点：
- 能覆盖一轮连续讨论
- 不会把半天前的群聊垃圾也拖进来
- 真出问题也更容易排查
如果你群特别安静，也可以放宽到 4 小时、6 小时。
但别上来就按私聊标准去配群聊，不然迟早串味。
哪些人不该直接照抄这套
这套配置，不是全场景通杀。
它是给“把 OpenClaw 当个人助手”的人准备的。
如果你是下面这些场景，就别无脑照抄：
1）客服 / 工单 / 值班机器人
这种场景更看重边界清晰、审计方便、上下文隔离。
那 daily 反而可能是合理的。
2）高合规环境
如果你的要求就是“每天必须开新会话”，那就不要用私人助手思路套进来。
3）极端成本敏感场景
虽然 OpenClaw 有压缩、摘要、记忆刷新这些机制，但会话活得越久，上下文管理通常越复杂。
如果你特别在意 token 和会话膨胀，就要把 idleMinutes 设得更保守一点。
改完之后，怎么确认自己真的修好了
最笨也最有效的方法，不是盯着配置发呆，而是直接做一次隔夜验证。
最小验证路径
今晚先跟 OpenClaw 聊一段有明显上下文的内容
- 比如一个部署方案
- 一个待办列表
- 一个你自定义的代号
确认你已经把
daily改成idle第二天早晨直接问：
按我们昨天那个方案继续。 |
成功表现
如果配置生效，正常应该看到这些现象：
- 它能自然续上昨天的讨论
- 不需要你再从头铺背景
- 不会像第一次见面一样重新起头
如果没生效，先查这几个地方
- 只改了
reset，没改resetByType - thread 里还留着
daily - 某个 channel override 又把它覆盖回去了
- 你测试的其实不是同一类会话（比如昨天在 topic，今天跑到私聊）
很多人以为自己已经改好了，结果不是没改成功，而是有覆盖项没清干净。
这个坑最容易误诊的 3 个方向
误诊 1：上来就怀疑 MEMORY / QMD
这最常见。
一看到隔夜接不上话，大家就会去查：
- MEMORY.md 有没有写入
- QMD 有没有 embed
- rerank 是不是挂了
- 向量索引是不是坏了
但啧，先别急着拆这么深。
先查 session.reset。
因为它才是最像“隔夜失忆”的第一嫌疑人。
误诊 2：觉得“只要关掉 daily 就万事大吉”
也不一定。
你如果只改全局 reset，但 resetByType.thread 还保留着：
thread: { mode: "daily", atHour: 4 } |
那你第二天在 Telegram topic 或 Discord thread 里，照样可能断。
误诊 3：一刀切追求“永不重置”
这也不是好路子。
表面上看，永不重置最连续。
但后面你很可能会遇到这些问题：
- 会话越来越脏
- 任务之间互相串味
- 排查问题更麻烦
- 某些场景下成本更难控
所以更稳的思路不是“彻底不重置”，而是：
该长的地方长，该短的地方短。
也就是：私聊长一点，线程中等，群聊短一点。
这才是更适合个人助手的现实配置。
最后一句话
如果你把 OpenClaw 当个人助手，
别让它每天凌晨 4 点把昨天的你“格式化”掉。
真正更顺手的配置，不是粗暴关掉会话管理，而是把 daily 改成 idle，再按 dm / thread / group 分开设置。
这样你既能保住“隔天还能接着聊”的体验，也不会把所有会话无限拖下去。
对个人助手来说，这不是边角料配置。
这是最影响体感的那一项。
]]>
