[Discussion] How should Dream diaries be surfaced to users? Lessons from OpenClaw diary UX

[CaralHsi]

Dream CE produces diary entries as human-readable traces of offline memory consolidation. OpenClaw already has a diary-like user experience, so we would like to discuss how Dream diaries should be surfaced in MemOS and agent workflows.

Current idea

A Dream diary is different from functional memory:

• Functional memory is used by the agent for future reasoning or recall.
• A diary is an explainability artifact that helps users understand what the system consolidated.

Currently, diary entries can be queried, but they are not necessarily surfaced proactively.

Design questions

• Should Dream diaries be shown to users at all?
• Should diaries be passive, only visible when queried?
• Should the agent proactively mention a diary entry in the next conversation?
• If proactive, when is it helpful rather than annoying?
• Should we add a surfaced status to avoid repeating the same diary?
• Should users be able to disable diary surfacing?
• Should diary entries be written in a raw technical style or a warmer “nightly journal” style?
• What can we learn from OpenClaw’s diary experience?
• Should diary UX be part of MemOS core, or handled by applications on top of MemOS?

Possible directions

• Passive diary API only.
• Proactive “I reflected on something from last time...” message.
• UI timeline of Dream diary entries.
• Configurable diary surfacing policy.
• App-specific diary rendering, with MemOS only storing structured entries.

Desired outcome

We hope to collect UX expectations and real use cases before implementing diary surfacing. The result may become follow-up issues around:

• human-friendly diary rewriting,
• surfaced status,
• diary API improvements,
• OpenClaw integration examples.

[fancyboi999]

diary 这块我想说几句不太顺耳但比较实在的话。

横向看一下,四个有"反思"机制的工业项目里只有我们想做给用户读的日记:

• Codex:没有 diary,Phase 2 产出 memory_summary.md 给 AI 用。
• Claude Code:没有 diary,有 MEMORY.md 也是给 AI 用。
• Hermes Curator:产出 run.json + REPORT.md,是给开发者审计用的,不是给最终用户读的。
• MemOS Dream:DreamDiaryEntry,目标用户是 OpenClaw 的最终用户。

学术界做过 user-facing journaling 的是 DiaryMate(CHI 2024)和近期几个 AI journaling app。DiaryMate 的核心发现是:LLM 作为协作写作伙伴(读用户写的内容并回应、跨多天连点找模式)被接受度高,LLM 单方面给用户写日记接受度低。这个差异在他们的用户访谈里很明确。

我们当前 diary.py 走的是后一条路:LLM 单方面写。而且更糟糕的是,diary.py 的代码注释明确写了"完全确定性,不调用 LLM",dream_entry 字段直接搬 reasoning 阶段的 dream_content。reasoning_prompt.py 里那段"妈妈睡在沙发上"的范例是典型的"LLM 写给 AI 自己看的高密度笔记",直接展示给用户,我觉得风险偏高。

具体担忧:

1. 风格错配:reasoning prompt 反复要求 "NOT summarization"、"YOUR thinking"、"bring in domain knowledge",这是在 push LLM 进入创作状态。创作状态的产物当 AI 内部笔记没问题,当用户日记会显得 over-interpretive,甚至有点"装"。
2. 主动 surface 的安全边界:issue 提到的 "I had a dream last night..." inject 到对话开场,这种交互在 ChatGPT Memory dossier 被吐槽过(Simon Willison 在 2025 年 5 月的 blog 公开批评 ChatGPT memory 太侵入)。我们如果默认开,翻车概率不低。
3. Diary 跟 InsightMemory 共享同一份内容,会导致两个目标互相牵制:reasoning 阶段如果为了"好读"而稀释密度,InsightMemory 给 AI 用的价值下降;如果保持密度,diary 难读。这是个 inherent 的设计冲突。

---

具体建议,从保守到激进:

短期(必做)

• Diary 默认 passive,只通过 /dream/diary API 查询,不主动 inject。surfaced 状态字段加上,但默认 false。
• Diary 加一道 LLM rewrite pass(diary.py 自己的注释里也写了这是 "consider but not limited to" 的方向),专门把 dense insight 转成 "neutral, factual, low-drama" 风格,明确禁止戏剧化、拟人化、推断动机。Fallback 到原文。

中期(可选)

• 提供两套 diary 风格:audit(干涩,给 power user / 开发者)和 journal(轻文学,给 OpenClaw 用户)。应用层选用哪种。
• 频率上限:每个 session 最多 surface 一条 diary,且只 surface confidence > 0.7 的。

不建议做

• 默认主动 inject 到对话开场。即使要做,也应该应用层(OpenClaw)自己决定,不在 MemOS core 里默认开启。

---

学术界还有一个相关工作可以借鉴:View-oriented Conversation Compiler(VCC, 2026),他们把 raw agent logs 编译成 "user-perceived view",pass rate 提升的同时 token 消耗减半到三分之二。我们可以考虑把 reasoning 阶段产出和 diary 渲染解耦。reasoning 输出结构化数据(motive / dream_action / rationale / source_ids),diary 是这个结构化数据上的"渲染层",用 LLM 渲染或纯模板都行,不同应用层用不同渲染策略。这样既不需要每次 reasoning 都重跑,又能给应用层灵活性。

总结:别让 diary 牵制 reasoning,别默认主动 surface,加一道 rewrite,把渲染和数据解耦。

[github-actions[bot]]

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