Repository navigation
[Discussion] Does a memory system need dreaming? Where should we draw the line between reasoning and summarization? #1700
Description
Dream CE explores whether an AI memory system should do more than store, retrieve, and summarize past interactions.
A key question is: does a memory system need a “dreaming” process at all?
By “dreaming”, we do not mean mystical generation or uncontrolled speculation. We mean an offline memory consolidation process that may detect unresolved patterns, conflicts, repeated user needs, and higher-level insights from past memories.
However, this introduces an important boundary problem:
- If Dream only summarizes memories, it may not add much beyond existing summarization.
- If Dream reasons too aggressively, it may hallucinate, over-interpret user intent, or create false memories.
- If Dream never reasons, it cannot discover cross-session patterns or produce useful long-term insights.
We would like to discuss where this boundary should be.
Questions
- Should an AI memory system have a Dream-like consolidation layer?
- What kinds of reasoning should be allowed over memory?
- What should Dream never infer?
- How do we prevent over-interpretation or false memory creation?
- What is the difference between:
- summarization,
- reflection,
- abstraction,
- inference,
- hallucination?
- Should Dream output only “safe” factual memory, or can it output hypotheses with confidence and rationale?
- How much reasoning would you want your own memory system or agent to perform?
Current direction
The current Dream CE design tries to stay between two extremes:
- not just batch summarization,
- not unrestricted autonomous reasoning.
Dream actions are expected to include rationale and confidence, and persistence should only happen when the output can justify how it helps future answers.
Desired outcome
We hope to collect principles, concerns, and use cases from the community. The outcome may become design guidelines for Dream CE, especially around:
- memory safety,
- confidence and rationale,
- what can be persisted,
- what should remain only as a diary or trace,
- how much “reasoning over memory” is acceptable.
Activity
fancyboi999 commentedon May 22, 2026
这个 issue 问得比较哲学,我倒觉得它有一个相当明确的工程答案,先把结论放在前面:需要,但默认行为应该是廉价的,昂贵的反思只是可选上层。
业界几个对照点:
我们的"假设演绎"约束(rationale 必须非空 + confidence > 0 才落盘)是上面几家里最严格的。
reasoning_prompt.py反复要求 "NOT summarization"、"the more YOUR thinking matters"、"bring in your domain knowledge",这个设计是认真的,代价是单次 Dream run 烧 5n 次 LLM 调用(n = motive 数)。这条路本身没错,但它不该是唯一可用的路。SCM 双阶段分离的思路我觉得我们可以学,把 Dream 拆成两条 path。
Fast path (NREM-like):只跑 motive formation + 直接 CREATE/UPDATE/MERGE,不做 context binding,不调用 reasoning 阶段的 LLM,不生成 diary。用一个 mini 模型(类似 Codex Phase 1 的 gpt-5.4-mini Low reasoning),成本低,频率高。
Slow path (REM-like):完整跑现在的 5 阶段流水线,包括 context binding + reasoning + diary。用大模型,频率低,产出 InsightMemory + DreamDiary。
触发逻辑也分两层:fast path 由 #1702 讨论的 recall hit / feedback 信号触发;slow path 由 importance 累积超阈值触发(类似 Generative Agents 的 150 门槛)。
这样回到 issue 标题。"need dreaming?"——need。"draw the line between reasoning and summarization?"——不必划一条线,做两条 path,廉价的那条接近 summarization,昂贵的那条做 reasoning,用户和应用层选哪条用。
最后一句我个人的看法:"dream" 这个命名长期看会绑架工程决策。叫 consolidation(Codex 的命名)的话,加 fast path 是天经地义的;叫 dream 的话,fast path 这种功利性的东西就感觉煞风景。命名会反向塑造代码,这一点以后内部讨论时也可以再 review 一次。
github-actions commentedon Jul 5, 2026
This issue has been automatically marked as stale due to inactivity.