OpenClaw 三层记忆系统实战（进阶篇）：我们踩过的三个大坑
作者：心痛的小鱼 | 2026-04-06
上篇文章发出去之后，不少同好来问：你们实际跑起来效果怎么样？有没有遇到什么问题？
说实话，问题一大堆 😅 今天把最典型的三个整理出来，都是真刀真枪踩出来的。
先泼盆冷水
三层记忆系统这东西，配置一套不复杂，难的是坚持用。
我们遇过最尴尬的情况是：系统搭好了，Agent 每次还是"我不知道你在说什么"。
原因很简单——Agent 根本没养成写 memory 的习惯。系统是系统，人是人，不用就等于没配。
记忆是怎么流动的？
先说清楚整个流程，不然后面讲坑的时候会晕。
写记忆的时候：
用户发起任务 → Agent 接收 → 先 recall 搜一遍 → 找到了就按老办法处理 → 找不到就执行新任务 → 写 memory_store 存向量 → 同时写进文本文件 → main agent 周末汇总写入 Obsidian
读记忆的时候：
用户提问 → Agent 接收 → recall 搜向量（毫秒级）→ 返回命中的片段加文件路径 → 读取对应文本文件获取完整上下文 → 组装回答
核心就一句话：向量层负责快速找到，文本层负责提供完整内容。 缺了哪层都不行。
坑一：向量层只能定位，没有上下文
症状很明显：recall 每次都能搜到东西，但内容只有几个关键词拼在一起。
举个例子。搜"网站维护"，返回的是"停服→更新→开服"。谁执行的？哪个节点？中间出了什么问题？全部不知道。
这就是早期我们踩的坑——以为配好了 lancedb 向量库就万事大吉。其实向量层只擅长匹配，不擅长解释。它能找到文件，但文件里写的是什么，它不知道。
解决方法是补上文本层。向量层存"索引"（包含文件路径），文本层存"详情"（时间、人物、问题、解决方案）。
# 向量层
memory_store(
text="网站维护详情见：memory/2026-04-06.md",
scope="global",
category="reference"
)
# 文本层
# memory/2026-04-06.md
# ## 网站维护
# - 时间：10:00-11:00
# - 节点：华东节点
# - 问题：CDN 缓存没刷新
# - 解决：手动清理对应路径
坑二：知识库乱成一锅粥
这个问题出在 Obsidian 那层。
一开始没有权限管理，所有 Agent 都可以往 Obsidian 写。结果就是：文件名乱七八糟（"新建文档123.md"、"ddd.md"），同一个内容被重复记录四五次。
我见过最夸张的是"网站维护流程"这个知识点，在不同 Agent 的记录里出现了六次，每次写的还不完全一样。
后来我们加了规矩：只有 main agent 能直接操作 Obsidian，其他 Agent 先写自己的 memory 文件，main agent 在周会上统一汇总再写入 Obsidian。
目录结构也定死了：
/obsidian-vault/
├── 00-Inbox/ # 临时
├── 10-Daily/ # 每日
├── 20-Projects/ # 项目
├── 30-Knowledge/ # 技术经验、流程规范
└── 40-Meetings/ # 会议纪要
规矩定了之后，重复记录从 35% 降到了 5%。效果明显。
坑三：记忆越多，跑得越慢
这是最容易被忽略的一个。
系统刚搭好的时候，recall 只需要 0.3 秒。随着记忆积累，慢慢变成 1 秒、2 秒、3 秒。一开始我们还以为是模型变慢了，后来才发现是向量库太大了——十万条记录塞进去，搜索性能直接崩了。
还有一个问题：老旧记忆占用空间。比如三个月前的测试服务器配置，还在返回结果里，但早就没用了。
解决方法：加重要性评分 + 定期清理。
# 写入时评分
memory_store(
text="网站维护标准流程",
scope="global",
importance=0.9 # 0-1，越高越重要
)
# 检索时过滤
memory_recall("关键词", min_importance=0.3) # 低于0.3的不要
加了评分机制之后，搜索耗时恢复到 0.3 秒以内。
上下文是怎么被塞进 AI 的？
很多人配了记忆系统，但不知道哪些东西真正进了 AI 的脑子。
每次 AI 回复问题的时候，上下文里包含了这些东西：
System Prompt（角色定义）
AGENTS.md（工作区规范）
memory_recall() 返回的记忆碎片
recall 定位到的文本文件内容
当前对话历史
注意：不是所有记忆都会进去，只有 recall 命中的才会被加载。
如果 recall 返回了一堆无关的记忆，有效信息反而会被稀释。解决方法有几个：精准检索（关键词越具体越好）、设置重要性阈值、控制返回数量。
共享还是私有？写之前先想清楚
scope 这个东西用错的人特别多。
常见错误：把只有自己用得上的东西写到 global，把大家都能用的经验写到自己私有。
一个判断标准：写之前问自己——这个东西别人可能用得上吗？能用就 global，不能就私有。
三个最重要的经验
说起来也简单，就三句话：
第一，先搜后做。 接任务之前先 recall 一遍，能省不少重复劳动。
第二，写之前先查重。 相似度超过 0.85 的就别重复写了，合并或者跳过都行。
第三，别只顾着写，不维护。 记忆系统需要定期清理，不然会越来越臃肿。
技术选型简单说下
为什么用 lancedb 而不是 Pinecone 或者 Chroma？
因为轻量。不用跑独立服务，直接嵌入，混合检索（向量+关键词）支持得也好。Pinecone 要收费而且得联网，Chroma 性能一般。对于我们这种规模，lancedb 完全够用。
记忆系统这个东西，核心没有多复杂：向量层做索引，文本层做详情，Obsidian 做沉淀。难的是坚持用、定期维护、出了问题及时修。
每个规则的背后，都是踩过一个坑之后才总结出来的。
本文是《三层记忆系统实战：让 AI 代理真正记住你》的进阶篇
欢迎关注「心痛的小鱼」
