[Discussion] What should trigger Dream CE?

[CaralHsi]

Dream CE currently starts from a simple signal: newly added memories accumulate until Dream can be triggered.

This is intentionally minimal, but a real memory system may need richer trigger signals.

Possible trigger signals

• Newness: many new memories have been added.
• Conflict: new memory contradicts or challenges existing memory.
• Frequency: similar topics or failures appear repeatedly.
• Feedback: user feedback shows an answer was wrong, useful, or unsatisfying.
• Recall hit patterns: certain memories are repeatedly retrieved.
• Unresolved goals: a task or user intention remains incomplete.
• Emotional or importance signal: some memory appears unusually important.

Questions

• What should trigger a Dream run?
• Should Dream run on a schedule, on thresholds, or only manually?
• Should different signal types produce different motive types?
• How should we rank which memories are worth dreaming about?
• How do we avoid running Dream too often?
• Should triggers be per user, per cube, per session, or per topic?
• What signals have you seen in your own agent or memory systems?

Current code direction

Current Dream CE has:

• DreamSignalStore
• DreamSignalSnapshot
• MotiveType
• cube-level trigger API

The code is designed to allow richer signal producers later.

Desired outcome

We want to identify the most useful first signal types to implement. Strong proposals may become implementation issues, such as:

• add conflict signal producer,
• add feedback signal producer,
• add frequency-based Dream trigger,
• add session/topic-level triggers.

[fancyboi999]

当前只用 newness(累积 100 条 pending)这一个信号,我觉得是几个项目里最被动的设计。把业界其他项目的触发机制摆一起对照一下:

项目	触发信号
Generative Agents (Park et al. 2023)	importance 累积超 150 阈值触发反思
Codex	启动时 + 候选 thread 满足时间窗 [6h, 30d]
Claude Code	24h 时间门控 + 5 sessions 累积双门控
Hermes	每轮 review + 7d 定时 + idle 阈值
Mem0	每条新消息触发 extract + LLM decide
MemoryBank	每次 recall 时更新 retention
MemOS Dream(当前)	累积 100 条

最早做这件事的 Generative Agents 论文就已经放弃了"按数量阈值",他们的方案是给每条新观察 LLM 打个 1-10 的 importance 分,累积超 150 触发。这等于把"什么时候该反思"的决策从"看数量"升级成"看权重"。

我们现在的 newness 触发有个具体问题:100 条琐碎闲聊和 100 条核心交互,从 motive formation 角度看价值差几个量级,但触发频率一样。

按 issue 列的七种信号,我按"代码实现成本从低到高 + 价值从高到低"排过一遍:

优先(1-2 周内可落地)

• Recall hit patterns:complements [Discussion] How should Dream memories decay, be archived, or be used by agents? #1704 的 usage_count 字段。某条记忆或某簇主题反复被召回,触发对该簇的定向 Dream(单 motive,跳过 motive formation,省一次 LLM 调用)。
• Feedback:用户给 negative feedback,立即触发针对该领域的 Dream(高优先级队列)。

中期(1 个月)

• Frequency:weak_context_id 聚类已经在做了,加个统计,某 context 在短期内累积超阈值就触发该 context 的定向 Dream。
• Importance scoring:照搬 Generative Agents,add 时 LLM 给个 1-10 分,累积过阈值触发。我们的 motive prompt 其实在做类似判断,只是放在了下游。

长期或暂不做

• Conflict:需要新旧记忆 LLM 比对,成本高,做完不一定有显著收益。
• Emotional / Unresolved goals:太软,先不投入。

具体建议把这个 issue 拆成 4 个 follow-up:add_recall_hit_signal、add_feedback_signal、add_frequency_signal、add_importance_scoring。前两个直接做,后两个看前两个效果再说。

---

再多说一句架构层面的事:我们现在的 DreamSignalStore 累积器只能装一种信号(memory_ids)。如果要支持多信号源,可能需要把 SignalSnapshot 改成多 channel,每个 signal producer 写自己 channel,scheduler 决定多 channel 怎么 merge 成一次 Dream 任务。这个改动建议跟 follow-up 1 一起做,免得后面每加一种信号就改一次接口。

[github-actions[bot]]

This issue has been automatically marked as stale due to inactivity.