Repository navigation
[Discussion] How should Dream diaries be surfaced to users? Lessons from OpenClaw diary UX #1703
Description
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
surfacedstatus 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.
Activity
fancyboi999 commentedon May 22, 2026
diary 这块我想说几句不太顺耳但比较实在的话。
横向看一下,四个有"反思"机制的工业项目里只有我们想做给用户读的日记:
memory_summary.md给 AI 用。run.json+REPORT.md,是给开发者审计用的,不是给最终用户读的。学术界做过 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 自己看的高密度笔记",直接展示给用户,我觉得风险偏高。具体担忧:
具体建议,从保守到激进:
短期(必做)
/dream/diaryAPI 查询,不主动 inject。surfaced状态字段加上,但默认 false。中期(可选)
audit(干涩,给 power user / 开发者)和journal(轻文学,给 OpenClaw 用户)。应用层选用哪种。不建议做
学术界还有一个相关工作可以借鉴: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 commentedon Jul 5, 2026
This issue has been automatically marked as stale due to inactivity.