拆解 OpenClaw Dreaming 的分层记忆流水线，看 Agent 如何把会话沉淀为可检索长期上下文。
导语
一个能长期工作的 Agent，麻烦点不在“把对话存下来”。因为聊天记录本身太粗糙：里面有临时指令、工具失败、过程性解释、重复确认，也有少量会在未来反复有用的偏好、事实和工程判断。把这些内容原封不动塞进长期记忆，只会让上下文越来越脏。
OpenClaw Dreaming 机制处理的是一类问题：怎样让一次次对话先变成可追溯素材，再经过候选筛选、稳定归纳和索引构建，最后成为未来任务可以调用的长期上下文。
这套机制更像一条后台运行的记忆生产线。前台会话负责完成当前任务和保留原始事实；后台 Dreaming 再把这些事实加工成不同稳定程度的记忆，并通过 SQLite、全文索引和 memory_search 接回未来对话。
记忆不是一个文件：从日志、候选到索引的三层边界
OpenClaw 的记忆系统最容易被误解为“一个 Markdown 长期笔记”。实际情况更接近一套分层存储：原始会话、加工过程、长期正文、检索索引分别承担不同职责。
| 层级 |
典型位置 |
保存内容 |
核心职责 |
人工介入建议 |
| 原始输入层 |
tech/sessions/*.jsonl |
用户消息、助手回复、工具事件、运行时元信息 |
留住当时发生了什么 |
不建议编辑，适合作为源日志 |
| 素材缓冲层 |
memory/.dreams/session-corpus/YYYY-MM-DD.txt |
从 session 中抽取出的可读片段 |
给 Dreaming 提供当天素材 |
不建议编辑，适合排查抽取问题 |
| 运行审计层 |
memory/.dreams/events.jsonl |
召回事件、阶段完成事件、写入路径 |
解释某次 Dreaming 是否运行、如何运行 |
只读排查 |
| 状态信号层 |
daily-ingestion.json、session-ingestion.json、short-term-recall.json、phase-signals.json |
游标、hash、召回次数、阶段命中 |
支持增量处理、去重和候选晋升判断 |
不建议手改 |
| 长期正文层 |
memory/YYYY-MM-DD.md、DREAMS.md |
Light Sleep、REM Sleep、反思摘要和稳定上下文 |
供人和 Agent 阅读、审计、复用 |
可谨慎编辑，保留结构标记 |
| 检索索引层 |
~/.openclaw/memory/tech.sqlite |
files、chunks、chunks_fts、embedding_cache |
支撑关键词检索、语义检索和增量索引 |
不应作为最终事实源 |
| 调用接口层 |
memory_search、memory_get |
查询和回读能力 |
让未来任务召回相关长期上下文 |
不涉及编辑 |
可以把这套结构拆成三条边界：
| 边界 |
关键判断 |
tech/sessions/*.jsonl 记录事实，但不判断长期价值 |
它回答“当时发生过什么”，不回答“什么值得以后记住”。 |
.dreams/* 记录生产过程，但不是最终知识库 |
它回答“为什么这条内容被召回或处理”，不适合直接当长期事实。 |
memory/*.md 是可审计正文，tech.sqlite 是派生索引 |
排查时可以先从索引定位，再回到 Markdown 原文看上下文。 |
记忆不会从当前对话直接跳到长期事实。它先经过素材化、候选化、稳定化，再进入可检索的长期上下文。
Session Ingestion：先保留原始上下文，再做延迟判断
每次用户发起请求时，系统首先要解决的是当前任务，而不是立刻“学习”。因此用户消息、助手回复、工具调用和运行元信息会先落到 session JSONL。这个阶段只保证一件事：原始上下文没有丢。
后续 Dreaming 会从这些持续追加的 session 文件里做增量抽取。session-ingestion.json 记录每个 session 文件的处理进度，例如文件大小、修改时间、内容 hash、行数以及最后处理到的内容行。这样后台任务不需要每次全量扫描，也能避免重复抽取同一段会话。
素材进入 session-corpus 后，会变成更适合阅读和回溯的行级文本：
[tech/sessions/...jsonl#L10] Assistant: 我先核对源码里的 dreaming / REM / DEEP 文件和规则，再把确认后的结论补进文档。
这一行看似普通，实际保留了三个关键信息：
| 字段 |
示例 |
作用 |
| 来源文件 |
tech/sessions/...jsonl |
能定位到哪个 Agent 会话产生了素材 |
| 行号锚点 |
#L10 |
支持回到原始日志查看上下文 |
| 角色与内容 |
Assistant: ...、User: ... |
给后续候选判断提供语义输入 |
这一步的设计取舍很清楚：先完整留痕，再延迟判断。对话里的很多内容只对当前任务有用，过早写入长期记忆会制造噪声；但完全不留痕，又会丢掉后续可能需要归纳的证据。
Light 与 REM：用稳定性区分候选记忆和长期判断
memory/YYYY-MM-DD.md 是 Dreaming 输出最直观的位置。它不是单纯按时间堆内容，而是在文件内部用阶段标记区分不同稳定程度的信息。
| 区块 |
典型标记 |
内容形态 |
语义定位 |
使用方式 |
| Light Sleep |
<!-- openclaw:dreaming:light:start --> 到 light:end |
Candidate、confidence、evidence、recalls、status |
候选记忆，表示“可能有用，但还要观察” |
适合近期续接、路径线索、任务偏好补全 |
| REM Sleep |
<!-- openclaw:dreaming:rem:start --> 到 rem:end |
Reflections、Possible Lasting Truths |
更稳定的长期归纳 |
更适合影响后续回答、工具选择和写作规范 |
| 会话补充 |
普通 Markdown 小节 |
文档链接、用户偏好、任务结果、实现锚点 |
人工或系统补写的稳定上下文 |
适合明确记录可复用事实 |
Light 和 REM 的差别不在格式，而在可信度和使用方式。
| 对比维度 |
Light Sleep |
REM Sleep |
| 目标 |
捕捉近期可能有价值的线索 |
提炼可长期复用的事实、偏好、模式和约束 |
| 粒度 |
较细，常带路径、原话、任务片段和证据位置 |
较粗，通常压缩成稳定判断 |
| 可信度表达 |
常见 confidence、status=staged、recalls |
通常来自多次 evidence 或更高置信归纳 |
| 行为影响 |
应谨慎使用，主要补全上下文 |
更容易影响后续回答和任务判断 |
| 典型用途 |
近期任务续接、排查线索保留 |
用户偏好、长期规则、重复问题模式 |
实际阅读日期记忆时，比较稳的顺序是：先看 REM 得到稳定判断，再回到 Light 看证据和来源。这样可以避免把候选层的低置信线索误当成长期事实。
Recall State 与 Phase Signal：候选为什么会被晋升
如果只有 Light 和 REM 两个正文区块，系统仍然难以回答一个调试问题：为什么这条内容会被保留，为什么它会从候选晋升为稳定记忆？
OpenClaw 用两类状态文件补齐这条证据链。
| 文件 |
处理对象 |
常见字段 |
粒度 |
解决的问题 |
daily-ingestion.json |
memory/YYYY-MM-DD.md 等日期记忆文件 |
mtimeMs、size、path |
文件级 |
判断每日记忆文件是否变化 |
session-ingestion.json |
tech/sessions/*.jsonl |
mtimeMs、size、contentHash、lineCount、lastContentLine |
文件级 + 行级 + hash |
支持持续追加日志的增量抽取 |
short-term-recall.json |
被检索命中的记忆片段 |
recallCount、recallDays、queryHashes、conceptTags |
片段级 |
判断哪些片段近期经常被搜索到 |
phase-signals.json |
Light / REM 阶段出现的 memory key |
lightHits、remHits、更新时间 |
阶段信号级 |
判断候选是否具备晋升趋势 |
short-term-recall.json 关注的是“它是不是经常被查到”；phase-signals.json 关注的是“它是不是反复被 Dreaming 认为重要”。两者结合，候选晋升才更有解释力。
事件日志则提供运行过程的时间线。典型事件会像这样出现：
{"type":"memory.recall.recorded","query":"dreaming_sessions:2026-05-09","resultCount":105}
{"type":"memory.dream.completed","phase":"light","inlinePath":".../memory/2026-05-10.md"}
{"type":"memory.dream.completed","phase":"rem","inlinePath":".../memory/2026-05-10.md"}
这些事件不适合直接用来回答用户问题，但很适合排查：某个日期有没有被 Dreaming 处理，处理到了 Light 还是 REM，召回结果数量是否异常，最终写入了哪个文件。
DREAMS.md 与 tech.sqlite：一个讲述变化，一个服务检索
长期记忆里还有两个容易混淆的对象：DREAMS.md 和 tech.sqlite。
DREAMS.md 更像系统近期状态的叙事层。它会用更自然的方式记录反复出现的主题、工作流变化、阻塞点和观察结论。它有助于理解“最近系统在关注什么”，但不一定适合作为严格事实源。
tech.sqlite 则完全是另一类东西。它是从 Markdown 记忆派生出来的检索加速层，服务 memory_search，不应该替代 Markdown 原文做人工审计。
| 对象 |
更像什么 |
主要读者 |
稳定性 |
适合用途 |
DREAMS.md |
叙事型反思日志 |
人类和 Agent |
偏解释性 |
理解近期主题、工作流变化、未解决问题 |
memory/YYYY-MM-DD.md |
结构化长期记忆正文 |
Agent、检索系统、人类 |
更适合长期复用 |
作为长期记忆主路径和可追溯证据 |
tech.sqlite |
派生索引 |
memory_search、索引器 |
依赖 Markdown 同步 |
快速定位相关片段 |
tech.sqlite 的表结构大致承担这些职责：
| 表 |
作用 |
与文件系统的关系 |
meta |
保存索引版本、配置等元信息 |
帮助判断索引结构和运行参数 |
files |
记录被索引文件的路径、hash、mtime、size |
判断哪些 Markdown 文件需要同步 |
chunks |
保存按行切分后的记忆片段、文本和 embedding 信息 |
把长 Markdown 拆成可检索单元 |
chunks_fts |
FTS5 全文索引 |
支持关键词、路径、中文片段等全文检索 |
embedding_cache |
缓存 embedding 结果 |
避免同一文本重复生成 embedding |
这条链路解释了一个关键原则：检索结果只是入口，Markdown 原文才是审计依据。排查记忆内容时，应先用索引找到路径和行号，再回到 memory/*.md 看完整上下文。
一次真实查询如何穿过记忆系统
当用户提出一个与历史任务、偏好或技术结论有关的问题时，OpenClaw 并不是只依赖当前上下文。它会在当前任务和历史记忆之间建立一条回路。
| 步骤 |
参与文件或接口 |
发生的事情 |
输出 |
| 理解当前问题 |
当前用户消息、会话上下文 |
判断问题是否需要历史偏好、任务结果或技术结论 |
明确检索意图 |
| 召回历史 |
memory_search、tech.sqlite |
从已索引记忆中找相关片段 |
获得候选历史上下文 |
| 回读证据 |
memory_get、memory/*.md |
按路径和行号读取原始 Markdown |
避免只凭索引摘要判断 |
| 查证过程 |
.dreams/*.json/jsonl、phase-signals.json |
读取事件、游标、阶段信号 |
判断某条记忆来源是否可靠 |
| 组织回答 |
DREAMS.md、session-corpus、日期记忆 |
区分叙事层、素材层、候选层、稳定层 |
形成可读解释 |
| 写回结果 |
文档、Markdown 或新的 session |
输出本次结论 |
成为未来 Dreaming 的潜在素材 |
Dreaming 的后台属性也体现在这里：当前对话产生素材，后台筛选素材，长期记忆被索引，未来对话再把它召回。系统不追求记住一切，它反复压缩真正有复用价值的上下文。
为什么不能退回单文件记忆
把所有长期信息放进一个 memory.md 文件，看起来简单，实际会很快暴露工程问题。
| 工程问题 |
单文件记忆的风险 |
分层机制的处理方式 |
| 原始会话太噪 |
问候、失败重试、过程说明混进长期事实 |
session-corpus 先作为素材层，等待筛选 |
| 候选事实不稳定 |
未验证事实直接污染长期记忆 |
Light Sleep 用 confidence、evidence、status 暂存 |
| 长期偏好需要压缩 |
历史上下文越积越长，检索结果越来越散 |
REM Sleep 将重复模式压缩为稳定判断 |
| 检索需要速度 |
每次查询都扫描全量 Markdown，成本高且不稳定 |
SQLite chunk + FTS + embedding 提供快速检索 |
| 调试需要证据链 |
不知道某条记忆从哪里来、为什么出现 |
events、ingestion、recall、phase signals 保留过程证据 |
| 多阶段处理需要去重 |
每次运行都可能重复写入同一素材 |
ingestion 游标和 recall key 支持增量处理与去重 |
分层不是为了把系统做复杂，而是为了让不同稳定程度的信息拥有不同出口。越靠近原始会话，越强调完整和可追溯；越靠近 REM 和索引，越强调稳定、压缩和复用。
排查 Dreaming：先看结果，再追过程，最后查索引
分析 Dreaming 输出时，不建议一上来就打开 SQLite，也不建议直接修改 .dreams 里的状态文件。更稳的路径是按“结果、过程、索引”逐层排查。
| 顺序 |
文件 |
先看它的原因 |
重点关注 |
| 1 |
memory/YYYY-MM-DD.md |
先确认最终有没有沉淀 |
Light / REM 是否存在，内容是否符合预期 |
| 2 |
memory/.dreams/events.jsonl |
确认 Dreaming 是否完成、完成哪个阶段 |
memory.dream.completed、phase、inlinePath |
| 3 |
memory/.dreams/session-corpus/YYYY-MM-DD.txt |
查看当天原始会话素材是否被抽取 |
是否有目标会话、来源行号是否正确 |
| 4 |
short-term-recall.json |
判断哪些片段近期被频繁召回 |
recallCount、recallDays、conceptTags |
| 5 |
phase-signals.json |
判断哪些片段被 Light / REM 反复命中 |
lightHits、remHits |
| 6 |
daily-ingestion.json、session-ingestion.json |
排查为什么没有新增素材或重复处理 |
lineCount、contentHash、mtimeMs |
| 7 |
tech.sqlite |
最后确认索引是否同步 |
files、chunks、chunks_fts |
这条路径能减少误判：先确认“最终有没有写入”，再确认“过程有没有运行”，最后确认“索引有没有跟上”。
几个容易踩错的理解
| 常见理解 |
更准确的说法 |
为什么重要 |
| Dreaming 就是把聊天记录写进 memory |
它会先抽取素材，再通过候选、召回和阶段信号筛选 |
避免把所有临时对话都当成长期事实 |
.dreams 目录就是长期记忆 |
.dreams 更偏中间状态和运行审计，长期记忆主要看 memory/*.md |
避免把状态文件误当正文知识库 |
tech.sqlite 是最终事实源 |
它是派生索引，Markdown 原文才更适合人工审计 |
排查时应回到 path 和 line 的原文 |
| Light Sleep 已经是稳定事实 |
Light 只是候选，常带 status=staged 和较低置信度 |
后续回答不应过度依赖候选层 |
| REM Sleep 一定完全正确 |
REM 更稳定，但仍应看 evidence 和上下文 |
长期记忆仍可能过期或受历史上下文影响 |
| 文件存在就一定能被搜到 |
需要被索引器同步进 tech.sqlite 才能被快速检索 |
能解释 memory 文件和 search 结果不一致的问题 |
用五个子系统重新理解 Dreaming
从工程架构看，Dreaming 可以拆成五个子系统，而不是一堆零散文件：
| 子系统 |
输入 |
输出 |
关键文件 |
| 输入记录 |
当前对话、工具事件、运行元信息 |
原始 session 日志 |
tech/sessions/*.jsonl |
| 素材抽取 |
新增 session 行 |
按日期聚合的可读素材 |
session-corpus/YYYY-MM-DD.txt、session-ingestion.json |
| 候选判断 |
素材、历史召回、阶段信号 |
Light Candidate |
short-term-recall.json、phase-signals.json |
| 长期沉淀 |
多次命中或高价值候选 |
REM Reflection、日期记忆 |
memory/YYYY-MM-DD.md、DREAMS.md |
| 检索回流 |
Markdown 记忆正文 |
chunk、FTS、embedding、未来召回 |
tech.sqlite、memory_search、memory_get |
这个拆法对排查很有帮助：素材缺失就看输入记录和抽取；候选不合理就看召回和阶段信号；回答没有复用历史记忆，就看索引回流和 memory_search。
结语
OpenClaw Dreaming 的价值，不在于让 Agent 机械地记住更多内容。它给长期记忆补上了一套生产过程。
原始会话先被保留下来，随后进入素材层；素材被召回、聚合、打分，形成 Light 候选；重复出现或价值明确的内容被压缩成 REM 判断；最终 Markdown 正文进入 SQLite 索引，再通过 memory_search 和 memory_get 回到未来任务。
这样形成的长期记忆不是黑盒摘要，也不是无限膨胀的聊天记录。它有来源、有阶段、有证据、有索引，排查时还能回到原文验证。对一个需要长期协作的 Agent 来说，盲目记住所有事情没有意义；能把可复用的上下文沉淀下来，并在下一次任务里解释清楚为什么召回它，才更有用。
更多 AI 工程实践与记忆系统设计讨论，欢迎移步 云栈社区 交流。
发表于 2 小时前
|
查看: 3|
回复: 0
