产品更新｜MemOS 新增 Dream 离线反思：让记忆系统学会在后台「做梦」

MemOS
8 阅读13分钟

从 Dream 第一次出现在社区开始，我们就在不同的渠道、社群、社区里反复听到大家询问：MemOS 什么时候做 Dream？

Anthropic 在 Managed Agents 里放出了 Dreams；OpenClaw 也在 memory-core 里加入了 Dreaming，把记忆整理拆成 Light、REM、Deep 三个阶段。

不难发现，大家最近都在做同一件事：让记忆系统在白天不工作的时候，也能在后台自己整理。

MemOS 这次新增的 Dream 也是。更准确地说，我们希望 Dream 不只是“批量整理新增记忆”，而是从“系统还有哪些没收尾的动机”出发。

没有梦因，整理只是批处理；有了梦因，系统才知道自己为什么要整理、围绕什么问题整理、最后应该沉淀出什么 insight。

这次更新之后，MemOS 可以在后台把白天分散写入的记忆重新组织起来：哪些记忆其实属于同一个问题，哪些反馈反复指向一个深层需求，哪些洞察未来能帮助 Agent 更快 search 到真正有用的内容。

本次更新亮点

微信图片1.png

📣 写在前面：Dream 这一版已经在 MemOS 仓库开源。

文章后半部分还有几个我们希望社区开发者一起做和贡献的设计。

如果你已经在做 agent memory，特别想听听你的意见。

一、Dream：让记忆从“保存反馈”走向“沉淀洞察”

在实时对话里，Agent 很容易被当前对话牵着走。

当你说“短一点”，它就压缩文本；说“重点突出一点”，它就加粗标题；然后又说“不要太 AI”，它就换一批更自然的词。

每一轮看起来都对，但连起来看，问题可能根本不在“怎么改一句话”，而在“这个任务的判断标准已经变了”。

Dream 的作用，就是把这些分散的记忆放到离线阶段重新看一遍。

它有点像团队每天收工后的复盘：先把客户反馈、会议讨论、临时修改都记下来；不急着继续干活，而是把这些记录摊开，看它们是不是在反复指向同一个更大的问题。

🌰 举个栗子：

用户想用 OpenClaw 这类 Agent 做一个 AI 简历优化工具官网，给了一连串的连续反馈：

  • 功能都写上了，但感觉没说服力。
  • 能不能更像一个正式产品？
  • 用户为什么要现在试用？
  • 别太像 AI 生成的营销文案。
  • 求职者已经有简历了，为什么还需要这个工具？

过去这种反馈会被系统拆成 5 个独立修改点：改标题、换文案、补功能、调语气、强化 CTA。

现在，Dream 会把这些分散反馈聚成一个“梦因”，发现它们都指向同一个深层问题：这个页面不应该围绕“AI 有哪些功能”来写，而应该围绕求职者的临门一脚焦虑来写。

Dream 可能生成这样的 InsightMemory：

这个落地页的核心不是展示 AI 功能，而是回答求职者为什么已经有简历、却仍然需要优化。首屏应该从“投了很多岗位却没有回应”的焦虑切入，再说明工具如何把 JD、简历和面试官视角对齐。最有说服力的不是“智能润色”，而是“让简历里的每一句话都更像目标岗位在找的人”。

第二天用户再说“帮我重写首屏”，Agent 就不用继续机械替换营销词，而是可以沿着这条 insight 调整页面结构、文案重点和行动按钮。

二、DreamDiary：Dream 不是黑箱改写记忆

离线反思听起来很有用，但记忆系统不能悄悄把过去改掉。

Dream 这次写入两类内容：

  • InsightMemory：给未来检索和回答使用的洞察记忆。
  • DreamDiary：给人看的梦境日记，记录这次 Dream 的动机、摘要、梦境内容和来源记忆数量。

这样做的好处是，未来 Agent 可以用 insight 提升任务表现，人也可以回头检查：这次 Dream 到底基于哪些记忆，为什么形成了这个判断。

🌰 举个栗子：每日简报为什么越全越没用

用户想让 Agent 每天早上整理邮件、日历、待办和消息，生成 morning briefing。反馈一轮轮出现：

  • 把邮件、日历、Slack 都看一下。
  • 结果太长了，我看不完。
  • 重要事项没突出。
  • 我不是要更多信息，我是要知道今天先做什么。

以前，系统容易把问题理解成“信息源还不够”或“摘要格式还不够好”，于是继续加邮件分类、会议列表、消息摘要。

简报越来越完整，用户却更难开始行动。

Dream 可以在离线阶段把这些反馈连起来看，生成这样的 insight：

用户的 morning briefing 不应该按信息来源组织，而应该按决策压力组织。先给今天唯一最重要的承诺，再给需要别人等待的事项，最后才是可选信息。它的成功标准不是覆盖全面，而是让用户少想 10 分钟。

这类 insight 很难在实时对话里马上形成，因为每次反馈看起来都只是“短一点”“重点突出一点”。Dream 的价值，是把多次局部反馈背后的稳定偏好和深层需求沉淀下来。

三、Dream 是怎么跑起来的？

Dream 的触发从新增记忆开始。

在添加记忆阶段，MemOS 会通过 add.after hook 捕获新增记忆 ID，并按 mem_cube_id 放入 DreamSignalStore。

当前社区版默认只使用一种信号：新增记忆数量。当某个 cube 的待处理记忆达到阈值，默认 100 条，系统会提交一个 mem_dream 调度任务。

📣 插件系统 Tips：2026 年 4 月 23 日，我们在 MemOS 引入了插件系统——把记忆生命周期里的关键扩展点（添加、检索、调度、维护等）开放出来，新能力可以以「插件」的方式挂上去，不用改动核心代码。本次的 Dream 就是以插件的形式接入的：可以按需启停、按 cube 配置参数，社区也可以在它基础上做自己的 Dream 变体。

微信图片2.png

Dream 执行阶段包含 4 个核心步骤：

3.1 形成梦因：从 pending memories 里找出值得反思的问题

LLM 会阅读 pending memories，把值得反思的记忆聚成最多 3 个 motive。它会优先寻找：跨对话模式、未解决问题、重复出现的主题、情绪张力。

这一步不是简单做摘要，而是在问：这些记忆反复出现，是不是因为背后有一个更核心的问题还没被解决？

3.2 围绕动机召回：把相关旧记忆拉回来

系统会走一遍召回模块，把梦因相关的旧记忆从 UserMemory和 LongTermMemory里拉回来，补充上下文。

单条反馈经常是不完整的。比如“首屏还是不对”，只有把前面的产品定位、用户画像、文案修改记录一起拉回来，Agent 才知道这个“不对”到底指向什么。

3.3 深度反思：写下洞察，再为它埋一个"未来会被问到的问题"

这是真正做梦的那一部分。系统把梦因和拉回来的旧记忆一起交给 LLM，让它重新思考一遍，沉淀出这次 Dream 的结论——也就是 dream_content。同时会让让 LLM 多做一件事：预想一下"哪种问法应该让这条洞察被检索出来"。

3.4 持久化：写入 InsightMemory 和 DreamDiary

系统会将洞察写入 InsightMemory，并把可解释记录写入 DreamDiary。

记忆整理、Dream 执行和持久化都在后台调度中完成，不会阻塞用户的实时对话。

四、上手用一下

下面是开源项目里的一个最小示例：

为确保 dream 插件能够被发现，需要在下载最新开源代码后，命令行执行：

pip install -e .

4.1 添加记忆并手动触发 Dream

把一组分散但相关的落地页反馈写进去，然后手动触发 Dream、查询日记：

import time
import uuid
import requests
BASE_URL = "http://127.0.0.1:8001"
SETTLE_SECONDS = 30
def wait_with_reason(reason: str, seconds: int) -> None:
    print(f"{reason}，等待 {seconds} 秒...")
    time.sleep(seconds)
user_id = f"dream-test-{uuid.uuid4().hex[:8]}"
mem_cube_id = f"cube-{user_id}"
# 添加一组分散但相关的产品落地页讨论
messages = [
    "我想用 OpenClaw 做一个 AI 简历优化工具的官网，帮我先搭一个 landing page。",
    "功能都写上了，但是感觉没什么说服力，像在堆能力点。",
    "能不能更像一个正式产品？用户看完要觉得这是可以信任的工具。",
    "首屏还是不对。用户为什么要现在试用？这个理由没有讲出来。",
    "不要太像 AI 生成的营销文案，别一直说智能、精准、高效。",
    "求职者已经有简历了，为什么还需要这个工具？",
    "页面应该让用户觉得：投了很多岗位没回应，不是我不行，而是简历没有对齐岗位。",
]
for msg in messages:
    response = requests.post(f"{BASE_URL}/product/add", json={
        "user_id": user_id,
        "mem_cube_id": mem_cube_id,
        "messages": [{"role": "user", "content": msg}],
    })
    response.raise_for_status()
    print(f"记忆写入请求已成功提交：{msg}")
wait_with_reason("等待 memory add 后台入库和调度队列处理完成", SETTLE_SECONDS)
# 手动触发 Dream
response = requests.post(
    f"{BASE_URL}/dream/trigger/cube",
    params={"cube_id": mem_cube_id, "user_id": user_id, "user_name": user_id},
)
response.raise_for_status()
print(f"Dream 触发请求已成功提交：cube_id={mem_cube_id}")
# Dream 在后台调度执行，等待一段时间后查询日记
wait_with_reason("Dream 在后台异步生成日记，等待生成结果可查询", SETTLE_SECONDS)
mem_cube_id="cube-dream-test-be09a7f9"
diary = requests.post(f"{BASE_URL}/dream/diary", json={
    "cube_id": mem_cube_id,
    "filter": {"limit": 5},
}).json()
for item in diary.get("data") or []:
    print("Title :", item.get("title"))
    print("Motive:", item.get("motive"))
    print("Dream :", item.get("dream_entry"))

4.2 按时间范围查询梦境日记

想看某段时间系统都"梦"了些什么，按时间过滤就行：

import requests
res = requests.post("http://127.0.0.1:8001/dream/diary", json={
    "cube_id": "cube-demo",
    "filter": {
        "created_after": "2026-05-01",
        "created_before": "2026-05-15",
        "limit": 10,
    },
})
for item in res.json().get("data", []):
    print(item["created_at"], item["title"])
    print(item["dream_entry"])

五、还没想清楚的事，想和你一起 Dream

在写这篇文章之前，我们想再次感谢 MemOS 社区里的大家伙！🙇🙇🙇

MemOS 开源以来短短几个月，已经有近 200 个被 merge 的 PR 和 issue，是社区里的贡献者一起把它推到了今天。仓库里的 issue 和 PR 也已经堆到处理不过来——每周都有新的设计被来自社区的讨论改写。

Dream 是我们想在社区一起完成的第一个完整功能。

截至当前版本，Dream 项目里能看到我们目前的 sketch——代码能跑、方案是通的。但有几个核心问题没有标准答案，最好的解法取决于大家实际怎么用 Dream。我们想把这部分留给社区一起决定，做出对真实使用场景最有用的社区版本：

  • Dream memory 该按时间衰减，还是按命中频率衰减？
  • 矛盾的 insight 怎么处理——归档、保留、还是触发再次 Dream？
  • Dream memory 进 prompt 时要不要带 confidence 标签？

下面按 “已经在做” 和 “想听你说”两类列一下当前的方向。

5.1 已经在做：Context 上下文绑定

现在的 Dream 能生成洞察，但还没有把相关记忆稳定绑定到同一个上下文里。

比如用户连续几天都在做“AI 简历优化工具”的落地页——有的记忆讨论首屏文案，有的讨论信任感，有的讨论求职者痛点。这些内容语义不完全相似，但其实都属于同一个产品上下文。

我们准备引入 Context 节点，把这些记忆绑定到一个中间层主题。Search 时不只是在全库做相似度匹配，而是先找到正确的 context，再在 context 内部检索和推理。

这个方向和近期 MEME: Multi-entity & Evolving Memory Evaluation 的结论一致：

现有记忆系统在静态检索上还可以，但遇到多实体、持续变化、依赖关系推理时会明显失效。论文里多个系统在 Cascade 和 Absence 类推理任务上平均准确率只有 3% 和 1%——说明"多搜一点"或"换更强模型"并不能从根上解决问题，记忆需要有上下文、实体关系和演化轨迹。

5.2 一起 Dream：Dream memory 的生命周期

Dream 不能像 raw memory 一样“写一次永久保留”。一个 6 个月前的咖啡偏好洞察，今天还有效吗？

这件事没有标准答案，每个设计选择背后是不同的用法假设。比如衰减策略：如果 Dream insight 主要给人看，时间衰减就够了；如果被注入到 prompt 影响 agent 行为，按命中频率衰减可能更安全。

所以我们把设计问题拆成 5 个 Discussion 放到了 GitHub 上，等你一起共建 💪：

微信图片3.png

5.3 一起 Dream：记忆库劣化治理

当前 Dream 不会主动修改旧记忆。但有几件事一直在我们的清单里：

  • 重复记忆合并：避免 top-k 被相似内容占满
  • 冲突记忆整理：保留状态变化轨迹，而不是简单覆盖
  • 过期 insight 归档：长期没用或被新反馈推翻的洞察自动降权或归档

这块代码我们还没动，如果你已经在自己的 agent 里处理过类似问题，欢迎在 #1704 下面分享你的做法，或者直接开新 issue。

怎么和我们一起做

Dream 这件事的特别之处是：你不需要写代码也能贡献。

🕐 5 分钟留个意见 挑一个让你最有感觉的 issue，进去给我们留个评论。哪怕只说一句"我觉得 Dream memory 应该按使用频率衰减，不按时间"！

🕐 30 分钟聊聊你的用例 你在做什么 agent？你会怎么用 Dream memory？什么时候希望它消失？什么时候希望它留下？我们希望了解社区里大家的真实使用场景。

🕐 一起共建：写个小提案 挑一个子问题（比如"Dream lifecycle 设计"），写一段 200-500 字的设计提案放进 issue 评论里。如果你的提案被采纳，我们将会在最终实现的 PR 描述里进行致谢！同时还会有 MemOS 官方礼包，让我们一起 Dream～

✨ 让 Agent 在睡觉的时候也能成长一点。而 Agent 怎么“做梦”，MemOS 想和你一起决定。

📎 相关链接

关于 MemOS

MemOS 为 AI 应用构建统一的记忆管理平台，让智能系统如大脑般拥有灵活、可迁移、可共享的长期记忆和即时记忆。

作为记忆张量首次提出“记忆调度”架构的 AI 记忆操作系统，我们希望通过 MemOS 全面重构模型记忆资源的生命周期管理，为智能系统提供高效且灵活的记忆管理能力。

avatar
文章
阅读
粉丝