Agent 管理的记忆:文件是真相源,索引只是加速器
一、默认三层文件
| 文件 | 角色 | 是否常驻上下文 |
|---|---|---|
MEMORY.md | 长期记忆:用户稳定偏好、背景、长期目标、重要决策、持续生效的规则、Agent 吸取的教训 | 是,所以必须短而精炼 |
memory/YYYY-MM-DD.md | 情景记忆:每日工作日志与经历 | 否,靠 memory_search 按需召回 |
DREAMS.md | 巩固过程的审查面:后台反思、候选记忆、巩固结果 | 否,供人检查「Agent 为什么决定记住这件事」 |
MEMORY.md 在形态上类似 Letta 的 Memory Block,但载体就是普通 Markdown。
由此形成一条流水线:每日详细经历 → 定期提炼 → 长期稳定摘要。
二、索引与召回
memory-core把 Markdown 切 chunk,索引进每个 Agent 独立的 SQLite。- 混合信号:FTS5/BM25(名字、ID、错误信息等精确文本)+ embedding(语义)+ 文件名/路径;另有可选时间衰减(旧日记降权)与可选 MMR(避免召回重复内容)。
- 对外只有两个基础工具:
memory_search(找相关记忆)、memory_get(读具体文件或行)。
三、可迁移的判断
- 索引不是真相源。 索引删了 Markdown 还在,可以重建 —— 所以索引层的选型、损坏、迁移都不构成数据风险。
- 常驻上下文的必须是提炼后的长期摘要,原始经历留在按需召回的层里。
- 自动巩固要有可审查的面。 让 Agent 自主决定「记住什么」时,把候选与理由写出来给人看,是可控性的前提。
来源:OpenClaw 官方文档 Memory overview / Memory search(docs.openclaw.ai)。
相关
- 短期记忆与长期记忆的边界
- 知识库先编译再查而不是查询时拼原文
- 真源要按维度显式指定
- 观测平台不能当运行状态真相源