Featured image of post ChatGPT Dreaming vs Hy-Memory:AI 的记忆,到底该放在谁手里?

ChatGPT Dreaming vs Hy-Memory:AI 的记忆,到底该放在谁手里?

OpenAI 的 ChatGPT Dreaming 和腾讯混元 Hy-Memory 都在做长期记忆,但路线完全不同:前者把记忆做进平台,后者更像给 Agent 接一个本地第二大脑。真正值得讨论的不是谁更聪明,而是谁拥有这份越来越重要的用户模型。

前几天刚写完 Hy-Memory,我本来不打算这么快再写一次 AI 记忆。

这个话题很容易写重复。上下文不是记忆、聊天记录不是记忆、Agent 需要把经历沉淀成经验——这些判断我在上一篇里已经说过了,再换个产品名重讲一遍,意义不大。

但 OpenAI 这次发布 ChatGPT Dreaming,还是值得单独拎出来。

不是因为它又证明了“长期记忆很重要”。这个已经不用证明了。

真正有意思的是,它和 Hy-Memory 刚好站在两条路上。

一边是 ChatGPT Dreaming:记忆被做进平台里,后台自动整理,用户最好什么都不用管。

另一边是 Hy-Memory:记忆作为 Agent 的外部第二大脑,通过插件、本地服务、分层结构和检索机制接进来,折腾一些,但更接近“用户自己的东西”。

平台记忆与本地记忆的两条路线

这两个东西放在一起看,问题就不只是“AI 怎么才能记住我”。

问题变成了:

AI 越来越记得你以后,这份记忆到底应该归谁管?

ChatGPT Dreaming vs Hy-Memory:AI 的记忆,到底该放在谁手里?

Dreaming 这次更新,重点不在“记得更多”

OpenAI 在 6 月 4 日发了《Dreaming: Better memory for a more helpful ChatGPT》,介绍 ChatGPT 新一代记忆系统 Dreaming V3。

如果只看产品层面,这次更新很好理解:ChatGPT 会更懂你,能跨对话带着上下文,也能把过期信息更新掉。

但 OpenAI 文章里有几个细节,比“记忆更强了”更值得看。

最早的 ChatGPT 记忆,是 2024 年的 saved memories。你要主动告诉它:

记住,我喜欢简洁直接的回答。

或者:

记住,我 7 月要去新加坡。

这种方式很像给 AI 写便签。问题也很明显:只有你明确说“记住”的东西,才容易留下来。

但真实使用里,很多重要信息并不是这样出现的。

你可能只是在一次次对话里反复表现出某种偏好:不喜欢废话,喜欢先给结论,写文章不要太像营销稿,做项目时先看目录结构。你未必会专门说一句“请记住,我讨厌空泛口号”。

Dreaming 要解决的,就是这类自然发生在对话里的信息。

它不是等你主动要求保存,而是在后台从多次对话里合成 ChatGPT 对你的理解。

这里的关键词不是 memory,而是 synthesis。

不是保存一句话,而是从一堆对话里提炼出状态。

这也是为什么它叫 Dreaming。这个名字虽然有点营销味,但方向是对的:整理发生在对话之外。

你聊天的时候,它服务你;你不聊天的时候,系统在后台把过去的对话重新压缩、合并、更新。

这和我之前写“语言模型也需要睡觉”的判断是连上的。一个长期工作的 Agent,不能只是不停执行。它需要某种休息、复盘、整理机制。否则上下文越堆越厚,最后反而变笨。

OpenAI 这次把这件事产品化了。

OpenAI 真正在补的是“用户模型”

Dreaming 文章里有三个评价目标:带着有用上下文进入下一轮对话、持续遵循偏好和约束、随着时间保持当前性。

听起来都很普通,但合在一起,其实就是一件事:

ChatGPT 要维护一个动态的用户模型。

比如旅行计划。

你以前说过 7 月要去新加坡,这在 6 月是计划,在 8 月就是历史。一个差的记忆系统会一直把“你要去新加坡”当成当前状态;一个好的记忆系统应该知道:这件事已经发生过了,之后再推荐餐厅和外卖时,不该默认你还在新加坡。

这类例子很小,但方向很大。

因为用户模型不是几条偏好标签。它包括你的项目、习惯、长期目标、已结束的计划、反复出现的判断、被你否掉过的方案,以及哪些东西已经不该再影响当前决策。

这也是 OpenAI 为什么要把 Dreaming 做成基础设施。

文章里提到,近期改进把服务 Dreaming 所需的计算量降低了大约 5 倍,所以才开始给 Free 用户逐步开放,同时提升 Plus / Pro 用户的记忆容量。

这个 5 倍挺关键。

它说明长期记忆不是一个小功能,而是成本很重的系统工程。几亿用户、多年对话、持续更新、还要尽量少出错,这不是加个“历史记录检索”就能解决的。

所以从 OpenAI 角度看,Dreaming 不是锦上添花。

它是在给 ChatGPT 变成个人助手补地基。

Hy-Memory 看的不是普通用户,而是长期合作的 Agent

再看 Hy-Memory。

Hy-Memory 的出发点就没那么“消费级”。它不是让一个聊天产品更贴心,而是问一个更工程化的问题:为什么 Agent 刚开始像搭档,三周后像查询工具?

我之前写那篇时,最打动我的不是“6 层记忆框架”这个数字,而是它承认记忆有密度差异。

原始痕迹、事件摘要、行为模式、心智模型、知识网络,不应该混在一个抽屉里。

有些东西只是“当时发生了什么”;有些东西是“为什么这么判断”;还有些是“这个用户、这个项目长期以来遵循什么原则”。

如果全都当聊天记录存,最后只会变成一个更大的垃圾堆。

Hy-Memory 的 System1 / System2 也很直观。

System1 负责实时写入,先别断片。

System2 负责后台整理,慢慢判断哪些东西值得长期留下,哪些该降权,哪些旧记忆已经被新事实推翻。

这和 Dreaming 的方向其实很像:都不满足于原始聊天记录,都需要后台整理。

差异在于,Dreaming 是 OpenAI 平台内置的能力;Hy-Memory 更像给 Agent 外接一个记忆层。

前者让用户少操心。

后者把控制权和复杂度一起交给用户。

平台记忆为什么会赢第一轮

如果只讨论今天谁更容易用,平台记忆几乎一定赢。

大多数人不可能为了“AI 更懂我”去配置向量库、Embedding、插件权限、本地 Python 进程和 JSON 文件。

他们只想要一件事:我上次说过的,你这次别忘。

ChatGPT Dreaming 这类能力最强的地方,就是把复杂性藏起来。

你不需要知道 saved memories、Dreaming V0、Dreaming V3,也不需要知道后台怎么合成记忆。你只会感觉它更连续了:问旅行时更贴近你的偏好,问写作时更像你平时要的风格,问项目时少一点从零开始的尴尬。

这就是平台产品的优势。

它不一定最开放,但体验最顺。

而且 OpenAI 可以在海量真实使用里不断调优:什么记忆该留下,什么该过期,用户怎样查看,怎样修改,怎样避免误记。

这些事情如果交给本地插件,很容易变成少数工程爱好者才玩得转的东西。

所以我不觉得 Hy-Memory 这种路线会直接替代 Dreaming。

至少在普通用户那里,不会。

但平台记忆越好,锁定越强

问题也出在这里。

平台记忆一旦好用,用户就会越来越离不开它。

过去换模型,主要看能力。

Claude 写代码更稳,ChatGPT 产品生态更强,Gemini 多模态不错。你可以按任务切换。

但长期记忆成熟以后,切换成本会变成另一回事:

另一个模型不认识你。

这比“哪个模型更强”更麻烦。

一个用了几个月的 ChatGPT,可能知道你的写作风格、常用项目、旅行偏好、文章选题边界、哪些观点你已经写过、哪些表达你不喜欢。

这些东西不是一个 prompt 能搬走的。

它们会慢慢变成平台护城河。

这也是我看 Dreaming 时最在意的地方。

OpenAI 当然需要让 ChatGPT 更懂用户。但用户也应该问:这份越来越准确的用户模型,能不能被我看见、修改、导出、迁移?

Memory summary 是个好方向。用户至少能看到 ChatGPT 认为自己知道什么。

但更难的问题还在后面:

如果某条记忆不是我明确写下的,而是平台从多次对话里推断出来的,它算谁的?

如果我删除一条记忆,相关推断会不会继续影响回答?

如果我想换到 Claude、Gemini 或本地 Agent,这份长期积累的用户模型能不能带走?

这些问题现在看起来有点超前,但等个人 AI 助手真的变成日常工作入口,就一点都不超前了。

本地记忆的价值,是把顺序倒过来

Hy-Memory 这类本地记忆路线,优势不是“更省事”。它一点也不省事。

它的价值在于把顺序倒过来。

平台记忆的默认逻辑是:平台拥有一份关于你的记忆,用来让这个平台更好地服务你。

本地记忆的理想逻辑是:你拥有一份自己的记忆,不同 AI 在授权后读取和更新它。

这个差别很大。

如果你只用 ChatGPT,一个平台记忆就够了。

但如果你同时用 ChatGPT、Claude Code、Gemini、本地模型和 OpenClaw,问题就会出现。

ChatGPT 记得你的旅行偏好,Claude Code 记得你的项目目录,OpenClaw 记得你的自动化流程,Gemini 记得你某次研究材料。

最后你拥有五个“部分认识你”的 AI。

它们彼此不通。

这时,一个用户自己的记忆层就有意义了。

用户自有记忆层:不同 AI 读取同一份长期记忆

这也是为什么我对 Obsidian、Markdown、Git、文件系统这类东西一直有偏好。它们不一定最智能,但信息在我手里。我可以看见、移动、备份、重写。

AI 记忆如果最终也能这么做,那它就不只是某个 App 的个性化功能,而更像个人数字资产。

可惜,本地记忆现在还是太折腾

当然,本地记忆路线的问题也很现实:太麻烦。

你要装插件,配模型,配 Embedding,维护向量库,处理权限,还要判断哪些内容应该写入长期记忆。

自动写入如果做不好,很容易把垃圾也写进去。

不同 Agent 写入格式不一致,也会让后续检索越来越乱。

旧记忆和新事实冲突时,谁来判断?

本地服务挂了怎么办?

记忆越来越多以后,检索质量会不会下降?

这些都是平台记忆替普通用户挡掉的问题。

所以本地记忆更自由,也更难用。它适合愿意折腾的人,适合把 AI 当长期工作流的人,适合需要跨工具、跨模型协作的人。

它不适合只想让 ChatGPT 记住自己喜欢什么语气的普通用户。

这没什么高下之分,只是使用场景不同。

两条路线争的其实是同一件东西

Dreaming 和 Hy-Memory 看起来一个消费级,一个工程化;一个平台内置,一个本地外挂。

但它们最后争的都是同一件东西:用户模型。

用户模型包括你的稳定偏好、项目状态、长期目标、写作风格、历史决策、踩过的坑、过期的计划、当前阶段。

谁掌握这份模型,谁就更容易成为你的默认 AI。

模型能力会被追赶,界面会被模仿,工具调用也会越来越标准化。

但一个长期积累的用户模型,很难一夜迁移。

这有点像社交平台的关系链,也有点像推荐系统的用户画像。只是 AI 助手里的用户模型更深,因为它不只是知道你喜欢看什么,还会参与到你怎么写、怎么判断、怎么工作。

这就是为什么我不太愿意把 Dreaming 只看成一次 ChatGPT 体验升级。

它是 OpenAI 在争夺用户长期上下文。

Hy-Memory 这类本地系统,则是在提醒另一件事:长期上下文也可以不完全交给平台。

我会怎么选?

如果只看当下,我会同时用。

ChatGPT Dreaming 负责即时体验。

本地记忆负责长期资产。

前者像某个 App 内部越来越懂你的个性化服务。它好用,省心,适合日常对话。

后者像自己的项目档案、知识库和工作记录。它不一定顺滑,但最好别完全交给某个平台。

更理想的结构可能是这样:

信息类型 更适合放哪里
当前对话和短期任务 平台 / 当前 Agent
某个产品内的使用习惯 平台记忆
项目结构、决策历史、任务状态 用户自己的记忆层
写作风格、长期偏好、稳定约束 用户为主,平台可读取
原始记录、笔记、文件、日志 用户自己保存

也就是说,ChatGPT 可以有自己的 Dreaming。

但用户也应该有自己的 Dreaming。

这句话听起来有点绕,但我觉得它很重要。

平台可以帮我整理一部分记忆,让产品更好用;但那些真正长期影响我工作和判断的东西,最好还能沉淀在我自己的系统里。

对个人知识库的启发

从 Obsidian 的角度看,Dreaming 给我的启发很简单:只记录不整理,迟早会失效。

很多人做知识库,最开始都以为关键是记录更多。

多写日记,多收藏文章,多保存链接,多同步资料。

后来才发现,真正难的是整理。

没有整理,知识库只是更大的仓库。

AI 记忆也是一样。

原始聊天记录越多,不代表记忆越好。真正有用的是整理后的状态:哪些事实还有效,哪些偏好变了,哪些任务结束了,哪些规则应该长期保留,哪些误解应该删除。

所以我觉得个人知识库也需要某种“睡眠流程”。

不一定多复杂。

比如每天留下原始记录,每周把高价值内容提炼成项目记忆,每月检查哪些规则和偏好已经过期。重要决策不要只记结论,也要记当时为什么这么判断。

这其实就是把平台的 Dreaming,变成自己的 Dreaming。

结论:别只问 AI 记不记得你,要问记忆属于谁

ChatGPT Dreaming 是个重要更新。

它会让 ChatGPT 更连续、更贴心,也更像一个真正认识你的助手。

但我不想只夸它。

因为长期记忆不是普通功能。

它会慢慢变成一个关于你的用户模型。这个模型越准确,产品越好用,平台也越有粘性。

所以问题不只是:ChatGPT 能不能记住我?

更应该问:

这份记忆我能不能看见?

能不能改?

能不能删?

能不能迁移?

能不能让别的 AI 在我授权后读取?

Dreaming 和 Hy-Memory 不是谁替代谁。

它们代表了两条都会继续发展的路线:平台记忆负责省心,本地记忆负责掌控。

普通用户会先享受到平台记忆的好处。

重度用户迟早会想要自己的记忆层。

未来真正重要的,可能不是哪个 AI 最会记住你。

而是你能不能拥有自己的记忆,然后决定让哪个 AI 来读。

参考来源

RSS Feed 使用 Hugo 构建
主题 StackJimmy 设计