AI Agent的三重记忆机制：打造高可用的多维记忆系统

没人提前规划的记忆问题

大多数 AI Agent 项目都从模型开始。该用哪个模型？是用 GPT、Claude、Gemini、Llama，还是本地部署的模型？要不要加工具？要不要加 function calling？要不要让它自主运行？

然后，第一个生产问题出现了。

Agent 忘记了用户上周说的话；从错误的文档里给出答案；搞不清哪条政策是最新版；把用户的说法和已核实的事实混在一起；无法把一个客户、一张工单、一张发票和一次历史对话关联起来；检索到了正确的文档，却漏掉了真正重要的关联关系。

这时候才想到：

"我们需要记忆。"

但"记忆"这个词本身就语义过载。

一个从帮助文档里回答问题的客服机器人，需要一种记忆。一个记住你饮食偏好的个人助理，需要另一种记忆。一个需要关联公司、事件、文件、管理层变动和时间线的金融研究 Agent，需要的又是另一回事。一个跨会话记住架构决策的编程 Agent，需要的则是截然不同的东西。

把这些统称为"记忆"只会导致糟糕的架构设计。

比如说需要个人记忆时却选了 RAG，Agent 会显得健忘。需要有据可查的答案时却选了 Agent Memory，Agent 可能会自信满满地重复未经核实的说法。过早引入知识图谱，则可能在需求尚未验证之前就构建出一套复杂系统。

本文是一份实用指南，帮助你选择合适的记忆层。

RAG，外部知识层

RAG 是检索增强生成（Retrieval-Augmented Generation）的缩写。

基本思路很简单：

1. 用户提出问题。
2. 系统检索相关文档或数据。
3. 检索到的内容传给模型。
4. 模型基于检索内容作答。

OpenAI 的检索文档将检索描述为对向量存储的语义搜索——数据先被索引，然后按语义而非精确关键词进行搜索。

微软 Azure AI Search 的文档将 RAG 描述为一种模式：将 LLM 的回答建立在用户自有内容之上，包括文档、PDF、图片和私有数据源。

简单来说：

RAG 让模型在回答之前有东西可以参考。

对于答案需要来自受控来源的系统，RAG 很有价值。

RAG 适合回答这类问题：

"我们的内容是怎么说的？"

适用场景：

• 公司政策检索
• 产品文档问答
• 法律文件检索
• 客户支持帮助台机器人
• 内部知识库
• 论文辅助阅读
• PDF 摘要
• 标准操作流程助手
• 合规文件查询
• 有强来源管控的医疗或金融内容检索

示例：

用户提问：

"年订阅的退款政策是什么？"

RAG 系统检索退款政策文档，提取相关段落，让模型基于该文本作答。答案不应该来自模型的通用训练数据，而应该来自公司的实际政策——这是一个合适的 RAG 使用场景。

大多数 RAG 系统以 chunk（文本块）的形式存储内容。长文档被拆分成更小的片段，每个 chunk 可能包含：

• 文本
• Embedding
• 文件名
• 页码
• 元数据
• 来源 URL
• 日期
• 访问权限
• 类别或部门

查询进来时系统找出最相关的 chunk，这一环节决定了许多 RAG 系统的成败。

切块方式差，正确答案可能被拆散在不同片段里；元数据差，权限过滤可能失效；索引差，新文档可能不出现在结果里；检索差，模型可能从错误来源作答。

微软的 RAG 综述指出了许多实际内容挑战，包括大型文档、PDF、图片、术语不匹配、相似性搜索、语义排序以及多语言内容。

RAG 不是"上传文档就能问答"这么简单——检索 Pipeline 本身就是核心。

经典 RAG 通常执行一次搜索，将最佳结果传给模型，而Agentic Retrieval 更进一步。

微软 Azure AI Search 的文档将 Agentic Retrieval 描述为针对复杂问题的多查询 Pipeline：LLM 将复杂查询拆解为若干聚焦子查询，分别执行搜索，并返回带有引用和查询详情的结构化 grounding 数据。

示例问题：

"将我们现行的休假政策与旧政策对比，告诉我对孟买员工有哪些变化。"

基础 RAG 系统可能只执行一次搜索。Agentic Retrieval 系统可能将其拆解为：

• 现行休假政策
• 旧版休假政策
• 孟买特定规定
• 两项政策的差异
• 生效日期

这对 Agent 更有价值，因为用户的真实问题往往是多层次的。不过即便是 Agentic Retrieval，本质上也是在寻找来源材料，与用户记忆是两回事。

RAG 的优势

RAG 流行是有道理的。LLM 基于训练时可获取的公开数据训练，不会自动了解你的内部文件、最新政策、私有文档或频繁变动的业务内容。微软 Foundry 的文档将 RAG 描述为结合搜索与 LLM 的方式，使回答建立在用户自有数据之上。

RAG 的优势在于：

• 将答案锚定在经过审批的来源上
• 减少无据可查的回答
• 提供引用来源
• 检索大规模文档集合
• 与现有企业搜索系统集成
• 支持私有数据和频繁变更的数据
• 将来源文档保存在模型之外
• 通过重新索引来更新知识

对许多团队来说，这是合适的起点。构建支持机器人、内部搜索助手、文档问答工具或政策助手，从 RAG 开始就对了。

RAG 的劣势

RAG 有用，但并非万能。在以下情况下会失效：

• 正确文档从未被索引
• 正确的 chunk 未被检索到
• 内容已过时
• 多个文档相互矛盾
• 问题需要跨多个来源推理
• 来源需要结合用户特定情况解读
• 访问权限未得到妥善处理
• Agent 需要记住过去的交互
• 答案依赖关联关系而非文本本身

示例：

用户提问：

"根据我最近三次与客服的对话，我应该选择哪个产品套餐？"

普通 RAG 系统可以检索产品文档，但如果这三次对话没有被存储、摘要并设为可检索状态，它可能无从得知用户的历史对话。这超出了 RAG 的范畴，属于 Agent Memory 要解决的问题。

Agent Memory，个人与工作流层

Agent Memory 关注的是 Agent 从交互中记住了什么。

LangChain 将记忆分为短期记忆（short-term memory）和长期记忆（long-term memory）。短期记忆追踪一个线程内正在进行的对话，长期记忆则跨对话和会话存储信息。

短期记忆回答的是：

"这次对话现在进行到哪了？"

长期记忆回答的是：

"这次对话结束后，有什么需要记住的？"

Agent Memory 适合回答这类问题：

"这个 Agent 应该记住关于该用户、任务或工作流的哪些内容？"

适用场景：

• 用户偏好
• 过去的决策
• 重复性指令
• 写作风格偏好
• 任务进度
• 客户历史
• 对话连续性
• 项目决策
• 个人助理行为
• 长时间运行的研究或编程会话

示例：

用户告诉旅行助手：

"我偏好素食，避免红眼航班，喜欢靠近活动场地的酒店。"

这些信息不应只存进文档库，而应作为用户专属记忆被记住。下次用户说：

"帮我规划去新加坡的行程。"

助手应自动应用这些偏好。这就是 Agent Memory。

一个常见错误是把记忆等同于"每次都发送完整聊天记录"。短对话这样做没问题，长期运行的 Agent 就不行了。

聊天记录越来越长，成本随之攀升；旧有细节可能干扰模型；矛盾信息不断堆积；模型可能无从判断哪条信息仍然有效。

LangChain 的记忆文档提醒：长对话可能超出上下文窗口，增加成本和延迟，旧上下文也可能干扰模型，降低响应质量。

更好的记忆系统需要能决定：

• 什么该存储
• 什么该忽略
• 什么该更新
• 什么该删除
• 什么该被召回
• 什么该被标记为不确定

这比保存对话记录要难得多。

Agent Memory 的类型

Agent Memory 通常有以下几种形态。

1、短期记忆（Short-Term Memory）

即当前对话或任务状态。

示例：

 # 用户正在咨询退款政策。
 # 用户已提供订单 ID。
 # Agent 已查询支付状态。
 # 下一步：说明退款资格。

短期记忆帮助 Agent 在单次会话内保持连贯。

2、长期用户记忆（Long-Term User Memory）

跨会话存储用户级别的事实。

示例：

 # 用户偏好简洁的回答。
 # 用户通常预订经济舱。
 # 用户正在开发一个 React 应用。
 # 用户默认需要 Python 示例，除非另有说明。

LangChain 将长期记忆描述为跨线程持久化的信息，可在之后被召回，通常按命名空间和 key 组织。

3、情节记忆（Episodic Memory）

存储过去发生的事件或交互。

示例：

 # 5 月 12 日，用户询问了定价页面的重新设计。
 # 5 月 14 日，用户批准了最终标题。
 # 5 月 16 日，用户拒绝了深色主题。

这对项目连续性很有帮助。

4、语义记忆（Semantic Memory）

存储持久性的事实。

示例：

 # 用户公司使用 Zoho CRM。
 # 项目使用 Next.js。
 # 首选品牌色为 [#009356](#009356)。

5、程序记忆（Procedural Memory）

存储 Agent 应如何行事。

示例：

 # 撰写博客文章时，先给出标题选项，再列提纲，最后写完整草稿。
 # 编辑代码时，除非被要求，只展示变更部分，不展示完整文件。

这类记忆接近于指令或偏好设置。

Agent Memory 的优势

Agent Memory 让系统具备延续感，可以：

• 减少重复性指令
• 个性化回应
• 延续长期任务
• 记住用户偏好
• 追踪多步骤工作流
• 存储历史决策
• 让 Agent 随时间推移行为更一致

对于个人助理、编程 Agent、写作助手、销售 Agent、客服 Agent 和工作流 Agent 来说，长期使用中记忆是必要组件，不是可有可无的附加项。没有记忆，每次会话都从零开始。

Agent Memory 的劣势

Agent Memory 也会带来新的风险。

• 它可能记错内容。
• 可能存储过多信息。
• 可能保留过时的事实。
• 可能把用户的说法当作已核实的真相。
• 可能造成隐私问题。
• 可能调用出不再适用的旧偏好。
• 可能在用户不需要个性化时反而强加个性化。

LangChain 的长期记忆指南直接说明，记忆没有放之四海皆准的方案，开发者需要自行决定存储什么、何时更新、如何检索——这些问题都没有标准答案。

问题不是：

"Agent 能记住吗？"

而是：

"Agent 该记住这件事吗？之后又该如何使用这条记忆？"

Agent Memory 最重要的规则事：记忆不等于真相。

示例：

用户说：

"我们公司政策允许报销这笔费用。"

Agent 可以记住：

 用户说其公司政策允许报销该费用。

但 Agent 不应将其视为经过核实的政策。要核实，需要通过 RAG 去查询可信来源，例如 HR 政策文档。

职责分工很清晰：

• Memory 存储用户说了什么、做了什么。
• RAG 检索可信来源说了什么。
• 模型决定如何综合两者。

这种分工能防止产生危险的答案。

知识图谱（Knowledge Graph），关联关系层

RAG 检索文本。

Agent Memory 存储有用的事实和历史。

知识图谱存储的是有关联的语义——实体（entity）和关系（relationship）。

示例：

 Dr. Mehta → 就职于 → City Hospital
 City Hospital → 位于 → 孟买
 Dr. Mehta → 参加了 → Webinar A
 Webinar A → 主题 → 退休规划
 Dr. Mehta → 咨询了 → FIRE Planning
 FIRE Planning → 关联 → 退休资金池

区别在于：存储的是关系本身，而不是一个文字段落。当 Agent 需要跨多个关联事实推理时，图谱的价值才真正显现。

知识图谱适合回答这类问题：

"这些事物之间是如何关联的？"

适用场景：

• 实体密集的企业数据
• 法律研究
• 医疗系统
• 金融研究
• 欺诈检测
• 合规监控
• CRM 智能化
• 客户 360 画像
• 代码库架构
• 科学研究
• 多跳推理（multi-hop reasoning）
• 时间推理
• 业务流程映射

示例：

用户提问：

"哪些客户参加了我们的税务研讨会，之后又预约了咨询，并通过孟买分行完成了投资？"

扁平文档检索可能无能为力。知识图谱可以对以下关系建模：

 客户 → 参加了 → 研讨会
 客户 → 预约了 → 咨询
 咨询 → 分配给 → 分行
 客户 → 完成了 → 投资

关系结构本身就是答案。

微软的 GraphRAG 文档将 GraphRAG 描述为一种结构化、层级式的 RAG 方法：从原始文本中提取知识图谱，构建社群层级结构，为这些社群生成摘要，再将这些结构用于检索任务。微软研究院将 GraphRAG 描述为结合文本提取、网络分析、LLM Prompt 和摘要生成，以更好地理解私有文本数据集的方法。

这与普通向量搜索不同。

向量搜索问的是：

"哪些 chunk 在语义上与这个查询相似？"

图检索可以问：

"哪些实体是相互关联的，通过什么关系，它们又属于哪些社群？"

结构决定答案时，差异就在这里。

用于 Agent Memory 的时序知识图谱

一些较新的 Agent Memory 系统正在向时序知识图谱（temporal knowledge graph）演进。

Zep 的 Graphiti 项目将自己描述为一个构建面向 AI Agent 的时序上下文图的框架。它追踪事实如何随时间变化，维护到源数据的溯源信息，并支持预定义和自学习的本体（ontology）。

Zep 论文指出，许多传统 RAG 系统局限于静态文档检索，而企业级 Agent 需要来自对话和业务数据的动态知识。Graphiti 被描述为一个时序感知的知识图谱引擎，能够综合非结构化对话和结构化业务数据，同时维护历史关系。

这一点很重要——现实世界的事实会发生变化。

• 用户可能换了公司。
• 政策可能被替换。
• 客户的风险画像可能改变。
• 支持工单可能已解决。
• 产品功能可能已废弃。
• 医生可能从一家医院转到另一家。

只追加事实的记忆系统可能变得不再准确。时序图谱可以表示：

 用户 2021 年至 2024 年就职于 A 公司。
 用户自 2025 年起就职于 B 公司。

这比简单存储以下内容更有价值：

 用户就职于 A 公司。
 用户就职于 B 公司。

没有时间信息，两条可能看起来都成立。

知识图谱的优势

知识图谱让关系显式化，可以：

• 关联实体
• 追踪关系
• 支持多跳推理
• 表示时间和变化
• 展示溯源信息
• 融合结构化与非结构化数据
• 减少重复的发现工作
• 帮助 Agent 跨业务系统推理
• 支持实体级检索，而不只是 chunk 级检索

对复杂 Agent 来说，这往往能解决根本问题。

知识图谱的劣势

构建知识图谱要求较高，需要处理：

• 实体抽取
• 关系抽取
• Schema 设计
• 去重
• 冲突处理
• 时间处理
• 来源追踪
• 图更新
• 查询策略
• 评估机制

一个糟糕的图谱可能比没有图谱更有害。如果抽取质量差，图谱会自信地将错误的事物关联起来。如果本体（ontology）不清晰，关系就会变得混乱。如果图谱过期，Agent 可能基于旧事实进行推理。如果使用场景只是简单的问答检索，图谱可能是过度设计。

有一条判断原则值得记住：

知识图谱默认不是更好的 RAG，只有当关系本身重要时，它才更好。

如何选择

问题是"来源说了什么？"时选 RAG

当 Agent 需要从可信来源作答时，使用 RAG。

典型示例：

• "这条政策是怎么规定的？"
• "合同里提到了什么？"
• "文档里的配置步骤是什么？"
• "这份 PDF 报告包含哪些内容？"
• "资格要求是什么？"
• "产品手册里是怎么说的？"
• "最新的支持操作指引是什么？"

RAG 是正确的起点，当：

• 有文档可用
• 需要引用来源
• 需要有据可查的答案
• 数据频繁变更
• 不希望只依赖模型训练数据
• 答案需要可追溯到来源

不要想太多。文档问答，从 RAG 开始。

问题是"Agent 应该记住什么？"时选 Agent Memory

当系统需要连续性时，使用 Agent Memory。

典型示例：

• "记住我偏好素食。"
• "继续昨天的项目。"
• "用和上次一样的语气。"
• "别再推荐这个选项了。"
• "你之前已经帮我确定了这个结构。"
• "我目前的目标是完成这次迁移。"
• "这个客户上个月也遇到了同样的问题。"

Agent Memory 是正确的起点，当：

• 用户频繁回访
• 偏好很重要
• 历史交互会影响下一次回答
• 工作流跨会话延续
• Agent 需要项目连续性
• 重复性指令在浪费时间

不要单独用 RAG 解决这类问题。文档检索系统不会自动理解个人延续性。

问题是"这些事物之间如何关联？"时，选知识图谱

当关联关系重要时，使用知识图谱。

典型示例：

• "哪些客户与这个销售周期有关联？"
• "哪些医生参加了这次活动，之后又预约了会面？"
• "哪条合规规则影响哪个产品？"
• "哪些代码模块依赖这个服务？"
• "哪些公司通过董事、投资和子公司相互关联？"
• "哪种疾病与哪种药物、症状和禁忌症相关？"
• "哪条政策取代了旧版，是什么时候？"

知识图谱是正确的起点，当：

• 实体很重要
• 关系很重要
• 时间很重要
• 多跳推理很重要
• 需要结构化的业务上下文
• 需要融合结构化和非结构化数据
• 单纯的文档相似性已不够用

不要因为知识图谱听起来高级就去用它。只有当结构本身能带来实际收益时，才值得投入。

一种简洁的架构模式

许多生产级 Agent 可以从这个架构出发：

 用户问题
↓
短期记忆：检查当前对话
↓
长期记忆：检索用户事实和偏好
↓
RAG：检索可信来源文档
↓
知识图谱：检索实体和关系
↓
工具层：执行计算或操作
↓
 模型：综合所有内容，附带来源引用和约束条件，生成回答

不要在第一天就把所有这些都搭起来。从与核心问题最匹配的那一层开始，只在需要时再逐步添加。

阶段一：从 RAG 开始

有文档的话，从这里开始。构建：

• 良好的数据摄入（ingestion）
• 良好的 chunk 切分
• 元数据
• 来源引用
• 权限过滤
• 评估问题集
• 重新索引流程

第一个版本做到这些就够了。

阶段二：加入 Agent Memory

当用户开始回访并期待连续性时，加入记忆。构建：

• 短期对话状态
• 长期用户事实
• 偏好存储
• 更新规则
• 删除规则
• 记忆审查流程
• 隐私处理

不要存储所有内容。只存储能改善未来回应的信息。

阶段三：加入知识图谱

当关联关系开始成为瓶颈时，加入图谱。构建：

• 实体模型
• 关系类型
• 来源溯源
• 时间处理
• 去重
• 图查询模式
• 评估示例

当简单检索已无法回答关系密集型问题时，再做这一步。

快速参考

作者：Pavan Dhake