AI Agent记忆系统实战：从LangGraph到生产级落地

1. 为什么"记住你"成了Agent落地的生死线

先讲一个我实际遇到的场景。半年前我在帮一个团队做客服Agent的PoC，功能跑得很顺：意图识别、工具调用、工单流转全部打通，Demo演示时客户当场点头。结果上了小流量真实用户之后，反馈一片狼藉——用户抱怨"这AI是不是失忆了？我上一条刚说完会员卡号，下一条它又问我卡号是多少"。技术负责人跑来找我排查，我打开对话日志一看，问题一目了然：Agent确实在单轮对话里表现得像个专家，但一旦话题跨越两三轮，它就彻底回到了"初次见面"的状态。

这就是AI Agent记忆缺失的典型症状。市面上的大模型本身有上下文窗口，但那个窗口是"用完即焚"的。你关掉对话、切换会话、或者上下文被截断之后，模型对你的一切认知都会归零。对于一个生产级Agent来说，这根本不是体验问题，而是能不能用的功能性问题。

我们在社区里聊AI Agent时，经常会把"记忆"挂在嘴边，但很少有人认真去分：Agent需要记住的到底是什么？是记住你上次说过的一句话？是记住你的偏好？还是记住它自己执行到哪一步了？

从工程角度看，我把Agent记忆拆成四个层次，这也是后面所有设计和排障的基础：

绝大多数初级Agent项目只做了第一层，会话一关就什么都不剩。真正能让用户产生"这AI懂我"感受的，是第三层长期语义记忆。本文的核心就是围绕这一层展开：怎么让Agent跨会话记住用户、记住事实、记住偏好，以及在这个过程中会踩到哪些坑。

这篇文章适合谁看？适合那些已经跑通了基础Agent调用、正在做产品化落地的开发者。你不需要是算法专家，但最好对LangGraph这类编排框架有基本认知。我会把记忆系统的设计思路、代码级实现方案、以及生产环境中的坑位全部摊开来讲。

2. 先搞清楚Agent的"记忆"和大模型上下文不是一回事

2.1 上下文窗口只是"草稿纸"，不是"笔记本"

很多人有个误区：觉得只要把历史对话全部塞进Prompt，Agent就有记忆了。这个思路在演示阶段确实成立，但在生产环境里会迅速撞墙。

首先是成本墙。GPT-4级别的模型，输入token是按量计费的。假设用户每天和Agent聊30轮，每轮平均800 token，你把全部历史都塞进去，第二个月账单出来的时候，老板的脸色不会好看。其次是质量墙。上下文越长，模型对早期信息的注意力越稀薄，这在业界有个很直白的说法叫"Lost in the Middle"。你把30轮历史全部塞进去，模型真正关注的往往是最后两轮的内容，早期的用户偏好反而被淹没了。最后是架构墙。多个Agent协作时，每个子Agent需要的信息维度完全不同，全量历史广播式地塞给所有Agent，既不安全也没效率。

所以我一直强调一个观点：上下文窗口是草稿纸，记忆系统才是笔记本。草稿纸负责当前这一步的计算，笔记本负责跨步骤、跨会话的信息沉淀。两者是分工关系，不是替代关系。

理解了这一点，再看市面上的Agent框架，你会发现它们其实都在做同一件事：帮你在"草稿纸"和"笔记本"之间建立一个同步机制。LangGraph的State机制解决的是单次任务内的短期工作记忆，Checkpointer解决的是任务中断后的恢复，而真正面向"记住用户"这个需求的，是持久化的长期记忆层。

2.2 长期记忆的两条实现路线：显式存储与隐式嵌入

顺着"笔记本"这个比喻继续往下走，你自然要问一个问题：笔记本上应该记什么？

业界目前有两条路线。

第一条是结构化显式记忆。把用户信息提炼成结构化的字段存起来，比如"用户ID: 12345，偏好：价格敏感型，历史订单：3单，上次投诉原因：物流慢"。这种记忆的优点是精确、可解释、可控。缺点是提炼规则需要人工设计，而且覆盖不了那些很难结构化表达的、模糊的用户特征。

第二条是语义向量记忆。把用户的历史对话、行为序列通过Embedding模型转换成向量，存进向量数据库，需要时用相似度检索把最相关的记忆片段捞出来塞进Prompt。这种记忆的优点是覆盖全面、无需人工设计规则，模型说什么都能存。缺点是检索结果不可控，可能捞回一堆噪音，而且向量本身不可解释，出了问题很难排查。

真实生产环境里，两条路线不是二选一，而是混着用的。我的实践经验是：能用结构化表达的用结构化，表达不了的用向量兜底。比如用户的收货地址、会员等级、订阅状态，这些必须精确存储，绝对不能靠向量相似度去"猜"；而用户随口说的一句"最近在健身，想控制饮食"，这种模糊偏好适合向量化，等哪天他问外卖推荐时，这条记忆就该被捞出来发挥作用。

2.3 记忆写入的时机：不是所有对话都值得记

明确了存什么，接着要解决什么时候存。很多初次做记忆系统的开发者会犯一个特别天真的错误：把所有对话全量写入记忆库。结果就是记忆库变成垃圾场，检索出来的都是一堆"嗯""好的""谢谢"这种毫无信息量的内容。

我的做法是设置一道"记忆写入过滤器"，可以从三个维度来判断一条信息是否值得写入长期记忆：

• 事实性：这句话包含可验证的事实吗？"我住在上海"值得记，"今天天气不错"不需要记。
• 稳定性：这个信息在时间维度上是稳定的吗？"我喜欢喝美式"值得记，"我今天想喝杯奶茶"不必记。
• 行动相关性：这条信息在未来可能影响Agent的行为吗？"我对乳糖不耐受"值得记，"我昨晚熬夜了"不一定需要记。

判断这个过滤逻辑，可以用模型来自动完成。在LangGraph里加一个判断节点，让大模型对每轮对话产出一个结构化的"记忆提取结果"，交给下游的记忆写入模块。这样做的token开销并不大——你只需要把当轮对话给模型，让它输出JSON，包含should_remember和memory_content两个字段即可。

说到底，记忆系统的质量取决于写入质量。写入侧不设防，检索侧再怎么优化都是白搭。这一条，请务必刻在脑子里。

3. 实操：用LangGraph构建一套可落地的Agent记忆系统

3.1 基础版：Checkpointer让Agent记住"做到哪了"

在进入长期记忆之前，先把短期工作记忆这块地基打牢。LangGraph里最容易被忽略、但价值极高的组件就是Checkpointer。

它的作用是：把Agent在图中的状态（State）持久化到存储后端。当任务中断、报错、或者需要恢复时，可以从最近的检查点恢复执行，而不是从头再来。

from langgraph.graph import StateGraph, START, END from langgraph.checkpoint.sqlite import SqliteSaver # 内存型checkpointer，适合开发和测试 # 生产环境建议替换为PostgreSQL的checkpointer实现 checkpointer = SqliteSaver.from_conn_string(":memory:") # 构建一个带持久化的Agent图 builder = StateGraph(AgentState) builder.add_node("agent", call_model) builder.add_node("tools", execute_tools) builder.add_edge(START, "agent") builder.add_conditional_edges("agent", should_continue, {"continue": "tools", "end": END}) builder.add_edge("tools", "agent") graph = builder.compile(checkpointer=checkpointer) # 用thread_id标识一个会话，这是记忆隔离的关键 config = {"configurable": {"thread_id": "user-123-session-456"}} result = graph.invoke({"messages": [{"role": "user", "content": "帮我查一下上月账单"}]}, config=config)

注意这里的thread_id，它就是短期记忆的"主键"。同一个thread_id下的多次调用，共享同一个状态快照。这意味着即使用户隔了三天重新发起对话，只要thread_id不变，Agent依然记得上次执行到哪一步。

但我要泼一盆冷水：Checkpointer只是让Agent记住了"自己做过什么"，并没有记住"用户是谁"。它是基础，不是全部。

3.2 进阶版：向量记忆库让Agent记住"用户是谁"

接下来是重头戏：长期语义记忆。我把实现拆成三个模块——写入、检索、注入。

写入模块的核心是一个"记忆提炼"节点。每次对话结束后，把新增的对话内容发给模型，让模型判断有没有值得记住的信息：

from openai import OpenAI import numpy as np from pymilvus import MilvusClient client = OpenAI() milvus_client = MilvusClient(uri="http://localhost:19530") MEMORY_EXTRACTION_PROMPT = """ 你是一个记忆提取引擎。根据用户的对话内容，提取值得长期记住的信息。 要求： 1. 只提取事实性、稳定性、行动相关性高的信息 2. 过滤寒暄、即时情绪、无效内容 3. 输出JSON数组，每个元素包含 type（属性/偏好/事实/关系）和 content（简洁的中文描述） 对话内容： {conversation} 输出： """ def extract_and_store_memory(conversation_text: str, user_id: str): response = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": MEMORY_EXTRACTION_PROMPT.format(conversation=conversation_text)}], response_format={"type": "json_object"} ) memories = json.loads(response.choices[0].message.content).get("memories", []) for mem in memories: if not mem.get("should_remember", True): continue embedding = client.embeddings.create( model="text-embedding-3-small", input=mem["content"] ).data[0].embedding milvus_client.insert( collection_name="user_memory", data=[{ "id": generate_uuid(), "user_id": user_id, "content": mem["content"], "type": mem["type"], "vector": embedding, "timestamp": int(time.time()) }] )

这里有几个细节值得展开说。第一，Embedding模型我推荐用text-embedding-3-small而不是text-embedding-3-large，因为记忆碎片通常很短，小模型足够产生有效的语义向量，而成本只有大模型的一小部分。第二，向量数据库选型上，开发阶段用Chroma或者Milvus Lite都行，生产环境我建议Milvus或Qdrant，PostgreSQL+pgvector也可以，看你们基础设施的熟悉程度。第三，每条记忆都要带user_id，这是记忆隔离的第一道防线，多用户场景下绝对不能省。

3.3 检索与注入：如何让记忆在正确的时机"被想起"

检索模块负责在每次对话开始时，根据用户当前的输入去向量库捞相关的历史记忆。这里有个关键参数是top_k，决定了捞多少条记忆。捞少了记不住关键信息，捞多了会把Prompt撑爆。

我常用的检索策略是混合检索：向量相似度为主，时间衰减为辅。一条记忆如果是一年前存的，它的参考价值通常低于昨天的记忆。可以在检索时对分数加一个时间衰减因子，让新记忆有更高概率被捞出来。

def retrieve_memories(user_id: str, query: str, top_k: int = 5) -> list[str]: query_embedding = client.embeddings.create( model="text-embedding-3-small", input=query ).data[0].embedding results = milvus_client.search( collection_name="user_memory", data=[query_embedding], filter=f"user_id == '{user_id}'", limit=top_k, output_fields=["content", "timestamp"] ) memories = [] for hit in results[0]: # 时间衰减加权：30天衰减到0.5 age_days = (time.time() - hit["entity"]["timestamp"]) / 86400 decay = 0.5 ** (age_days / 30) score = hit["distance"] * decay memories.append((score, hit["entity"]["content"])) memories.sort(key=lambda x: x[0], reverse=True) return [content for _, content in memories[:top_k]]

最后是注入模块。把检索到的记忆拼接到系统提示词里，让Agent在回答问题时"带着记忆"思考。这块要注意的是格式设计，我习惯把记忆放在整个Prompt的最前面，用明确的标记框起来：

你是用户专属的AI助理，以下是关于用户的长期记忆： <memory> - 用户住在上海，工作在陆家嘴 - 用户对乳糖不耐受，点咖啡时偏好燕麦奶 - 用户近期在备考CFA，希望周末不要被打扰 </memory> 请基于这些记忆，结合用户的当前问题，给出个性化回复。 当前问题：{current_query}

注入的位置不能放在对话历史后面，必须放在系统层。实践中我踩过一个坑：把记忆放在对话历史末尾，结果模型把它当作用户刚说的话，反而造成了混乱。记忆是前提条件，不是对话内容，这个身份必须分清。

3.4 记忆的更新与遗忘：只进不出的记忆库就是定时炸弹

很多人做到检索注入这一步就觉得完事了。但真正上线之后你会发现，只进不出的记忆库会在两周内变成一团浆糊。

用户是会变的。半年前他喜欢喝全糖奶茶，现在他健身减脂改喝无糖美式了。如果你不更新旧记忆，Agent会永远用半年前的偏好来服务他。有些用户甚至会为此发火："我都说了多少次我不喝全糖了，这AI怎么还给我推荐全糖？"

所以记忆系统必须加上两个机制：冲突消解和遗忘策略。

冲突消解的逻辑不复杂：新写入一条记忆时，先用它的语义向量去库里检索有没有同用户的高相似度旧记忆。如果相似度超过某个阈值，就把它当作旧记忆的更新，而不是新增一条。

def upsert_memory(user_id: str, new_mem: dict, conflict_threshold: float = 0.92): conflicts = milvus_client.search( collection_name="user_memory", data=[new_mem["vector"]], filter=f"user_id == '{user_id}'", limit=3, output_fields=["id", "content"] ) for hit in conflicts[0]: if hit["distance"] > conflict_threshold: # 替换旧记忆 milvus_client.delete( collection_name="user_memory", ids=[hit["id"]] ) break milvus_client.insert( collection_name="user_memory", data=[{**new_mem, "user_id": user_id}] )

遗忘策略则更偏运营侧。我的建议是设置一个"记忆保鲜期"，比如180天未激活的记忆自动降权或归档。对于涉及隐私敏感的信息（后面第4章会细说），还需要支持用户手动删除。

这一套写入—检索—注入—更新的闭环跑通之后，Agent才算是真正"记住"了用户。别急着高兴，这还只是单机版记忆系统。多Agent协作、多租户隔离、隐私合规这些生产级课题，才是真正拉开工程水平差距的地方。

4. 生产环境中记忆系统的四个大坑

4.1 记忆污染：Agent"精分"的根源

记忆系统上线两个月后，你大概率会遇到一个新问题：Agent变得"精分"了。同一个用户，这次问它推荐餐厅，它推荐川菜；下次问同样的问题，它推荐粤菜。原因就是记忆库里同时存在"用户喜欢吃辣"和"用户口味清淡"两条互相矛盾的记忆。

这个问题的根源在于写入侧没有做好冲突检测，或者上游的信息本身就是噪音。比如用户某天随口说了句"最近在吃清淡点"，这个信息如果被当成稳定偏好写入，就会和之前真正的口味偏好打架。

应对方案有三层。第一层是写入侧增加真实性校验：对于"用户声称某偏好"的信息，尽量标记为候选记忆而不是正式记忆，等出现第二次佐证时才转正。第二层是本章3.4讲的冲突消解，写入时主动检索相似记忆。第三层是定期做记忆一致性审计，用模型扫描记忆库，标记矛盾项交给运营确认。三层都做到，基本能消除80%以上的记忆污染问题。

4.2 检索失效：向量相似度不是万能的

向量检索最大的软肋是语义鸿沟。用户在Agent里的对话是分散的碎片："我上次说的那个项目""帮我改一下之前那份文档"。这种指代性表达，单靠用户当前这句话去做向量检索，很难命中真正相关的历史记忆。

我的做法是给检索加一层"改写"逻辑：先把用户当前的问句发给大模型，转成一个更完整的检索语句，再做向量检索。比如用户说"帮我改一下之前那份文档"，改写模块会把它变成"用户需要修改之前提过的那份关于XX项目的评审文档"，这样的向量检索命中率会高很多。

另外，对于那些高度结构化的记忆（比如用户ID、订单号、收货地址），不要走向量检索，直接走关系型查询。向量检索处理的是模糊语义，结构化查询处理的是精确事实，各管一摊，别混着用。

4.3 隐私与合规：记忆越强，责任越大

这是我在企业客户那边最常被问到的话题：Agent记住了用户的个人信息，这在合规上站不站得住脚？

必须得说清楚：记忆系统天然伴随数据存储，而数据存储天然受隐私法规约束。你存了用户的偏好、地址、行为记录，就意味着你有义务保护这些数据不被泄露，也有义务响应用户的删除请求。在设计阶段就要把这三个机制做进去：

• 数据加密：记忆库中的敏感字段必须加密存储，至少做到传输层TLS。
• 记忆可见性：给用户提供查看Agent记住了他什么的界面。很多团队不做这个，用户被问起来时根本不知道AI存了自己的什么信息，信任感很差。
• 一键遗忘：提供"清除我的所有记忆"的功能。这个不只是合规要求，对产品体验也是加分项。我见过有产品因为提供了这个功能，用户反而更愿意让Agent记住信息——因为知道自己随时可以反悔。

4.4 多Agent共享记忆：协作和隔离的边界

在复杂Agent系统里，往往不是单个Agent在服务用户。你可能有一个主Agent负责对话，一个子Agent负责查订单，另一个子Agent负责推荐商品。这些Agent之间，记忆该怎么共享？

我的建议是：共享记忆要按需最小化。主Agent可以访问用户的完整记忆画像，但订单子Agent只需要读取和订单相关的记忆，推荐子Agent只需要读取偏好类记忆。给他们各自配一个Memory View，类似数据库里的视图（View），只暴露该Agent需要的那部分记忆。这样既实现了协作，又把信息泄露的风险控制在最小范围。

技术上可以用记忆内容里的type字段做粗粒度隔离，也可以用标签系统做更细的权限控制。这块没有标准答案，但原则是确定的：能不给的权限就不给，记忆的读取面越小越安全。

5. 可选技术路线：成熟的记忆框架该怎么用

如果你不想从零手写这套记忆系统，目前市面上有几套现成的框架可以选。我用过的有Mem0、Zep和LangMem，简单说一下它们的差异和选型建议。

5.1 记忆框架对比

我个人更倾向于在LangGraph项目里自研记忆层，因为LangMem目前的能力边界还比较窄，而实战中的记忆系统往往需要深度定制。但如果你是快速验证产品想法、或者团队人手不足，直接集成Zep会省不少事。

5.2 混合记忆架构的参考设计

这里分享一下我在一个实际项目里用到的分层记忆架构，它是一个通用参考模式：

• 第一层：Redis缓存，存当前会话最近20轮的消息，保证对话连贯性。
• 第二层：PostgreSQL，存结构化用户画像（显式记忆），包括用户填写的资料、订单记录、状态标签。
• 第三层：向量数据库（Milvus），存非结构化语义记忆（隐式记忆），包括对话中提炼的偏好和事实。
• 第四层：摘要记忆（定期生成），当对话历史超过窗口长度时，把前面的对话压缩成摘要存进向量库，需要时再捞出来。

每一层的写入侧都有独立的触发策略，比如第一层是每条消息都写，第二层是业务事件触发，第三层是记忆提炼模型触发，第四层是达到上下文长度阈值时触发。这个架构的好处是每一层各司其职，出问题时方便定位，也方便按层做容量规划和成本控制。

5.3 记忆系统上线后的"体检指标"

最后补充一个运营细节。记忆系统不是上线就完事的，它需要持续的指标监控。我建议至少盯住这几个数据：

• 记忆唤起率：检索结果中被模型实际用到的比例。过低说明检索或注入环节有问题。
• 记忆冲突率：同一用户记忆库中矛盾条目占比。超过5%就要检查冲突消解逻辑。
• 记忆冗余度：包含重复信息的记忆条目比例。过高说明写入侧过滤不足。
• 用户遗忘请求率：用户主动清除记忆的频次。异常增长往往是隐私信任危机的前兆。

这些指标的采集需要在前面的代码基础上加一点埋点，成本很低，但价值非常高。它能把模糊的"记忆系统状态"变成可量化、可报警的数字，让你在出问题之前就发现隐患。

6. 一些想留给你的实操建议

写到这里，把几个我反复踩过、最终沉淀下来的操作心得列在下面，希望能帮你少走弯路。

第一，记忆系统的第一版不要追求大而全，先只记住"用户明确说过、且近期还会用到的信息"。我见过太多团队一上来就做全量对话语义记忆，结果成本高、效果差、还难调试。从最小可用集开始，上线上之后根据用户反馈逐步放开写入范围，这是最稳的路径。

第二，给每条记忆打上可信度标签。这个标签可以来自提取时模型的self-confidence，也可以来自"该信息被提及的次数"。每被提及一次，可信度加一。低于某个阈值的记忆在检索时降权。这个机制能显著改善4.1说的记忆污染问题。

第三，记得做记忆的版本控制。当用户明确说"我之前说的那个偏好改了"时，你要能定位到旧记忆的条目、把新的覆盖上去，并在必要时留下变更日志。这不只是为了技术上的正确，还是为了将来做合规审查或运营回放时有据可查。

第四，Prompt里注入记忆时，明确告诉模型"这些信息仅供参考，以用户当前表述为准"。人的偏好是动态的，模型如果死板地执行旧记忆，反而会激怒用户。给模型一个"允许违背旧记忆"的心理暗示，能减少很多奇怪的行为。

第五，也是我个人最重要的体会：记忆系统的意义不在于"记住更多"，而在于"在正确的时间想起正确的事"。把80%的精力花在检索质量和写入过滤上，比花在扩大存储容量上更值得。存储便宜，但误召回和记忆污染造成的体验伤害，是很贵很贵的。

如果你正在做Agent产品，我强烈建议你把记忆系统当成一等公民来设计，而不是最后补丁。它决定了你的Agent是一个"会聊天的接口"，还是一个"越来越懂你的伙伴"。这两者之间的差距，恰恰就是用户留存率的差距。