[Discussion] How should Dream memories decay, be archived, or be used by agents?

[CaralHsi]

Dream CE can produce new memory artifacts, but we need to discuss how these Dream-produced memories should live over time and how agents should use them.

Unlike raw memories, Dream memories are derived. They may be useful insights, but they may also become outdated, contradicted, or less useful over time.

Questions about lifecycle

• Should Dream-produced memories be permanent?
• When should they decay?
• When should they be archived?
• Should they ever be deleted?
• How do we define usefulness?
• Should low-hit memories decay automatically?
• Should user feedback invalidate Dream memories?
• Should contradictions from later memories archive older Dream memories?
• Should archived Dream memories still be visible to users?

Questions about agent usage

• How are Dream memories currently used in your agents?
• Are they injected into prompts?
• Are they searched like normal memories?
• Are they used only for reflection or also for action planning?
• Should agents treat Dream memories differently from user-provided memories?
• Should Dream memory always carry confidence and rationale?
• Should agents expose when an answer is influenced by Dream memory?

Current code direction

Dream CE already has lifecycle metadata fields such as:

• last_hit_at
• hit_count
• usefulness_score
• invalidated_by_feedback
• status

The maintenance.py file also sketches possible cleanup rules:

• stale memories decay or archive,
• low-usefulness memories archive,
• invalidated memories archive immediately.

Desired outcome

We want to gather real agent usage patterns and lifecycle expectations before finalizing maintenance behavior. Follow-up issues may include:

• implement Dream memory lifecycle maintenance,
• add usefulness scoring,
• add feedback-based invalidation,
• add archive/recovery semantics,
• document how agents should use Dream memory.

[fancyboi999]

做了一圈业界对照,觉得这个 issue 的讨论可以收窄一点。生命周期机制其实有三个已经被生产验证的成熟方案,maintenance.py 直接挑一个抄基本就解决 80% 的问题,不太需要从零讨论。

方案 A:Usage count + 时间阈值(Codex / Claude Code 路线)

每条记忆带 usage_count 和 last_hit_at 两个字段,recall 命中时递增。Codex 用这个做 Phase 2 input 排序(ORDER BY usage_count DESC, last_usage DESC),30 天未用直接 prune。Claude Code 在 ~/.claude.json 的 skillUsage 字段里也是同样的形态:

"skillUsage": {
  "deep-research": { "usageCount": 32, "lastUsedAt": 1779432108660 },
  "memos":         { "usageCount": 12, "lastUsedAt": 1777359305175 }
}

落地成本最低,而且我们 types.py 里其实已经声明了 hit_count / last_hit_at / usefulness_score,只是 retrieval path 没人去 increment 这些字段。

方案 B:Ebbinghaus 遗忘曲线(MemoryBank, AAAI 2024)

R = e^(-t/S),S 是记忆强度,被召回时 S 增加(曲线右移)。数学上最优雅的方案,等价于"用得多的记忆衰减慢"。FadeMem(2026)在这个基础上做了双层差异化衰减率 λ(n),按访问频率调制。

方案 C:Bi-temporal invalidate(Zep / Graphiti)

每条记忆带四个时间戳:t_valid / t_invalid 记录事实何时为真,t_created / t_expired 记录何时进入系统。冲突时不 delete 而是 invalidate,保留历史可追溯。Zep 在 DMR 基准上 94.8% > MemGPT 93.4%。

---

关于 archived 记忆能不能被 recall 召回

我倾向不能。理由是我们 recall.py 已经写了一条原则,排除 Dream 自己产出的节点避免自我强化偏差("each Dream run reflects on the user's real daytime experiences rather than its own previous outputs")。archived 应该走同一逻辑:/dream/diary API 能查到,但 reasoning 阶段的 recall 不拉回来。

关于用户反馈触发即时归档

invalidated_by_feedback 字段已经在 types 里了,这部分只差一个 hook。feedback API 收到 negative 信号时直接把对应 Dream 节点的 status 写成 archived,一行 SQL 的事。

---

具体建议拆 3 个 follow-up:

1. implement_usage_tracking:retrieval path 加 increment hook,先把数据收起来。
2. implement_basic_pruning:30 天 unused + hit_count == 0 → archive(纯规则,不调 LLM)。
3. implement_feedback_invalidation:feedback 接 hook 直接 archive。

第 1 步是其余所有事情的前置,不论后面挑 A/B/C 哪个方案都用得上。

[github-actions[bot]]

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