这次不聊新模型，聊一个在 Agent 工程里反复出现、但经常被搞混的架构问题：RAG 和 Memory，到底该怎么选。很多团队在搭建 AI Agent 时，第一版方案里往往同时出现“知识库检索”和“长期记忆”两个需求。产品经理说用户问答要准确，所以要挂 RAG；另一个需求方说 Agent 要记住用户偏好，所以要加 Memory。结果开发过程中发现两块都依赖向量数据库，都做文本切片，都在给大模型拼上下文，很容易做成同一套东西，后面出问题又不知道在哪一环。
RAG（Retrieval-Augmented Generation）和 Memory 在实现层面有重叠，但架构定位、数据生命周期、失败模式和运维成本差异非常大。这篇文章会把二者的边界拆开，先讲清楚各自解决什么问题，再给出一套选型判断方法，最后落到 Agentic RAG、长期工作记忆、切块策略、引用溯源这些常见工程细节上。读者看完应该能回答三个问题：当前场景需要 RAG 还是 Memory，两者是否可以合并，以及落地时最容易踩哪些坑。
1. 核心能力速览
在进入细节之前，先给一张速览表。这张表不纠结具体代码实现，只解决“它们是什么、该用在哪、和 Agent 是什么关系”这件事：
| 对比维度 | RAG | Memory（Agent 记忆） | Agent |
|---|---|---|---|
| 解决的核心问题 | 为生成补充外部知识 | 保持上下文和用户状态 | 自主决策、规划、工具调用 |
| 数据来源 | 知识库、文档、网页、数据库 | 对话历史、任务日志、用户行为 | 由 LLM 能力、工具链和记忆共同驱动 |
| 数据写入时机 | 索引构建期，通常离线批处理 | 对话过程中持续写入，实时性高 | 无独立写入，依赖内部模块 |
| 数据读取时机 | 每次生成前按查询检索 | 对话过程中按需读取，多轮复用 | 持续运行，按流程触发 |
| 更新方式 | 重建索引或增量更新，成本较高 | 追加写入，低成本 | 视实现而定 |
| 可解释性 | 强，可溯源到文档片段 | 中等，可查看记忆条目 | 决策链路可追踪，但复杂流程难排查 |
| 主要失败模式 | 检索不到、切块断裂、召回不相关 | 遗忘关键信息、记忆写入脏数据 | 规划偏离、工具调用不稳定 |
| 成本大头 | 离线索引、向量化、检索链路 | 摘要生成、记忆写入、存储扩容 | 多轮推理、工具调用、上下文加长 |
从表中能看出一个关键结论：RAG 更像“外部知识管道”，Memory 更像“交互状态容器”，Agent 则是把两者用起来的上层执行体。三者不是同一层的东西，所以不能简单说“RAG 比 Memory 强”或者“有了 Memory 就不需要 RAG”。
2. 概念拆解：RAG、Memory、Agent 分别解决什么问题
2.1 RAG 的本质
RAG 的核心逻辑是“先检索，再生成”。当大模型缺乏某个领域的知识，或者知识可能过时、幻觉风险高时，RAG 会在推理前先从外部知识库中检索与当前问题相关的片段，把这些片段拼进提示词，让模型基于这些材料生成答案。
这个机制决定了 RAG 的几个天然特点：
- 知识可更新：知识库里的文档变了，重新索引就可以，不需要重训模型。
- 答案可溯源：输出可以关联到具体文档片段，方便做引用验证和 groundedness 评估。
- 推理依赖外部库：检索质量直接决定生成质量，检索不到正确内容时，模型只能凭记忆硬答，幻觉风险回升。
在热门搜索词里能看到一个高频问题：RAG 切块策略。这是 RAG 落地最典型的难点。文档切成多大的片段、怎么切、段与段之间要不要重叠，直接决定检索命中率。切得太小，语义断裂；切得太大，噪声增多。固定 300 到 500 token 的切法只适合演示，真实业务里要按文档类型、语言、排版结构单独设计。
2.2 Memory 的本质
Memory 在 Agent 系统中承担的是“状态保持”职责。大模型本身没有跨会话记忆，一个对话窗口结束，之前的信息就没了。Memory 要做的事情就是把这些信息保存下来，在需要时重新读入上下文。
按时间维度分，Agent 记忆通常有三类：
- 短期记忆：当前对话窗口内的上下文，包括用户输入、Assistant 回复、工具返回结果。短期记忆通常由系统维护，本质上就是上下文窗口管理。
- 长期记忆：跨会话保存的用户偏好、历史结论、重要事实。比如用户上次提到自己是财务人员，下次对话时 Agent 能想起来，就属于长期记忆。
- 工作记忆：当前任务执行中的临时状态，比如正在处理的订单号、中间计算结果、已经完成的步骤。工作记忆更像 CPU 里的寄存器，任务结束即失效。
长期记忆的实现在热门词里有几个高频方向：记忆通道（Memory Channel）、记忆编译器（Memory Compiler）、长期工作记忆智能体。这些方向的核心问题是：什么时候写入记忆，什么时候读记忆，记忆满了之后怎么压缩和遗忘。写入太频繁，记忆库变成垃圾场；写入太少，Agent 又没有记忆能力。
2.3 Agent 的本质
Agent 是大模型驱动的自主执行框架。它不只是回答问题，而是基于目标和工具，执行一系列动作：拆解任务、调用函数、读取数据、观察结果、调整策略，直到任务完成。
在这个框架里，RAG 和 Memory 都只是 Agent 的一个能力组件。Agent 可以选择在某个步骤调用 RAG 去检索知识，也可以选择在开始阶段读取 Memory 恢复用户画像，还可以把中间结果写入 Memory 供后续复用。很多 Agent 框架之所以内置 Memory 模块，是因为没有记忆的 Agent 每次对话都是“失忆状态”，根本谈不上连续执行。
所以 Agent 开发和 RAG、Memory 的关系不是并列选型，而是“Agent 在什么环节需要知识、什么环节需要状态”。理解这一点，选型思路就清晰了。
3. RAG 和 Memory 的核心差异
把两者放在同一张表里对比，能更清楚地看到选型依据：
| 维度 | RAG | Memory |
|---|---|---|
| 数据来源 | 外部知识库，如技术文档、产品手册、法律法规 | Agent 自身交互历史，如对话记录、任务日志、用户画像 |
| 信息流动性 | 相对静态，知识库版本更新慢 | 实时流动，每一轮对话都可能写入新记忆 |
| 存储形态 | 向量索引 + 原始文档副本 | 向量索引 + 结构化键值 + 上下文窗口摘要 |
| 生命周期 | 以知识库版本为生命周期 | 以用户或会话为生命周期 |
| 读取策略 | 每个查询独立检索，无状态 | 受当前对话上下文影响，按相关性读取历史片段 |
| 写入成本 | 离线构建成本高，涉及文档解析、切片、嵌入 | 写入成本相对低，但需要设计摘要和去重策略 |
| 典型失败 | 检索未命中、切片割裂语义、检索结果排序错误 | 记忆遗忘、记忆冲突、脏记忆污染后续回答 |
| 评估指标 | 召回率、命中率、生成答案准确率 | 记忆命中率、记忆一致性、长期记忆保持率 |
这里的核心区别在于数据来源和生命周期。RAG 的数据来自“系统之外”，是对世界知识的补充；Memory 的数据来自“系统之内”，是对交互过程的记录。如果一个数据是产品文档里的内容，它应该进 RAG；如果一条数据是“用户昨天要求把报告导出为 PDF”，它应该进 Memory。
很多开发者的困惑来自实现上的相似性：两者都用 embedding，都存向量库，都用相似度检索。但这只是“工具相同”，不代表“目标相同”。RAG 的检索目标是“找到与问题相关的知识片段”，Memory 的检索目标是“找到与当前场景相关的历史状态”。同一条查询，可能 RAG 命中了十年前的政策文档，而 Memory 命中了用户上周的需求记录，两者服务的上下文完全不同。
4. Agent 开发中如何选型：先判断场景
选型不是看技术潮流，而是看业务场景里“缺失的到底是什么”。可以从三个问题入手：
- 用户问的问题，答案在哪？答案是写在某个外部文档里，还是来自用户之前说过的内容？
- 问题的答案会随时间变化吗？如果相关知识会更新，RAG 更合适；如果是用户偏好这类持续累积的信息，Memory 更合适。
- 模型自己在通用知识上能否回答？如果问题在通用知识范围内，两者可能都不需要；如果问题高度专业，RAG 是必需品。
4.1 优先选 RAG 的场景
典型特征：答案客观、外部可查、需要引用依据。企业知识库问答、智能客服、法律政策检索、技术文档助手、教育和培训场景都属于这一类。用户问“公司报销标准是多少”，Agent 要回答，就必须去查最新报销政策文档，而不是靠模型记忆。这个场景下 RAG 是主干，Memory 只是辅助记录用户的询问历史。
企业级 RAG 的实战痛点在热门词里出现频率很高，集中在文档格式复杂、表格解析困难、多文档内容冲突、检索结果不排序、引用溯源缺失。这些问题不是模型能力问题，而是工程链路问题。文档加载和解析做不好，后面再怎么优化切片效果都有限。
4.2 优先选 Memory 的场景
典型特征：答案依赖用户个人信息、跨会话状态、任务连续性。例如个人助理型 Agent，需要记住用户的称呼、偏好、常用时间、常去的地点；又比如企业内部的流程 Agent，需要知道用户当前处于哪个审批节点、已经填过哪些字段。这类场景靠 RAG 解决不了，因为信息不在外部知识库里，而在用户与 Agent 的交互历史里。
长期工作记忆的构建思路是：把每次对话的高价值信息提取出来，写入记忆库；下一轮对话开始时，先检索与当前用户相关的记忆，拼入上下文。Memory 里保存的不只是原文，还可以是摘要化、结构化的事实，比如用户偏好、历史结论、待办事项。
4.3 两者都需要、但分工明确
复杂业务里 RAG 和 Memory 经常同时出现。比如一个运维诊断 Agent：在诊断时，它需要 RAG 去检索运维手册和故障案例库；在连续多轮排查中，它需要 Memory 记住已经检查过哪些服务、当前怀疑哪个环节、用户提供的服务器 IP 是什么。没有 RAG，Agent 没有专业领域知识；没有 Memory，Agent 会在第二轮对话中忘记第一轮的排查结果。
这种场景的正确做法是拆成两条独立链路：RAG 链路负责“知识检索”，Memory 链路负责“状态记录”。两者可以共用一个向量库，但索引目录、写入策略、读取策略必须分开。耦合在一起会导致知识更新时把用户记忆覆盖掉，或者记忆写入多轮后污染检索排序。
5. Agentic RAG：RAG 与 Agent 的融合形态
选型不是二选一之后就不能变了。近一年讨论最多的 Agentic RAG，就是把 RAG 从“一次检索 + 一次生成”升级成“Agent 自主决定检索策略”的形态。
传统 RAG 的流程是：用户提问 → 向量检索 → 拼接上下文 → 生成回答。这个流程的问题在于，一次检索不一定能找到答案。复杂问题可能需要把问题拆成多个子问题，分别去不同知识源检索；也可能第一次检索结果不理想，需要换一种查询表达再检索一次；还可能需要先查知识库，再查数据库，最后综合分析。
Agentic RAG 的流程变成：用户提问 → Agent 判断要不要检索 → 选择检索哪个知识库 → 执行检索 → 判断结果是否够用 → 不够就改写查询再检索 → 够用就生成回答。这个流程把“检索”变成了 Agent 的一个工具调用，让 Agent 像人一样决定查什么、怎么查、查到什么程度。
Agentic RAG 的工程价值在于提高复杂问题的命中率。比如用户问“我们公司最近三个月的报销政策变化对我这个月报销有什么影响”，传统 RAG 很难用一次向量检索回答。Agent 可以拆成三步：先检索历史报销政策，再检索当前政策，最后对比差异生成结论。每一步都可以调用不同的检索 API，这就是 RAG 和 Agent 架构结合的意义。
但 Agentic RAG 也有代价：额外多轮推理带来更高延迟和成本，调度逻辑变复杂，失败点增多。Agent 可能做出错误的检索决策，比如明明不需要检索却去检索了一遍，或者选错了知识库。落地时要设置 Agent 的检索决策上限，避免无限循环检索消耗 Token。
6. Agent 使用 RAG 的落地路径
如果团队决定在 Agent 里引入 RAG，核心落地链路可以拆成三步：文档加载与切块、向量化与召回、回答生成与引用。
6.1 文档加载与切块策略
文档加载要做的事是把手里的 PDF、Word、HTML、Markdown、表格数据转换成可检索的纯文本。这一步没做好，后面全是白费。PDF 要处理扫描件 OCR，表格要抽取结构化数据，图文混排要保留上下文顺序。
切块策略是 RAG 项目里调优空间最大的一环。推荐从递归切块起步，按标题、段落、句子层级递归切割，保留语义边界。语言混合文档要避免按字符硬切；表格类内容最好单独走结构化解析，不要和正文混在一起；代码文本按函数或代码块切割，不要按行切。
重叠窗口可以缓解切块断裂问题。每个切片保留前后 50 到 100 个字符的上下文重叠，检索时能提高上下文恢复能力。但重叠量不是越大越好，重叠太多会导致向量索引冗余，检索结果重复度高。
6.2 向量化与召回
切块之后需要做 embedding，把文本变成向量。向量化模型可选通用中文 embedding 模型，也可以针对垂直领域微调。向量库可以选择开源自建，也可以使用托管服务。对于团队自身测试环境，建议先用轻量向量库跑通链路，再评估是否需要扩展。
召回阶段要关注两件事：召回率和排序质量。先用向量相似度做粗召回，必要时加一层重排模型，把语义上最相关的片段排到前面。知识库规模变大后，混合检索效果好于纯向量检索：向量检索负责语义，BM25 或全文检索负责精确词匹配，两者融合结果再重排，能显著提升命中率。
6.3 回答生成与引用溯源
生成阶段要把检索结果和原始问题一起拼入提示词，要求模型只能基于给定材料回答。这里的关键是引用溯源：模型在输出答案时，应该标注内容来自哪份文档的哪一段，方便用户核查。
热门词里的“RAG 的引用溯源与 groundedness”就是这个问题。评估 RAG 系统不能只看答案是否通顺，还要看答案是否 grounded，即是否忠于检索材料。可以通过比对答案中的关键事实和检索片段来判断；如果答案出现了材料里没有的细节，说明模型又开始生成幻觉了。
7. Agent Memory 的落地路径
Memory 的落地比 RAG 更抽象，因为它没有一个像“文档加载”那样固定的物理起点。实际可以从三层设计开始。
7.1 会话内记忆
会话内记忆就是上下文窗口管理。最简单的方式是把多轮对话全部传给模型，但上下文长度有限，且越长延迟越高。常见做法是滑动窗口：只保留最近 N 轮对话，更早的内容截断或总结。
如果 Agent 在执行复杂任务，中途有大量工具调用结果，这些结果不宜全部留在上下文里。可以把工具结果压缩成摘要，只保留关键字段。比如 SQL 查询返回了上千行，可以只保留行数、列名和聚合统计结果。
7.2 长期记忆与用户画像
跨会话记忆需要单独设计。每轮对话结束后，Agent 可以把值得记忆的信息提取出来，写成结构化记录：用户 ID、记忆类型、内容、时间、来源对话 ID。比如用户说“我每周五要开项目周会”，这条信息可以写入“周期性任务”记忆；用户在上一轮提供了公司名称，可以写入“用户属性”记忆。
长期记忆的检索时机是每轮对话开始前。先把用户 ID 下的记忆做一次检索，把与当前问题相关的记忆条目拼入上下文。实际操作要注意记忆体量控制：记忆库中存入的上千条内容不能全部塞进上下文，必须做相关性和时效性评分，只选择最有用的一小部分。
7.3 记忆的写入与遗忘
记忆系统最难的是写入策略和遗忘机制。所有对话都记录会造成信息过载，而且低质量记忆会反复干扰 Agent 判断。
建议设置白名单式写入策略：只有包含明确偏好、明确行为、明确任务上下文的内容才写入长期记忆；寒暄、无关闲聊、临时性内容不写入。遗忘可以通过时间衰减实现：超过一定时间未被访问的记忆降权，长期未使用的记忆归档。记忆之间出现矛盾时，以最近写入为准，同时保留历史版本以便回溯。
热门词里的 Memory Compiler 和 Memory Channel 就是在做这件事：把零散记忆编译成结构化知识，或者按通道管理不同维度的记忆。这些方向还比较新，落地时可以把它当成“记忆的清洗与索引层”，不要指望开箱即用一个统一的记忆标准。
8. 效果验证与性能观察
Agent 接入了 RAG 和 Memory 之后，怎么判断效果好还是坏？需要分链路验证，不能只看最终回答是否流畅。
8.1 RAG 链路验证
RAG 的验证应该从构建评测集开始。准备一批“问题 + 正确文档片段”的测试样本，覆盖业务高频场景和边界情况。评测指标建议记录：
- 检索召回率：正确答案是否在返回的 Top-K 片段里。
- 命中位置：正确答案排在第几位，排名越靠前越好。
- 生成准确率：模型是否基于召回片段正确回答了问题。
- 引用正确率：答案标注的引用是否真的能支撑结论。
切片策略调整后要重新跑评测集对比。不要把某一条问答看起来不错当作 RAG 调优成功的标准，要统计一批样本的召回分布。召回率没变化时，优先查文档加载和切块；召回率提升了但回答还是错，优先查提示词和模型选择。
8.2 Memory 链路验证
Memory 的验证更偏场景化。构造一个多轮交互测试，让 Agent 在第 N 轮获得某个关键信息，然后跳到第 N+10 轮观察 Agent 是否还记得。测试维度包括：
- 记忆写入命中率：高价值信息是否被识别并写入。
- 记忆读取准确率：相关记忆是否在合适时机被读取。
- 遗忘正确性：过期信息是否被降权，不会影响当前回答。
- 记忆冲突处理：矛盾信息出现时，Agent 是否按最新信息应答。
性能方面，RAG 和 Memory 都会增加推理延迟。每多检索一次，平均增加几百毫秒到数秒不等，取决于向量库规模和检索方式。如果 Agent 每条消息都在做多次记忆检索，会明显增加首 Token 延迟。优化方向是给记忆查询加缓存，同一次会话内避免重复检索相同记忆。
8.3 资源占用观察
RAG 链路的高峰资源消耗通常出现在离线索引阶段：文档解析需要 CPU 和内存，embedding 需要 GPU 或模型服务。在线推理阶段，检索本身不消耗太多算力，但拼接大段上下文会增加模型推理的显存和 Token 消耗。Memory 链路的高峰消耗在摘要生成和长期记忆写入，因为需要额外调用一次大模型做信息提取，这比向量化更耗时、更贵。
部署环境中可以用一套通用查看方法观察资源占用：索引任务看 CPU 和内存峰值；推理任务看 GPU 显存和吞吐；Web 服务看接口延迟和并发上限。当上下文变长时，显存占用上升是正常现象，需要控制上下文长度或用 KV Cache 优化。
9. 常见问题与排查方法
Agent 同时使用 RAG 和 Memory 时，容易出现以下问题：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| Agent 回答明显没有参考知识库 | 检索链路失效或召回为空 | 打印检索日志，查看召回片段 | 检查索引是否构建成功、查询嵌入是否正常 |
| 检索到了但回答还是错 | 切片语义断裂或重排排序差 | 单独测试检索结果和生成结果 | 优化切块策略，增加重排模型 |
| 答案出现幻觉，引用无依据 | 提示词允许模型自由发挥 | 检查生成提示词约束 | 明确要求只能基于检索材料回答 |
| Agent 跨会话忘记用户信息 | 长期记忆写入失败 | 查看记忆库是否有新记录 | 检查记忆写入触发逻辑，确认提取节点正常 |
| 记忆库越来越大，检索变慢 | 没有遗忘机制和去重 | 统计记忆库条目增长曲线 | 引入时间衰减、去重与归档策略 |
| 多轮任务中途失忆 | 工作记忆未保存工具状态 | 检查任务执行日志 | 将中间状态写入工作记忆或数据库存储 |
| 上下文太长，显存不够 | 历史记录和高频记忆全量塞入 | 查看每次请求 token 数 | 做窗口裁剪、摘要压缩、记忆条数限制 |
| 一个查询触发多次检索，成本飙升 | 检索决策没有预算控制 | 查看 Agent 完整调用链 | 给 Agent 设置单次检索次数上限，或引入确定路由规则 |
| 知识库更新后回答仍用旧内容 | 索引未重建或缓存未清 | 对比知识库版本和索引版本 | 重建索引或启用增量更新，更新后清理缓存 |
| 答案相似但细节错误 | 记忆脏数据覆盖正确信息 | 检查记忆冲突日志 | 设置冲突处理规则，以时间或可信度为优先级 |
排查顺序建议是：先看数据，再看链路，最后看模型。大多数“效果不好”不是模型能力问题，而是检索数据没进对地方、切片把语义切断了，或者记忆库里的脏数据污染了上下文。
10. 最佳实践与合规边界
10.1 工程最佳实践
- 最小可用先行。第一版不要试图同时上线完美 RAG 和复杂长期记忆。先跑通一个基础 RAG 链路，再逐步叠加 Memory。
- RAG 和 Memory 分目录管理。同一个向量库里可以用不同 collection 或前缀区分，避免知识索引和用户记忆互相干扰。
- 日志是一切排查的基础。RAG 需要记录检索 query 和召回片段，Memory 需要记录写入条目和读取时机。没日志，出问题只能拆代码看。
- 建立评测集并持续回归。切片策略、模型替换、提示词调整都会影响效果，每次变更都要跑同一套评测集。
- 接口服务要设置超时与重试。如果 Agent 会调用记忆或知识库服务，要考虑接口不可用时的降级方案。比如知识库检索超时，可以先用模型自身知识回答并标注不确定性。
- 控制上下文成本。RAG 和 Memory 都是“上下文消耗者”，两块的检索结果全部塞入后，单次请求可能吃掉几千个 Token。限制检索条数和单条长度，避免成本失控。
10.2 合规与安全边界
RAG 和 Memory 都涉及数据存储，必须明确合规边界。企业内部知识库可能包含未公开的敏感信息，上线前需要确认数据授权范围、访问权限分级和审计机制。用户对话历史和画像属于个人信息，存储时应该脱敏、加密、设置访问范围，并在产品隐私政策中明确告知用户。
涉及人脸、声音、身份信息等敏感场景时需要格外谨慎，Agent 记忆如果记录了用户生物特征或身份细节，风险等级会显著升高。不应为了“记忆效果好”而无限采集用户数据，更不应把用户长期记忆用于未获授权的场景。内部测试环境用脱敏或模拟数据验证功能，真实场景上线前必须完成合规评审。
关于 RAG 知识库里的版权内容：不要随意将未获授权的文档灌入知识库做商用回答。开源文档可以用，企业自主文档可以用，但抓取第三方网站、扫描出版物整本入库，都需要确认版权边界。
11. 总结
回到标题的问题：RAG 和 Memory，Agent 到底该用哪个？答案是：先看数据来源。答案藏在外部文档里的，用 RAG；答案藏在用户交互历史里的，用 Memory；两者都存在的，就分两条链路同时用，但要在索引、写入、读取策略上严格分离。
最值得先验证的功能是检索命中率。不管团队选 RAG 还是 Memory，第一件事是确认检索能不能找到正确内容。检索命中不了，后续生成和质量优化全都无从谈起。最容易踩的坑则是把两者耦合在同一套逻辑里，导致更新知识库时污染用户记忆，或者记忆写入过频让检索结果越来越偏。
后续可以延伸的方向包括：Agentic RAG 的多轮检索调度、记忆通道的标准化设计、基于记忆的个性化 Agent、记忆冲突自动消解、以及把 RAG 引用溯源和记忆审计结合起来做完整的可信链路。技术迭代很快，但架构判断的标准不变：一条信息是知识还是状态，决定了它该放在哪里。
