Agent 的记忆应该如何管理？

核心回答

Agent 的记忆要围绕写入、使用和维护管理。先区分当前会话的短期状态与跨会话保留的长期信息：前者保存任务进度、消息和工具结果，后者选择性保存以后仍有价值的用户偏好、事实或经验。

写入时判断信息是否值得长期保留，并记录来源、时间和适用范围；使用时先按用户、项目等范围筛选，再检索与当前任务相关的记忆，控制进入上下文的内容；维护时处理纠错、冲突、过期、去重和删除。最后用多轮任务验证能否记对、用对、改对、忘掉，而不只检查“数据是否存进了向量库”。

例如用户平时要求中文报告，这可以成为长期偏好；本次临时要求英文，应覆盖当前任务的输出语言，但不应直接改掉长期偏好。

先确定记什么、保存在哪里

短期状态围绕一次会话或任务。 可以保存最近消息、已经调用的工具、阶段成果和未完成事项。状态可用消息历史或 checkpointer 管理；线程标识用于找回对应状态，身份认证与可访问范围仍由应用控制。

长期记忆围绕跨会话仍有用的信息。 例如用户明确表达的稳定偏好、持续中的项目背景、经过核实的工作约定。一般会给记忆增加用户、项目等命名空间，再用键值、文档或向量索引等方式组织。需要按语义查找时才引入向量检索，按确定键读取的偏好不必先做向量搜索。

在 LangGraph 的常见设计里，checkpointer 保存线程状态，Store 可以保存跨线程信息。这里的“长期”首先描述使用范围；InMemoryStore 或 InMemorySaver 仍然是内存实现，需要重启后保留时，应选择持久化后端。

写入：把候选信息变成可维护的记忆

不要把每一轮对话都自动变成长期事实。写入前至少判断信息是否与未来任务有关、是否稳定、依据是否明确，以及它只适用于本次任务、某个项目还是用户全局。

例如“这份报告用英文”属于任务约束；“以后我的报告默认用中文”才明确表达了长期偏好。模型从一次行为推测出的偏好，可以先作为待确认候选，而不是直接覆盖既有记录。

一条记忆除了正文，还应保留来源、创建或更新时间、适用范围，以及按需设置的有效期或失效条件。这样发现回答过时时，能够追到它依据哪次交流，而不只是看到一条来源不明的向量。

简单而明确的偏好可以同步写入；从长任务里提炼经验可以在任务完成后异步处理。选择方式取决于下一轮是否马上要用，以及额外延迟是否值得，不必每轮都增加一次提取模型调用。

使用：从存储中取出，再构建本次上下文

一次合理的使用过程是：先确认可访问的用户和项目范围，再按问题检索候选，过滤过期、重复和不适用的信息，最后在上下文预算内选取内容。命名空间有助于分组，但命名空间字符串本身不会自动完成权限校验。

已经存储，不代表本轮全部交给模型。 原始历史、摘要和检索到的长期记忆，可以按任务需要组合；要保留关键约束、必要证据以及调用与结果的对应关系。上下文压缩方法可结合长对话中的上下文管理展开。

记忆也不是实时业务状态的权威来源。用户之前提到订单未发货，可以帮助识别查询目标；回答“现在发货了吗”时，应查询订单系统。语义相似只说明可能相关，不能证明内容仍然正确。

维护：让变化真正影响后续回答

纠错和冲突要结合来源与范围处理。 用户明确修改长期偏好，可以更新当前有效记录，必要时保留变更依据；临时任务要求只在本次生效。来自另一篇文档的矛盾说法，不能只因为时间较新就覆盖已确认事实，应结合来源、版本和适用条件核对。

去重、整合与过期处理用于降低噪声。 同一事实的多种表达可以合并，但应保留必要出处。旧项目版本、临时安排等信息应能失效；摘要也要随原事实变化，避免原文已经改了，摘要仍持续注入旧结论。

删除要覆盖实际使用链路。 删除主记录后，还应处理向量索引、派生摘要和缓存中的相关内容，或通过统一的失效标记阻止它继续被使用。删除流程应能验证，而不是只返回一个成功提示。

怎样验证管理机制有效？

可以准备一组连续场景：先记住默认中文；另开会话检查是否能取回；本次要求英文，检查是否仅影响本次；再明确修改长期偏好，检查旧记录是否失效；最后删除该偏好，检查后续检索与回答是否仍使用它。

同时加入另一个用户和项目的样本，验证检索范围是否正确。观察有效记忆能否召回、过期或错误记忆是否被引用、回答是否遵守当前要求，以及引入的延迟和 token 成本。指标要与这些场景对应，不能仅用记忆条数增加证明效果提升。

对应教程

参考资料