Agent 记忆系统设计：从会话到长期记忆

你花了 30 分钟和 AI Agent 讨论项目细节，把架构方案、技术选型、风险评估都过了一遍。第二天打开同一个对话，它问你：“您想讨论什么内容？”

昨天的所有东西——你的偏好、讨论的结论、进度跟踪——全没了。

说实话，这不是 Agent 能力的问题。问题出在架构设计上：你给它装了大脑，但没给它装记忆。

LLM 默认是无状态的。每次请求都是一张白纸，除非你主动构建记忆系统。我见过太多团队在 Agent 上线后才发现这个问题：用户投诉”怎么又问一遍”、“上次说好的事怎么忘了”，然后才开始亡羊补牢。

这篇文章想分享的，就是一套完整的 Agent 记忆系统设计蓝图：四种记忆类型怎么选、五阶段流水线怎么搭、框架怎么选、成本怎么控。

第一章：为什么 Agent 需要记忆系统

LLM 天生就是”金鱼记忆”。你发一个请求，它给你一个回复，完事。下一个请求来了，它又是全新的状态，啥也不记得。这不是缺陷，是设计上的特性——每次推理独立进行，保证输出的可预测性。

但这个特性在 Agent 场景里简直就是灾难。

想象一个客服 Agent，用户说”我想改地址”。Agent 回复”好的，请提供新地址”。用户说”就上次那个仓库地址”。这时候 Agent 彻底懵了：上次是哪次？哪个仓库？它什么都不知道。

更糟糕的是”上下文腐烂”（Context Rot）——你不断往对话里塞东西，上下文越来越长，里面的垃圾信息也越来越多。用户问个简单问题，Agent 却要在几十轮历史里翻找答案。据 Redis 官方博客的数据，满上下文方案会导致 p95 延迟飙到 17.12 秒，token 开销翻 14 倍。

成本差距就更离谱了。我看过一个对比：满上下文方案一个月烧 100 万美元，选择性记忆方案只要 10 万美元。十倍差距。

这里的核心矛盾是：你想让 Agent 记住一切，但又不能把所有东西都塞进上下文窗口。怎么办？答案很简单——给它装个记忆系统。

记忆系统解决三个核心问题：

跨会话连续性：用户今天说了喜欢中文回复，明天、下周、下个月打开，Agent 都该记得这个偏好。

个性化体验：每个用户的使用习惯、业务背景、历史记录都不一样，记忆系统让 Agent 能”认出”用户。

崩溃恢复：Agent 执行到一半出错了，有记忆系统的话，重启后能从上次断的地方继续，不用从头来过。

第二章：四种记忆类型：认知科学到技术架构

记忆不是一块存储空间，它有层次、有分工。认知科学家把人类记忆分成工作记忆、情景记忆、语义记忆、长期记忆——Agent 的架构设计完全可以借鉴这套模型。

工作记忆（Working Memory）

工作记忆就是 Agent 当前会话的”脑子”。你跟它对话，它脑子里转的东西都在这里——用户刚说了什么、当前任务进度、中间推理结果。

存储位置很直接：上下文窗口。生命周期也短——对话结束，工作记忆就清空了。下次对话从头开始。

技术实现上，大多数框架用 Redis 或 KV Store 作为后端，加上一个 Checkpointer 定期把状态保存下来。LangGraph 的 MemorySaver 就是典型的例子：每执行完一个节点，就把状态快照存到内存或数据库里。

情景记忆（Episodic Memory）

情景记忆是”发生过什么”的记录。用户上次问过什么问题、Agent 怎么回答的、中间有什么决策——这些事件按时间顺序存储，像一本流水账。

和工作记忆不同，情景记忆是跨会话持久化的。今天对话结束了，明天的对话还能查到上次的事件记录。

存储方式通常是事件流（Redis Streams）或时序数据库。一个关键的优化策略是”摘要压缩”——原始事件可能很冗长，用 LLM 总结成精简版本，既保留关键信息，又节省存储和检索成本。

语义记忆（Semantic Memory）

语义记忆是”知道什么”。它存的是抽象知识和事实——“用户偏好中文回复”、“公司总部在上海”、“产品 A 的定价是 500 元”。

这些东西不关心什么时候知道的、从哪个对话里知道的，只关心知识本身。

存储方式主要是向量数据库（Pinecone、Weaviate、Milvus）加上知识图谱。向量化后，用 HNSW 或 IVF 索引加速检索。知识图谱则用来存实体关系——比如”用户 A 偏好 B”、“公司 C 位于 D”。

长期记忆（Long-Term Memory）

长期记忆是”用户是谁”。它存的是用户画像、偏好设置、长期领域知识——这些东西不会轻易变化，跨所有会话都有效。

存储方式是持久化数据库——PostgreSQL、MongoDB 或者云服务商提供的专门方案（阿里云 AnalyticDB、PolarDB）。检索方式通常是语义检索 + RAG，结合属性过滤（比如按用户 ID 筛选）。

这四种记忆不是孤立的，而是形成金字塔结构：工作记忆最底层、最快但最短命；长期记忆最高层、最持久但检索最慢。Agent 根据任务需求，从不同层级调取信息。

第三章：五阶段记忆流水线：从抽取到遗忘

记忆不是把对话存下来就完事了，它需要一套完整的流水线：抽取、整合、存储、检索、遗忘。每个阶段都有讲究。

Stage 1：抽取（Extraction）

对话里并不是每一句话都需要记住。“你好”、“谢谢”、“稍等一下”这些噪音信息，存了也是浪费空间。

抽取阶段的任务就是识别哪些信息值得保留。一般做法是 LLM 分类 + 规则过滤。LLM 判断这条信息是否有长期价值（“用户偏好中文回复” vs “用户说了你好”），规则过滤补充处理一些明显模式（比如长度过短、纯问候语）。

# 抽取阶段伪代码
def extract_memories(conversation):
    candidates = []
    for message in conversation:
        # LLM 分类：是否值得记忆？
        classification = llm.classify(message, "memory_candidate")
        if classification == "worth_remembering":
            candidates.append(message)
    # 规则过滤：去除明显噪音
    candidates = filter_noise(candidates)
    return candidates

Stage 2：整合（Consolidation）

抽取出来的信息可能有重复。“用户喜欢中文”可能在不同对话里出现过三次，你不需要存三份。

整合阶段的任务是：合并重复、更新旧记忆、构建知识图谱三元组。

比如：

• 旧记忆：“用户偏好中文回复”
• 新抽取：“用户说更喜欢简洁的中文回复”
• 整合后：“用户偏好简洁的中文回复”（合并并细化）

# 整合阶段伪代码
def consolidate_memories(new_memories, existing_memories):
    for new in new_memories:
        # 检查是否与已有记忆重复或相关
        similar = find_similar(new, existing_memories)
        if similar:
            # 合并或更新
            merged = llm.merge(new, similar)
            update_memory(similar.id, merged)
        else:
            # 新增记忆
            add_memory(new)

Stage 3：存储（Storage）

存储阶段涉及两个关键决策：存储格式和索引方式。

存储格式取决于记忆类型：工作记忆用 KV Store，情景记忆用事件流，语义记忆用向量数据库，长期记忆用关系型数据库。

索引方式则影响检索性能。主流选择是 HNSW 和 IVF：

• HNSW：适合中小规模数据集（十万到百万级），相同延迟下召回率更高，但内存消耗大。
• IVF：适合大规模数据集（百万到亿级），内存效率高，但精度略低。

据 Redis 博客的数据，HNSW 在相同延迟目标下通常能达到更高召回率，IVF 则在大规模数据上更省内存。选择要看你的数据量和精度要求。

Stage 4：检索（Retrieval）

Agent 需要用记忆时，检索阶段负责把相关信息捞出来。

纯向量检索有时不够精准。更好的做法是”混合检索”——向量检索 + 全文检索 + 属性过滤的组合。

比如用户问”上次说的仓库地址是什么”：

1. 向量检索：找语义相似的记忆（“仓库地址”、“物流信息”）
2. 属性过滤：只看这个用户的记忆
3. 时序排序：优先返回最近的记忆

# 混合检索伪代码
def retrieve_memories(query, user_id):
    # 向量检索
    vector_results = vector_db.search(query, top_k=20)
    # 属性过滤：只看当前用户
    filtered = [m for m in vector_results if m.user_id == user_id]
    # 时序排序：优先最近
    sorted_results = sort_by_time(filtered, descending=True)
    return sorted_results[:5]

Stage 5：遗忘（Forgetting）

遗忘听起来是消极词，但在记忆系统里它至关重要。不遗忘的话，存储会无限膨胀，噪音会淹没有价值的信息。

遗忘策略主要有两种：

时间衰减：记忆的重要性随时间递减。一个月前的偏好设置可能已经过时了，权重自动降低。

重要性淘汰：根据访问频率、用户反馈、验证次数等指标评估重要性。低重要性记忆定期清理。

一个容易被忽略的问题是”一次性错误固化”。用户随口说了一句错误信息，Agent 就把它存成”事实”了——这很危险。解决办法是在整合阶段加入验证逻辑，或者对低置信度记忆标记为”待确认”。

构建 Agent 记忆系统

五阶段流水线实现记忆的抽取、整合、存储、检索、遗忘

⏱️ 预计耗时: 60 分钟

1. 1

   步骤1: 抽取阶段：识别有价值信息

   从对话中识别值得记忆的信息：
   
   • 使用 LLM 分类判断信息是否有长期价值
   • 规则过滤去除明显噪音（问候语、无意义短句）
   • 关键指标：用户偏好、业务约束、决策结论
2. 2

   步骤2: 整合阶段：合并与更新

   处理抽取结果，避免重复存储：
   
   • 检测相似记忆，合并重复信息
   • 更新旧记忆（如偏好细化）
   • 构建知识图谱三元组
   • 低置信度信息标记为"待确认"
3. 3

   步骤3: 存储阶段：选择合适方案

   根据记忆类型选择存储和索引：
   
   • 工作记忆：Redis/KV Store（亚毫秒级）
   • 情景记忆：Redis Streams/时序数据库
   • 语义记忆：向量数据库 + HNSW/IVF 索引
   • 长期记忆：PostgreSQL/MongoDB + RAG 检索
4. 4

   步骤4: 检索阶段：混合检索策略

   组合多种检索方式提升精度：
   
   • 向量检索：语义相似度匹配
   • 全文检索：关键词精确匹配
   • 属性过滤：按 user_id、时间范围筛选
   • 时序排序：优先返回最近记忆
5. 5

   步骤5: 遗忘阶段：防止膨胀与噪音

   定期清理低价值记忆：
   
   • 时间衰减：重要性随时间递减
   • 访问频率淘汰：长期未访问的记忆降权
   • 防止错误固化：验证逻辑 + 待确认标记
   • 定期反思：LLM 检查矛盾或过时信息

第四章：框架对比：Mem0 vs Zep vs LangMem vs LangChain

市面上已经有成熟的记忆框架了，没必要从零造轮子。问题是：选哪个？

这四个框架各有特点，我先列个对比表：

维度	Mem0	Zep	LangMem	LangChain 原生
类型	托管平台（有开源版）	上下文工程平台	LangGraph 库	基础框架
知识图谱	Pro 版支持	核心特性	不支持	需外挂
自托管	开源版可自托管	仅云端	完全本地	完全本地
SDK	Python、JS、MCP Server	Python、TS、Go	仅 Python	Python
定价	Free → $19 → $249/月	$25/月起	免费	免费

选型决策树

选择框架前，先问自己三个问题：

Q1: 需要知识图谱吗？
    → 是 → Mem0 Pro 或 Zep（两者都有成熟的图谱能力）
    → 否 → 继续 Q2

Q2: 需要托管服务吗？
    → 是 → Mem0（入门简单）或 MemoClaw（无 API Key 设置）
    → 否 → 继续 Q3

Q3: 使用 LangGraph 吗？
    → 是 → LangMem（原生集成，无额外依赖）
    → 否 → 自己实现（用 LangChain Checkpointer + 向量数据库）

实际场景推荐

智能客服 → Mem0

客服 Agent 需要记住用户偏好、历史订单、投诉记录。这些信息适合用知识图谱存——“用户 A 购买了产品 B”、“用户 A 投诉过问题 C”。Mem0 的托管版省运维成本，Pro 版提供图谱能力。

医疗诊断 Agent → Zep

医疗场景涉及复杂的实体关系和时间线——症状什么时候出现、药物什么时候调整、检查结果什么时间变化。Zep 的核心优势是”时序事实”（Temporal Facts），能精确跟踪事件的时间维度，适合需要推理病史的场景。

内部工具 Agent → LangMem

如果你的 Agent 已经用 LangGraph 搭建了，直接加 LangMem 最省事。它是 LangGraph 的原生库，不需要额外依赖，Checkpointer 和记忆存储一体化。

快速原型验证 → MemoClaw

想先试试记忆系统效果，不想注册账号、配置 API Key？MemoClaw 提供”记忆即服务”，简单调用 store/recall 两个接口就能用。适合原型阶段，生产级项目可能需要更强的框架。

Mem0 的集成生态

值得一提的是 Mem0 的集成覆盖度。据 Mem0 官方博客 2026 年初的数据，它已经支持 21 个框架和平台的集成——包括 OpenAI、LangChain、LlamaIndex、CrewAI、AutoGen 等。如果你用的是主流框架，大概率已经有现成的集成包。

第五章：生产级实现：成本控制与性能优化

Demo 能跑，不代表生产能跑。记忆系统上线前，三个问题必须解决：性能够不够快、成本够不够低、安全够不够稳。

索引选型：精度 vs 规模

向量检索的性能瓶颈在索引。三种主流选择：

FLAT：暴力检索，精度完美，但速度慢。适合小规模数据（万级以下），或者需要百分百准确度的场景。

HNSW：分层小世界图，召回率高，速度快。适合中小规模（十万到百万级），但内存消耗较大——每百万向量大概需要几 GB 内存。

IVF：倒排索引，把向量分桶，检索时只搜几个桶。适合大规模（百万到亿级），内存效率高，但精度略低——因为可能漏掉不在目标桶里的相关向量。

选型逻辑很直接：数据量小选 FLAT 或 HNSW，数据量大选 IVF。如果你对精度要求特别高（比如医疗诊断），宁可牺牲速度也要高召回率，那就选 HNSW。

延迟优化：从秒级到毫秒级

用户问一句话，Agent 检索记忆、推理、生成回复——每个环节都叠加延迟。满上下文方案之所以慢，就是因为它在推理前要处理超长上下文，p95 延迟能到 17 秒。

优化思路：把检索放到推理前，而且要快。

Redis 作为统一平台能做到亚毫秒级查询。它同时支持向量检索、事件流、KV 存储——工作记忆、情景记忆、语义记忆都能放一个地方，省掉跨服务调用的网络延迟。

另一个坑是”多次推理叠加”。有些设计是：检索 → 用 LLM 整理检索结果 → 再推理回答。两次 LLM 调用，延迟翻倍。更好的做法是：检索结果直接注入上下文，一次推理搞定。

成本控制：10 倍差距的秘密

我前面提过，满上下文 vs 选择性记忆的成本差距是 10 倍。怎么做到的？

核心策略有三条：

选择性记忆：只存有价值的信息，不把所有对话历史都塞进去。抽取阶段过滤掉噪音，存储阶段控制记忆数量。

摘要压缩：原始对话可能几千字，摘要后几百字。用 LLM 定期把情景记忆压缩成精简版本，减少 token 消耗。

智能遗忘：存储会无限膨胀，定期清理低重要性记忆。时间衰减 + 访问频率淘汰，保持记忆池在可控规模。

按 Mem0 官方团队的估算，选择性记忆方案能把月成本从 100 万美元压到 10 万美元——主要是 token 开销和存储成本的下降。

安全与隐私：记忆隔离

记忆系统存的是用户数据，安全设计不能马虎。

记忆隔离：每个用户的记忆独立存储，检索时严格按 user_id 过滤。绝对不能出现”用户 A 检索到了用户 B 的记忆”这种事故。

记忆中毒防御：恶意用户可能故意输入虚假信息，想让 Agent 把错误事实存进记忆。整合阶段要有验证逻辑——低置信度信息标记为”待确认”，不直接写入长期记忆。

数据脱敏：敏感信息（手机号、身份证号）在存储前要脱敏处理。检索后还原时也要有权限控制。

一致性维护：分布式锁 + 反思

多实例部署时，记忆一致性是个问题。实例 A 更新了某条记忆，实例 B 可能还在用旧版本。

两个机制来解决：

分布式锁 + 版本控制：更新记忆前加锁，更新后写入新版本。检索时默认取最新版本，避免读到过期数据。

周期性反思：定期让 LLM 检查记忆库，发现矛盾或过时信息，主动清理或更新。阿里云 AnalyticDB 方案里就内置了这个机制。

结论

说到底，记忆系统不是 Agent 的”可选功能”，而是它区别于普通 LLM 接口的核心能力。没有记忆的 Agent，每次对话都是一次新的认识——它永远无法真正”理解”用户，也无法在长周期任务里保持连贯性。

但装记忆系统也不是一劳永逸的事。你得先想清楚：需要知识图谱吗？能接受托管服务吗？现有框架绑定是什么？这些问题回答完，框架选择自然就清晰了。

如果还拿不准，我的建议是从 LangMem 或 Mem0 开源版开始实验——投入最小，效果最直观。等工作记忆玩熟了，再考虑扩展到情景记忆、长期记忆。

常见问题

Agent 为什么需要记忆系统？LLM 不是已经有上下文了吗？

LLM 的上下文是临时的，对话结束就消失。用户第二天打开同一个对话，Agent 完全不记得之前的内容。记忆系统解决三个问题：跨会话连续性、个性化体验、崩溃恢复。

四种记忆类型有什么区别？分别用什么技术实现？

工作记忆（当前会话，Redis/KV Store）、情景记忆（事件历史，Redis Streams/时序数据库）、语义记忆（知识事实，向量数据库 + 知识图谱）、长期记忆（用户画像，PostgreSQL/MongoDB）。

Mem0、Zep、LangMem 选哪个？

智能客服选 Mem0（知识图谱）、医疗诊断选 Zep（时序事实）、LangGraph 项目选 LangMem（原生集成）、快速原型选 MemoClaw（无配置）。关键是先回答：需要知识图谱吗？接受托管服务吗？

记忆系统怎么控制成本？满上下文太贵了怎么办？

三个策略：选择性记忆（只存有价值信息）、摘要压缩（LLM 定期压缩情景记忆）、智能遗忘（时间衰减 + 访问频率淘汰）。按 Mem0 估算，月成本可从 100 万美元降至 10 万美元。

记忆系统上线要注意哪些安全问题？

记忆隔离（严格按 user_id 过滤，防串号）、记忆中毒防御（验证逻辑 + 待确认标记）、数据脱敏（敏感信息存储前脱敏）、一致性维护（分布式锁 + 周期性反思）。

向量索引选 HNSW 还是 IVF？

数据量小（十万到百万级）选 HNSW，召回率高但内存消耗大；数据量大（百万到亿级）选 IVF，内存效率高但精度略低。医疗等高精度场景选 HNSW。

16 分钟阅读 · 发布于: 2026年4月23日 · 修改于: 2026年4月25日