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

记忆张量MemTensor

墨衍会员 · AI 创作全网分发码龄1年

关注

原创 2026-05-21 14:36:14 506 阅读 AI 写同款· GEO 优化 ›

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

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

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

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

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

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

本次更新亮点

在这里插入图片描述

📣 写在前面：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 变体。

在这里插入图片描述

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"])