本文详解 AI Agent 长期记忆的工程实践。核心围绕两大存储载体:VectorStore(语义检索)与 GraphStore(关系知识)。维护策略采用 LLM 决策的 CRUD 模式,检索环节通过查询改写、重排序及多路召回提升精准度。结合 mem0 实例,手把手教你实现 Agent 的个性化与持续学习。

引言

从本质上来说,AI Agent 仍然是一种工具。但与软件工程领域中的其他工具不同,我们对 AI Agent 怀有更高、也更复杂的期待。这种期待源于 AI 能力的加持——我们希望它不仅仅提升效率,而是真正解放生产力。

在这一愿景下,“长期记忆"成为关键能力之一。它的意义在于,让 Agent 不再只是被动执行指令,而是能够在持续交互中逐渐变得更智能、更贴近使用者,甚至越来越"懂我”。

在正式展开之前,先简单回顾一下长期记忆与短期记忆的区别。

短期记忆:存储会话中产生的各类消息,包括用户输入、模型回复、工具调用及其结果等。这些消息直接参与模型推理,实时更新。当消息累积导致上下文窗口超出限制时,需要通过压缩、卸载、摘要等上下文工程策略进行处理。

长期记忆:Agent 在多次交互与会话之间持久化存储信息的系统。它相当于智能体的"个人档案"或"知识库",用于保留需要跨会话记忆的关键信息,如用户偏好、重要事实、从历史会话中积累的经验与知识等。其核心目标是实现个性化持续学习

Agent 长期记忆的工程实现,核心可以归结为两个基本问题:

  1. 如何维护长期记忆 —— 包括长期记忆的新增、更新与删除;
  2. 如何使用长期记忆 —— 即在实际推理与决策过程中,如何高效、准确地检索与注入相关记忆。

围绕这两个问题,我们需要首先明确长期记忆的存储载体。在当前主流的工程实践中,长期记忆通常依赖两类基础设施:VectorStore(向量数据库)GraphStore(图数据库)。接下来,我们将从这两种载体的特性与适用场景出发,逐步展开长期记忆的工程化实现方式。

以下内容我们将结合mem0进行说明,github地址:https://github.com/mem0ai/mem0


一、长期记忆的载体

1.1 VectorStore:语义检索的基石

向量数据库是当前长期记忆最主流的存储载体。其核心思路是:将文本信息通过 Embedding 模型转换为高维向量,存储在专门的向量索引结构中。检索时,将查询语句同样转换为向量,通过余弦相似度或内积等度量方法,找出语义最相近的记忆条目。

这种方式的优势非常直接——语义相似即可命中。即便用户的表述与存储时的措辞完全不同,只要语义接近,向量检索就能找到对应的记忆。例如,Agent 存储了"用户不喜欢辣食",当下次对话中用户问到餐厅推荐时,即便没有提及"辣",Agent 也能从向量空间中召回这条偏好。

常见的 VectorStore 选型包括:

方案 特点 适用场景
Chroma 轻量级,易集成,支持本地持久化 本地开发、小规模部署
Qdrant 高性能,支持丰富的过滤条件 生产环境,记忆量较大
Pinecone 全托管,开箱即用 快速原型、云端部署
pgvector PostgreSQL 扩展,与关系数据融合 已有 PG 栈的团队
Faiss 极致性能,适合批量检索 离线分析、大规模召回

向量数据库的局限同样明显:它擅长处理孤立事实,但对于实体间关系的表达能力较弱。"张三是李四的上司"和"李四喜欢咖啡"对向量数据库而言没有本质差异,它无法自然地表达和利用实体之间的关联结构。这正是图数据库要解决的问题。

1.2 GraphStore:关系知识的天然载体

图数据库将知识以节点(Node)和边(Edge) 的形式组织,节点代表实体(人、地点、事件等),边代表实体间的关系。这种结构天然适合表达复杂的关联信息。

以 mem0 的 Graph Memory 实现为例,当 Agent 处理"Alice 在 GraphConf 2025 上认识了 Bob"这条信息时:

  • 向量数据库:将这句话嵌入为一个向量,语义检索时可以找到它;
  • 图数据库:提取出 AliceBobGraphConf 2025 三个节点,以及 MET_AT 关系边,形成结构化的知识图谱。

后续当用户问"Alice 认识哪些人?"时,图数据库可以直接沿着边遍历,精确返回所有相关节点,而不依赖语义相似度的模糊召回。

mem0 的 Graph Memory 架构如下:

Conversation → Extraction LLM → VectorStore (embeddings)  
                              ↓  
                           GraphStore (nodes & edges)  
  
Query → VectorSearch → Candidate Memories  
                     → Graph traversal → Contextual Relations

两者并行工作:向量检索负责语义召回,图遍历补充关系上下文,最终合并返回给 Agent。

GraphStore 的接入示例(以 Neo4j 为例):

from mem0 import Memory  
  
config = {  
    "graph_store": {  
        "provider": "neo4j",  
        "config": {  
            "url": "neo4j+s://<your-instance>.databases.neo4j.io",  
            "username": "neo4j",  
            "password": "your-password",  
        }  
    }  
}  
  
memory = Memory.from_config(config)

目前 mem0 支持的图数据库后端包括 Neo4j、Memgraph、Amazon Neptune 和 Kuzu(嵌入式),可以按部署环境灵活选择。

1.3 两者的核心差异
维度 VectorStore GraphStore
存储单元 文本片段 + 向量 节点 + 边 + 属性
检索方式 语义相似度搜索 关系遍历 + 模式匹配
擅长场景 偏好、事实、陈述性知识 人物关系、事件脉络、多跳推理
部署复杂度 中高
典型问题类型 “用户喜欢什么?” “Alice 认识谁?谁参加了哪个会议?”

值得注意的是,以上仅是工程上常见的实现方式,实际应用中可能因具体需求而异。在我们此前对 OpenClaw 的分析《OpenClaw 入门指南:从原理到实战》就发现,其长期记忆是以本地 MEMORY.md 文档的形式存储的——简单直接。这告诉我们,不应拘泥于形式,而应根据实际需要合理评估,有时候最朴素的方案反而是最合适的。


二、如何维护长期记忆?

确定了存储载体,接下来的核心问题是:如何让记忆库保持准确、及时、不冗余

长期记忆的维护本质上是一个持续的 CRUD 过程:新信息到来时新增,信息发生变化时更新,矛盾信息出现时删除。听起来简单,但在实际 Agent 交互中,判断"这条信息是新增还是更新"并不容易。

图片

2.1 维护策略:规则 + LLM vs 纯 LLM

目前主流的维护策略有两种路径:

路径一:规则 + LLM 判断

设定一些明确的规则,例如"情感倾向明显的表达优先存储"、“重要度评分超过阈值才触发写入”,在规则过滤之后再交由 LLM 做最终判断。这种方式可控性强,适合有明确记忆策略的产品场景。

路径二:完全交给 LLM

直接将当前对话和已有记忆库交给 LLM,让它自行判断应该 ADD、UPDATE、DELETE 还是 NONE。这种方式更灵活,能处理更复杂的边界情况。

我个人更倾向于后者。既然我们选择了使用 AI,就应该充分信任 AI 的判断力。在AI Agent 的记忆系统:从必要性到工程实践一文中对 Cursor 记忆系统的解析中也发现,Cursor 正是采用了这种"完全交给 LLM"的方式。

mem0 将这种灵活性通过 Custom Update Memory Prompt 开放给开发者,允许用户自定义 LLM 的决策逻辑。

2.2 记忆的新增(ADD)

当会话产生了新的、尚未存储的信息时,触发 ADD 操作。mem0 的信息提取流程分为两步:

  1. 信息抽取:通过 LLM 从对话中提取关键事实、偏好、决策等信息片段;
  2. 冲突检测:与现有记忆进行比对,确认是否为全新信息。
from mem0 import Memory  
  
m = Memory()  
  
messages = [  
    {"role": "user", "content": "我计划下个月去东京旅行。"},  
    {"role": "assistant", "content": "好的,我会记住这个计划,方便后续提供相关建议。"}  
]  
  
result = m.add(messages, user_id="alice")

执行完毕后,mem0 会自动从对话中抽取"用户计划下个月去东京旅行"这一事实,写入向量存储,同时(如果启用了图存储)在图中创建 Alice → PLANS_TO_VISIT → Tokyo 的关系边。

infer=True 是默认行为,也是推荐做法——让 LLM 决定哪些信息值得存储,而不是盲目地把所有对话都塞进记忆库。

2.3 记忆的更新(UPDATE)

更新是维护中最复杂的操作。当新信息与已有记忆描述的是同一件事,但内容有所变化时,需要更新而非新增。

以 mem0 的 Custom Update Memory Prompt 为例,它通过结构化的 LLM 决策来处理这个问题:

UPDATE_MEMORY_PROMPT = """你是一个智能记忆管理器,负责控制系统的记忆。  
你可以执行四种操作:(1) 新增记忆 (2) 更新记忆 (3) 删除记忆 (4) 不做变更  
  
比较新获取的事实与现有记忆。对于每条新事实,决定是否:  
- ADD:作为新条目添加  
- UPDATE:更新现有记忆条目  
- DELETE:删除现有记忆条目    
- NONE:不做变更(事实已存在或不相关)  
"""

更新场景示例:

旧记忆:[{"id": "0", "text": "用户喜欢奶酪披萨"}]  
新事实:["用户喜欢鸡肉披萨和奶酪披萨"]  
  
决策结果:  
{  
  "memory": [{  
    "id": "0",  
    "text": "用户喜欢鸡肉披萨和奶酪披萨",  
    "event": "UPDATE",  
    "old_memory": "用户喜欢奶酪披萨"  
  }]  
}

有两个细节值得关注:保留原始 ID,确保历史追溯链路不断;//记录 old_memory//,方便审计与 Debug。

2.4 记忆的删除(DELETE)

当新信息与已有记忆产生直接矛盾时,触发 DELETE。这是记忆库保持"当前真实"的关键机制。

旧记忆:[{"id": "1", "text": "用户喜欢奶酪披萨"}]  
新事实:["用户不喜欢奶酪披萨"]  
  
决策结果:  
{  
  "memory": [{  
    "id": "1",  
    "text": "用户喜欢奶酪披萨",  
    "event": "DELETE"  
  }]  
}

矛盾信息不应被"更新"掩盖,而应被删除——因为这不是一次"说法变化",而是一次"事实反转"。LLM 需要能准确区分这两种情形。


三、如何使用长期记忆?

维护好的记忆库,只有在被有效利用时才体现价值。"如何使用长期记忆"的本质,是在正确的时机,把正确的记忆注入到 LLM 的上下文中

图片

3.1 检索流程全貌

mem0 的检索流水线如下:

用户查询  
   ↓  
查询改写(Query Rewrite)  
   ↓  
向量检索(Vector Search)  
   ↓  
重排序(Reranking)  
   ↓  
注入上下文

每一步都在为最终结果的精准度做贡献,不能随意省略。

3.2 为什么需要查询改写(Query Rewrite)?

用户在对话中的表达往往不适合直接作为检索 Query。以一个具体例子说明:

用户问:“帮我推荐一家今晚吃饭的地方。”

这句话直接丢给向量检索,能命中什么?最可能返回的是"用户曾经去过某家餐厅"或"用户提到过晚饭"——而真正有用的记忆是"用户不吃辣"、“用户偏好日式料理”、“用户对花生过敏”。

查询改写的作用,就是将用户的原始表达转化为更适合记忆检索的语义查询。例如将上述问题扩展为:“用户的饮食偏好”、“用户的食物禁忌”、“用户过往的餐厅偏好”,分别独立检索,再合并结果。

这一步通常由一个轻量的 LLM 调用完成,成本可控,但对检索质量的提升非常显著。

3.3 为什么需要重排序(Reranking)?

向量检索基于余弦相似度(最常见),返回的是"语义最近"的结果,但"语义最近"≠"最相关"。

举一个典型的反例。用户问:“我学过哪些编程语言?”,记忆库中存储了以下四条:

  • A “用户认为学好编程最重要的是多实践”
  • B “用户大学读的是计算机专业,辅修数学”
  • C “用户掌握 Python、Java 和 Go,目前主力使用 Go”
  • D “用户不喜欢前端开发”

向量检索按余弦相似度排序后,假设结果可能是:A(0.88)> B(0.85)> C(0.79)> D(0.74)

原因并不难理解:A 里"学好编程"和 B 里"计算机专业"与查询中"学过"和"编程语言"的向量表示高度重叠,而 C 虽然是这道题的直接答案,但措辞不同,语义向量反而排第三。

如果此时 limit=2,用到的记忆就只有 A 和 B,真正的答案 C 被截断丢掉了。

Reranking 的作用正在于此:它在向量召回之后引入另一个模型(通常是交叉编码器 Cross-Encoder),将查询和每条记忆作为一对输入,整体评估其语义相关性,而不是分别计算各自的向量再做比较。经过精排,C 会被推到第一位,A 和 B 反而被压后。

Reranking 前后的排序对比:

排名 向量检索(召回阶段) Reranking(精排后)
1 A - “学好编程最重要的是多实践” C - “掌握 Python、Java 和 Go”
2 B - “大学读计算机专业” B - “大学读计算机专业”
3 C - “掌握 Python、Java 和 Go” D - “不喜欢前端开发”
4 D - “不喜欢前端开发” A - “学好编程最重要的是多实践”

在 mem0 中,开启 Reranking 只需一个参数:

results = m.search(  
    "推荐一部今晚适合看的电影",  
    user_id="alice",  
    rerank=True,  
    limit=5  
)

两阶段检索(向量召回 + Reranking 精排)是当前 RAG 领域的主流范式,在记忆检索场景同样适用,也是 mem0 官方推荐的使用方式。

3.4 其他优化策略

除了改写和 Reranking,还有几种常见的检索优化手段:

① 相关度阈值过滤(Threshold Filtering)

只返回相似度分数超过阈值的记忆条目,避免将不相关的记忆注入上下文,干扰 LLM 推理。

results = m.search(  
    "用户的饮食偏好",  
    user_id="alice",  
    threshold=0.7  # 只返回相似度 > 0.7 的记忆  
)

② 元数据过滤(Metadata Filtering)

为记忆条目附加结构化元数据,检索时通过过滤条件缩小候选范围,提高精度同时降低延迟。

# 写入时携带元数据  
m.add(messages, user_id="alice", metadata={"category": "food_preference"})  
  
# 检索时按类别过滤  
results = m.search(  
    "用户喜欢吃什么",  
    user_id="alice",  
    filters={"categories": {"contains": "food_preference"}}  
)

③ 图关系增强(Graph-Enhanced Retrieval)

对于涉及实体关系的查询,启用图存储可以在向量召回的基础上补充关系上下文,使 Agent 对复杂关联有更完整的认知。

results = m.search(  
    "Alice 认识哪些人?",  
    user_id="demo-user",  
    enable_graph=True  
)  
  
# results["results"] 包含向量召回的记忆  
# results["relations"] 包含图数据库返回的关系信息

④ 多路检索合并(Multi-Query Retrieval)

对一个用户请求生成多个不同角度的检索 Query,分别独立检索后合并去重。这在用户问题较模糊或涉及多个维度时特别有效。

以"帮我安排下周的学习计划"为例,这是一个需要综合多维度上下文才能回答好的问题。如果只用原始问题检索,很可能只能命中"用户提到过学习"之类的泛化记忆。

正确做法是先将其拆解为多个语义明确的子查询:

from mem0 import Memory  
  
m = Memory()  
  
user_query = "帮我安排下周的学习计划"  
  
# 将原始问题拆解为多个子查询,覆盖不同维度  
sub_queries = [  
    "用户的学习目标和方向",  
    "用户每天的可用时间和作息习惯",  
    "用户目前的学习进度",  
    "用户偏好的学习方式",  
]  
  
# 分别检索,去重合并  
all_memories = []  
seen_ids = set()  
for q in sub_queries:  
    results = m.search(q, user_id="alice", limit=3)  
    for mem in results["results"]:  
        if mem["id"] notin seen_ids:  
            all_memories.append(mem)  
            seen_ids.add(mem["id"])  
  
# all_memories 包含从四个角度召回、去重后的完整上下文

四路检索分别可能命中:

  • 子查询1 → “用户目标是通过 AWS 认证考试”、“用户想深入学习分布式系统”
  • 子查询2 → “用户工作日晚上有 1-2 小时空余”、“用户周末可以学习半天”
  • 子查询3 → “用户已经看完了第 3 章,卡在第 4 章的实验上”
  • 子查询4 → “用户更喜欢边做项目边学,不喜欢纯看书”

将这些记忆合并注入上下文,Agent 才能给出真正贴合用户实际情况的学习计划,而不是完全自由发挥、脱离实际需要的结果。


结语

长期记忆是 AI Agent 从"工具"走向"伙伴"的关键一步。

本文围绕长期记忆的两个核心工程问题展开:存储载体的选择(VectorStore vs GraphStore),以及记忆的维护(ADD/UPDATE/DELETE)与检索(改写 + 向量召回 + Reranking)。

核心逻辑就是:把合适的信息存在合适的地方,在合适的时机以合适的方式取出来。这句话说起来平平无奇,但其中每一步,都是工程上多次实践后的结晶。

在如何维护长期记忆这个问题上,我更倾向于信任 LLM 的判断——无论是记忆维护时的 ADD/UPDATE/DELETE 决策,还是检索时的查询改写,LLM 的灵活性远超硬编码规则。当然,"信任 AI"并不意味着放任不管,有审计、有监控、可干预,才能使我们设计出一个更安全、可靠的Agent。

Agent 的“懂你”,从来不是一蹴而就的。 它不是某个模型参数的瞬间跃迁,而是一次次交互之后,一条条记忆沉淀下来的结果。

而我们作为工程师,要做的并不是赋予它“理解”的幻觉,而是为这种长期积累的过程搭建稳固的地基—— 让记忆可存储、可演化、可调用, 让“越来越懂你”不再只是愿景,而成为一种可以被工程化实现的能力。

辑就是:把合适的信息存在合适的地方,在合适的时机以合适的方式取出来。这句话说起来平平无奇,但其中每一步,都是工程上多次实践后的结晶。

在如何维护长期记忆这个问题上,我更倾向于信任 LLM 的判断——无论是记忆维护时的 ADD/UPDATE/DELETE 决策,还是检索时的查询改写,LLM 的灵活性远超硬编码规则。当然,"信任 AI"并不意味着放任不管,有审计、有监控、可干预,才能使我们设计出一个更安全、可靠的Agent。

Agent 的“懂你”,从来不是一蹴而就的。 它不是某个模型参数的瞬间跃迁,而是一次次交互之后,一条条记忆沉淀下来的结果。

而我们作为工程师,要做的并不是赋予它“理解”的幻觉,而是为这种长期积累的过程搭建稳固的地基—— 让记忆可存储、可演化、可调用, 让“越来越懂你”不再只是愿景,而成为一种可以被工程化实现的能力。

AI时代,未来的就业机会在哪里?

答案就藏在大模型的浪潮里。从ChatGPT、DeepSeek等日常工具,到自然语言处理、计算机视觉、多模态等核心领域,技术普惠化、应用垂直化与生态开源化正催生Prompt工程师、自然语言处理、计算机视觉工程师、大模型算法工程师、AI应用产品经理等AI岗位。

在这里插入图片描述

掌握大模型技能,就是把握高薪未来。

那么,普通人如何抓住大模型风口?

AI技术的普及对个人能力提出了新的要求,在AI时代,持续学习和适应新技术变得尤为重要。无论是企业还是个人,都需要不断更新知识体系,提升与AI协作的能力,以适应不断变化的工作环境。

因此,这里给大家整理了一份《2026最新大模型全套学习资源》,包括2026最新大模型学习路线、大模型书籍、视频教程、项目实战、最新行业报告、面试题、AI产品经理入门到精通等,带你从零基础入门到精通,快速掌握大模型技术!

由于篇幅有限,有需要的小伙伴可以扫码获取!
在这里插入图片描述

1. 成长路线图&学习规划

要学习一门新的技术,作为新手一定要先学习成长路线图,方向不对,努力白费。这里,我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。

在这里插入图片描述

2. 大模型经典PDF书籍

书籍和学习文档资料是学习大模型过程中必不可少的,我们精选了一系列深入探讨大模型技术的书籍和学习文档,它们由领域内的顶尖专家撰写,内容全面、深入、详尽,为你学习大模型提供坚实的理论基础(书籍含电子版PDF)

在这里插入图片描述

3. 大模型视频教程

对于很多自学或者没有基础的同学来说,书籍这些纯文字类的学习教材会觉得比较晦涩难以理解,因此,我们提供了丰富的大模型视频教程,以动态、形象的方式展示技术概念,帮助你更快、更轻松地掌握核心知识

在这里插入图片描述

4. 大模型项目实战

学以致用 ,当你的理论知识积累到一定程度,就需要通过项目实战,在实际操作中检验和巩固你所学到的知识,同时为你找工作和职业发展打下坚实的基础。

在这里插入图片描述

5. 大模型行业报告

行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估,以了解哪些行业更适合引入大模型的技术和应用,以及在哪些方面可以发挥大模型的优势。

在这里插入图片描述

6. 大模型面试题

面试不仅是技术的较量,更需要充分的准备。

在你已经掌握了大模型技术之后,就需要开始准备面试,我们将提供精心整理的大模型面试题库,涵盖当前面试中可能遇到的各种技术问题,让你在面试中游刃有余。

在这里插入图片描述

为什么大家都在学AI大模型?

随着AI技术的发展,企业对人才的需求从“单一技术”转向 “AI+行业”双背景。企业对人才的需求从“单一技术”转向 “AI+行业”双背景。金融+AI、制造+AI、医疗+AI等跨界岗位薪资涨幅达30%-50%。

同时很多人面临优化裁员,近期科技巨头英特尔裁员2万人,传统岗位不断缩减,因此转行AI势在必行!

在这里插入图片描述

这些资料有用吗?

这份资料由我们和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理,现任上海殷泊信息科技CEO,其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证,服务航天科工、国家电网等1000+企业,以第一作者在IEEE Transactions发表论文50+篇,获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目,无论你是小白还是有些技术基础的技术人员,这份资料都绝对能帮助你提升薪资待遇,转行大模型岗位。

在这里插入图片描述
在这里插入图片描述

大模型全套学习资料已整理打包,有需要的小伙伴可以微信扫描下方CSDN官方认证二维码,免费领取【保证100%免费】

在这里插入图片描述

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐