MemOS记忆图谱实战：从零构建LangChain智能体的长期记忆系统（含完整代码）

文章详细介绍了MemOS开源框架的Graph记忆图谱能力及其在LangChain智能体中的应用。首先通过TreeTextMemory实现基于图结构的记忆存储与检索，构建带记忆的ChatBot；其次介绍了异步记忆重组机制，自动将孤立记忆节点组织成知识图谱；最后展示了如何借助LangChain的Middleware机制将MemOS无缝集成到Agent中，实现非侵入式的长期记忆增强，使AI智能体具备知识积累和上下文关联能力。

MemOS 是一款具有独特设计理念的智能体记忆（Memory）开源项目。我们在前一篇（[上篇回顾]）中深入解读了 MemOS 的核心架构与相关设计，本篇我们聚焦 MemOS 的开源框架，深入体验其基于 Graph 的记忆“图谱”能力，以及如何把它集成到基于 LangChain1.x 框架构建的智能体。

现在让我们一起走进 MemOS 的开源框架。

快速开始：基于记忆“图谱”的ChatBot
更进一步：体验记忆“图谱”的自动重组
将 MemOS 记忆图谱集成到 LangChain 智能体

本文探讨的在LangChain1.x Agent中集成外部Memory产品的方法是通用的。

PART 01

快速开始：基于记忆“图谱”的 ChatBot

明文记忆是 MemOS 的“记忆立方体”（MemCube）中最核心的记忆形态。在物理组织上，它支持两种方式：基于向量的“扁平化”记忆，以及基于 Graph 的“树形”记忆（TreeTextMemory）。

TreeTextMemory 本质上是一种带分层结构的记忆“图谱”：它以结构化的方式抽取、关联与检索记忆，同时又兼容传统向量记忆（每个 Graph 节点仍然支持语义检索）。更重要的是，它还能用图结构捕捉记忆之间的层级与关联关系：

我们首先构建一个基于TreeTextMemory的带记忆能力的经典 ChatBot ：

记忆框架：MemOS 开源框架
大模型/嵌入模型：使用公有云模型 API（可自行选择）
开发框架：由于是简单的ChatBot，可以不使用任何框架
图数据库：使用 Neo4j Desktop

核心流程如下：

其中关键的步骤是添加记忆、检索记忆与构建 Prompt 并生成结果。

初始化MemCube

与使用 Cloud API 不一样，直接使用框架有更大的自由度。在框架里记忆体（Cube）是记忆的容器，所以第一步需要初始化一个 Cube 实例，大致如下：

...EXAMPLE_CUBE_ID = "example_cube_id"components = init_server() # 初始化组件cube = SingleCubeView( cube_id=EXAMPLE_CUBE_ID, naive_mem_cube=components["naive_mem_cube"], mem_reader=components["mem_reader"], mem_scheduler=components["mem_scheduler"], logger=logger, searcher=components["searcher"],)

注意这里所有的初始化配置在.env文件中，包括LLM、嵌入模型、图数据库等，具体可以参考开源项目的docker/.env.example文件。

添加记忆

为了在业务层实现记忆隔离，后续所有记忆操作都会针对传入的cube_id，从而避免记忆“污染”。另外MemOS通过操作时的user_id、readable_cube_ids、writable_cube_ids实现更复杂的记忆权限管理与交互逻辑。

可以直接通过记忆体实例进行添加操作：

EXAMPLE_USER_ID = "example_user_id"writable_cube_ids = [EXAMPLE_CUBE_ID]conversation = [ {"role": "user", "content": "我叫张明，在北京做程序员"}, {"role": "assistant", "content": "你好张明！程序员是个不错的职业"},]add_req = APIADDRequest( user_id=EXAMPLE_USER_ID, # 待添加的用户id messages=conversation, # 待添加为记忆的对话 writable_cube_ids # 可写入的cube_id列表)cube.add_memories(add_req)

上面我们模拟了一个对话历史(conversation），然后通过cube添加到记忆库。

【问题：如何增量添加记忆】

在一个多轮对话的应用里，添加记忆有个现实的问题：不能每次都把完整历史对话交给 MemOS 提取 — 既浪费性能，也可能产生重复记忆。一种做法是每次只添加本轮对话；但更灵活的方式是追踪“已记忆的消息位置”：

简单说就是：

每次写入记忆时，用一个“指针”记录已经“记住”的对话位置；下一次写入时，只截取从指针之后的新增对话，用来生成增量记忆。这样你甚至不必每轮都触发“记忆”动作，比如每 2 轮一次、甚至更多轮一次都可以：

避免频繁调用记忆 API ，提升性能
能让记忆时上下文更丰富，更容易抽取到有价值的记忆

检索记忆

借助 cube 的search_memories方法，可以很方便检索出与输入相关的记忆：

# 检索与查询相关的记忆query="用户是做什么工作的？"results = cube.search_memories( APISearchRequest( user_id=EXAMPLE_USER_ID, readable_cube_ids=[EXAMPLE_CUBE_ID], # 可检索的cube id列表 query=query, ))for mem_item in results["text_mem"][0]["memories"]: print(f"- {mem_item.get('memory', '')}")# 输出: - 用户职业相关的记忆

将记忆“注入”Prompt

有了记忆后，你需要把记忆注入到上下文中“喂”给 LLM。MemOS 官方文档提供了推荐的 Prompt 模板，可以直接复用。集成后大致如下：

...# 检索记忆memories = [f"- {m.memory}"for m in results["text_mem"][0]["memories"]]# 构建 System Promptsystem_prompt = f"""你是一个拥有长期记忆的助手。....以下是关于用户的记忆信息：<memories>{chr(10).join(memories)}</memories>.....其他记忆使用说明......请结合记忆信息为用户提供个性化回答。"""# 使用上面的system_prompt 调用 LangChain.....

完成以上步骤后，我们就实现了一个简单的“带记忆”的ChatBot。它与无状态 LLM 对话的区别在于：可以跨用户、跨会话保留用户相关记忆，从而提供更个性化的体验。

效果测试

为方便观察，我们构建一个可交互的命令行程序，支持连续对话，也支持以 “/” 开头的管理命令（如清空记忆等）。不设置初始记忆，直接开始对话：

👤 [You] 我喜欢足球和网球,你觉得如何?🤖 [Assistant] 足球和网球都是很精彩的运动！...👤 [You] 你觉得梅西和C罗谁更强一些?🤖 [Assistant] 梅西和C罗都是足球历史上最伟大的球员，...👤 [You] 我还是偏向技术型球员,C罗很厉害,但我更喜欢梅西.今年世界杯哪天开始🤖 [Assistant] 2026年世界杯将于6月8日开始，并将在美国...👤 [You] 必须继续支持阿根廷啊🤖 [Assistant] 支持阿根廷是个不错的选择！...👤 [You] 可惜工作太忙了,不能看所有比赛.我是一名AI应用架构师🤖 [Assistant] 作为一名AI应用架构师，...

现在，打印出已经生成的记忆，可以清晰的看到提取的记忆内容：

👤 [You] /memory user📚 [UserMemory] 共 5 条记忆:[1][UserMemory] 用户是一名AI应用架构师，工作繁忙，无法观看所有比赛。...[2][UserMemory] 用户在2026年1月16日下午5:22确认他将继续支持阿根廷国家队参加2026年世界杯。...[3][UserMemory] 用户在2026年1月16日下午5:22表示，他偏向技术型球员，虽然认为C罗很厉害，但更喜欢梅西。...[4][UserMemory] 用户对梅西和C罗的强弱进行了讨论，询问助手对这两位球员的看法。...[5][UserMemory] 用户喜欢足球和网球，并对这两项运动的特点表示了兴趣。...👤 [You] /memory long📚 [LongTermMemory] 共 2 条记忆:[1][LongTermMemory] 助手建议用户关注阿根廷的关键比赛或高峰时段的精彩时刻，并提到可以利用时间观看重播或精彩集锦，以保持对比赛的了解。...[2][LongTermMemory]2026年世界杯将于2026年6月8日开始，并将在美国、加拿大和墨西哥举行。...

然后退出本次会话，开启一个新的会话：

👤 [You] 帮我推荐一款工作使用的笔记本电脑,我喜欢苹果公司的产品🤖 [Assistant] 推荐你考虑苹果的MacBook Pro。它拥有强大的性能，适合需要运行AI应用的任务，且其Retina显示屏非常适合长时间工作。此外，macOS系统在开发和设计方面也非常友好。如果预算允许，选择M1或M2芯片的型号会更具性价比和效率。

很显然，这里 AI 的回答充分参考了上下文中的记忆信息：用户是一名 AI 应用架构师，因此推荐了更偏高性能的产品。同时新会话又生成了新的“增量”记忆：

👤 [You] /memory user📚 [UserMemory] 共 6 条记忆: [1][UserMemory] 用户在2026年1月16日下午5:49表示喜欢苹果公司的产品。.......

PART 02

更进一步：体验记忆“图谱”的自动重组

现在，MemOS 会对输入的对话记录进行结构化抽取，生成嵌入向量，并将记忆存入 Neo4j 图数据库。记忆条目在图数据库中以节点（Nodes）形式存储并用于检索，但在默认情况下，它还不太像“图”：

记忆条目仍是一个个“孤岛”；检索仍以向量相似度匹配为主；也无法进行图遍历或关联推理。

如果你打开Neo4j观察，可以看到这样的Graph：

那为什么不在每次添加记忆时自动建立关联？原因很现实：延迟与体验 — 若每次写入都同步触发 LLM 做必要的关联分析并等待完成，对话响应时间会明显变长；尤其当记忆条目越来越多时，性能可能急剧下降。

因此 MemOS 采用异步后台记忆重组，把“添加”与“重组”解耦，其大致逻辑如图：

记忆重组器（Reorganizer）是MemOS的后台模块，负责在后台完成新增记忆的冲突检测与冗余处理、以及将孤立的记忆节点“编织”成更有意义的知识图谱。比如聚类相关记忆、生成摘要节点形成层级结构、并通过边把节点连接成图等。

这种方式的好处是：

用户无感知（前端对话响应不被拖慢）
批量处理（攒一批再分析，减少 LLM 调用）
可以智能调度（比如系统空闲时再做重组，降低资源竞争）。

现在让我们来启用异步的记忆“重组”。

启用记忆重组

启用树形记忆的重组，只需要设置一个参数，在.env文件中将MOS_ENABLE_REORGANIZE设置为true即可。

启用后，系统会启动后台线程进行上述的重组过程。注意，整体结构的优化与层次关系生成需要图节点数量达到一定阈值才会触发（默认 20 个）。

效果测试

为了测试记忆重组的效果，我们批量添加一批记忆(以满足数量条件）：

然后观察 Graph 的变化，可以明显的看到变化 — 开始出现层次与关联关系：

重组器在分析记忆节点后，会自动创建多种“边”关系。最常见的是 PARENT（父子关系）：它会将一组语义靠近的记忆节点聚类，再生成一个摘要节点作为“父节点”，用 PARENT 关系链接到子记忆条目。比如“用户偏好”的父节点下面，可能有“运动偏好”“饮食偏好”等多个子节点。

此外，在记忆冲突处理时可能产生 MERGE_TO（合并）关系；具有时间顺序的节点之间还可能产生 FOLLOWS 等。这些关系使得检索可以超越普通向量相似度，通过图遍历与多跳关联，得到更丰富、更成体系的上下文。

PART 03

将 MemOS 集成到 LangChain 智能体

真实项目中的应用通常不会止步于简单 ChatBot。尤其进入 Agent 时代，我们往往会借助低代码 Agent 开发平台，或者更底层的开源框架做工程化开发。接下来我们介绍如何把 MemOS 的记忆图谱能力带入 LangChain（1.x版本) 构建的智能体中，替代其默认的 MemoryStore 的长期记忆机制。

LangChain 记忆机制的不足

LangChain 内置了基础的记忆机制，最常用的是InMemorySaver（用于会话状态）和InMemoryStore（用于持久化存储）。

.....store = InMemoryStore()agent = create_agent( model="gpt-4o", checkpointer=checkpointer, # 会话状态 store=store, # 长期存储)

但是在企业级应用中，内置的 MemoryStore 很多时候并不够用：

以 key-value 的形式做持久存储，无法表达记忆关联关系
推理依赖精确匹配或者简单的向量相似，无法做复杂推理
不支持 Graph 中的各种层级、因果、时序关联等记忆结构
无法自动在对话过程中根据上下文提取结构化记忆

因此，我们更需要一个真正“可组织、可推理、可演进”的企业级记忆系统。

借助 LangChain 的 Middleware 集成MemOS

LangChain 1.x的 Middleware 机制允许开发者在 Agent 执行的各个阶段注入自定义逻辑，而无需修改 Agent 本身的代码：

我们可以利用Middleware 来“注入”基于MemOS的长期记忆能力：

before_agent：在Agent开始时检索本次任务相关记忆
wrap_model_call：在模型调用前将已经检索的记忆并注入 Prompt
after_agent：在任务结束后把本次对话记忆存入记忆系统

这种方式下，整体是非侵入式的 — 无需修改 Agent 核心逻辑，只需构建一个Middleware，并通过 create_agent 方法的 middleware 参数添加即可。

整体流程如下：

下面简单介绍实现步骤（详情请参考源代码）：

【STEP1: 创建一个 MemOS 记忆助手】

这个助手类简单封装 MemOS 的初始化操作，负责与 Neo4j 图数据库交互，提供记忆增删改查能力：

# memos_memory_helper.py classMemosMemoryHelper: def__init__(self, user_id: str, top_k: int = 5): ...... self._init_memos() # 初始化 Memory 和 MemCube defsearch_memories(self, query: str) -> List[str]: """检索与查询相关的记忆""" ..... defadd_conversation(self, user_message: str, assistant_message: str): """将对话添加到记忆库（增量式）""" .....

【STEP2: 实现 MemOSMiddleware】

实现一个 LangChain Agent 使用的 Milddleware。这是核心的组件：

...class MemosMiddleware(AgentMiddleware): def __init__(self, user_id: str, top_k: int = 5, auto_memorize: bool = True): self.memory_helper = MemosMemoryHelper(user_id, top_k) ..... def before_agent(self, state: AgentState, runtime: Runtime): """Agent 开始前：检索记忆（只执行一次）""" ...... def wrap_model_call(self, request: ModelRequest, handler) -> ModelResponse: """包裹模型调用：注入已检索的记忆到 Prompt""" ..... def after_agent(self, state: AgentState, runtime: Runtime): """Agent 完成后：存储对话到记忆库""" ......

这里核心的 hook 方法就是before_agent, wrap_model_call 和 after_agent，分别在其中完成：检索记忆、注入System Prompt、保存记忆。这其中有一些细节处理（比如把LangChain的消息格式转化为MemOS需要的消息格式、如何提取Tools消息记忆等），可以参考源代码。

* 是否可以在wrap_model_call中检索记忆？

可以。但由于一次Agent任务中会多次调用模型，这样会导致每次模型调用都会检索记忆；除非你需要每次基于新的上下文重新检索记忆。

* 是否可以在before_agent中注入System Prompt？

不可以。在before_agent这个钩子中暂无法访问到System Prompt。

【STEP3：将 MemOS 集成到 create_agent】

完成中间件后，构建一个实例，并通过middleware参数传给Agent即可：

# 创建 Agent —— 只需添加 middleware 参数agent = create_agent( model="gpt-4o-mini", tools=[tavily_search], system_prompt="你是一个拥有长期记忆的智能助手...", middleware=[memos_middleware] # 🔑 注入记忆中间件)

【STEP4：效果测试】

用一个简单的搜索任务开始：

可以看到未检索到历史记忆，但是在对话结束了添加了新的记忆：

如果退出会话，再次询问相关问题：

可以发现：此时Agent会检索到相关的记忆，且会智能判断是否可以利用这些记忆，这里没有再次调用搜索工具 — 这是对之前工具结果产生记忆的效果。

Agent还可以利用记忆更智能的完成任务。比如：

在这次对话中，Agent由于“回忆”到你“喜欢动画片，还关注疯狂动物城”，所以自动搜索类似的动画片来进行推荐 — 这体验了记忆对客户体验的价值。

探讨：另一种集成方法

Middleware 的集成方式更偏“系统级” — 每次对话自动检索记忆、注入 System Prompt，对话结束后也自动存储。实际上还可以有另一种方式：借助 Agent 的工具能力，让它自己决定何时“记忆”与“回忆”。

做法是把 Memos 记忆操作（添加与检索）封装成工具交给 Agent，由 Agent 自主决定调用。它的控制权在 Agent — 由其 “按需调用”，也更容易在日志中看到“为什么它去查了记忆”；不足是更依赖模型的工具推理能力，小模型可能会遗漏调用或传错参数，而且也更需要更精心的 Prompt 设计。比如：

重要行为准则：1. **主动记忆**：如果用户提供了新的个人信息（如名字、喜好、居住地等），请务必调用 `add_memory` 工具记录。2. **主动回忆**：如果用户的问题依赖于上下文（如“我上次说想去哪里？”），请务必先调用 `search_memory` 工具。3. **透明度**：在利用记忆回答时，可以委婉地表示你记得这些信息。

与 Middleware 对比：Middleware 模式更适合“总是需要记忆”的场景，比如个人随身 AI 助理；Tool 模式更适合“按需记忆”的场景，比如复杂多步骤任务。

这是一个设想的流程：

具体的实现留给大家去尝试。

PART 04

总结

上文我们体验了MemOS基于Graph的记忆“图谱”生成与检索能力，并探讨了如何借助 LangChain 1.x 的 Middleware 机制，将其无缝集成到LangChain框架中，从而赋予create_agent构建的智能体更强大的记忆能力。其特点是：