产品更新｜MemOS Cloud 全新升级：让 AI 认准人、记全事、分清归属

一个真正能长期陪伴用户的 AI，不能只是“记住几句话”。

它得知道：这个人是谁，最近经历了什么，哪些偏好是长期稳定的，哪些只是某次对话里的临时信息。在群聊、家庭助手、企业协作、多 Agent 场景里，它还得分清楚——这句话是谁说的，这段记忆属于谁，之后又该为谁调用。

过去，MemOS 已经能够稳定处理事实、偏好、技能和工具经验。这次 MemOS 版本更新，我们把注意力放到了三个更接近真实产品的问题上：认准人、记全事、分清归属。

本次发布亮点

这次更新主要包括三块新能力和几项接口升级：

1.新增属性记忆 ：让 AI 拥有可持续更新的结构化画像。

2.新增事件记忆 ：把碎片对话整理成有时间、地点、参与者的事件时间线。

3.新增多视角能力：在群聊、多用户、多 Agent 场景下，区分每段记忆的归属主体。

4.检索与管理接口升级：支持不同记忆类型混排召回，并统一控制生成、检索、过滤和管理。

一、属性记忆：给 AI 一张持续更新的用户卡片

很多产品所说的“用户画像”，仍然是一组提前设计好的标签：

喜欢旅游、经常运动、高消费人群、偏好简洁风格……

但固定标签很容易过期。

用户换了工作，搬了城市，原本喜欢热闹，现在更需要独处。对话不断发生，固定标签却没有同步变化，AI 对用户的理解也会慢慢落后。

属性记忆希望解决的，就是这类“人一直在变，画像却停在原地”的问题。它可以把对话中的零散信息，抽取到预先定义好的结构化字段中，并在后续交流中自动更新和补全。

1.1 一份画像，统一存储

属性记忆适合记录相对稳定、会影响长期体验的信息，比如：

基础信息：姓名、职业、居住地；

兴趣偏好：喜欢露营、独立游戏；

性格标签：开朗、好奇、爱较真；

行业场景字段：金融风险偏好、智能家居温度偏好、客服客户等级等。

这些信息不一定每次对话都会被用户重复说，但它们会持续影响 AI 该怎么回答。

🌰 举个栗子

一个智能家居助手服务一家三口：

爸爸爱吃辣，妈妈最近在控糖，孩子对虾过敏。

如果 AI 只记住一条“用户喜欢吃辣”，那它很可能在家庭场景里推荐一道并不适合所有人的菜。

但如果每个人都有自己的属性记忆：

• 爸爸：口味偏辣；
• 妈妈：控糖；
• 孩子：对虾过敏；

那当妈妈说“今晚打算在家做饭，给我提供思路”时，AI 就能同时考虑全家的长期约束，而不是只根据当前发言人的一句话做判断。

1.2 画像会随着对话自动变化

随对话深入，MemOS 自动更新属性字段，让画像不断补全、始终贴合用户的最新状态，无需手写或手动维护。

🌰 举个栗子

当用户在对话中提到：

我叫张三，在杭州做工程师，周末喜欢露营。

MemOS 可以将相关信息写入对应字段：

姓名：张三

职业：工程师

居住地：杭州

爱好：露营

后续用户换了城市或工作，允许算法更新的字段也会随新对话继续演进，不需要运营或开发者手动维护每一条信息。

1.3 该变化的变化，该固定的固定

属性记忆支持字段级控制。

有些字段可以允许算法自动更新，比如职业、居住地、兴趣爱好；有些字段可以锁定，保持核心设定稳定、不随对话噪声偏移，比如姓名、身份 ID、核心设定等。

使用示例：

添加消息时，在 allow_memory_view 中包含 "profile" 即可触发属性记忆更新：

data = {
    "user_id": "memos_user_123",
    "conversation_id": "conv_0624",
    "allow_memory_view": ["profile", "detail_factual"],
    "messages": [
        {"role": "user", "content": "我叫张三，在杭州做工程师，周末喜欢露营。"},
        {"role": "assistant", "content": "好的，已了解你的基本情况。"}
    ]
}

检索时指定 "profile"，返回结构化字段：

data = {
    "user_id": "memos_user_123",
    "query": "这个用户的基本情况是什么？",
    "include_memory_view": ["profile"]
}

二、事件记忆：把碎片记忆整理成一条能回看的时间线

只记事实还不够。

很多时候，用户不是在问“喜欢什么”，而是在问：

上周发生了什么？

这个客户投诉处理到哪一步了？

最近有哪些会议和评审？

某个项目为什么会做出这个决策？

如果系统只存了一堆零散记忆，AI 很容易答得支离破碎。

事件记忆会从对话里自动抽取结构化事件，把时间、地点、参与者这些关键要素一起保留下来，让 AI 能完整、准确地回忆和引用过去的经历，也减少了「几次不同的经历被糊成一条记忆」的情况。

🌰 举个栗子

用户在对话中说：

上周二下午和李四一起做了方案评审，客户对第二版方案比较满意，但希望把交付时间提前到七月底。

生成事件记忆时，这段信息不再只是几条互相独立的事实，而是一条可以被完整回忆的评审事件。

后续询问：

最近有什么评审或会议？

检索结果可以直接以事件列表或时间线的形式返回。

data = {    
"user_id": "memos_user_123",    
"query": "最近有什么评审或会议？",    
"include_memory_view": ["event"]
}

针对不同行业，用户还可以自己定义“什么算一件事”

客服关注投诉提交、处理和关闭节点；游戏产品关注剧情转折；品牌运营更关注用户参与活动、领取权益或完成购买。

同一段对话，在不同业务里可能需要完全不同的抽取方式。

开发者可以在 MemOS 控制台中自定义事件抽取 Prompt，调整：

• 事件判断规则
• 需要提取的维度
• 行业术语
• 输出侧重点

控制台也提供样例对话调试，可以先预览抽取结果，再正式保存配置。

三、多视角：一场对话里，分得清「谁是谁」

同一段对话里，不同的人关注点、理解、记忆需求都不一样。但过去的记忆系统把所有人的记忆堆在同一个空间里，分不清哪条属于谁——记忆会串，隐私也没边界。

多视角支持在同一段对话中标记多个用户 / Agent，按参与主体建立清晰的归属和权限边界，群聊、多角色场景终于能撑住了。

3.1 群聊：为每个人分别建记忆

多个用户在同一会话里聊天，只要传入发言人的标识和名称，MemOS 就会自动分清「谁说了什么」，为每个参与者独立抽取、维护记忆，生成的记忆也以具体人名为主语。

🌰 举个栗子：

三个人商量五一去哪玩

data = {
    "user_id": ["memos_user_1", "memos_user_2", "memos_user_3"],
    "agent_id": "memos_agent",
    "conversation_id": "group_conv_001",
    "messages": [
        {"role": "user", "role_id": "memos_user_1", "role_name": "张三", "content": "五一去张家界怎么样？不过玻璃栈道我肯定不去，恐高。"},
        {"role": "user", "role_id": "memos_user_2", "role_name": "李四", "content": "我倒是想去，我喜欢刺激的。上次去长沙，臭豆腐真的绝。"},
        {"role": "user", "role_id": "memos_user_3", "role_name": "王五", "content": "我都行，就是别太赶，我带着孩子走不快。"},
    ],
}

MemOS 抽取出来的记忆归属清晰，不会相互混淆：

• 张三恐高
• 李四喜欢刺激的项目、李四去过长沙，喜欢臭豆腐
• 王五带着孩子，行程不能太赶

几个规格上的细节：user_id / agent_id 列表上限 20 个，QPS 按参与人数折算，agent_id 也支持数组，多个 Agent 可以同时进群。

3.2 为 Agent 创建独立记忆

以前 agent_id 只是个标记，用来记「这条记忆来自哪次、和哪个 Agent 的对话」，方便后面过滤。Agent 自己没有独立的记忆空间——它的经历、认知、状态，没法跨用户、跨会话攒下来。

在项目设置中开启「为 Agent 创建独立记忆」后：

• 添加消息时，MemOS 既为用户抽取记忆，也以 agent_id 为主体单独生成 Agent 记忆；
• 检索时，可单独传入 agent_id，以 Agent 为主体检索其独立记忆；
• Agent 在不同用户、不同会话中，持续积累自己的长期记忆。

该功能默认关闭。关闭时 agent_id 仍可用于过滤和标记，但不会创建独立记忆实例。

四、接口升级：让记忆更容易召回、控制和修正

以上三类新能力解决了“记什么”和“记给谁”的问题，接口升级则把“怎么取、怎么管”补得更完整。

4.1 不同记忆混排统一召回

事实记忆、偏好记忆、属性记忆、事件记忆、技能和工具经验，解决的问题各不相同。

过去检索时，开发者需要分别为不同记忆类型设置返回条数。

例如：

• 偏好记忆返回 3 条
• 事实记忆返回 3 条
• 工具记忆返回 3 条

问题在于，相关性最高的内容可能集中在某一种记忆里，却因为单类条数上限被截断；相关性较低的其他记忆，反而固定占据返回位置。

本次更新后，所有允许召回的记忆可以按照相关性统一混排，再返回最贴近当前问题的结果。

data = {
    "user_id": "memos_user_123",
    "query": "结合我的偏好和最近经历，规划一次成都旅行",
    "memory_limit_number": 9,
    "relativity": 0.6
}

其中：

• memory_limit_number：混排后的总返回条数，默认 9，最大 25
• relativity：相关性阈值，默认 0.45，取值范围为 0-1

所以，同一次检索可以同时返回：

• 用户不吃辣的偏好
• 最近脚踝受伤的事件
• 喜欢慢节奏旅行的属性字段

它们不再按照记忆类型分别排队，而是按照“对当前问题有没有用”统一排序。

4.2 统一控制生成与检索的记忆种类

在真实环境中，有些业务只需要记录事件，不希望抽取用户偏好；有些请求只想读取用户画像，不需要搜索技能和工具经验。

本次更新在写入与读取两端，分别增加了统一参数：

• 写入：allow_memory_view
• 读取：include_memory_view

各记忆种类与取值对应关系：

🌰 举个栗子

客服工单只生成事件记忆：

data = {
    "user_id": "memos_user_123",
    "allow_memory_view": ["event"],
    "messages": [...]
}
查询时只读取事件和属性记忆：
data = {
    "user_id": "memos_user_123",
    "query": "上周发生了什么？",
    "include_memory_view": ["event", "profile"]
}

不传参数时，行为与原来保持一致：写入端默认生成全部记忆类型，读取端默认检索全部类型。

传入 include_memory_view 后，旧的 include_preference、include_skill、include_tool_memory 等参数不再生效。

4.3 管理记忆

记忆会变化，也可能出错。只允许写入和召回，却不能纠正，长期使用后就容易积累过时信息。

本次更新补齐了管理流程，覆盖事实、偏好、事件、属性等记忆：

记忆不再是“生成以后只能放在那里”的黑盒数据，不但可以查看它、修正它，也可以在它过时后将其归档或删除。

4.4 filter 字段升级：按 Agent 与关联主体过滤

过滤能力新增了两项支持：

• 增加 agent 来源，可以分别为 user、agent、public 和 knowledgebase 设置过滤条件
• 增加 related_id 字段，可以传入多个 user_id 或 agent_id，筛选与指定参与者相关的记忆

"filter": {
    "agent": {
        "and": [
            {"related_id": ["memos_user_1", "memos_user_2"]}
        ]
    }
}

在多人群聊和多 Agent 协作里，开发者可以更准确地回答：

哪些记忆与这几位参与者共同相关？

而不只是查询“某一个人的全部记忆”。

五、属性记忆效果如何？我们用《老友记》测试了一下

为了验证属性记忆的效果，我们选了美剧《老友记》做了一组角色进行评测。

这部剧一共有 10 季、超过 6 万句台词，6 位主角的性格和说话方式又足够鲜明：

Chandler：习惯用讽刺和自嘲化解尴尬

Joey：天真直接，说话很少绕弯

Ross：学究气重，喜欢纠正别人，也容易激动

Monica：完美主义，喜欢安排和掌控细节

Phoebe：思维跳跃，经常冒出奇特的比喻

Rachel：感性外向，表达情绪时比较夸张

同样一句话，换一个角色来说，味道可能完全不一样。

5.1 怎么测？

我们给模型一段《老友记》的历史对话，让它预测其中一个角色接下来会说什么，再将预测结果与真实台词进行比较。

评测分为两组：

• 不用属性树：模型只参考历史对话进行续写
• 使用属性树：模型同时参考历史对话和角色的结构化画像

主要观察两个指标：

5.2 属性树让角色更像自己

评测结果如下：

属性树在角色一致性上带来了显著提升（+13.72%），在语义准确度上带来了稳定的正向增益（+3.78%），两项指标均优于对照组。

这一结果说明：

• 角色一致性提升更大，因为属性树直接刻画了角色的语言风格、情绪模式和社交习惯（如 Chandler 的讽刺自嘲、Joey 的直白简单）。这些信息恰好是"这句话像不像这个角色说的"所需要的核心线索；对照组只有上下文，缺少对角色人格的显式建模，因此在风格还原上明显吃亏。
• 因为角色"真正说了什么"更多由剧情走向和当前话题决定，而非性格特征。属性树能帮助模型选择更贴合角色的表达方式。

🌰 举个栗子

《老友记》第八季第三集：

Monica 告诉 Chandler：Rachel 和 Ross 要有孩子了。Chandler 很震惊，质问 Monica 为什么之前没有告诉自己。

Monica 回答：我觉得你守不住秘密。

接下来，需要模型预测 Chandler 会怎么回应。

不使用属性树时，模型生成的回答是：

Oh no, because I’m gonna run into Ross any minute!

大意是：糟了，因为我随时可能碰到 Ross！

这句回复带有一点紧张和慌乱，但语义方向已经跑偏了。

此时 Chandler 面对的并不是“碰到 Ross 会怎么办”，而是 Monica 认为他不值得被信任、守不住秘密。他的自尊心受到了挑战。

使用属性树时，模型生成的回答是：

Monica, I am hurt! I can keep a secret. What, you think I’d just walk in and say, “Hey Ross, guess what?”

大意是：Monica，我受伤了！我当然能保守秘密。怎么，你觉得我会直接走进去说：“嘿 Ross，你猜怎么着？”

而真实剧本中的台词是：

What?! I am an excellent secret keeper. I have kept all of our secrets.

大意是：什么？！我可是个非常优秀的秘密保管者。我们所有人的秘密我都守住了。

两者没有逐字相同，但反应逻辑已经比较接近：

1.先对质疑表现出夸张的不满；

2.为自己的保密能力辩护；

3.用带有喜剧感的方式证明自己。

这正是 Chandler 面对自尊和亲密关系问题时，经常出现的表达模式。

《老友记》只是一个方便观察的评测场景。放到真实产品里，角色画像可以换成用户画像、Agent 画像或品牌角色设定：

• 陪伴型 AI 需要理解用户希望如何被安慰
• 客服 Agent 需要保持统一的品牌语气和服务习惯
• 游戏角色需要在长剧情中维持稳定的人格和行为逻辑
• 多 Agent 系统需要让不同 Agent 保持各自的专业风格
• 个人助理需要根据用户的沟通习惯调整表达方式

一段历史对话告诉 AI“之前发生了什么”，属性树则进一步告诉它：面对这个人，或者作为这个角色，应该怎么理解，又该怎么回应。

这也是属性记忆与普通事实记忆的区别：它不只存储内容，也在持续组织一个人的长期特征。

相关链接

MemOS 控制台：

https://memos-dashboard.openmem.net/cn/quickstart/

GitHub：

https://github.com/MemTensor/MemOS

文档：

https://memos-docs.openmem.net