Dream 的真实机制
核对空闲门控、DreamLock、后台整理和记忆写回的实际边界
本页解决的问题
先给结论「Dream 的真实机制」要解决的关键问题是什么？
核对空闲门控、DreamLock、后台整理和记忆写回的实际边界
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
读懂 Dream 从触发到重建索引的完整链路，能解释 DreamGate、幂等要求、锁竞争和写入失败回滚各自解决什么问题。
一次 Dream 的状态机
下图是教学化图示。节点名称来自源码，布局与文字说明经过课程化整理。
1. 配置门
MemoryDreamConfig.enabled 默认为 true。子 Agent 会话直接跳过 Dream。
2. 时间门
min_hours 默认为 4。锁文件 mtime 记录上次成功 consolidation 的时间。
3. 会话门
min_sessions 默认为 3。统计上次 consolidation 后修改的 session Markdown，并排除当前会话。
DreamLock 是最佳努力协调
.dream-lock 保存 PID，并用 mtime 兼作上次成功时间。活进程持有且未过期时返回 Ok(None)。死进程或超时锁可被回收。
源码注释明确说明它并非严格互斥。写后复读能降低竞争概率，仍可能有两个进程都认为自己获胜，所以 Dream 必须容忍重复 consolidation。
成功边界决定清理边界
- 模型返回空、NO_REPLY 或无 Markdown 标题时，不写入也不删 session。
- 写 MEMORY.md 失败时调用 rollback(prior) 恢复旧锁状态。
- 写入成功后才清理已读取的 session；5 分钟内仍活跃的文件会跳过。
- 搜索索引只移除实际删掉的路径，再为新 MEMORY.md 重建索引与 embedding。
pub fn check_dream_gates(
config: &MemoryDreamConfig,
lock: &DreamLock,
sessions_dir: &Path,
current_session_sid8: Option<&str>,
) -> DreamGate {
if !config.enabled { return DreamGate::Disabled; }
// Time gate, then session gate
...
DreamGate::Open { sessions }
}快照说明：代码保留真实函数签名与返回类型，中间实现以省略号压缩。页面中的状态机 SVG 属于教学化表达，不对应仓库生成的架构图。
课堂练习：定位失败后的系统状态
情境：Dream 已完成模型调用，但写入 MEMORY.md 失败。请回答：锁文件应恢复到什么状态？哪些 session 文件可以删除？索引需要更新吗？再从 execute_dream 的分支给出依据。
「一次 Dream 的状态机」为什么能找到相关内容
「读懂 Dream 从触发到重建索引的完整链路，能解释 DreamGate 、幂等要求、锁竞争和写入失败回滚各自解决什么问题」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。
相似度不是答案，召回之后还要核对
在「MemoryDreamConfig.enabled 默认为 true。子 Agent 会话直接跳过 Dream」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。
- 模型返回空、NO_REPLY 或无 Markdown 标题时，不写入也不删 session
- 写 MEMORY.md 失败时调用 rollback(prior) 恢复旧锁状态
- 写入成功后才清理已读取的 session；5 分钟内仍活跃的文件会跳过
先区分找得到和找得准
把「情境：Dream 已完成模型调用，但写入 MEMORY.md 失败。请回答：锁文件应恢复到什么状态？哪些 session 文件可以删除？索引需要更新吗？再从 execute_dream 的分支给出依据」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。
从「一次 Dream 的状态机」走到「1. 配置门」
「一次 Dream 的状态机」先把问题落在「下图是教学化图示。节点名称来自源码，布局与文字说明经过课程化整理」上；到了「1. 配置门」，讨论继续推进到「MemoryDreamConfig.enabled 默认为 true。子 Agent 会话直接跳过 Dream」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。
- 「一次 Dream 的状态机」：下图是教学化图示。节点名称来自源码，布局与文字说明经过课程化整理
- 「1. 配置门」：MemoryDreamConfig.enabled 默认为 true。子 Agent 会话直接跳过 Dream
- 「最后的要点」：搜索索引只移除实际删掉的路径，再为新 MEMORY.md 重建索引与 embedding
最后的「最后的要点」把讨论落到「搜索索引只移除实际删掉的路径，再为新 MEMORY.md 重建索引与 embedding」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。