Clawdbot 的记忆系统：为什么说“文件即记忆”（以及它怎么检索）
Clawdbot 的记忆系统：为什么说“文件即记忆”（以及它怎么检索）
适用范围
你想把 Clawdbot 当作“长期在线的个人助理”，很快就会遇到两个现实问题：
- 聊天上下文会变长，模型有窗口上限
- 你需要它“记住”决策、偏好、项目状态，但又不想把记忆交给云端黑盒
Clawdbot 的做法是：把记忆当作你工作区里的普通文件，并为它建立一个本地索引。
先区分两个概念：Context vs Memory
Context（一次请求的上下文）
上下文是模型本次请求“能看到的一切”，例如：系统提示词、对话历史、工具结果、附件等。
它的特点是：临时、有限、昂贵（上下文越大成本越高）。
Memory（落盘的长期记忆）
记忆是落在磁盘上的内容，例如：
MEMORY.md（长期沉淀）memory/*.md（日常增量记录）- 会话转录（sessions transcript，按配置决定是否纳入索引）
它的特点是：持久、可增长、可检索。
“文件即记忆”的好处
从工程角度，这个设计非常朴素，但带来三点收益：
- 可审计：你能直接打开文件看它记了什么
- 可版本化：你可以用 git 管理（至少管理关键规则与结论）
- 可控：不依赖外部向量数据库；索引是派生物，坏了可重建
检索是怎么做的（实现视角）
在当前实现里，索引使用 SQLite；向量检索可选用 sqlite-vec 扩展；关键词检索用 FTS5。
一个更贴近现实的简化流程是：
- 扫描 workspace 中的记忆源文件（Markdown、可选 sessions）
- 将内容切块（chunk）
- 计算 embedding（可走 OpenAI/Gemini/本地 embedding）
- 写入 SQLite（chunks / embedding_cache / 可选 chunks_fts / chunks_vec）
- 查询时并行做：
- 向量相似（语义）
- BM25（关键词） 然后按权重合并结果
默认索引路径（可配置）：
~/.clawdbot/memory/{agentId}.sqlite
（对应配置项：agents.defaults.memorySearch.store.path）
多 agent 时的隔离
多 agent 场景下，一般推荐做到“配置、workspace、索引”三者都隔离：
- 每个 agent 对应自己的 workspace（源文件）
- 每个 agent 对应自己的 SQLite 索引（派生数据）
这样能避免“个人助理”与“工作助理”互相污染上下文与记忆。
你应该怎么用（可操作建议）
1) 把规则写进可持久化文件
如果你希望它长期一致地工作，建议把这些内容写进 workspace 的引导文件：
- 你是谁、偏好是什么（少而准）
- 你希望它遵守的边界（例如哪些命令必须询问）
- 你希望它定期检查什么（heartbeat/cron 的任务清单）
2) 把“结论”写进 MEMORY.md，把“过程”写进 daily notes
一个简单的经验：
memory/YYYY-MM-DD.md更像当天流水MEMORY.md更像可复用的结论与长期约束
3) 索引坏了别慌：它是派生物
只要源文件还在，索引通常可以重建。真正要备份的是：
~/.clawdbot/（配置与凭证）~/clawd/（workspace）
参考与延伸
- 相关实现：
src/memory/manager.ts、src/memory/memory-schema.ts（Clawdbot 源码） - （待补）Clawd 风格工作区与记忆文件：
/en/docs/start/clawd/
素材来源：docs_doc/_docs/docs/clawdbot/2015780646770323543.md