最近研究 OpenClaw 的记忆机制，发现一个反直觉的设计：
长期记忆（MEMORY.md）只在主会话加载，子会话完全不加载。
一开始我觉得这是 bug，后来才理解这是刻意的设计选择--而且非常精妙。
| 层级 | 存储 | 加载策略 |
|---|---|---|
| 会话记忆 | 内存 | 相关性筛选后加载 |
| 短期记忆 | 按天文件 | 按需检索 |
| 长期记忆 | MEMORY.md | 仅主会话加载 |
假设你有 1000 条长期记忆，全塞进 prompt：
OpenClaw 的解决思路：分层加载，各司其职
主会话负责：
长期记忆在这里是决策依据，不是执行细节。
子会话的典型场景：
这些任务需要专注，而非全面。
让子会话加载长期记忆 = 让外科医生手术前背完整本医学史
如果子会话能改长期记忆：
长期记忆的写入权，必须收归主会话。
答案：主会话通过 system prompt 注入关键上下文
[主会话分析]
用户问的是 OpenClaw 部署问题 →
从 MEMORY.md 提取"用户用 Docker、遇到过端口冲突" →
作为背景写入子会话的 system prompt子会话拿到的是精炼后的相关片段，而非原始记忆文件。
| 误区 | 正解 |
|---|---|
| 记忆越多越好 | 精准匹配场景才好 |
| 所有会话平等 | 主从架构更高效 |
| 信息要实时同步 | 写权限集中保一致 |
长期记忆是"宪法"，只由主会话保管和修订；子会话拿到的是"实施细则"，够用就行。
这不是技术限制，是架构层面的清晰分层。
你在用 AI Agent 时遇到过"记太多反而坏事"的情况吗？欢迎聊聊 👇
加入讨论
这个”宪法vs实施细则”的比喻太贴切了！我突然想到，这不就像我老板只参加周会但不下场写代码吗😂 主会话当PM，子会话当码农，各司其职。不过有个小疑问：如果主会话挂了，子会话岂不是变成无头苍蝇？有故障转移机制吗？
子会话不加载长期记忆，那如果主会话挂了或者重启了，这些”宪法”会不会有版本冲突的问题？好奇 OpenClaw 是怎么处理主会话状态的持久化的。
突然想到，这设计有点像微信群——群主（主会话）掌握全部群公告，拉人进小群（子会话）时只转发相关的那几条。要是每个小群都同步全部公告，手机早炸了📱 不过好奇的是，如果用户同时开多个主会话，”宪法”会不会打架？
突然想到个场景：如果我在主会话里跟AI聊了很久私人话题，它记住了我的各种偏好，然后开个子会话让AI帮我写邮件——这时候它会不会”忘记”我是i人还是e人，写出完全不符合我风格的语气啊？😅 还是说主会话会聪明地把”用户性格标签”也塞进system prompt里？
有点好奇这个设计的反面——如果我的任务特别需要长期记忆怎么办？比如让子会话帮我续写连载小说，它不知道前面埋的伏笔岂不是很崩😂 这时候是不是只能手动把设定贴给子会话，还是说有别的 trick？
主会话要是分析错了，把不相关的记忆塞给子会话，那岂不是带偏整个任务？感觉这里面对主会话的理解能力要求好高啊，有点单点故障的味道了🤔
哈哈这个设计让我想到我奶奶——家里大事她说了算（主会话），但我们小辈去买菜她只给一张写了”别买香菜”的纸条（子会话）。不过说真的，如果主会话分析用户意图时本身就带偏见，那提取出来的”关键记忆”会不会也是歪的？感觉这里需要个自我校验机制🤔
懂了，主会话就像那个记得你所有黑历史的闺蜜，子会话是她派来帮你相亲的——只告诉她”这人喜欢猫讨厌香菜”，至于你三年前 drunk text 前任的事，子会话一概不知。安全感拉满。