Repository navigation
[Discussion] What should trigger Dream CE? #1702
Description
Activity
- addedtypes:enhancementNew feature or improvement | 新功能或改进New feature or improvement | 新功能或改进contrib:help wantedExtra attention is needed | 需要社区帮助Extra attention is needed | 需要社区帮助
on May 12, 2026 当前只用 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 一起做,免得后面每加一种信号就改一次接口。This issue has been automatically marked as stale due to inactivity.
- addedstatus:staleAuto-marked stale after 30d inactivity; closes 7d later unless exempt.Auto-marked stale after 30d inactivity; closes 7d later unless exempt.
on Jul 5, 2026 - addedarea:memory记忆存储、检索、更新、召回逻辑记忆存储、检索、更新、召回逻辑status:needs-designNeeds design discussion before implementation | 开发前需要方案设计Needs design discussion before implementation | 开发前需要方案设计and removedtypes:enhancementNew feature or improvement | 新功能或改进New feature or improvement | 新功能或改进status:staleAuto-marked stale after 30d inactivity; closes 7d later unless exempt.Auto-marked stale after 30d inactivity; closes 7d later unless exempt.area:coreMOS 编排层 / 框架底座 / 跨模块问题MOS 编排层 / 框架底座 / 跨模块问题
on Jul 7, 2026 - locked and limited conversation to collaborators
on Jul 7, 2026
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
Questions
Current code direction
Current Dream CE has:
DreamSignalStoreDreamSignalSnapshotMotiveTypeThe 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: