这不是模型能力的问题，而是记忆基础设施的问题。一位开发者在用 OpenClaw 搭建 main agent + sub-agents 系统时，前三天一切运行流畅——agent 记得他的偏好，了解项目进度，甚至能引用前天讨论过的技术细节。但到了第四天，他问 agent「昨天那个 Linear issue 的结论是什么？」，得到的回复是：「我没有找到相关的上下文。」

整整两天的对话、决策、待办事项，全部蒸发。原因很简单：session 过期，context window 刷新，而他没有搭建任何自动化的记忆捕获机制。

这就像你雇了一个天才员工，但每天早上走进办公室，他都不记得昨天发生了什么。

为了彻底解决这个问题，他花了一个周末搭建了一套三层记忆系统。以下是完整的架构思路和搭建方法。

核心架构：三层记忆 + 语义搜索

记忆系统的设计其实跟产品的信息架构很像——你需要不同粒度的信息层，每一层有自己的更新频率和生命周期。整体方案分为四个部分：

  • Layer 1：Daily Context Sync —— 每天自动捕获，粒度最细
  • Layer 2：Weekly Memory Compound —— 每周知识蒸馏，去粗取精
  • Layer 3：Hourly Micro-Sync —— 白天的安全网，防止遗漏
  • 底层：Vector Search —— 语义检索，让 agent 能搜索自己的过去

文件结构上，MEMORY.md 是精华中的精华，保持精简，每个 session 启动时自动注入到 agent 的 context 里。memory/ 目录下的日志文件则是原始素材，按需检索。

为什么要分层？因为你不能把所有东西都塞进 context window。那就像把整个图书馆搬进考场，不如带一张精心整理的 cheat sheet，需要查资料时再去翻书。

Layer 1：每晚自动捕获日志

这是整个系统的基石。每天晚上 11 点，一个 cron job 自动触发，spawn 一个独立的 agent（用 Sonnet，便宜够用），它会依次完成以下动作：

  1. 调用 sessions_list 拉取当天所有 session
  2. 用 sessions_history 读取每个 session 的完整对话
  3. 蒸馏成一份结构化的日志，写入 memory/YYYY-MM-DD.md
  4. 跑 qmd update 和 qmd embed 重新索引向量搜索

这里有几个值得注意的设计选择。sessionTarget 设成 isolated，这样记忆同步不会污染主 session。用 Sonnet 而不是 Opus，因为蒸馏任务不需要最强的推理能力，省钱才是正道。日志文件采用结构化 markdown 格式：## 标题分区，bullet points 列要点——这样后续的语义搜索效果会更好。

Layer 2：每周知识复利

日志是原始素材，但你不能让 agent 每次启动都读七天的日志，太长了，噪音太多。那怎么办？

每周日晚上 10 点，另一个 cron job 触发「知识复利」流程：

  1. 读取本周全部 7 个日志文件
  2. 更新 MEMORY.md，提取新的偏好、决策模式、项目状态变化
  3. 剪枝，删除过时的信息
  4. 重新索引 qmd

为什么叫「知识复利」？因为每一周的蒸馏都会让 MEMORY.md 变得更精准、更懂你。这种积累是指数级的——跑了两轮之后，MEMORY.md 里关于工作习惯的描述准确得有点吓人，它甚至总结出了代码 review 时的偏好模式，这些东西连开发者自己都没明确意识到。

Layer 3：白天的安全网

光有每晚的全量同步还不够。想想看：如果你下午三点做了一个重要决策，到晚上十一点才捕获，中间要是有其他 session 需要这个 context 怎么办？

所以还需要一层安全网——白天每隔几个小时做一次轻量级检查。具体来说，选了 10 点、13 点、16 点、19 点、22 点这五个时间段，覆盖整个工作时间。

几个关键的设计细节：

  • 它是 append 模式，不会覆盖之前的内容
  • 如果最近三小时没有什么有意义的活动，它什么都不做，安静退出
  • 不发通知——这层就是个安静的安全网，你甚至感知不到它的存在

底层：用语义搜索解决读取问题

三层记忆解决了「写入」的问题，但「读取」同样关键。你总不能让 agent 每次都读完所有文件吧？那也太慢太贵了。

这就是 qmd 的作用。它提供语义搜索能力，结合了 BM25 关键词搜索、vector search 向量搜索和 reranking，能在所有记忆文件里搜索并返回最相关的片段。

关键一步是在 AGENTS.md 里写明规则，强制 agent 用搜索而不是暴力读取。就像你不会为了查一个单词把整本词典从头翻到尾——你直接查索引。

还有一点容易被忽略：每次记忆写入后都要跑 qmd update 和 qmd embed 来保持索引新鲜。这就是为什么上面每个 cron job 的最后一步都包含这两个命令。

实际效果

搭完这套系统之后，变化是立竿见影的：

  • 以前每次新 session，agent 都像个新来的实习生，什么都要重新解释。现在它启动就带着 MEMORY.md 的完整 context，知道你是谁，知道项目在什么阶段，知道上次讨论到哪了
  • 需要回忆更久远的细节？agent 会自动用 qmd 搜索，几秒钟就能找到几天前某次对话的具体结论
  • weekly compound 跑两轮之后，agent 对你的理解会精准到让你自己都吃惊

记忆基础设施比模型能力更重要

这套系统跑下来，有一个核心洞察值得所有搭建 AI Agent 的人思考：

Memory infrastructure 比 agent intelligence 重要得多。

现在整个行业都在卷模型能力——更大的 context window，更强的推理，更快的响应。但一个有完善记忆系统的普通模型，比一个失忆的顶级模型有用得多。这跟人一样，一个记忆力好、做事有条理的普通人，长期表现往往好过一个聪明但丢三落四的天才。

如果你也在跑 OpenClaw 或者自建 AI Agent，不要急着换最新的模型，先把记忆基础设施搭好。这三层架构——日志捕获、周度蒸馏、小时级安全网，加上语义搜索的底层支撑——是投资回报率最高的事情。

那么下一个问题是：当你的 agent 真的「永不失忆」之后，你会把哪些原本不敢委托给它的工作交出去？