没人提前规划的记忆问题
大多数 AI Agent 项目都从模型开始。该用哪个模型？是用 GPT、Claude、Gemini、Llama，还是本地部署的模型？要不要加工具？要不要加 function calling？要不要让它自主运行？
然后，第一个生产问题出现了。
Agent 忘记了用户上周说的话；从错误的文档里给出答案；搞不清哪条政策是最新版；把用户的说法和已核实的事实混在一起；无法把一个客户、一张工单、一张发票和一次历史对话关联起来；检索到了正确的文档，却漏掉了真正重要的关联关系。
这时候才想到：
"我们需要记忆。"
但"记忆"这个词本身就语义过载。
一个从帮助文档里回答问题的客服机器人，需要一种记忆。一个记住你饮食偏好的个人助理，需要另一种记忆。一个需要关联公司、事件、文件、管理层变动和时间线的金融研究 Agent，需要的又是另一回事。一个跨会话记住架构决策的编程 Agent，需要的则是截然不同的东西。
把这些统称为"记忆"只会导致糟糕的架构设计。
比如说需要个人记忆时却选了 RAG，Agent 会显得健忘。需要有据可查的答案时却选了 Agent Memory，Agent 可能会自信满满地重复未经核实的说法。过早引入知识图谱，则可能在需求尚未验证之前就构建出一套复杂系统。
本文是一份实用指南，帮助你选择合适的记忆层。
RAG，外部知识层
RAG 是检索增强生成（Retrieval-Augmented Generation）的缩写。
基本思路很简单：
- 用户提出问题。
- 系统检索相关文档或数据。
- 检索到的内容传给模型。
- 模型基于检索内容作答。
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
当用户开始回访并期待连续性时，加入记忆。构建：
- 短期对话状态
- 长期用户事实
- 偏好存储
- 更新规则
- 删除规则
- 记忆审查流程
- 隐私处理
不要存储所有内容。只存储能改善未来回应的信息。
阶段三：加入知识图谱
当关联关系开始成为瓶颈时，加入图谱。构建：
- 实体模型
- 关系类型
- 来源溯源
- 时间处理
- 去重
- 图查询模式
- 评估示例
当简单检索已无法回答关系密集型问题时，再做这一步。
快速参考
https://avoid.overfit.cn/post/1e2620b890de4eb8b9a6bda4dde9b56a
作者：Pavan Dhake
