文件层：记忆的第一现场

OpenClaw 的记忆本体就是一堆 Markdown，按热度分层：

workspace/
├── MEMORY.md            # 长期精炼记忆（画像/项目/待办/钦定规则）——主会话每次注入
└── memory/
    ├── daily/           # 每日原始日志 YYYY-MM-DD.md——当天事实随手写
    ├── projects/        # 专项档案（某条业务线的完整历史）
    ├── profiles/ contacts/ schedules/ context/   # 人物/日程/上下文档案
    └── ── 结构化知识 → ~/.openclaw/wiki/main/（entities/concepts/syntheses/sources）

运转节奏：当天事写 daily，定期（我放在每天 23:56 的 cron 维护班）把 daily 提炼进 MEMORY.md，过时内容清理或迁 projects 档案。主人说"记住这个"，必须立刻落文件——没有"心里记一下"这回事，因为每次会话都是全新醒来。关联信息用 [[双向链接]]，这玩法直接抄 Obsidian。

这条路上我交过的学费是体积：这些文件每次会话都注入，就是持续的 token 成本。9/25 大瘦身，TOOLS.md 12.6KB→3.7KB、开机注入总量 42KB→20KB，手法就一招——细节全部下沉到 projects 档案，常驻只留指针。

索引层：坏过三次的位置

文件多了要找回来，靠内置 memory_search（向量语义+关键词两路并行，和我做 RAG 项目的混合检索同一个架构）。它的三次事故：

事故一（6/19）：一个反斜杠消失在搜索里。 现象：前一天的发布记录搜不到。根因：openclaw.json 里 memorySearch.extraPaths 写了单反斜杠路径，JSON 未转义，自定义目录（profiles/projects 等）全部加载失败。修复：改双反斜杠 \\，重启网关。附带发现：session-memory hook 也没把旧会话落盘——从此我定了规矩：重要对话手动写 daily，不赌自动 hook。

事故二（9/3 起，瘫了近 50 天）：语义那条腿断了。 现象：memory_search 持续不可用。当时定位到"openai provider 无 API key"，先拿 qmd CLI 和直接读文件兜底，业务照常跑——检索坏了不等于记忆丢了，文件才是事实源，这是这个架构最让我安心的一点。

事故三（10/21 根治）：根因查实。 配置里只有 extraPaths 没写 embedding provider → 系统默认走 OpenAI 的 embeddings 接口要 OPENAI_API_KEY → 本机没这个 key → 语义检索废了，qmd 也是同一个死因。当天修复：

// agents.defaults.memorySearch
"provider": "openai-compatible",
"model": "BAAI/bge-m3",
"remote": { "baseUrl": "https://api.siliconflow.cn/v1", "apiKey": "<复用我 .env 里的 SILICONFLOW key>" }

然后 openclaw memory index --force 全量重建索引，config validate 通过，实测查询返回正常（vectorScore 有值了）。选 bge-m3 是因为它本来就是我 RAG 学习项目的同款，硅基流动免费档够用，同路还有 bge-reranker-v2-m3 以后精排可以直接复用。成本：零（key 现成，模型白嫖）。

验收记忆是否真的在

openclaw memory status      # 索引状态
openclaw memory index --force  # 重建
qmd update && qmd embed --no-gpu  # 备用 CLI 索引

再加一条行为层的验收：隔几天新开一个会话，问它"我 9 月干过什么"——能从 daily 和 MEMORY.md 里答对，这套记忆才算活着。

「OpenClaw 实战」系列（随我用随更）：① Windows 安装上线篇 · ② 架构扫盲 · ③ 控制台与日常使用 · ④ 模型接入 · ⑤ 记忆系统 · ⑥ 定时任务与降本 · ⑦ 增加依赖