今天这一篇我们把视角切换到工程实现。选了四款在业界影响力最大的记忆产品**ChatGPT MemoryDreaming**代表闭源端到端系统Mem0、Zep、LangMem代表开源与开放生态的三个方向——轻量记忆层、企业级图谱引擎、框架原生集成。01 · CHATGPT MEMORYDreaming — 对话即记忆零配置的端到端系统OpenAI · 2024 Saved Memories · 2025 引入 Dreaming · 闭源商业产品产品基本信息Dreaming 是 OpenAI 深度集成在 ChatGPT 产品内的记忆机制。更准确地说ChatGPT 记忆最早是 2024 年的 Saved Memories用户可以显式要求 ChatGPT 记住某些偏好到 2025 年OpenAI 引入 Dreaming让系统能够在后台参考历史对话自动整理更自然、更连续的用户上下文。可以把 Dreaming 理解成一种后台记忆巩固机制它不像早期 Saved Memories 那样完全依赖用户显式说「请记住」而是从多轮对话中综合提炼用户状态、长期偏好和正在推进的任务。OpenAI 后续又在此基础上继续强化记忆架构让它从补充能力逐渐变成 ChatGPT 个性化体验的核心部分。核心机制Dreaming 是闭源系统OpenAI 并未公开完整实现细节。以下是基于官方公开信息和产品行为的推测性拆解帮助理解它大致的记忆流程异步写入触发对话结束后后台任务对本轮对话进行语义分析识别值得记住的信息——用户偏好、明确表达的需求、个人背景等而非逐字存储整段对话。自然语言摘要 结构化标签记忆以自然语言形式存储如「用户更喜欢简洁的回答风格」同时附加结构化元信息——时间戳、来源对话 ID、置信度方便后续检索与过期处理。语义检索 规则过滤新对话开始时系统根据当前上下文自动检索最相关的记忆片段将其注入 System Prompt使模型在回答前就已「知道」用户的历史偏好。用户可见性与隐私控制用户可以在设置中查看所有记忆、手动删除单条或全部也可完全关闭记忆功能。透明度是 Dreaming 设计的重要原则之一。应用示例用户在第一次对话中提到自己是一名后端工程师习惯用 Python不喜欢冗长的解释。几天后开启新会话ChatGPT 在没有重新介绍的情况下直接给出简洁的 Python 代码示例**用户**帮我写一个读取 CSV 文件并按某列排序的函数。ChatGPT基于已记住的背景Python 后端工程师偏好简洁import pandas as pddef sort_csv(path, col): return pd.read_csv(path).sort_values(col)没有重新询问技术栈没有多余解释直接给出符合偏好的答案。优缺点优点零配置开箱即用无需任何开发工作记忆质量高依托 OpenAI 端到端模型与产品系统能力隐私控制直观用户全程可见可管理与 ChatGPT 产品体验无缝融合缺点完全黑盒无法定制记忆结构或召回策略不可二次开发无法集成到自有系统中企业和团队场景下的记忆边界、数据治理仍需要额外关注记忆容量上限和遗忘策略对用户不透明02 · MEM0Mem0 — 面向 AI Agent 的长期记忆层前身 EmbedChain · 开源 Apache 2.0 托管云服务 · Python / TypeScript SDK产品基本信息Mem0 的核心设计理念是记忆不应该被耦合在某一个 LLM 应用里它应该是一个独立的基础设施层任何 Agent、任何 LLM 框架都可以接入。这与 Dreaming 的「内嵌式」思路形成了鲜明对比——Mem0 更像是一个可插拔的「记忆数据库服务」。在技术选型上Mem0 支持多种向量数据库Qdrant、Pinecone、Chroma 等。图记忆最早通过外接图数据库如 Neo4j需在配置里设置versionv1.1实现而在较新的版本中Mem0 已经移除了对外部图库的依赖改为内置图记忆——直接在向量库里维护实体关联无需再额外部署图数据库。核心机制Mem0 的 API 设计非常克制真正高频使用的核心函数基本就是两个add和search。前者负责把对话加工成记忆后者负责在下一次推理前把相关记忆找回来。核心函数 01 · add调用方式mem.add(messages, user_idUSER_ID)作用从对话中提取事实性陈述与已有记忆做语义对比和合并再向量化写入向量库同时提取实体维护记忆之间的关联关系新版本内置无需额外部署图库。核心函数 02 · search调用方式mem.search(query, user_idUSER_ID)作用根据当前问题做语义检索并按user_id、agent_id、run_id等作用域过滤返回最相关的记忆片段注入下一次 LLM 上下文。三层记忆模型**用户级记忆**跨 Agent 共享的个人偏好。**会话级记忆**当前任务或当前上下文摘要。**Agent 级记忆**特定 Agent 的专有知识和行为习惯。add 解决的是「什么会被记住」它不只是把原始对话塞进数据库而是会做事实抽取、去重、冲突合并和结构化存储。search 解决的是「什么时候想起来」它根据当前 query 去找相关记忆并通过用户、Agent、会话等作用域控制召回范围。对 Agent 来说真正影响回答质量的往往不是记了多少而是 search 能不能把正确的几条记忆放回上下文。前面提到的图记忆本质上就是把记忆之间的关系显式化像「用户 → 使用 → Python」「用户 → 在 → 北京」这样的三元组连起来后Agent 就能做多跳推理而不只是找到一条条孤立的相似片段。这和上篇论文里讲的 A-MEM 思路非常一致。应用场景多 Agent 共享记忆不同 Agent 读写同一个用户的记忆池实现跨 Agent 上下文一致性。客服 / 销售机器人积累用户画像、历史问题、购买偏好实现千人千面的服务体验。健康 / 运动助手记住用户的训练历史、饮食偏好、伤病情况长期跟进用户状态。跨平台记忆同步通过托管云服务 API打通 Web、App、桌面端的记忆数据。应用示例用 Mem0 为对话机器人添加跨会话记忆核心调用其实就是两步写入用add检索用search。下面是一个简化示意from mem0 import Memoryfrom openai import OpenAImem Memory()client OpenAI()USER_ID “alice”第一轮对话写入记忆messages [{“role”: “user”, “content”: “我是一名 Python 后端工程师偏好简洁风格。”}]mem.add(messages, user_idUSER_ID) # 自动提取事实存入记忆库第二轮对话新会话检索记忆注入上下文query “帮我写一个排序函数”memories mem.search(query, user_idUSER_ID, limit3)system_prompt “用户背景信息\n” “\n”.join([m[“memory”] for m in memories[“results”]])response client.chat.completions.create(model“gpt-4o”,messages[{“role”: “system”, “content”: system_prompt},{“role”: “user”, “content”: query}])print(response.choices[0].message.content)对于运动健康类助手场景一个更具体的例子是AI 健身教练记住用户「右膝有旧伤深蹲需要减重」三个月后用户来问新的训练计划教练自动规避了深蹲动作不需要用户再次说明。优缺点优点开源可自托管搭配本地模型或合规模型服务时数据边界更可控API 设计简洁接入成本极低Python / TypeScript 均有 SDK支持多种 LLM 和向量库后端灵活可替换图记忆能力突出支持多跳关联推理缺点自托管仍需自行管理向量库等基础设施并承担相应运维成本记忆提取质量强依赖底层 LLM低质量模型提取效果差记忆写入涉及 LLM 抽取与合并开启异步模式时新记忆不会立即可检索长期积累下记忆条数可能失控遗忘与更新策略相对简单03 · ZEPZep — 面向生产环境的记忆与知识图谱引擎Zep Cloud / Enterprise · Graphiti 开源时序知识图谱引擎 · Agent Memory产品基本信息Zep 从诞生之初就明确面向生产环境而非研究原型。更准确地说今天的 Zep 可以理解为企业级 Agent Memory / Context Infrastructure而 Graphiti 是它背后的开源时序知识图谱引擎。它的设计思路是记忆系统需要像正式的数据库服务一样可靠、可扩展、可审计。需要注意的是早期可以本地自托管的 Zep 社区版Community Edition已于 2025 年 4 月停止维护。现在完整的 Zep 只以 Zep Cloud 托管形式提供企业客户可通过 BYOC 部署在自己的云中如果你想完全自托管路线是直接使用开源的 Graphiti 库再自行准备图数据库和 LLM 服务。与 Mem0 相比Zep 在稳定性、治理和企业级上下文管理上投入更多而它最突出的能力之一是时序感知Temporal Awareness通过 Graphiti 这类时序图谱结构系统可以区分「用户现在喜欢 Python」和「用户三年前喜欢 Java」这类随时间变化的偏好。这在客服、医疗、金融等对信息时效性有严格要求的场景中至关重要。核心机制对话历史压缩与摘要自动对长对话进行滚动摘要将旧消息压缩为结构化摘要大幅降低注入 context 的 token 消耗同时保留语义完整性。实体提取与知识图谱构建自动从对话中识别人物、地点、事件、产品等实体构建结构化的实体关系图支持跨会话的关联查询。时序记忆核心差异化所有记忆都带有精确时间戳支持有效期与状态变更追踪避免过期信息污染当前对话。例如用户已换工作但旧职业信息不会继续被引用。图结构驱动的关系存储底层 Graphiti 以时序知识图谱形式持久化实体与关系支持多跳图查询能回答「用户接触过哪些相关产品」等复杂问题。自托管 Graphiti 时可选 Neo4j、FalkorDB、Kuzu 等图数据库作为后端。应用场景企业客户服务CRM 与 AI 对话深度融合客服 Agent 掌握完整的客户历史与关系图谱。医疗健康对话追踪患者病史、用药记录、就诊经过时序感知保证信息时效准确。金融投资顾问记录客户风险偏好变化、持仓历史区分「过去的」和「当前的」决策背景。教育辅导平台长期追踪学生知识掌握程度的变化精准识别薄弱点与进步轨迹。应用示例下面直接放 Zep 官方 Python SDK 的核心写法用thread.add_messages写入对话再用thread.get_user_context获取可注入 Prompt 的 Context Block。from zep_cloud.client import Zepfrom zep_cloud.types import Messagefrom datetime import datetime, timezoneAPI_KEY “YOUR_API_KEY”thread_id “thread_id”zep_client Zep(api_keyAPI_KEY,)Add incoming user messages to Zepmessages [Message(created_atdatetime.now(timezone.utc).isoformat(),name“Jane Smith”,role“user”,content“Who was Octavia Butler?”,)]response zep_client.thread.add_messages(thread_idthread_id, messagesmessages)Get context for the threaduser_context zep_client.thread.get_user_context(thread_idthread_id)Access the context block (for use in prompts)context_block user_context.contextprint(context_block)时序感知的实际效果举例用户去年提到「对股票比较保守不想碰高风险产品」今年突然问「我想了解一下可转债」Zep 会把这两条记忆一起召回并标注各自的时间让模型意识到用户的偏好可能正在发生变化而不是直接用旧偏好否定新需求。优缺点优点时序感知是 Zep / Graphiti 最突出的差异化能力之一尤其适合事实随时间变化的业务场景生产级稳定性有大量企业用户验证提供独立官方 SDK不绑定特定框架同时也有 LangChain / LlamaIndex 等集成企业客户可通过 BYOC 部署在自有云中满足合规与数据驻留要求缺点完整的 Zep 只提供云服务普通开发者无法像早期社区版那样本地自托管若要完全自托管只能用底层 Graphiti需要自行运维图数据库和 LLM 服务成本较高学习曲线相对陡概念thread / 图谱 / 时序较多轻量场景下显得「过于重型」作为托管服务数据需要交给 Zep Cloud对数据主权敏感的团队需评估 BYOC 或替代方案04 · LANGMEMLangMem — LangChain 官方记忆框架LangChain 官方 SDK · 原生集成 LangGraph Store · 开源产品基本信息LangMem 是 LangChain 官方推出的长期记忆 SDK专为 Agent 持续学习、偏好沉淀和跨会话知识维护而设计。它与旧版 LangChain Memory 最大的区别在于**记忆不再只是一个被动注入聊天历史的组件而是一组可被 Agent 主动调用的工具和后台管理器。**Agent 可以在推理过程中决定何时写入、何时检索也可以在任务结束后由后台流程统一整理。LangMem 将认知科学中经典的三类记忆分类映射到工程实现使得记忆系统的设计有了更清晰的语义边界这也是它在概念层面最值得学习的地方。核心机制LangMem 的三类记忆类型直接对应认知科学的分类三类记忆类型**语义记忆Semantic**存储陈述性事实如「用户的职业是工程师」「用户在北京」**情节记忆Episodic**存储具体经历如「上周用户询问过 RAG 的实现方案」**程序记忆Procedural**存储行为规律如「用户每次都喜欢先看示例再看原理」LangMem 最有特色的能力之一是后台记忆管理Agent 完成任务后可以通过 memory manager 在后台提取、合并和更新长期记忆将本次任务中的关键发现、用户行为模式沉淀下来。这和 Dreaming 的异步巩固机制在思路上相似但 LangMem 更偏开发者工具允许开发者自行配置存储、命名空间和写入策略。此外LangMem 支持多用户、多 Agent 的记忆命名空间隔离不同用户的记忆严格分开同一用户下的不同 Agent 可选择共享或独立。Store、Checkpoint 和 State 的区别理解 LangMem最好先把 LangGraph 里的三个概念分清楚**State 是运行时上下文Checkpoint 是过程快照Store 才是长期记忆。**这三个东西都和“记住”有关但解决的问题完全不同。01 · State**State 是一次图运行里的当前工作区。**比如当前消息列表、工具调用结果、中间推理结果、当前任务状态都会放在 state 里在 LangGraph 的节点之间流转。它更像 Agent 当前正在处理的“工作记忆”服务于这一次运行。02 · Checkpoint**Checkpoint 是 state 的持久化快照。**它记录某个 thread 在某一步运行后的状态主要用于恢复执行、断点续跑、人工介入、回放和 time travel。它保存的是“这次任务进行到哪一步”不是跨任务沉淀出来的用户长期偏好。03 · Store**Store 是跨 thread、跨会话的长期存储。**用户偏好、稳定事实、历史经验、可复用知识一般应该放进 store并通过 namespace 区分用户、团队或 Agent。LangMem 的 memory tools 本质上就是在帮 Agent 管理和搜索这个长期 store。简单说**State 管当前这次运行Checkpoint 管这次运行的恢复Store 管跨会话长期记忆。**如果把用户偏好放在 state 里下次对话就丢了如果把长期偏好只存在 checkpoint 里它会被绑死在某个 thread 上真正可复用的长期记忆应该进入 store。应用场景LangGraph 多步骤 Agent原生集成记忆状态与 LangGraph 节点状态无缝共存零适配成本。研究与原型验证轻量易上手三类记忆分类清晰适合快速验证记忆设计方案。记忆与推理深度耦合的工作流需要 Agent 在推理过程中动态决定「记什么、查什么」的复杂场景。LangChain 存量项目升级已有 LangChain 项目从旧版 Memory 迁移到新架构的首选路径。应用示例LangMem 官方更推荐两种接入方式一种是在 hot path 中给 Agent 暴露管理和搜索记忆的工具另一种是在后台用 memory manager 自动提取和合并记忆。下面是更接近官方用法的简化示意from langgraph.prebuilt import create_react_agentfrom langgraph.store.memory import InMemoryStorefrom langmem import create_manage_memory_tool, create_search_memory_toolstore InMemoryStore()agent create_react_agent(“openai:gpt-4o”,tools[# Agent 可以主动写入长期记忆create_manage_memory_tool(namespace(“memories”, “alice”)),# Agent 可以主动搜索相关记忆create_search_memory_tool(namespace(“memories”, “alice”)),],storestore,)agent.invoke({“messages”: [{“role”: “user”, “content”: “我以后写技术文章时喜欢先讲直觉再讲架构。”}]})后续对话里Agent 可以通过 search memory tool 找回这条偏好也可以用后台 memory manager 定期做提取、合并和更新。这种设计最直观的价值是Agent 不只是从对话历史里找答案而是可以逐渐沉淀用户偏好、任务经验和行为策略。下次面对类似问题时记忆影响的不只是回答内容也可能影响它的工作方式。优缺点优点LangGraph 原生集成在 LangChain 生态内使用体验最顺畅三类记忆分类概念清晰设计直观学习成本低hot path 工具 后台 memory manager 的组合很灵活既能主动记忆也能异步整理LangChain 官方维护与 LangGraph 生态协同演进版本兼容性较有保障缺点强依赖 LangGraph 生态非 LangChain 技术栈的项目迁移成本高生产成熟度不及 Zep企业级案例较少还在快速迭代中持久化需自行配置默认内存存储不适合生产环境图记忆能力弱于 Mem0 和 Zep多跳推理场景下表现一般SUMMARY · 总结记忆系统最后拼的不是框架而是业务理解看完 Dreaming、Mem0、Zep、LangMem很容易产生一种错觉只要接入一个记忆框架Agent 就拥有了长期记忆。但真实工程里不是这样。**这些产品更多解决的是记忆的工程底座问题——怎么写入、怎么存储、怎么检索、怎么注入上下文。**而记忆系统真正难的部分是判断什么信息重要、应该如何压缩、用什么结构表达、什么时候更新和遗忘。上篇我们说**记忆的加工是基于重要度的信息压缩。**这句话放到业务系统里尤其关键什么叫“重要”不是模型自己能稳定判断出来的而是高度依赖业务。例如教育场景里用户连续三次答错同一类题是重要记忆客服场景里用户上次投诉的核心原因是重要记忆健康场景里过敏史、伤病史这种低频信息哪怕一年只出现一次也绝对不能被遗忘。所以做记忆系统不是简单地把对话丢进向量库也不是把所有事实抽成 KV 就结束了。KV 结构怎么设计图关系怎么定义重要度如何打分冲突如何消解哪些信息需要永久保留哪些信息应该随时间衰减这些都需要大量业务逻辑支撑。没有业务语义记忆系统很容易变成一个更复杂的聊天记录仓库。这也是为什么同样接入 Mem0、Zep 或 LangMem不同团队最后做出来的效果会差很多。框架提供的是通用能力抽取、存储、检索、图谱、时序但真正决定上限的是业务建模你是否知道业务里哪些事实会影响未来决策哪些状态会变化哪些关系需要追踪哪些记忆会带来风险。记忆的核心目标不是对过去的归档而是对未来行动的预测性准备。技术框架只能帮你把信息存起来、搜出来真正决定质量的是业务判断下次需要做决策的时候什么信息才值得被放进上下文所以这篇文章虽然讲的是几个记忆产品但真正想强调的是**记忆系统的关键从来不是几个技术框架而是对业务的理解。**框架是工具业务语义才是记忆的骨架。没有业务理解记忆只是存储有了业务理解记忆才可能变成智能。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】