MemOS用图重塑智能体长程记忆

许多开发者在构建长周期智能体时都会遭遇性能瓶颈：随着交互轮数增加，向量数据库中堆积了大量未清洗的对话切片，导致检索结果充斥着陈旧甚至自相矛盾的信息；一旦用户的技术栈或习惯发生改变，新旧记忆常常互相打架；在面对省略主语的复合问题时，单一的余弦相似度检索也无法还原深层上下文。直接把对话文本切块存进向量数据库，难以构建出具有生命周期的长期记忆系统。开源项目 MemOS 提出了全新的架构路线：将记忆视为操作系统的核心资源，以图数据库 Neo4j 为基础存储，依托聚类粗筛与大模型仲裁的重组调度机制、显式拓扑连边与多路召回，打造能够自主演化与归纳的智能体记忆网络。1 记忆节点是结构化独立实体传统知识图谱在处理通用对话时，强行抽取实体与三元组极易出现关系断裂。MemOS 将图数据库的一级公民定义为记忆节点（Memory Node），每个节点作为一个封装完备的对象，同时集成自然语言事实、高维密集向量以及业务元数据。存储在 Neo4j 中的核心节点统一挂载 Memory 标签：(:Memory { id: "mem-001", memory: "用户主要使用 Python 开发 AI 后端", key: "user_backend_language", tags: ["Python", "AI", "backend"], memory_type: "UserMemory", status: "activated", user_name: "developer_01", confidence: 0.96, created_at: 1711800000, updated_at: 1711800000, embedding: [0.012, -0.043, 0.088, 0.021] })系统依据信息的存活周期与作用域，划分出清晰的记忆分类体系，在数据写入与后续过滤时提供类型隔离：记忆类型职能定义典型存储内容UserMemory用户长期画像与固定技术偏好常用编程语言、技术栈、代码生成风格偏好LongTermMemory跨会话的客观事实与项目经历曾经解决的系统Bug、某个特定模块的设计指标WorkingMemory当前正在执行的活跃工作上下文多步任务执行中的中间推理状态、临时目标PreferenceMemory交互层面的显式与隐式习惯回复详略要求、特定格式要求、语言风格2 会话入库从自然语言到图谱节点当用户输入包含多种意图的长文本时，系统执行原子化拆解、向量化转换与图节点入库三个连续阶段。假设用户在会话中表达：我平时主要用 Python 做 AI 后端，Android 端主要用 Kotlin。以后给我代码示例时优先用 Python。第一阶段，系统调用 MemReader 模块中的抽取大模型执行精细化语义萃取。模型过滤无意义客套，提取独立事实并打上类型标签，生成标准化的 JSON 结构：