深度使用过 OpenClaw 的人，大概率会遇到这三件事中的一件或多件：

场景一：昨晚你和它一起调试了一个棘手的 bug，方案曲折，结论清晰。今天再问它同一个问题，它一脸茫然，好像那场对话从未发生过。

场景二：在一个 session 里，你和它来回讨论了几十轮，然后你问它前面讨论过的内容，它说"你要是知道就发给我吧，我不记得我们讨论过这个"。

场景三：你把详细的行为规范写进了 MEMORY.md（任务怎么执行、汇报用什么格式、删除文件前如何确认）。它每次回复都很好，除了从来不按规范来。

不是 AI 变笨了，是记忆系统的架构问题。

记忆是把需要记住的东西写成 Markdown 文件，下次需要时检索出来注入上下文，不是靠模型本能地记住对话内容。

OpenClaw 的记忆文件分两类：

每天一个文件，以追加方式写入当天的对话摘要、项目进展、决策结论。AI 需要主动调用 memory_search 工具才能检索到它们的具体内容。

这是用户精心筛选的长期记忆，比如项目背景、技术偏好、工作流程规范。但这类文件只在私人会话中加载，群组会话中不存在于上下文中。

此外还有 SOUL.md（人格、语调与行为边界）和 AGENTS.md（工作区操作指令模板），两者在会话启动时加载到上下文，AI 每次回复都能看到。

只有文件分类理解了，问题才会清晰：这些文件是如何被触发、被加载的？为什么理论上能记住，实际上却记不住？

OpenClaw 有一个自动记忆刷新机制（memory flush）：在上下文快满、即将触发压缩之前，先让 AI 把这一段对话中的重要信息写入 memory/YYYY-MM-DD.md，然后再压缩。这样记忆被提前保护，压缩不会导致记忆丢失。

问题在于：这个 flush 触发条件，在日常短对话中几乎不会满足。

flush 在以下任一条件满足时触发：

也就是说，日常的短对话几乎不会触发 flush。

flush 与 compaction 是两个独立机制：flush 是写入记忆（写入 memory/YYYY-MM-DD.md），在 compaction 之前运行；compaction 是压缩会话历史本身，用精简的浓缩版本替代原始消息，两者触发时机不同，但都依赖相同的 context 阈值。

而一次普通的项目讨论，通常远未达到这些阈值。当天讨论的所有内容始终停留在 Session 内存中，没有写入磁盘。第二天开始新的 Session，memory/YYYY-MM-DD.md 是空的。

这是设计问题，不是 bug。

退一步讲，就算 flush 触发了，内容也成功写入了 memory/2026-03-24.md，第二天 AI 能想起来吗？

OpenClaw 官方 AGENTS.md 模板中，包含一条启动指令（这是用户可自定义的配置，不是系统强制的加载顺序）：

Before doing anything else:1. Read SOUL.md — this is who you are2. Read USER.md — this is who you're helping3. Read memory/YYYY-MM-DD.md (today + yesterday) for recent context4. If in MAIN SESSION (direct chat with your human): Also read MEMORY.md

memory/YYYY-MM-DD.md 的内容通过 AGENTS.md 的启动指令在会话开始时加载到上下文，AI 需要主动调用 memory_search 工具才能检索其中的具体内容。AGENTS.md 里虽然写了"先读昨天日志再回复"，但这只是文字层面的指令约束，没有任何机制说"AI 必须先执行完这三步才能回复"。AI 可以选择执行，也可以直接跳过。

先读昨天日志再回复"是一个文字层面的最佳实践，不是技术层面的执行保证。

这个根因的隐蔽之处在于：它不是某一行代码的问题，而是文件定位层面的错误。行为规范被写进了知识仓库 MEMORY.md，而非操作指令文件 AGENTS.md。

我曾经在 MEMORY.md 里写了大量行为规范：任务怎么执行、汇报用什么格式、删除文件前如何确认。但 AI 几乎从不遵守这些规范。

原因是：虽然 MEMORY.md 在会话启动时会自动加载，但它的定位是"知识仓库"。OpenClaw 官方对文件有明确分工：SOUL.md 定义人格、语调与行为边界（Persona、Tone、Boundaries），AGENTS.md 定义操作指令和工作流程（Operating Instructions、"how to behave"）。行为准则应该写在 AGENTS.md，而非 MEMORY.md。MEMORY.md 里的内容，AI 更多是当作信息来检索，当作必须遵守的规则的情况很少。

打个比方：把行为规范写入 MEMORY.md，类似于把宿舍公约放进图书馆的资料柜里，它确实存在，但不会被当作公约来执行。

使用 OpenClaw 时，我最自然的表达是"记住这个"、"永久记住这条规范"、"记下来，以后照这个做"。我期待 AI 把规范内化为行为约束。AI 收到这个指令后，实际做的动作是把文本写入 MEMORY.md，从这一刻起，这条规范静静躺在文件里，等着被检索，很少真正被遵守。

这不是我的错。我发出"记住"指令，AI 却把它理解为"存储信息"，从一开始就走在不同的方向上。根因三说的是规则写在了错误的位置，根源更靠前：我发出"记住"指令的那一刻，AI 就已经把行为规范存进了错误的地方。

OpenClaw 的记忆文件有明确分工：MEMORY.md 是知识仓库，AGENTS.md 才是行为准则的载体（Operating Instructions、"how to behave"）。我把行为规范写入 MEMORY.md，AI 把它当作信息检索而非行为约束来引用，导致规范被记住但不被执行。

那么，把规则从 MEMORY.md 迁到 AGENTS.md 是不是就解决了？

这只解决了表层问题。AGENTS.md 里即使写了"禁止跳过第 1 步直接回答"，AI 仍然可以选择性忽略这条指令直接回复用户。AGENTS.md 是被加载的上下文，不是强制执行的系统。

配置层面的优化无法根本解决这个问题：规则被看见了，执行却全靠自觉。

前提说明：以下改动依赖 AI 对 prompt 指令的服从性，无法做到系统级强制执行。配置优化能做的，是提高 AI 表现出预期行为的概率，而非保证执行。

前面五个根因指向同一个事实：OpenClaw 的记忆系统本身存在多层制约，AI 的输出本质上是概率生成，不是确定性执行。

没有任何配置方案能让 LLM 变成"听话的机器"。

AGENTS.md 每次会话都加载，AI 每次回复都在上下文中。MEMORY.md 虽然也会在启动时加载，但它被定位为知识仓库而非行为准则。

把原本写在 MEMORY.md 里的行为准则（任务执行流程、汇报格式规范、删除确认格式等）全部迁移到 AGENTS.md。MEMORY.md 之后只保留索引功能：记录客观信息（如知识库结构、常用工具链等），不混入行为规范。

同时，在 AGENTS.md 中明确写入一条：当对方说"记住"时，AI 需要判断内容类型。回答"怎么做"的内容写入 AGENTS.md，回答"是什么"的内容写入 MEMORY.md。这样我的自然指令能直接导向正确的文件位置。

在 AGENTS.md 中加入：

## 跨天记忆（每次新消息必须执行）
每次收到新消息（包括每天第一次消息）：1. 先调用 memory_search 查询最近的 memory/YYYY-MM-DD.md（今天 + 昨天）2. 再读 SOUL.md3. 再处理当前消息

这一改动重在提醒 AI 有这么个步骤，而非让它强制读取。 实际效果取决于 AI 在当前上下文中的服从性。

将 MEMORY.md 从混合了行为规范和各类项目信息的混乱状态，改为干净的索引结构：只保留客观事实，所有行为准则不再混入。

## 每日 End-of-Day 检查
当 heartbeat 触发且时间已接近日终时：1. 读取当天的 memory/YYYY-MM-DD.md2. 如果内容少于 3 行，向用户确认后追加3. 追加内容：完成工作、决策、待办、问题解决

这个流程的作用是兜底：即使当天对话量不足以触发 flush，end-of-day 检查也能把重要内容写入日志。

self-improving-agent 是一个独立项目，提供了一套完全不同的解决思路：它聚焦于建立主动捕获+提炼+晋升的循环，而不是优化现有系统的触发条件。

它的核心假设是：即使优化了配置，遗漏仍然会发生。我纠正了 AI 的错误做法、AI 发现了更好的方法、某个错误反复出现，这些"活的经验"既不是写在 AGENTS.md 里的规则，也不是会被 flush 保存的对话内容。

self-improving-agent 的价值在于捕获这些遗漏，并把它们提炼成规则。

三层架构：

关键设计：

1）任务后提醒：每次我提交 prompt 后输出一个提醒块（约 50-100 tokens），提醒 AI 评估是否有值得记录的学习。错误检测则在 Bash 命令执行失败后触发。

2）三类日志分类：

• LEARNINGS.md：我纠正 AI 的做法，最佳实践，知识缺口

• ERRORS.md：命令失败、异常

• FEATURE_REQUESTS.md：我请求但不存在的能力

3）重复检测：每个学习条目可标记 Pattern-Key，用于检测重复出现的模式，避免同一错误被记录多次

4）晋升机制：这是 self-improving-agent 项目在 SKILL.md 中自定义的晋升规则（不是系统默认行为）：当某个模式同时满足以下三个条件时，建议晋升：有价值的学习条目会被晋升到 SOUL.md/AGENTS.md/TOOLS.md（由 AI 判断是否执行）。条件一：Recurrence-Count ≥ 3（同一 Pattern-Key 出现 3 次以上）；条件二：跨至少 2 个不同任务；条件三：出现在 30 天窗口内。

• 根因 1（Flush 触发苛刻）：有效，任务后提醒，不依赖 flush

• 根因 2（第二天未必读）：有局限，提醒仍靠自觉，无法保证

• 根因 3（规则写错地方）：有效，晋升机制自动写对位置

• 根因 4（"记住"被误解）：有效，Hook 引导 AI 判断内容类型

• 根因 5（无强制执行）：无效，仍是 prompt 层，无法根本解决

方案一和方案二解决的是不同层面的问题，不是同一问题的两种解法。

• 配置层（系统如何设计才合理）：方案一 规则迁移、索引重构；方案二 无（不涉及）

• 触发层（何时写入记忆）：方案一 flush 优化 + end-of-day 定时；方案二 任务后主动提醒

• 捕获层（遗漏了怎么办）：方案一 HEARTBEAT 定时提醒（有局限，依赖 AI 自觉）；方案二 activator 每次提醒（有局限，依赖 AI 自觉）

• 执行层（看了不执行）：方案一 无法解决；方案二 无法解决

1）最小配置：只用方案一，适合不想引入新机制的场景。

2）完整配置：方案一 + 方案二叠加，两者互补：

• 方案一确保规则放在正确位置，让 AI 每次都能看到

• 方案二捕获运行中的遗漏，并把它们提炼成新的规则

• 方案二的晋升机制持续补充方案一的规则库

核心逻辑：方案一是"预防"，方案二是"补救"。两者都依赖 AI 的自主行为，能做的是"提高概率"，不是"保证执行"。承认这个局限，才能更理性地选择和使用这些方案。

说白了：记忆这套系统和执行这套系统，从根上就是分开的两套东西，我们一直把它们混在一起用，这才是大多数 AI Agent 记忆系统设计出问题的真正原因。

所以，AI Agent 记忆系统设计的核心问题，是怎么让记忆系统主动影响执行，而不是怎么让 AI 记住更多。这需要在架构层面把要被记住的事实和要被执行的规则分开设计。

承认 AI 天生不可靠，是做好 AI Agent 应用的前提。