今天这一篇，我们把视角切换到工程实现。选了四款在业界影响力最大的记忆产品：

**ChatGPT Memory（Dreaming）**代表闭源端到端系统；

Mem0、Zep、LangMem 代表开源与开放生态的三个方向——轻量记忆层、企业级图谱引擎、框架原生集成。

01 · CHATGPT MEMORY

Dreaming — 对话即记忆，零配置的端到端系统

OpenAI · 2024 Saved Memories · 2025 引入 Dreaming · 闭源商业产品

产品基本信息

Dreaming 是 OpenAI 深度集成在 ChatGPT 产品内的记忆机制。更准确地说，ChatGPT 记忆最早是 2024 年的 Saved Memories，用户可以显式要求 ChatGPT 记住某些偏好；到 2025 年，OpenAI 引入 Dreaming，让系统能够在后台参考历史对话，自动整理更自然、更连续的用户上下文。

可以把 Dreaming 理解成一种后台记忆巩固机制：它不像早期 Saved Memories 那样完全依赖用户显式说「请记住」，而是从多轮对话中综合提炼用户状态、长期偏好和正在推进的任务。OpenAI 后续又在此基础上继续强化记忆架构，让它从补充能力逐渐变成 ChatGPT 个性化体验的核心部分。

核心机制

Dreaming 是闭源系统，OpenAI 并未公开完整实现细节。以下是基于官方公开信息和产品行为的推测性拆解，帮助理解它大致的记忆流程：

1. 异步写入触发：

   对话结束后，后台任务对本轮对话进行语义分析，识别值得记住的信息——用户偏好、明确表达的需求、个人背景等，而非逐字存储整段对话。

2. 自然语言摘要 + 结构化标签：

   记忆以自然语言形式存储（如「用户更喜欢简洁的回答风格」），同时附加结构化元信息——时间戳、来源对话 ID、置信度，方便后续检索与过期处理。

3. 语义检索 + 规则过滤：

   新对话开始时，系统根据当前上下文自动检索最相关的记忆片段，将其注入 System Prompt，使模型在回答前就已「知道」用户的历史偏好。

4. 用户可见性与隐私控制：

   用户可以在设置中查看所有记忆、手动删除单条或全部，也可完全关闭记忆功能。透明度是 Dreaming 设计的重要原则之一。

应用示例

用户在第一次对话中提到自己是一名后端工程师，习惯用 Python，不喜欢冗长的解释。几天后开启新会话，ChatGPT 在没有重新介绍的情况下，直接给出简洁的 Python 代码示例：

**用户：**帮我写一个读取 CSV 文件并按某列排序的函数。

ChatGPT（基于已记住的背景：Python 后端工程师，偏好简洁）：

import pandas as pd
def sort_csv(path, col): return pd.read_csv(path).sort_values(col)

没有重新询问技术栈，没有多余解释，直接给出符合偏好的答案。

优缺点

优点：

• 零配置，开箱即用，无需任何开发工作
• 记忆质量高，依托 OpenAI 端到端模型与产品系统能力
• 隐私控制直观，用户全程可见可管理
• 与 ChatGPT 产品体验无缝融合

缺点：

• 完全黑盒，无法定制记忆结构或召回策略
• 不可二次开发，无法集成到自有系统中
• 企业和团队场景下的记忆边界、数据治理仍需要额外关注
• 记忆容量上限和遗忘策略对用户不透明

02 · MEM0

Mem0 — 面向 AI Agent 的长期记忆层

前身 EmbedChain · 开源 Apache 2.0 + 托管云服务 · Python / TypeScript SDK

产品基本信息

Mem0 的核心设计理念是：记忆不应该被耦合在某一个 LLM 应用里，它应该是一个独立的基础设施层，任何 Agent、任何 LLM 框架都可以接入。这与 Dreaming 的「内嵌式」思路形成了鲜明对比——Mem0 更像是一个可插拔的「记忆数据库服务」。

在技术选型上，Mem0 支持多种向量数据库（Qdrant、Pinecone、Chroma 等）。图记忆最早通过外接图数据库（如 Neo4j，需在配置里设置 version="v1.1"）实现；而在较新的版本中，Mem0 已经移除了对外部图库的依赖，改为内置图记忆——直接在向量库里维护实体关联，无需再额外部署图数据库。

核心机制

Mem0 的 API 设计非常克制，真正高频使用的核心函数基本就是两个：add 和 search。前者负责把对话加工成记忆，后者负责在下一次推理前把相关记忆找回来。

核心函数 01 · add

调用方式：mem.add(messages, user_id=USER_ID)

作用：从对话中提取事实性陈述，与已有记忆做语义对比和合并，再向量化写入向量库；同时提取实体，维护记忆之间的关联关系（新版本内置，无需额外部署图库）。

核心函数 02 · search

调用方式：mem.search(query, user_id=USER_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 Memory
from openai import OpenAI

mem = Memory()
client = OpenAI()
USER_ID = “alice”

第一轮对话：写入记忆

messages = [{“role”: “user”, “content”: “我是一名 Python 后端工程师，偏好简洁风格。”}]
mem.add(messages, user_id=USER_ID) # 自动提取事实存入记忆库

第二轮对话（新会话）：检索记忆注入上下文

query = “帮我写一个排序函数”
memories = mem.search(query, user_id=USER_ID, limit=3)

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 · ZEP

Zep — 面向生产环境的记忆与知识图谱引擎

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」这类随时间变化的偏好。这在客服、医疗、金融等对信息时效性有严格要求的场景中至关重要。

核心机制

1. 对话历史压缩与摘要：

   自动对长对话进行滚动摘要，将旧消息压缩为结构化摘要，大幅降低注入 context 的 token 消耗，同时保留语义完整性。

2. 实体提取与知识图谱构建：

   自动从对话中识别人物、地点、事件、产品等实体，构建结构化的实体关系图，支持跨会话的关联查询。

3. 时序记忆（核心差异化）：

   所有记忆都带有精确时间戳，支持有效期与状态变更追踪，避免过期信息污染当前对话。例如：用户已换工作，但旧职业信息不会继续被引用。

4. 图结构驱动的关系存储：

   底层 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 Zep
from zep_cloud.types import Message
from datetime import datetime, timezone

API_KEY = “YOUR_API_KEY”
thread_id = “thread_id”

zep_client = Zep(
api_key=API_KEY,
)

Add incoming user messages to Zep

messages = [
Message(
created_at=datetime.now(timezone.utc).isoformat(),
name=“Jane Smith”,
role=“user”,
content=“Who was Octavia Butler?”,
)
]

response = zep_client.thread.add_messages(thread_id=thread_id, messages=messages)

Get context for the thread

user_context = zep_client.thread.get_user_context(thread_id=thread_id)

Access the context block (for use in prompts)

context_block = user_context.context
print(context_block)

时序感知的实际效果举例：用户去年提到「对股票比较保守，不想碰高风险产品」，今年突然问「我想了解一下可转债」，Zep 会把这两条记忆一起召回，并标注各自的时间，让模型意识到用户的偏好可能正在发生变化，而不是直接用旧偏好否定新需求。

优缺点

优点：

• 时序感知是 Zep / Graphiti 最突出的差异化能力之一，尤其适合事实随时间变化的业务场景
• 生产级稳定性，有大量企业用户验证
• 提供独立官方 SDK，不绑定特定框架，同时也有 LangChain / LlamaIndex 等集成
• 企业客户可通过 BYOC 部署在自有云中，满足合规与数据驻留要求

缺点：

• 完整的 Zep 只提供云服务，普通开发者无法像早期社区版那样本地自托管
• 若要完全自托管，只能用底层 Graphiti，需要自行运维图数据库和 LLM 服务，成本较高
• 学习曲线相对陡，概念（thread / 图谱 / 时序）较多，轻量场景下显得「过于重型」
• 作为托管服务，数据需要交给 Zep Cloud，对数据主权敏感的团队需评估 BYOC 或替代方案

04 · LANGMEM

LangMem — 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_agent
from langgraph.store.memory import InMemoryStore
from langmem import create_manage_memory_tool, create_search_memory_tool

store = 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”)),
],
store=store,
)

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%免费】