如果让 Agent 连续处理 50 轮对话之后还能准确记得用户第一次提出的核心需求这件事靠“拼命拼上下文”是做不到的。今天我们把企业级 Agent 的记忆系统整个拆开讲从短期 Context到长期记忆 Long-term Me再分别看 LangChain、LangGraph 以及 DeepAgent 这类深度 Agent 框架各自解决了记忆链路中的哪一段问题。先说结论Agent 记忆不是“把历史消息塞进提示词”而是一套包含存储、检索、写入、更新、遗忘和权限控制的完整数据系统。企业级环境下记忆至少需要解决四个问题存什么、怎么取、何时写、如何忘。文章会先给出一套记忆分层架构再对比 LangChain 传统记忆组件与 LangGraph 状态图方案然后给出可落地的状态定义、持久化配置、记忆读写节点代码示例最后补充权限隔离、隐私合规和常见故障排查清单。适合正在做多轮对话 Agent、智能客服、企业内部知识助手、Agent 平台底层架构的同学。看完你就能判断自己的 Agent 当前缺的到底是模型能力还是记忆治理。1. Agent 记忆系统核心能力速览能力项说明记忆分层短期工作记忆、长期持久记忆、语义记忆、程序记忆状态管理LangGraph StateGraph记忆作为显式状态在节点间流转持久化方案Checkpointer 机制支持 SQLite / Postgres / Redis 等存储后端记忆生命周期写入、更新、检索、过期、遗忘、清理上下文控制摘要压缩、滑动窗口、记忆筛选控制 Token 成本多 Agent 协作主从 Agent 模式子 Agent 本质上作为工具被调用记忆与技能解耦Agent Skill 管理“会做什么”记忆系统管理“记住了什么”工程治理租户隔离、权限控制、敏感信息脱敏、审计日志典型场景客服系统、运维助手、办公助手、知识问答、多轮任务型 Agent这套能力不是某一个框架全部覆盖的。LangChain 提供了模型调用、工具接入和 Prompt 抽象LangGraph 把记忆变成了图中的显式状态DeepAgent 一类框架则在更上层做 Agent 团队的组织、技能注册和治理。实际项目里往往是三者结合使用。2. 从 Context 到 Long-term Me先搭建记忆分层架构很多团队做 Agent 记忆一上来就接向量数据库结果效果不稳定。问题在于记忆本身不是单一结构。参考认知科学的分层方式工程上可以把 Agent 记忆拆成四层。2.1 工作记忆短期 Context工作记忆对应当前任务执行过程中的临时数据比如当前会话最近的几轮消息、上一步工具返回的结果、中间计算出来的临时变量。在 LangGraph 里这一层就是 State 中的 messages 字段它会随图的执行不断更新。工作记忆的特点是生命周期短、变化快、不需要跨会话持久化。它的核心约束是 Token 窗口必须设计淘汰策略否则上下文会无限膨胀。2.2 情景记忆历史会话情景记忆记录用户和 Agent 之间发生过的事件上周问过什么、上次工单处理到哪一步、用户说过哪些关键信息。这一层适合用“摘要 结构化事件”的方式存储。例如每轮对话结束后抽取关键事件写入数据库同时定期生成会话摘要。检索时优先读取摘要需要细节再回查原文。这样可以避免把全部历史对话塞进上下文。2.3 语义记忆用户画像与知识语义记忆是长期稳定的信息用户的偏好、技术栈、业务规则、产品知识库、常见问题的标准答案。这一层在企业场景里价值最高。例如客服 Agent 需要记住用户的会员等级、历史投诉记录、沟通偏好运维 Agent 需要记住不同系统的负责人和变更窗口。语义记忆通常是结构化和向量化混合存储用用户 ID 和业务标签做过滤再用向量检索做相似度匹配。2.4 程序记忆技能与流程程序记忆解决的是“怎么做”的问题调用哪个工具、按什么顺序执行、遇到异常走哪条分支。在工程上对应 Agent Skill、工作流定义、Prompt 模板和 Tool 封装。程序记忆可以理解为 Agent 的方法库。它和上面三层记忆最大的区别是它不是关于用户的而是关于 Agent 自身能力的。合理的架构应该让程序记忆和用户记忆分开管理否则技能更新会污染用户数据用户数据变化也会影响技能发布。长期记忆 Long-term Me 的本质就是用户画像、历史事实、偏好习惯和 Agent 自身技能沉淀后的综合结果。工程上实现起来就是上面四层记忆的读写接口和存储设计。3. 为什么长上下文替代不了记忆系统自从各家模型把上下文窗口做到 128K、200K 甚至 1M 之后有个声音一直存在还需要什么记忆系统直接把历史都放进去不就行了。这里要分清一个关键问题上下文窗口是“容量”记忆系统是“组织方式”。容量再大也不代表模型能有效利用。第一个问题是成本。假设每次请求携带 50 轮历史对话Token 消耗会随轮数线性增长。在多轮任务型 Agent 里一次任务可能涉及 10 轮以上的内部推理和工具调用如果每轮都全量携带历史成本会快速失控接口响应延迟也会明显升高。第二个问题是有效检索。大模型面对超长上下文时对早期信息的注意力权重可能衰减。与其让模型在 20 万 Token 里自己找关键信息不如提前用检索把最相关的 5 条记忆筛选出来直接注入系统提示词。这相当于在模型前面加了一道索引。第三个问题是生命周期管理。上下文没有“遗忘”概念但真实世界的用户信息是会过期的。用户换了手机号、改了偏好、撤回了投诉记忆系统要支持更新和删除。长上下文方案做不到这一点你不可能在历史消息里精准修改一条记忆。第四个问题是多用户隔离。上下文方案天然是单用户、单会话的。企业级场景需要一套统一的记忆服务让不同 Agent、不同租户、不同会话都能访问和理解同一份用户数据同时又保证隔离和权限。这是长上下文方案完全无法覆盖的。所以更稳妥的设计是上下文窗口只承担“当前正在处理的短期信息”跨会话的信息全部交给记忆系统管理。4. LangChain 记忆组件从 BufferMemory 到链式上下文LangChain 很早就意识到记忆的重要性提供了一批经典记忆组件。这些组件到今天仍然有参考价值但也存在明显的工程边界。组件机制适用场景局限ConversationBufferMemory缓存全部对话历史短对话、演示 Demo上下文无限增长ConversationBufferWindowMemory只保留最近 N 轮轮数可控的对话会丢失早期关键信息ConversationSummaryMemory用摘要替代原始对话长对话压缩摘要质量不稳定ConversationSummaryBufferMemory窗口内保留原文窗口外转摘要折中方案实现复杂无法跨会话VectorStoreRetrieverMemory向量库检索相关历史信息分散的长对话依赖 embedding 质量从设计思路上看LangChain 的记忆组件解决的是“一条链上怎么带历史信息”。这在早期原型验证阶段很有效但到了企业级场景问题就暴露了。第一个问题是记忆与调用强耦合。记忆组件挂在 Chain 内部你想让多个 Agent 共享同一份用户记忆需要复制整个 Chain 的结构很难复用。第二个问题是检索后置。很多实现是先把历史塞进 Prompt让模型自己理解而不是提前做精准的检索和筛选导致 Token 利用率低。第三个问题是缺少生命周期管理。组件更多关注“读”对“什么时候写入、什么时候更新、什么时候过期”没有统一约束。第四个问题是没有图状流程。链式结构只能顺序执行无法表达“先判断是否需要记忆再决定走哪条分支”这种条件逻辑。所以 LangChain 解决的问题是“Agent 能调用模型和工具”记忆系统的真正工程化要看 LangGraph 这类状态图方案。5. LangGraph 的工程化记忆状态图 检查点持久化LangGraph 和 LangChain 最大的区别可以概括为一句话LangChain 组织一次调用LangGraph 维护一套状态。在 LangGraph 里Agent 的执行过程是一张有向图每个节点负责一个具体任务节点之间通过 State 共享数据。记忆在这里不是一个外挂组件而是图状态的一部分。这个设计带来的直接好处是读写记忆的时机可以精确控制哪些节点需要记忆、哪些不需要由图的边和条件路由显式决定。5.1 用 State 定义记忆数据契约先定义一个包含记忆字段的 Agent State。from typing import TypedDict, Annotated from langgraph.graph.message import add_messages class AgentState(TypedDict): # 短期工作记忆当前会话消息通过 add_messages 自动合并 messages: Annotated[list, add_messages] # 记忆归属者用于长期记忆隔离 user_id: str # 本次从长期记忆中检索到的内容 memories: list[str] # 本次检索命中的记忆 ID方便后续更新或回写 memory_ids: list[str] class MemoryInput(TypedDict): user_id: str query: str class MemoryOutput(TypedDict): memories: list[str] memory_ids: list[str]这里把 messages 定义为带合并逻辑的字段LangGraph 会自动把新旧消息拼接到一起。user_id 是记忆隔离的关键字段所有长期记忆读写都必须带上它。5.2 Checkpointer让记忆跨会话持久化LangGraph 的 Checkpointer 是记忆工程化最重要的机制。它把图的完整状态按 thread_id 持久化这意味着 Agent 跑一半中断了可以恢复执行用户隔天再来系统还能从 state 里恢复上一次的上下文。from langgraph.checkpoint.sqlite import SqliteSaver # SQLite 持久化轻量场景足够 checkpointer SqliteSaver.from_conn_string(agent_memory.db)生产环境如果并发量大可以换用 Postgres 或 Redis 作为 checkpoint 存储。选择标准是checkpoint 只解决“状态恢复”不解决“语义记忆检索”。长期记忆的向量检索需要单独的向量库。5.3 记忆读取节点检索并注入上下文下面实现一个记忆读取节点从长期记忆服务中检索与当前问题相关的历史信息并写入 State。def load_memory_node(state: AgentState) - AgentState: # 取当前用户最新一条消息作为检索 query实际项目可拼接多轮关键信息 query state[messages][-1].content # 调用统一记忆服务强制按 user_id 过滤 memory_hits memory_service.retrieve( user_idstate[user_id], queryquery, top_k5, filters{tenant_id: tenant-001}, ) return { memories: [item.content for item in memory_hits], memory_ids: [item.id for item in memory_hits], }注意检索必须按 user_id 过滤这是防止“记忆串号”的第一道防线。5.4 条件路由按需决定是否读记忆不是每一轮都需要访问长期记忆。比如用户只是说“你好”没必要查询向量库。通过条件路由可以降低延迟和成本。def should_load_memory(state: AgentState) - str: last_message state[messages][-1].content # 简单规则消息过短或纯打招呼跳过记忆检索 if len(last_message.strip()) 4: return skip_memory # 也可以在这里接入意图识别判断是否需要长期记忆 return load_memory再把这个条件路由接到图的边上面from langgraph.graph import StateGraph, START, END graph_builder StateGraph(AgentState, inputMemoryInput, outputMemoryOutput) graph_builder.add_node(load_memory, load_memory_node) graph_builder.add_node(agent, agent_executor) graph_builder.add_conditional_edges( load_memory, should_load_memory, { load_memory: load_memory, skip_memory: agent, }, ) graph_builder.add_edge(START, load_memory) graph_builder.add_edge(agent, END) app graph_builder.compile(checkpointercheckpointer)条件路由对应了 LangGraph 教程里常说的 conditional_edge 分支控制。在记忆系统里它的价值是让记忆读取变成一种“按需资源”而不是每轮都执行。5.5 记忆写入异步化避免阻塞主流程记忆写入不能放在主链路里同步执行否则一次向量化 入库可能会拖慢整个响应。更稳妥的方式是在主图里生成待写入的记忆事件然后推入异步队列由后台 worker 处理。from langchain_core.messages import HumanMessage def collect_memory_event(state: AgentState) - AgentState: # 将关键信息发送到异步队列不阻塞主流程 if should_write_memory(state): memory_queue.enqueue( { user_id: state[user_id], messages: state[messages][-5:], memory_ids: state[memory_ids], } ) return {}这里的 memory_queue 可以是 Redis Stream、RabbitMQ 或者 Kafka。核心思想是主流程只负责生成记忆事件写入、向量化、去重、过期处理全部放到后台。这样即使记忆服务短暂抖动也不会影响用户对话。5.6 子图与记忆模块化LangGraph 支持把一组节点封装成子图。记忆相关节点完全可以独立成子图在主图中作为模块引用。多 Agent 场景下可以给每个 Agent 挂上同一个记忆子图实现记忆读写逻辑的统一复用。这比 LangChain 时代把记忆耦合在 Chain 内部要清晰得多。6. DeepAgent 框架的组织方式记忆与技能解耦从目前公开的方向看DeepAgent 一类深度 Agent 框架的重点已经不在“怎么调用一次模型”而在“怎么组织和维护一个 Agent 团队”。6.1 主从 Agent 与 SubAgent 的本质现在很多 AI Agent 项目里你会看到 Supervisor、Planner、Executor、Critic 等多种角色并存。这种主从模式的工程本质其实并不神秘主管 Agent 把子 Agent 当作一种特殊的 Tool 来调用。子 Agent 接收任务描述返回执行结果主管 Agent 负责综合判断。在 LangGraph 里主从模式可以表达为主管节点通过工具调用接口触发子图执行子图内部再走自己的状态流。子 Agent 的“记忆”不再混在主管 Agent 的上下文里而是放在子图自己的 State 中按需持久化和恢复。6.2 Agent Skill 与记忆的关系近期热词里 Agent Skill 出现频率很高。Skill 和记忆是两个不同维度的概念Skill 是“会做什么”记忆是“记住了什么”。一个客服 Agent 可以先注册一个“查询订单状态”的 Skill这是它的能力边界而“用户当前在处理哪一笔订单、多久前联系过客服”则属于记忆供所有 Skill 在执行时共享。这里要区分一下 Agent Skill 和 MCP。Skill 是 Agent 内部对能力的封装和调度方式MCP 是模型与外部工具之间的标准化接入协议。二者可以配合使用用 MCP 接入外部工具能力用 Skill 决定 Agent 在什么场景下如何组合这些能力而记忆系统则负责给 Agent 提供需要的背景信息。6.3 深度框架对记忆治理的启发DeepAgent 这类框架给工程实践带来的最大启发不是某一个具体 API而是治理分层。它把 Agent 的理解拆成“技能层 记忆层 工具层 编排层”每一层独立演进、独立运维。这样当 Agent 数量变多时你不会陷入“为了改一个技能结果污染了所有用户记忆”的泥潭。实际落地时可以先把 LangGraph 作为编排底座把用户语义记忆独立成服务再按 DeepAgent 的思路把公司内部流程封装成 Skill。这个组合既利用了 LangGraph 的状态图能力又保留了上层业务的可扩展性。7. 企业级记忆治理存储、权限、隐私与生命周期记忆一旦进入生产环境就不再只是一个检索问题而是一个数据治理问题。7.1 存储选型记忆类型推荐存储原因短期工作记忆Redis / 内存读写快、TTL 过期好控制会话摘要与结构化事件PostgreSQL事务能力、SQL 检索、权限控制成熟语义记忆向量数据库 PostgreSQL相似度检索 元数据过滤大文件与消息原文对象存储成本低、适合冷数据实际项目里不建议把全部记忆都丢进向量库。向量检索适合语义相似度匹配但精确条件和权限过滤能力弱。结构化的用户画像、业务标签放到关系数据库里更可靠。7.2 记忆 Schema 与版本管理记忆作为数据资产必须考虑 schema 演进。给每条记忆加上 schema 版本、来源、置信度、时间戳和生命周期。{ memory_schema_version: 1.2, memories: [ { id: mem_0a1b2c, user_id: user-42, tenant_id: tenant-001, type: semantic, content: 用户偏好使用简体中文团队技术栈以 Java 为主, source: conversation_20250101_003, confidence: 0.92, created_at: 2025-01-01T10:00:00Z, updated_at: 2025-01-05T14:30:00Z, ttl: 2025-12-31T23:59:59Z, access: [user-42, team-cs] } ] }有了 schema 版本后续升级读取逻辑时可以按版本做兼容。有了 confidence 字段可以对低置信度的记忆做人工复核。7.3 权限隔离与数据安全记忆读取必须做双重校验既要校验调用方身份也要校验数据归属。用户 A 的 Agent 绝对不能检索到用户 B 的记忆哪怕两条记忆语义完全一致。具体落地时所有记忆检索接口都强制要求 user_id 和 tenant_id并且只允许在权限过滤后的集合内做向量检索。如果 Agent 会被部署到企业内部多个部门建议在记忆服务层增加类似 ACL 的能力而不是把权限逻辑散落在各个 Agent 代码里。7.4 遗忘机制与隐私合规长期记忆不是越全越好。企业级场景必须支持用户“被遗忘的权利”用户可以主动要求删除全部历史记忆系统也能在到期后自动清理。另外人脸、声音、身份信息、健康数据等敏感内容在写入记忆服务之前就应完成脱敏和授权确认。测试环境也要使用匿名化数据避免真实用户数据外泄。8. 记忆系统常见问题与排查方法问题现象可能原因排查方式解决方案多轮对话丢失早期信息只依赖短期工作记忆未写入长期记忆检查记忆写入节点是否被跳过在关键节点后增加记忆抽取与异步写入记忆检索命中大量无关内容向量相似度阈值过低查看检索日志中的相似度分数提高阈值增加时间、标签过滤用户之间串记忆检索时未按 user_id 过滤打印实际检索条件强制在检索接口中拼接 user_id记忆写入阻塞对话响应同步执行向量化和入库观察主链路耗时占比改异步队列后台批量写入服务重启后上下文丢失使用了内存 Checkpointer确认 checkpoint 存储位置切换到 SQLite / Postgres 持久化Token 成本快速上涨messages 无压缩策略统计单轮 Token 消耗趋势接入摘要压缩或滑动窗口记忆更新冲突多会话并发写同一条用户记忆检查 updated_at 冲突使用乐观锁或按时间戳覆盖注入记忆后回答质量下降注入记忆过多、top_k 过大对比不同注入条数的效果控制 top_k按业务优先级排序Agent 执行卡死不再响应图中存在循环执行路径查看执行轨迹是否重复访问同一节点设置 recursion_limit增加循环检测排查记忆问题最重要的是可观测性。每条记忆的写入、检索、命中、注入、过期都要有日志和指标。否则出了问题很难判断是模型问题还是记忆链路问题。9. 最佳实践与落地建议先从一条最小闭环开始验证。建议先只做一层语义记忆用户 ID 向量检索 top_k 注入。跑通之后再逐步加入摘要压缩、事件存储、异步写入和权限控制。一次把四层记忆全部设计完的项目往往周期太长反而无法落地。记忆写入要异步、要幂等。同一个用户同一轮对话可能触发多次写入事件后台合并时必须按记忆 ID 或内容哈希去重。另外批量处理记忆时要加失败重试和死信队列避免一条脏数据阻塞整个消费链路。检索注入要有度。top_k 不是越大越好。从实践看注入 3 到 5 条高相关记忆比一次注入 20 条低质记忆效果更好。同时记忆注入后要和当前对话自然融合建议在系统提示词里单独划分一个“已知用户信息”区块让模型明确区分哪些是记忆、哪些是当下输入。敏感信息处理必须在写入之前完成。不要在 Agent 生成回复之后才想起来脱敏那时候敏感信息可能已经出现在日志和输出链路里了。比较稳妥的做法是在记忆写入服务入口统一做 PII 检测和脱敏。做 A/B 测试验证记忆价值。给一部分用户开启记忆系统另一部分关闭对比任务完成率、重问率、平均对话轮数。记忆系统不是拍脑袋上的要用数据证明它确实降低了用户重复描述成本。最后建议定期做记忆审计。检查是否存在过期记忆、重复记忆、错误记忆和越权访问。记忆系统和数据库一样需要运维和治理不是部署完就能一直跑。10. 总结与下一步如果你现在准备在企业项目里上 Agent 记忆建议按这个顺序验证第一步用 LangGraph 把记忆做成显式 State接入 Checkpointer 实现跨会话恢复第二步把记忆读写独立成服务按用户隔离第三步再引入 Agent Skill 体系把技能和记忆解耦治理。最先应该验证的功能是用户隔天回来Agent 还能记得他上次的需求和偏好。这是记忆系统最基本的价值。最容易踩的坑是检索时忘记加用户过滤导致记忆串号这会让用户对系统的信任感直接归零。后续可以扩展的方向包括多 Agent 之间的记忆共享与冲突解决、基于时间衰减的遗忘策略、记忆注入效果自动评估、以及面向不同业务领域的记忆 Schema 标准化。记忆系统的本质是一套有权限、有生命周期、可观测、可治理的数据基础服务。把它当成数据工程来做Agent 的质量才能稳定把它当成提示词拼接来做上线越久问题越多。