上一篇聊完"Agent记忆插件怎么选"，后台好几个朋友问同一个问题：

"道理我都懂了，可到底怎么配？"

说实话，我配的时候踩的坑，比选的时候多得多。

今天就干一件事：把 OpenClaw v2026.8.2 记忆插件的全套配置和踩坑经验，一次性交给你。照着抄，少走两周弯路。

一、先看整体：六个模块，一条"记忆流水线"

别看插件多，其实各干各的活，串起来就是一条线。

一句话总结：core 负责存，active 负责找，wiki 负责编，search 管搜索，workshop 和 self-improving 管"越用越聪明"。

数据怎么流动？一句话：

对话 → active-memory 预召回 → 主 Agent 应答、存记忆 → 每天定时 Dreaming 整理 → memory-wiki 编译成知识库 → 下次对话再召回。

这条线跑起来，Agent 才算真正"长了记性"。

二、memory-core 怎么配：盯住三处

memory-core 是内置的，不用装。但别用默认值，下面三处一定要改。

1. Dreaming：什么时候整理记忆

三个关键点：

• Frequency 是 cron 表达式（分 时 日 月 周），每天 1-2 次足够，设太频繁只费资源；
• Dreaming 默认开启，但开启≠在跑——它不读聊天记录，只整理 memory/*.md 里的碎片（见坑1）。
• dreaming.phases.deep字段，用来提升 MEMORY.md 记忆质量，不设置即采用默认值，建议初期采用默认值，待写入MEMORY.md 的记忆数量增加，再提高质量。

2. active-memory：让它主动"找你"

这是配置项最多、也最容易"配了个寂寞"的插件——它决定你的 Agent 是"被动查记忆"还是"主动想起来"。

每个参数怎么配：

两个最容易错的：

• 其一，toolsAllow要跟着记忆插件换。用 memory-core 写 ["memory_search","memory_get"]；如果是 memory-lancedb 要改成 ["memory_recall"]——不匹配时 active-memory 不报错，只是静默不干活。

• 其二，enabled有两层，缺一不可。插件层 enabled: true 和外层 enabled: true 都要开。

配置生效不用重启 Gateway，改完重启会话即可。

用 /active-memory status 查开关、/verbose on 看召回摘要、日志里搜 status=timeout——三个工具随时自查。

3. memory.search：搜索的"发动机"

不配它，记忆搜索就只是"关键词匹配"。

配置步骤三步走：

1. 看状态：跑一句 openclaw memory status --deep，看到“向量搜索就绪”就对了；
2. 做实测：存“报表”，再搜“周报”——能搜出来才算真的好；
3. 别乱换：模型/服务商一旦定下，尽量别频繁换。

三、3个必避的坑

坑1：Dreaming 开了 ≠ 会记，它可能一直在"空转"

我碰到的情况：

配置全对、日志也有"promotion complete"，但2周后 MEMORY.md 一条没涨，Agent 还是"失忆"。

为什么：

Dreaming 只读 memory/*.md 里的短期碎片，不读聊天记录——Agent 不主动存，它永远"没米下锅"。

社区很多人开了 Dreaming 以为万事大吉，结果几周后发现一条记忆都没沉淀。

怎么查：

# 手动跑一次，看有没有产出openclaw dream run --force# 看 DREAMS.md 有没有新条目

怎么防：

1. 在每个 Agent 的 AGENTS.md 里写死"记忆约束"：

需要保存：稳定事实、业务规则、用户明确偏好、重要结论不要保存：闲聊、临时对话、中间思考过程

坑2：active-memory 是"性能刺客"，三处最易翻车

我碰到的情况：

晚高峰云端 embedding 延迟从 0.2 秒飙到 125 秒，召回整段失败。

社区有人开着 active-memory 就觉得系统变卡，社区普遍做法是关掉，只靠手动 memory_search。

为什么：

active-memory 要调子代理+向量搜索，链路长。三个最容易"不报错但静默失效"的坑位：

1. agents 列表写错 → 只有写的 Agent 有召回（比如写 ["main"]，其他 几 个全部沉默）
2. toolsAllow 不匹配 → 子代理没工具，静默跳过（memory-core 要用 ["memory_search","memory_get"]，写错就废）
3. timeoutMs 设太大 → 用户干等；设太小 → 召回还没回来就被砍了

怎么查：

# 看 active-memory 状态/active-memory status# 看日志里是 ok 还是 timeout/verbose on# 打开详细日志，看召回摘要

怎么防：

• queryMode 用 recent（看近期几轮，别用 full全量又慢又费）
• timeoutMs 保持默认 15000（超时就放弃召回，别让主回复等它）
• toolsAllow 必须跟记忆插件匹配（memory-core → ["memory_search","memory_get"]）
• agents 填所有要启用召回的 Agent ID，漏一个少一个
• 上线后用日志确认 status 是 ok 不是 timeout
• 晚高峰（20:00-22:00）测一次延迟，白天通过≠晚上可用

Tips: 如果开了 active-memory 觉得明显变卡，可以先关掉（/active-memory off），退回到手动 memory_search，不影响核心记忆功能。

坑3：你以为在用语义搜索，其实一直是关键词

我碰到的情况：

"报表"搜不到"周报"，但配置里明明写了 embedding 模型。

为什么：

provider 没配对时不报错，悄悄退回关键词匹配。

这个坑在社区是 Top-6 高频问题，官方 troubleshooting 专门写了："Only keyword matches? embedding provider may not be configured"。

更隐蔽的三连坑：

1. chat 能用的 key ≠ embedding 能用（套餐权益不含，比如火山 Agent Plan 的端点调 embedding 会报 429）
2. 多模态向量模型≠纯文本可用（火山的 Doubao-embedding-vision 支持图片 + 文本，但配在 memory.search 里完全不生效——直到换阿里百炼的纯文本向量模型才正常。OpenClaw 的 embedding 适配器对多模态模型的请求格式有兼容性问题）

怎么查：

# 第一步：用 curl 裸测 embedding 端点# 确认三件事：模型已开通？维度对吗？批量上限多少？# 第二步：配置后跑这个命令openclaw memory status --deep# 看到”向量搜索就绪”才对了，如果显示 keyword-only 就是没配上# 第三步：语义实测# 存”报表”，再搜”周报”——能搜出来才算真的好

怎么防：

1. 先 curl 裸测 /embeddings 端点，别等 OpenClaw 跑失败再查
2. 配置后跑 openclaw memory status --deep 探测向量就绪
3. 做一次语义实测：存"报表"、搜"周报"，能召回才算真配好

Tips：status 绿了不算，"报表"能搜到"周报"才算。

写在最后

这套配置的心法，一句话：OpenClaw 的记忆组件出错不吭声，只静默降级——所以每一步都要"配置 → 验证 → 实测"。

三句口诀：

1. 配置看闭环——Dreaming 跑了不算，MEMORY.md 涨了才算
2. 召回看工具——active-memory 开了不算，日志 status=ok 才算
3. 搜索看实测——status 绿了不算，"报表"能搜到"周报"才算

记忆系统配得好不好，不看你存了多少，看你有没有把"自动"两个字真正跑起来。

下一篇聊“从 lancedb 切到 memory-core 的完整迁移实录”——我花了 3 天踩完 9 个坑，从换插件、建索引、写代理到 Dreaming 阈值，一整条链路的真实经历。

关注「红尘炼AI」，我们下篇见。