MindMemOS让Agent记忆进化

华为诺亚方舟实验室近日开源了面向AI Agent的记忆操作层MindMemOS，试图解决智能体长期存在的一个工程短板：Agent不仅要记住用户和任务，还要把成功经验沉淀成可以迁移、修订和持续演进的Skill。

MindMemOS是一个独立于具体Agent和大模型的可迁移、自演进记忆操作层。 它将记忆的写入、检索、更新、删除、反馈和离线巩固拆成完整生命周期，并通过MindSchema、Feedback和Dreaming三套机制，让记忆不再只是向量数据库里的一批历史文本。

截至2026年8月3日，项目公开代码已经提供FastAPI HTTP接口、Python SDK、CLI、Skills和OpenClaw插件等接入方式。对开发者而言，这意味着MindMemOS并不要求重写现有Agent，而是希望像数据库或文件系统一样，成为能够被不同框架复用的基础设施。

Agent缺的不是更长上下文，而是可继承的经验

上下文窗口是模型在单次推理中能够直接读取的信息范围。 它可以让模型处理更长的对话和文档，却不等于真正的长期记忆：窗口有容量上限，完整塞入历史会推高推理成本，而换一个Agent、模型或应用后，原始上下文通常也不会自动迁移。

RAG是先从外部知识库检索相关材料，再把结果交给大模型生成答案的技术路径。 它擅长回答“哪份文档提到过这件事”，但不天然理解“这条信息是否仍然有效”“用户后来是否纠正过它”以及“这次执行失败应该怎样改变下一次操作”。

Agent Memory是智能体对用户、环境、任务过程和执行结果进行长期保存与调用的能力。 一个可用的记忆系统至少要解决事实提取、身份归属、时间变化、冲突消解、权限隔离和反馈更新，而不只是把历史对话切块后做相似度搜索。

目前不少Agent产品已经能记住称呼、偏好和常用格式，但其记忆通常依附于单个应用。用户一旦切换Agent框架、模型供应方或业务系统，就要重新解释项目背景，相当于每换一个工具都要重新培训一名员工。

MindMemOS瞄准的正是这种割裂：记忆应该属于用户、团队或任务，而不是永久锁在某个Agent实例里。

MindSchema先规定“什么值得记”

MindSchema是MindMemOS用于描述记忆实体、属性、关系和提取规则的结构化模式。 它的作用类似数据库Schema，但面对的不是固定业务表，而是大模型从自然语言和任务轨迹中抽取出的长期事实。

不同业务对“值得记住”的定义并不相同。个人助手关心用户偏好、日程和关系变化；代码Agent关心仓库结构、编码规范和历史故障；工业运维Agent则更需要设备型号、异常现象、故障原因、处理步骤与最终结果。

固定模板很难同时覆盖这些场景，而完全自由的文本记忆又会迅速失控。MindSchema提供的是中间路线：开发者可以预设提取规则，也可以围绕具体任务和标注问答，在离线阶段演化提取策略。

例如，用户先说“报告默认导出PDF”，几个月后又明确要求“这个项目统一交付可编辑的DOCX”。普通向量检索可能同时召回两条内容，甚至因为旧记录出现次数更多而选错；结构化记忆则可以保留两次变化的时间和适用项目，将新规则标记为当前状态，同时留下旧状态的历史证据。

时间性记忆是能够记录事实何时成立、何时变化以及被什么新事实取代的记忆。 这项能力对企业Agent尤其关键，因为客户状态、审批规则、产品价格和项目负责人都会变化，“曾经正确”与“现在有效”不是一回事。

Feedback让用户纠正不再白白流失

Feedback是从用户显式评价或隐式纠正中提取监督信号，并调整现有记忆可信度的机制。 用户不一定会点击“错误”按钮，但“不是这个客户”“不要再用旧模板”“上次那种处理方式会破坏公式”等表达，本身就是高价值反馈。

MindMemOS的思路不是把每一次纠正都机械追加成新规则，而是判断反馈指向哪条记忆、适用范围是什么，以及原记忆应该被强化、降级还是替换。这样可以降低两个常见风险：错误记忆反复被检索，以及局部例外被误写成全局规则。

以表格Agent为例，系统可能从一次失败中学到“不要破坏公式”，但这条经验不能被粗暴执行成“任何单元格都禁止写值”。更成熟的Skill应该进一步判断公式列、源列、目标列和映射关系，并在信息不完整时主动确认，而不是为了通过缓存值检查，把公式全部替换成硬编码结果。

这种细化说明，反馈的价值不只是增加规则数量，而是建立规则边界。只有知道一条经验何时适用、何时停止，Agent才算从“背答案”转向“积累判断力”。

Dreaming是在离线阶段整理记忆

Dreaming是MindMemOS在非实时路径中对长期记忆进行重组、去重、冲突消解和抽象归纳的过程。 它并不是让模型凭空“做梦”，而是把白天积累的零散交互整理成更稳定的经验资产。

实时写入只能保证信息不丢，却很难保证记忆质量。一个Agent运行数月后，记忆库里往往会出现重复事实、互相冲突的偏好、过期状态和粒度不一致的经验；如果每次检索都把这些原始记录交给模型，召回越多，噪声反而越大。

Dreaming更像数据库维护、日志归档和员工复盘的组合。系统可以将多次相似事件归纳为稳定模式，把互相矛盾的记录按照时间和证据重新排序，并将高频成功路径提升为更容易调用的经验。

离线巩固的代价是需要额外模型推理和存储计算，而且整理过程本身也可能产生错误归纳。因此，企业部署时不能把Dreaming当成不受约束的自动改写器，而应保留原始证据、变更记录、版本回滚和人工审计入口。

更有意思的是Skill也能演进

Skill是Agent完成某类任务时可复用的流程、工具使用规则、约束条件和经验集合。 传统Skill往往是一份人工编写的提示词或工作流文件，发布后基本固定；MindMemOS希望让它变成带版本、带证据、可持续更新的长期能力资产。

记忆与Skill的区别在于，记忆回答“发生过什么”，Skill回答“下次应该怎样做”。如果系统只保存历史事实，Agent仍可能在相同位置重复犯错；如果能从多次执行结果中提炼操作边界，成功经验才会真正改变后续行为。

这也是MindMemOS比普通记忆插件更值得关注的地方。它不只追求“下一次还记得用户喜欢什么”，而是试图把用户纠偏、任务轨迹和执行结果转化为能力更新。

当然，自动演进Skill也比保存用户偏好危险得多。一条错误偏好最多让回答风格不合适，一条错误操作规则却可能导致批量发信、修改生产数据或执行错误脚本。因此，Skill晋级需要证据门槛、作用域控制、风险分级、版本审核和回滚机制，不能只看单次成功或单个用户反馈。

LoCoMo达到94.03，但跑分不能代表生产可靠性

LoCoMo是用于评估超长、多会话对话记忆能力的基准，包含10组长期对话数据。 在项目公开的对齐测试中，回答模型采用GPT-4.1 mini，系统、检索、回答和评判配置与EverOS默认实现保持一致。

MindMemOS-Modeling在LoCoMo上的Overall Accuracy达到94.03，公开对比中的EverOS成绩为92.73，前者高出1.30个百分点，按92.73为基数计算相对提升约1.40%。

PersonaMem是用于评估长期用户画像、偏好记忆和个性化推断的基准。 MindMemOS-MindSchema在该测试上的Overall Accuracy为70.63%，MindMemOS-MindVanilla为67.74%，两种配置相差2.89个百分点。

| 测试或方案 | 配置 | Overall Accuracy | 说明 | |---|---:|---:|---| | LoCoMo | MindMemOS-Modeling | 94.03 | 项目公开结果中的最高成绩 | | LoCoMo | EverOS | 92.73 | 对比成绩，低1.30个百分点 | | PersonaMem | MindMemOS-MindSchema | 70.63% | 使用结构化记忆模式 | | PersonaMem | MindMemOS-MindVanilla | 67.74% | 基础记忆配置 |

这些数字证明结构化建模并非只让数据“看起来更整齐”。在相同回答模型和对齐配置下，合理组织时间、实体与关系，确实可以提高长期事实召回和个性化推断的准确性。

不过，LoCoMo只有10组超长对话，仍不足以覆盖企业生产环境中的脏数据、权限变化、恶意输入和跨系统身份冲突。记忆系统的真实质量还要看误写率、过期事实淘汰率、召回延迟、存储成本、删除合规性以及错误Skill造成的任务损失。

MindMemOS与上下文、RAG和普通记忆插件的差别

MindMemOS的核心定位不是替代上下文窗口或RAG，而是为它们增加长期状态与演进机制。 上下文仍负责当前任务，RAG仍负责查找外部资料，记忆操作层则决定哪些经历应长期保存、何时更新，以及如何转化为下一次任务可调用的经验。

| 方案 | 主要保存对象 | 是否跨会话 | 是否处理时间变化 | 是否利用反馈演进 | 是否支持Skill演进 | 成本形态 | |---|---|---|---|---|---|---| | 长上下文 | 当前输入与近期历史 | 有限 | 弱 | 通常不支持 | 不支持 | token越多，推理成本通常越高 | | 传统RAG | 文档与知识片段 | 支持 | 依赖外部设计 | 通常不支持 | 不支持 | 向量库、检索与重排成本 | | 普通记忆插件 | 用户偏好、历史摘要 | 支持 | 部分支持 | 多为覆盖或追加 | 通常不支持 | 存储与摘要模型成本 | | MindMemOS | 事实、关系、反馈、任务经验 | 支持 | 支持时间与冲突建模 | 支持Feedback与Dreaming | 支持持续演进 | 开源自部署，成本取决于模型、数据库与运维 |

这张表也说明，MindMemOS不是“装上就让Agent变聪明”的魔法组件。它更像给Agent增加一套可编程的长期记忆文件系统，最终效果仍取决于Schema设计、检索策略、底层模型和业务反馈质量。

独立操作层比单项跑分更重要

架构解耦是MindMemOS此次开源最有实际价值的部分。 项目将Agent接入层、记忆算法层和记忆结构层拆开，并覆盖add、search、update、delete、feedback与dreaming等生命周期操作。

这种设计允许同一套记忆服务被多个Agent调用。客服Agent可以读取客户历史，分析Agent可以继承项目背景，执行Agent则只获得经过授权的任务约束；当团队更换模型或Agent框架时，已有记忆不必一起作废。

可迁移并不意味着所有记忆都应该共享。企业内部至少需要按用户、部门、项目、Agent角色和数据敏感级别设置命名空间及访问控制，否则“跨Agent复用”很容易退化成跨边界泄露。

删除能力也不能只做到数据库中少一条记录。系统还要处理向量索引、摘要结果、Dreaming生成的衍生记忆、Skill版本及审计备份之间的依赖，否则用户删除了原始事实，Agent仍可能从归纳结果中继续推断出来。

判断：方向对了，真正难点在治理而非召回

MindMemOS把Agent记忆从应用功能提升成了独立基础设施。 这是一个正确方向，因为模型可以更换、Agent框架也会迭代，但用户偏好、组织知识和任务经验应该成为可持续积累的数据资产。

它最值得肯定的地方不是94.03的LoCoMo成绩，而是把Schema、反馈、离线巩固和Skill版本放进同一个闭环。单纯提高召回率只能让Agent“记得更多”，而这套闭环试图让Agent知道哪些记忆可信、哪些已经过期，以及经验应该如何改变行为。

它最大的风险同样来自自演进。记忆一旦写错，会在未来多次影响回答；Skill一旦演进错误，则可能稳定地重复错误动作。对生产系统来说，记忆置信度、来源证据、权限边界、变更审批和回滚能力，最终会比单个基准的准确率更重要。

MindMemOS目前更适合有明确长期任务、重复流程和反馈闭环的场景，例如企业客服、软件工程、工业运维、研究助手和多Agent协作。对于一次性问答或低频工具，额外维护长期记忆层未必划算，甚至可能引入不必要的隐私和运维成本。

Agent行业过去两年主要在竞争模型能力、工具调用和任务编排，下一阶段的差异可能转向谁能积累更可靠的经验。模型决定Agent的即时智力，记忆与Skill演进则决定它能否在半年后比今天更懂用户、更少犯错。

参考来源

• MindMemOS项目仓库：华为诺亚方舟实验室公开的项目代码、架构说明、接入方式与评测信息。
• 华为诺亚方舟实验室GitHub主页：实验室开源项目与后续版本更新入口。