考察点
这道题出自 2026 年 Agent 高频面经（"RAG 是 Agent 记忆的一部分吗？""RAG 和 Agent 是什么关系？"），考察的是概念辨析能力。面试官想分清两种人：背八股说"记忆就是 RAG 存历史"的，和真正设计过系统、知道两者在数据生命周期上根本不同、但工程上又能共用管道的。追问往共用向量库行不行、检索冲突怎么排上走。
参考答案
概念上：两个东西
判断标准看数据的来源和生命周期：
| 维度 | RAG 知识库 | Agent 记忆 |
|---|---|---|
| 数据是什么 | 领域文档、产品手册、代码库 | 用户偏好、历史交互提炼、Agent 经验 |
| 谁写入 | 系统管理员/离线管道批量灌入 | 运行时由用户交互和模型自动产生 |
| 时效性 | 相对稳定，按版本更新 | 持续累积，逐条有生命周期 |
| 正确性责任 | 知识库方保证（权威来源） | 无权威背书，可能是模型推断的，会错 |
| 查询模式 | 按当前问题的语义查 | 按"当前用户是谁、现在在干嘛"查 |
一句话：RAG 回答"世界上有什么知识"，记忆回答"这个用户和这段交互里发生过什么"。把用户记忆混进知识库，就像把浏览器的收藏夹写进百科全书——格式相似，性质完全不同。
工程上：管道可以复用，存储必须分开
说"一点关系没有"也不对。两者的检索侧技术栈几乎一样：embedding、向量索引、top-k、重排序。成熟的做法是复用同一套检索基础设施（同一个向量库服务、同一套 embedding 模型），但分 collection/分表存：
- 知识库 collection：离线 ETL 灌入，按文档版本管理，更新走重建索引。
- 记忆 collection：运行时在线写入，带 user_id、namespace、时间戳、重要性、TTL，更新走查重覆盖。
分开的原因不只是洁癖：记忆的过滤维度（用户、项目、时效）在知识库上不存在；知识库的规模（百万级 chunk）和记忆（用户级千条）对索引参数的要求也完全不同。混在一起的系统，最后都会因为"召回的知识里夹了别人的记忆"或"知识更新把记忆冲了"而拆开重做。
更准确的定位：都是上下文供给层
在上下文工程的框架里，RAG 和记忆是并列的两个信息来源（见上下文工程题的五来源划分），统一由 context builder 调度：一轮推理前，分别向知识库和记忆库发查询，各自召回、各自打分，然后按预算拼装。记忆比知识多两个排序信号（时间衰减、重要性），知识比记忆多一个权威性权重。调度层知道它们的差异，基础设施层让它们共享——这是我认为最干净的架构。
一个容易踩的交叉点
有些团队会把"Agent 从知识库里学到的东西"自动写回记忆，比如"上次检索发现文档 X 有用"。这条路要慎重：知识库更新后这类记忆立即过期，而且本质上是把检索日志错当记忆。检索历史的归属是会话日志，不是长期记忆。
可能的追问
- 能只用一个 collection 加类型字段区分吗？——小规模可以，但要保证过滤在元数据层强制执行；规模上来后两类数据的索引、备份、权限策略都会分化，迟早拆开。
- 用户问"我上次让你查的那个结论"，该查记忆还是查知识库？——查记忆（情景记忆记录了那次交互），知识库没有"你查过"这个概念；这就是两类数据不可互相替代的典型例子。
- 记忆会不会污染 RAG？——反向更常见：RAG 召回的错误文档被模型当事实写进记忆，完成二次污染；防法是记忆写入标注来源，源自检索的记忆带文档版本号，知识更新时连带失效。