最近几次技术交流里，我被问得最多的一个问题就是：Agent 到底该用 RAG 还是 Memory？是不是有了 RAG 就不需要 Memory 了？还是反过来，先做 Memory，知识库可以放一放？
这个问题之所以让人纠结，是因为很多团队的 Agent 已经跑起来了，但效果总是差一口气。问产品手册里的内容，回答得还算靠谱；可只要对话稍微一长，或者用户换了一种说法，Agent 就像失忆一样——要么答非所问，要么把上一轮刚确认过的信息推翻。这时候，有人去调 RAG 的切块策略，有人去加 Memory 模块，还有人直接上 Agentic RAG。折腾一圈，效果却不一定变好。
我的判断是：RAG 和 Memory 根本不是同一层的东西，它们解决的问题也不一样。把两者放在一起二选一，本身就可能说明我们还没定位到真正的病灶。真正关键的，是先搞清楚你的 Agent 到底在哪一个环节断裂了。
1. 先别急着选，这个问题的前提可能就错了
1.1 为什么 RAG 和 Memory 总被放在一起比较
表面上看，RAG 和 Memory 确实有相似之处：它们都会给大模型“多塞一些信息”，都能缓解幻觉，都跟上下文有关。于是很多人在描述需求时，会把它们混着说——“Agent 记不住东西，那就上 RAG 吧”“RAG 效果不好，是不是该换 Memory”。
这里有一个很常见的思维误区：把“上下文”当成一个统一的筐。但实际上，模型生成时需要的上下文，至少来自三条完全不同的路径：
- 外部知识：产品文档、规章制度、行业资料，这些内容模型在训练时没见过，或者见过但已经过时。需要从外部文件里找回来。
- 当前会话状态：用户上一轮说了什么、你已经答应过什么、任务执行到哪一步，这些信息只存在于这次对话内部。
- 跨会话偏好与经历：用户长期关注什么、上次帮你处理过什么、你总结过哪些结论。这些信息需要跨 session 保留。
RAG 解决的是第一条路径。Memory 解决的是第二条和第三条路径。把这三条路径统一成一个“要不要记忆”的问题，从一开始就问偏了。
1.2 一个反直觉的判断：它们不是同一层的东西
我倾向于把 RAG 理解成一种推理时的外部检索机制，把 Memory 理解成一种状态持久化与调取机制。两者最本质的区别是：
- RAG 是“读”外部语料，每次请求都是一次全新的检索，它不做状态累积。
- Memory 是“写”和“读”Agent 自身的历史，带有明确的时序和状态含义。
用生活里的例子类比，RAG 更像是你临时去图书馆查资料：不管你来过多少次，每一次查书都是按当下的问题重新找。图书馆不会记住你昨天借过什么，也不会因为你昨天查过某个主题，今天就自动把相关章节摆到你桌上。
Memory 则更像你自己的笔记本：它会记录这个任务做到哪一步、对方在意什么、上次讨论得出过什么结论。下一次打开本子，你能接着上次的进度往下走。
所以 RAG 和 Memory 并不互斥。真正的问题不是“该用哪个”，而是“你的 Agent 缺的是哪一层”。
| 对比维度 | RAG | Memory |
|---|---|---|
| 核心目标 | 从外部知识库取回相关证据 | 保留并恢复 Agent 自身的历史状态 |
| 数据来源 | 文档、网页、数据库、非结构化文件 | 会话历史、任务状态、用户画像、历史结论 |
| 发生时机 | 每次推理时按查询触发检索 | 会话中持续写入，在需要时调取 |
| 典型操作 | 向量检索、重排、引用溯源 | 写入、更新、过期、读取、摘要压缩 |
| 失败表现 | 检索不到相关片段或引错了文档 | 回答与之前矛盾、上下文遗漏或记忆污染 |
| 典型问题 | 不知道“这个知识” | 不记得“刚才的事”或“这个人是谁” |
2. RAG 的本质：把外部知识变成可检索上下文
2.1 RAG 真正解决的是“知识缺口”，不是“记忆问题”
RAG 的全称是检索增强生成。它的核心思路是：在模型生成之前，先从外部知识源里检索出与问题相关的片段，把这些片段作为参考内容塞进 prompt，再让模型基于这些内容作答。
它解决的是大模型最典型的一个短板：模型内部的知识是训练时固化的，专业文档、企业内部资料、最新政策，它不可能都知道。你问一个通用大模型最新的内部流程，它大概率会一本正经地编一个答案，因为它的参数里根本没有这个信息。
RAG 的作用不是让模型“记住”，而是让模型在回答的那一刻“看得到”正确资料。这也是为什么它特别适合企业知识库、产品问答、合规问答这类场景：答案必须来自指定的文档，而不是模型自由发挥。
2.2 一个最小 RAG 系统里，真正决定效果的四个环节
很多人以为 RAG 就是“把文档丢进向量数据库，然后查一下”，实际上一个可直接使用的 RAG 系统，至少要经过四个环节：
- 文档加载与解析
- 切块（Chunking）
- 向量化与存储
- 检索、重排与引用生成
这几个环节里，最容易让新手栽跟头的是切块。切块策略直接决定了后续检索的精度。如果你的文档是规范的企业手册、制度文件，按章节、标题层级来切，通常比固定 500 字一刀切要靠谱。因为固定长度切块很容易把“问题”和“答案”切成两段，导致检索时只命中一半内容。
更合理的做法是先按文档结构切分出语义单元，比如标题、段落、列表，再对过长的单元做二次拆分。拆分时可以设置一个 overlap，让相邻片段重叠一部分，避免关键信息卡在切缝里。
向量化和存储阶段，要特别注意embedding 模型和业务语料的匹配问题。通用的 embedding 模型对日常文本效果不错，但遇到大量专业术语、缩写、中文企业表达时，检索质量可能明显下降。常见的实践是先准备一批真实问题，跑一轮检索，看看 top-k 结果是否相关，再决定要不要换领域适配的 embedding 模型。
从工程角度看，一个最小可运行的 RAG 流程可以这样理解：
# 常见流程示意，具体实现需结合你的框架和向量库 docs = load_and_split_documents(your_files) # 加载 + 切块 vectorstore = build_vectorstore(docs, embedding_model) # 向量化存储 retriever = vectorstore.as_retriever(search_kwargs={"k": 4}) # 检索配置 context = retriever.invoke(question) answer = llm.invoke(assemble_prompt(question, context))这里的关键不是代码行数，而是每一步都值得单独验证：解析出来的文本是不是干净的？切出来的块是不是有独立含义？检索回来的片段是不是真的能回答问题？
2.3 RAG 的边界：它不负责记住你上一轮说了什么
很多人对 RAG 失望，是因为拿它去解决了一个它根本不该解决的问题。
RAG 的每次检索都是独立的，它不会因为你之前问过“报销流程”，这一轮就问“那发票呢”时，自动把上一轮里的“报销流程”作为检索上下文。它只会按当前这一句话去查。如果 Agent 没有把对话历史拼进检索查询里，RAG 就会显得“断片”。
这就是为什么在多轮对话场景里，RAG 通常需要配合会话状态的维护。否则你加再多的知识库，Agent 依然会在连续对话中失去方向。
注意：如果对话一长就答非所问，先别急着调切块参数。你遇到的很可能不是检索问题，而是上下文和记忆问题。
3. Memory 的本质：Agent 的状态、经历与自我一致性
3.1 对话记忆、工作记忆、长期记忆，别混为一谈
RAG 容易被笼统理解，Memory 更容易。因为在 Agent 开发里，“Memory”这个单词被塞进了太多含义。
我建议至少把 Memory 拆成三个层级：
- 工作记忆（Working Memory）：当前任务执行过程中的临时状态，比如正在填写的表单、已经收集到的参数、任务执行到第几步。这部分通常只需要在本次任务内有效。
- 会话记忆（Conversation Memory）：当前对话的历史记录，包括用户说过的话、Agent 回答过什么、已经确认的约束。它负责维持多轮对话的一致性。
- 长期记忆（Long-term Memory）：跨会话保留的信息，比如用户的偏好、历史项目结论、Agent 在多次任务中积累的经验。它让 Agent 在下次出现时“还认识你”。
很多团队的问题在于：所有历史都堆在一起，没有分层。结果就是短期对话里塞进了几个月前的旧结论，把当前任务带偏；或者更常见的是，长期记忆里存了大量临时状态，越用越乱。
3.2 实现 Memory 不是“把历史拼接起来”那么简单
最简单粗暴的 Memory 实现，是把所有对话历史全部拼进 prompt。这在测试阶段可行，但对话一长就会出问题：
- token 成本爆炸：上下文窗口是有限的，历史越长，留给推理和检索的空间越小。
- 关键信息被稀释：模型面对几千行历史时，很难准确识别哪一条是当前最相关的约束。
- 旧信息干扰新决策：用户上一轮说的是 A，这一轮改成了 B，如果 history 里 A 和 B 都存在，模型可能会犹豫甚至答错。
更常见的工程方案是分层设计：保留最近几轮完整对话作为短期记忆，把更早的历史做一轮摘要压缩，再抽取出需要长期保存的用户偏好或任务结论，单独存进记忆库。需要时，通过向量检索把最相关的历史记忆取回来，而不是全量塞进去。
这里涉及到一个搜索引擎里也会遇到的热词：memory channel。通俗说，就是把不同类型的记忆分开管理，比如一个 channel 存对话摘要，一个 channel 存用户画像，一个 channel 存任务状态。Agent 在决策时可以根据当前需求，只读取相关 channel，而不是什么都看。
3.3 Memory 一旦做错，比没有 Memory 更危险
这一点经常被低估。RAG 写错了，最多是检索回来的片段不准；Memory 写错了，是会“污染后续所有交互”的。
举个例子：Agent 在一次对话里误解了用户的意思，把“用户希望每周自动生成报表”写进了长期记忆。接下来每一次对话，Agent 都会带着这条错误信息行动。用户要反复纠正，甚至直接弃用。
更隐蔽的问题是记忆过期。用户三个月前的偏好，可能现在已经不适用了。如果长期记忆没有时效机制，Agent 就会拿旧结论回答新问题，表现甚至不如一个没有记忆的 Agent。
所以，Memory 的设计重点不只是“怎么存”，还包括：
- 写入校验：什么信息值得写入长期记忆，什么信息只是临时状态。
- 时效与淘汰：每条长期记忆是否带时间戳，多久未被使用后应该被弱化或删除。
- 用户控制：用户能不能查看、修改、删除 Agent 存下的关于自己的信息。
- 冲突处理：新信息与旧记忆不一致时，以谁为准。
如果你发现 Agent 的回答“越用越怪”，很多情况下不是模型变笨了，而是 Memory 层写入了错误的记忆，并且没有淘汰机制。
4. 不是二选一，而是分层配合：Agentic RAG 的正确打开方式
4.1 Agent 决策时，如何判断该检索还是该回忆
当 Agent 同时具备 RAG 和 Memory 之后，真正的问题变成了：每一步，它应该去查资料，还是应该回忆历史，还是直接回答？
这就是 Agentic RAG 要解决的核心问题。它和传统 RAG 的区别在于：传统 RAG 是“每次必查”，Agentic RAG 是“按需查”。Agent 会根据当前问题、已有上下文、记忆中的信息，自主决定是否检索、检索什么、以及是否要改写检索查询。
一个比较实用的判断逻辑是这样的：
- 如果问题涉及外部事实、专业文档、最新资讯 → 走 RAG 检索。
- 如果问题依赖之前的对话内容、用户偏好、任务状态 → 走 Memory 调取。
- 如果问题既需要文档知识，又需要结合历史上下文 → 先调取记忆，再用记忆补充后的意图去做检索。
换句话说，Memory 负责回答“我们刚才聊到哪里”，RAG 负责回答“这个问题的事实依据是什么”。两者服务的对象不同，但最终都汇入同一个 prompt。
4.2 一个可直接参考的混合流程
在实际项目里，我比较推荐的流程是这样的：
- 用户输入进入 Agent。
- Agent 先读取工作记忆和当前会话摘要，明确“现在在做什么、已经知道什么”。
- 判断当前问题是否需要新知识。如果需要，就带着会话上下文改写检索查询，执行 RAG。
- 检索结果回来后，结合记忆中的历史约束一起组装 prompt，交给模型生成。
- 生成结束后，判断本轮的对话内容里，有没有值得写入长期记忆的信息。如果有，走写入校验流程，而不是无条件全存。
这个流程看起来简单，但它和“一上来就堆功能”的区别很大。它实际上把决策权交给了 Agent，同时给了 Agent 一套明确的判断标准。
在技术选型上，现在很多框架都已经内置了相关能力，比如 LangChain 的 memory 模块、Spring AI 2.0 结合 Qdrant 做向量存储、Dify 这类低代码平台里的知识库和会话变量。还有一个值得关注的方向是 MCP，它把外部工具和数据访问标准化了，Agent 接入 RAG 和 Memory 的方式会更统一。选哪个框架不重要，重要的是你的 Agent 是否能区分“该查”和“该记”。
4.3 从单次用到工程化，差的是日志、评估和治理
很多 RAG 项目在演示时跑得通，一上线就崩，不是因为算法不行，而是因为缺少工程化支撑。
RAG 和 Memory 都属于“效果需要持续观察”的模块。你不能只跑通一次流程就宣布完成。至少需要补三样东西：
- 链路日志：记录每次请求里，模型到底检索到了哪些片段、调取到了哪些记忆、最后用了哪部分。这样出了问题才能回溯，而不是猜。
- 评估集：准备一批真实问题，包含“只需要知识库”“需要结合历史”“需要跨会话记忆”三种类型，定期回归。评估的是最终回答质量，而不是单个环节的指标。
- 治理规则：RAG 需要版本化的知识库和引用溯源；Memory 需要写入权限、时效策略、删除机制。
RAG 的引用溯源尤其重要。企业场景里，回答必须能指出“这句话来自哪一篇文档、哪一段”，否则一旦答错，责任没法追溯。这也是检索增强体系里最容易被忽略、却最能体现专业度的部分。
5. 实操判断框架：五个问题帮你做决策
5.1 先回答这五个问题
如果你现在正在纠结“RAG 和 Memory 该用哪个”，我建议你先别急着写代码，先回答下面五个问题：
- 当前最明显的失败表现是什么？是回答里出现编造的知识，还是多轮对话里前后矛盾，还是跨会话完全不认识用户？
- 这个失败发生在哪一层？是“没有资料”，是“忘了当前上下文”，还是“没有长期状态”？
- 如果只加 RAG，问题能解决多少？能解决知识类错误，但解决不了“记不住刚才”的问题。
- 如果只加 Memory，问题能解决多少？能解决对话一致性，但解决不了“不知道企业内部文档”的问题。
- 你是否有办法验证加了之后真的变好了？如果没有评估集和日志，你只是在猜。
回答完这五个问题，大部分场景的结论会非常清楚。
5.2 不同组合下的典型架构
| 实际场景 | 推荐组合 | 原因 |
|---|---|---|
| 企业内部文档问答，单轮为主 | 只需要 RAG | 用户问一句查一句，不依赖历史状态 |
| 多轮客服/任务型 Agent | 会话记忆 + RAG | 既要知道答什么，也要记得聊到哪 |
| 个性化助手，需要跨会话识别用户 | 长期记忆 + 会话记忆 + RAG | 需要记住身份、偏好和历史结论 |
| 对话很短，但知识覆盖很广 | RAG + 足够的引用溯源 | 核心风险是知识错误，不是上下文丢失 |
| 实验阶段，效果还没评估 | 先别加 Memory，先加日志 | Memory 写错了会污染后续，先确认链路可观测 |
5.3 一些容易掉进去的坑
切块策略一刀切。固定字数切块最省事，但如果你的文档有明确的层级结构，不要浪费它。按标题、表格、列表、代码块来切，检索精度通常比纯长度切块高出不少。切完之后一定要抽样检查：把每个片段单独拿出来看，它是否还像一个“可理解的完整单元”。
检索数量拍脑袋。top-k 不是越大越好。k 太小可能漏掉关键信息，k 太大又会在 prompt 里塞进大量无关内容，反而干扰模型。我一般建议从 k=3 到 k=5 开始，结合实际评估集测试，而不是一上来就拉满。
只要知识库不要引用。知识库回答如果无法溯源，几乎等于没有可信度。上线前一定要确认回答里能带上文档来源，并且这个来源真的能对应到原文。
Memory 写入没有门槛。最怕的就是“每个 session 结束时把所有东西都存进长期记忆”。长期记忆应该只保存有复用价值的结论和偏好，而不是流水账。
忽略隐私和权限。如果 Agent 服务多个用户，Memory 必须按用户隔离。不同用户之间的历史信息串了，这是安全事故，不是效果问题。
无评估就上线。我见过太多团队把 RAG 和 Memory 做完就宣布完成，结果第二天就被用户问出明显错误。没有评估集，你甚至说不清楚是检索的问题还是记忆的问题。
6. 排查链路：效果不好时，先查哪一层
6.1 现象 → 输入 → 环境 → 参数 → 工具边界
无论是 RAG 还是 Memory，出了问题都要按链路排查，不要一上来就怀疑模型不行。
我常用的排查顺序是：
- 看现象：是“答非所问”，是“前后矛盾”，是“完全没检索到”，还是“检索到了但答案不对”？现象决定了方向。
- 看输入：文档加载后是否乱码？切块后内容是否完整？当前查询有没有把对话历史带进去？如果查询本身缺了上下文，后面的检索再准也没用。
- 看环境：依赖版本是否一致？embedding 模型和向量库版本是否兼容？本地部署的模型和后端之间有没有调用超时？
- 看参数：切块大小、overlap、top-k、相似度阈值、摘要触发长度、记忆写入条件，这些参数是否和你的数据量匹配。
- 看工具边界：当前框架或模型对上下文窗口的限制是多少？向量库是否支持你要的元数据过滤？框架是否限制记忆 channel 的数量？
6.2 RAG 效果差，最容易出问题的环节
| 现象 | 优先排查项 |
|---|---|
| 检索结果看起来相关，但回答还是错 | 看引用溯源：答案是否真的基于检索片段，切块是否把关键信息拆散了 |
| 检索结果完全不相关 | 看 embedding 模型是否适配业务术语，看查询是否缺上下文，看是否需要重排 |
| 触发检索时很慢 | 看向量库索引方式、文档总量、是否需要元数据过滤缩小范围 |
| 回答“看起来像编的” | 看 prompt 是否明确要求“只能基于给定资料回答”，看是否启用了引用约束 |
6.3 Memory 异常，更隐蔽也更难查
Memory 的问题往往不是“没生效”，而是“悄悄生效但生效错了”。
- 如果 Agent 在对话中突然说出和当前用户无关的信息，优先查长期记忆是否按用户隔离。
- 如果 Agent 总是用旧结论回答新问题，查记忆写入是否带时间戳，是否缺少过期和弱化机制。
- 如果历史一长就答错，查是否全量拼接历史，有没有做摘要压缩和关键信息抽取。
- 如果 Agent 的回答越来越“奇怪”，第一件事是把日志里命中的记忆记录打开，看看模型到底读了什么。
排查 Memory 问题时，最好先关掉长期记忆，只保留会话记忆跑一轮。如果问题消失，说明是长期记忆写入或调取有误；如果问题还在，说明不是记忆层的问题。
写在最后
回到最开始的题目：RAG 和 Memory，Agent 到底该用哪个？
我的答案很简单：先选层，再选模块。如果缺的是外部知识，用 RAG；如果缺的是状态连续性，用 Memory；如果两者都缺，就分层配合。不要在还没有定位到问题层之前，就急着堆功能。
RAG 是让 Agent 在面对未知问题时“查得到”，Memory 是让 Agent 在持续交互中“记得住、接得上”。它们一个管外部事实，一个管内部状态，本来就是搭档而不是对手。
如果你现在手头正好有一个效果不达预期的 Agent，我建议你先别改代码，先花半天时间梳理：上一轮它为什么答错了？是因为没有资料，还是因为忘了上下文？把这个问题想清楚，比多换一个框架管用得多。
下一个阶段你要做的可能不是“二选一”，而是把 RAG 的检索质量、Memory 的写入门槛、以及整个链路的日志和评估一起补齐。到那时候你会发现，所谓“该用哪个”的问题，其实早就消失了。
