企业官网建设流程全解析

这段时间在好几个技术社区里，反复看到同一个问题：Agent 应用到底应该用 RAG，还是应该上 Memory？有人把 RAG 当成解决幻觉的万能药，所有问题都甩给知识库；也有人把 Memory 当成 Agent 的“记忆宫殿”，觉得只要加上长期记忆，AI 就能像人一样越用越懂你。结果真到了落地阶段，RAG 做了，答案还是不对；Memory 加了，反而把上下文搞得一团糟。

先说我的判断：RAG 和 Memory 根本不是二选一的替代关系，而是两条解决不同问题的技术路径。RAG 的核心价值是“让模型知道”，它解决的是模型知识不足、信息过时、无法引用来源的问题；Memory 的核心价值是“让模型记住”，它解决的是多轮交互中上下文丢失、用户偏好无法保留、任务状态无法延续的问题。而 Agent 是更大的执行框架，它完全可以同时调用 RAG 和 Memory，甚至可以说，一个合格的 Agent 架构，这两者早晚都要有。

这篇文章我会从概念差异、适用场景、混合架构设计、代码示例、常见误区和工程最佳实践几个角度，把 RAG、Memory 和 Agent 的关系彻底讲清楚。读完你就能明白：自己手头的项目到底该选哪个，以及如果两个都要，该怎么设计才不会相互打架。

1. 为什么这个问题让很多人纠结

先看几个真实场景。

场景一：你在做一个企业内部的智能客服机器人。员工问“报销差旅费需要什么发票？”，模型其实懂报销的基本流程，但它不知道你们公司刚更新的财务制度。这时候你需要把最新的制度文档喂给模型，这就是 RAG 的典型场景。

场景二：你在做一个 AI 编程助手。用户昨天说“我用的框架是 Spring Boot 3.2”，今天又问“帮我把项目里的 Controller 改成 WebFlux 写法”。模型单次对话里看不到昨天的上下文，它不知道用户的项目背景，这时候你需要让 Agent 记住用户的历史信息，这就是 Memory 的典型场景。

场景三：你在做一个个人知识助理。用户问“帮我总结一下我上周保存的几篇文章”，同时又要求“输出的风格按照我平时习惯来”。第一个需求需要 RAG 去检索文章内容，第二个需求需要 Memory 去记忆用户偏好。这就是混合场景。

很多开发者的误区在于：把 RAG 和 Memory 都当成“给模型多一点信息”的手段。确实，从实现层面看，两者最终都会变成“往上下文窗口里塞内容”。但从架构职责来看，它们应该被严格区分。RAG 管的是临时性、外部化、可检索的事实知识；Memory 管的是持续性、个性化、随交互更新的状态信息。

如果混为一谈，你会在设计系统时走很多弯路。比如给每个用户都建一个专属知识库来记忆偏好——成本高、维护难，而且用户偏好变化根本不适合用向量检索来做；反过来，把公司的制度文档放进 Memory 里让模型长期携带——上下文爆掉不说，文档更新后旧记忆还残留，模型就会一本正经地引用过时内容。团队里关于“到底用哪个”的争论，本质上是没有先把问题拆清楚。

2. 先对齐概念：RAG、Memory、Agent 各自是什么

为了避免后续讨论出现歧义，这里先把三个概念放在同一张表里对齐。

这里要特别说明一个容易混淆的点：Memory 在 AI Agent 语境下，说的不是计算机内存，而是模型交互过程中的“记忆机制”。很多 Java 背景的开发者第一次看到 Memory 会联想到 JVM 堆内存，甚至搜到 outofmemoryerror 之类的内容，这些和本文讨论的 Agent Memory 完全是两回事。在 Agent 语境里，Memory 更接近认知科学里的“记忆”，包括工作记忆（短期）和长期记忆两个层面。

RAG 的完整流程可以理解为一次“开卷考试”。模型不需要把所有知识背下来，考试时给它一份参考资料，它照着资料答题，并且可以标注答案出自哪一页。这就是为什么 RAG 特别强调引用溯源（groundedness），它要让模型的回答有据可查。

Memory 的机制则更接近“记笔记”。和用户交互过程中，系统把重要的信息记在本子上，下次见面时先翻一翻，知道对方是谁、上次聊到哪、有什么偏好。这个本子需要不断更新，也需要定期清理过时内容。

Agent 则是整个执行系统的“调度中心”。它接收用户意图，判断需要哪些信息，决定调用哪个工具，然后组织语言输出。Agent 可以使用 RAG 作为外部知识工具，也可以使用 Memory 作为自我状态管理模块，两者是 Agent 的组成部分，而不是对立面。

3. RAG 和 Memory 的关键差异：知识从哪来，记忆存到哪

把概念讲清楚后，我们再深入一层。RAG 和 Memory 的差异，本质上体现在信息生命周期的不同阶段。

3.1 信息来源不同

RAG 的信息源是外部语料库：企业内部文档、产品手册、合规文件、实时抓取的网页、论文库等。它的特点是更新独立于用户交互，也就是说，知识库的更新由运营人员或上游系统完成，用户每次提问时触发的是检索动作，而不是写入动作。

Memory 的信息源是用户与 Agent 的交互过程：对话历史、用户声明的偏好、系统推理出的隐含状态、工具调用的中间结果。它的特点是动态生成、随每次交互而更新，每次对话都可能产生新的记忆，也可能修正旧记忆。

3.2 信息组织与存储方式不同

RAG 为了支持高效检索，通常会把文档切成小块（chunk），再通过 embedding 模型转成向量，存入向量数据库。检索时用相似度计算找出最相关的片段。除了向量检索，现代 RAG 框架还会加入重排、混合检索（关键词加向量）、引用标注等机制。切块策略是 RAG 工程里非常关键的环节，切大了容易混入无关内容，切小了容易丢失上下文，这直接影响召回质量。

Memory 的存储方式更多样化。短期记忆通常就是对话窗口里的消息列表；长期记忆可能有几种形态：键值对存储用户偏好、向量存储语义记忆片段、结构化数据库存储任务状态，甚至是摘要化的自然语言记录。Memory 系统不只是“存下来”，还要解决什么时候写、什么时候读、什么时候遗忘的问题。

3.3 对模型回答的影响方式不同

RAG 对回答的影响是“提供事实依据”。模型看到检索回来的片段，从中提取信息组织答案，并且可以在引用位置标注来源。它影响的是答案的准确性和可验证性。

Memory 对回答的影响是“提供交互连续性”。模型看到历史记忆，知道用户的身份背景、项目上下文、风格偏好，从而让回答更个性化。它影响的是对话的一致性和体验感。

3.4 失效模式和治理重点不同

RAG 最常见的失效模式是：检索召回的内容本身不相关，模型仍然强行利用这些内容回答，导致答案更差；或者知识库中混入了错误信息，模型凭着“开卷内容”一本正经地胡说。

Memory 最常见的失效模式是：记忆污染。例如用户之前说过“我偏好 Python”，后来改用了 Go，但旧记忆没有更新或权重过高，导致 Agent 一直用 Python 视角回答；又比如短期记忆窗口太长，上下文里塞满历史对话，反而把关键指令淹没，甚至触发上下文长度超限。

这两种失效模式的治理方法也不同：RAG 需要治理的是文档质量、切块策略、召回阈值和引用校验；Memory 需要治理的是写入规则、更新策略、遗忘机制和权限边界。理解了这些差异，才能理解为什么不能简单替换。

4. 到底什么场景用 RAG，什么场景用 Memory

现在可以谈谈选型方法论了。我会先给一个快速判断框架，再给一些典型场景分析。

4.1 快速判断框架

做一个三元判断：

1. 用户的问题，是否依赖模型参数之外的最新/私域/专业知识？

   • 是 → 有 RAG 需求
   • 否 → 仅靠模型能力可能就够

2. 用户的问题，是否依赖前几轮对话中的上下文或长期用户画像？

   • 是 → 有 Memory 需求
   • 否 → 单轮问答即可，不需要记忆

3. 用户的问题，是否需要模型自主规划步骤、调用多个外部工具？

   • 是 → 需要 Agent 框架支撑
   • 否 → 可以不做 Agent 编排

实际项目里，这三个回答常常同时为“是”，所以真正的问题不是“用哪个”，而是“各自承担什么职责”。

4.2 几乎只适合 RAG 的场景

如果需求核心是“让模型基于指定资料回答”，就应该优先做 RAG：

• 企业规章制度问答：问题范围固定，答案必须引用最新制度条款。
• 产品使用文档问答：用户问的是“这个功能怎么配置”，答案在官方文档里，而且版本经常变化。
• 学术文献综述：需要基于检索到的多篇论文生成回答，并要求标注出处。
• 电商平台商品问答：商品信息、库存、价格实时变化，不可能让模型预训练记住。

这类场景共同特征是：正确答案存在于外部资料中，且资料的更新频率较高，不能依赖模型参数内的陈旧知识。同时，对回答的可验证性有要求，需要知道“这个答案是从哪份文档里来的”。

4.3 几乎只适合 Memory 的场景

如果需求核心是“让交互体验更连续、更个性化”，就应该优先做 Memory：

• 个人助理：用户说“帮我提醒我周五下午三点开会”，Agent 需要记住这个待办事项，并在后续交互中主动关联。
• AI 编程助手：记住用户的项目语言、框架、代码风格、常用依赖。
• 教育辅导 Agent：记住学生的学习进度、薄弱知识点、上次讲到哪。
• 长期陪伴型对话系统：用户偏好、兴趣范围、历史话题提及。

这类场景共同特征是：没有一份外部文档可以检索，关键信息散落在多轮交互过程中，并且随着交互持续更新。系统要能维护一个不断演进的状态，而不是每次从零开始。

4.4 同时需要 RAG 和 Memory 的典型场景

实际上，企业级 Agent 项目里混合场景非常普遍。我们以一个企业知识助理为例：

• 用户问“公司年假制度是什么？” → RAG 检索制度文档。
• 用户补充“我去年还剩三天年假，帮我算算今年能休几天？” → 这里既需要 RAG 读取制度规则，也需要 Memory 读取该用户的年假余额历史记录，甚至需要调用 HR 系统的 API，这时就需要 Agent 来做任务编排。
• 用户最后说“下周帮我预约休假申请” → Agent 需要记住这个行动项，在未来合适的时间触发。

在这种场景里，RAG 和 Memory 不是竞争关系，而是协作关系。Agent 在规划阶段判断：当前任务需要外部知识，还是需要用户历史状态，或者两者都要。设计合理的 Agent 系统会为每条信息标注来源类型，并在生成回答时明确指出“制度来自公司文档，个人余额来自用户历史记录”。

4.5 企业级 RAG 的常见实践痛点

既然提到企业级场景，这里多说一句。很多项目在真正落地 RAG 时会发现，难点反而不在“接一个向量数据库”，而在更前端的工程问题：

• 文档加载与解析：PDF、Word、PPT、扫描件，格式五花八门，解析出来经常乱码或丢内容。
• 切块策略：切块大小、重叠度、按标题层级切还是按段落切，直接影响召回效果。
• 召回质量：只用向量相似度经常召回不准确，需要加关键词混合检索和重排模型。
• 引用溯源与 groundedness：模型可能检索到了正确内容，但回答时自行发挥，需要额外加校验环节。
• 知识库更新：文档更新后，旧向量没有及时失效，导致回答新旧混杂。

这些问题都说明：RAG 不是“加一个检索步骤”就完事，而是一整套系统工程。这也是为什么现在很多人开始研究 Agentic RAG——让 Agent 自主判断什么时候检索、检索几轮、检索后如何验证。但无论架构多复杂，RAG 的职责边界依然是清晰的：它负责对外部知识的获取与引用。

5. 可落地的混合架构：RAG + Memory 在 Agent 中如何协作

理解了职责边界后，我们来看一个可落地的架构方案。这个架构不做过度设计，而是把 RAG 和 Memory 作为两个独立模块接入 Agent，让 Agent 在其中做决策。

5.1 架构分层

整个系统可以分成四层：

• 交互层：接收用户输入，返回模型输出。
• Agent 决策层：判断当前任务类型，决定是否需要检索、是否需要读取记忆，编排调用顺序。
• 工具与记忆层：RAG 检索模块、Memory 读写模块、业务 API 工具。
• 基础设施层：向量数据库、长期记忆存储、文档解析服务、模型推理服务。

从交互层到基础设施层，信息单向流动，各模块之间通过明确的接口通信。特别要注意的是：Memory 和 RAG 不应互相直接访问内部存储，应该都通过 Agent 的调度逻辑来协调，否则容易出现数据竞争和权限混乱。

5.2 一个简洁的 Agent 调度流程

我用一个伪代码级别的流程来说明：

1. 接收用户输入。
2. Agent 读取短期记忆（最近几轮对话），形成当前上下文。
3. Agent 判断：是否需要读取长期记忆（用户偏好、历史事实）。如果需要，读取并加入上下文。
4. Agent 判断：是否需要外部知识。如果需要，调用 RAG 检索模块，对结果做重排和截断，再加入上下文。
5. 大模型综合上下文和检索结果，生成回答。
6. 回答生成后，Agent 判断是否有值得写入记忆的新信息（例如用户新声明的偏好），按规则写入 Memory。
7. 返回回答。

这套流程看起来简单，但每一步都有工程细节。下面给出一个可运行的最小实现，帮助理解。

5.3 基础环境准备

本文后面的示例代码以 Python 为主，依赖 LangChain 生态的常用组件。环境要求如下：

• Python 3.9 或更高版本（实测建议 3.10+）
• 一个可用的 OpenAI 兼容接口的模型服务，可以是本地部署，也可以是云端 API
• Chroma 或 FAISS 作为本地向量数据库
• LangChain、langchain-community 等依赖

这里不写死具体版本，因为 LangChain 更新较快，API 可能有调整。建议以官方最新稳定版为准。核心思路和编码风格比版本号更重要。

安装依赖示例：

pip install langchain langchain-community chromadb faiss-cpu openai tiktoken

如果你的模型服务不是 OpenAI 官方接口，而是本地通过 llama.cpp 或 vLLM 部署的 OpenAI 兼容服务，可以在环境变量里配置 base_url 和 api_key，LangChain 的 ChatOpenAI 可以直接对接。

5.4 代码实现：RAG 检索模块

先写 RAG 模块，它负责加载文档、切块、写入向量库、检索。

# 文件路径：modules/rag.py from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import OpenAIEmbeddings from langchain_community.vectorstores import Chroma from langchain_openai import ChatOpenAI class RAGModule: def __init__(self, collection_name="company_kb", persist_dir="./data/kb"): self.embeddings = OpenAIEmbeddings() self.vectorstore = Chroma( collection_name=collection_name, embedding_function=self.embeddings, persist_directory=persist_dir ) self.chunk_size = 800 self.chunk_overlap = 120 def ingest_document(self, file_path: str): """加载文档并写入向量库。生产环境应单独执行，而不是每次启动都重跑。""" loader = TextLoader(file_path, encoding="utf-8") documents = loader.load() splitter = RecursiveCharacterTextSplitter( chunk_size=self.chunk_size, chunk_overlap=self.chunk_overlap, separators=["\n\n", "\n", "。", "！", "？", "；", "，"] ) chunks = splitter.split_documents(documents) self.vectorstore.add_documents(chunks) print(f"已写入 {len(chunks)} 个切块") def search(self, query: str, k: int = 5): """检索最相关的文档片段。""" docs = self.vectorstore.similarity_search_with_score(query, k=k) return docs

代码说明：

• 切块用 RecursiveCharacterTextSplitter，先按段落边界切，再按句子边界兜底。这样能尽量保住语义完整性。
• chunk_size 设为 800 字符、重叠 120 字符，是一个相对稳妥的起步值，实际要根据文档类型和模型上下文窗口调整。
• similarity_search_with_score 返回片段和相似度分数，便于后续过滤低相关结果。
• ingest_document 应在运维阶段独立执行，而不是每次用户请求都触发，否则会产生大量重复向量。

5.5 代码实现：Memory 读写模块

Memory 模块用两层设计。短期记忆直接用内存中的消息列表；长期记忆用 JSON 文件存储键值对，便于理解，生产环境可以用 Redis 或数据库替代。

# 文件路径：modules/memory.py import json import os from datetime import datetime from typing import Optional class MemoryModule: def __init__(self, memory_file: str = "./data/memory.json"): self.memory_file = memory_file self.short_term_messages = [] self.long_term = self._load() def _load(self) -> dict: if os.path.exists(self.memory_file): with open(self.memory_file, "r", encoding="utf-8") as f: return json.load(f) return {} def _save(self): os.makedirs(os.path.dirname(self.memory_file), exist_ok=True) with open(self.memory_file, "w", encoding="utf-8") as f: json.dump(self.long_term, f, ensure_ascii=False, indent=2) def add_short_term(self, role: str, content: str, max_messages: int = 10): """添加短期对话消息，并控制窗口长度。""" self.short_term_messages.append({ "role": role, "content": content, "time": datetime.now().isoformat() }) if len(self.short_term_messages) > max_messages: self.short_term_messages.pop(0) def set_long_term(self, key: str, value: str): """写入或更新一条长期记忆。""" self.long_term[key] = { "value": value, "updated_at": datetime.now().isoformat() } self._save() def get_long_term(self, key: str) -> Optional[str]: """读取一条长期记忆。""" item = self.long_term.get(key) return item["value"] if item else None def get_relevant_context(self, user_id: str) -> str: """将长期记忆中与该用户相关的记录拼成上下文提示。""" contexts = [] prefix = f"user_{user_id}_" for k, v in self.long_term.items(): if k.startswith(prefix): contexts.append(f"{k.replace(prefix, '')}: {v['value']}") return "\n".join(contexts)

代码说明：

• 短期记忆用列表实现，超过 max_messages 自动丢弃最旧消息。这是一个简单策略，实际项目可以升级为滑动窗口加摘要压缩。
• 长期记忆用 JSON 文件持久化，key 的设计采用 user_id 前缀，例如 user_1001_language: Python，这样同一个服务可以为多个用户隔离记忆。
• set_long_term 会覆盖旧值，这就是最简单的“更新”和“防污染”策略。更复杂的场景需要记录多版本、时间权重、置信度等。
• get_relevant_context 只取当前用户相关的记忆，避免无关用户的信息混入。

5.6 代码实现：Agent 决策编排

最后把 RAG 和 Memory 接到 Agent 里。这里用一个简化但结构清晰的 Agent 类。

# 文件路径：agent.py from modules.rag import RAGModule from modules.memory import MemoryModule from langchain_openai import ChatOpenAI SYSTEM_PROMPT = """你是一个企业知识助理。回答时请遵循以下规则： 1. 如果知识库提供了参考资料，请优先依据参考资料回答，并在末尾标注引用来源。 2. 如果记忆中有用户的偏好或历史信息，请自然地结合到回答中。 3. 如果两者都没有相关信息，请明确说“我没有找到相关资料”，不要编造。 """ class AssistantAgent: def __init__(self, user_id: str): self.user_id = user_id self.rag = RAGModule() self.memory = MemoryModule() self.llm = ChatOpenAI(model="gpt-4o-mini", temperature=0.2) def run(self, user_input: str) -> str: # 1. 短期记忆拼接 messages = [{"role": "system", "content": SYSTEM_PROMPT}] for msg in self.memory.short_term_messages: messages.append({"role": msg["role"], "content": msg["content"]}) # 2. 长期记忆拼接 long_term_context = self.memory.get_relevant_context(self.user_id) if long_term_context: messages.append({ "role": "system", "content": f"以下是该用户的长期记忆：\n{long_term_context}" }) # 3. RAG 检索 retrieved = self.rag.search(user_input, k=3) if retrieved: rag_context = "\n\n".join([ f"[源文档片段 {i+1}]\n{doc.page_content}" for i, (doc, score) in enumerate(retrieved) if score > 0.5 ]) if rag_context: messages.append({ "role": "system", "content": f"以下是知识库检索结果：\n{rag_context}" }) # 4. 用户请求 messages.append({"role": "user", "content": user_input}) # 5. 模型生成 response = self.llm.invoke(messages) # 6. 写入短期记忆 self.memory.add_short_term("user", user_input) self.memory.add_short_term("assistant", response.content) # 7. 简单规则：自动记住用户偏好，例如以“我喜欢”开头的句子 if "我喜欢" in user_input or "我用的是" in user_input: self.memory.set_long_term(f"user_{self.user_id}_preference", user_input) return response.content

代码说明：

• Agent 在构造 messages 时，先放系统提示词，再放短期记忆、长期记忆、RAG 检索结果，最后放当前用户输入。这种顺序能让模型更注意最新的用户请求。
• RAG 检索结果通过 score 过滤，低于 0.5 的直接丢弃，避免低相关片段干扰模型。这个阈值需要根据 embedding 模型和业务场景调优。
• 记忆写入使用非常简单的规则：如果用户输入包含“我喜欢”“我用的是”，就写入长期记忆。真实项目需要更精细的记忆抽取策略，可以专门训练抽取模型或用大模型在后台做记忆提炼。
• 短期记忆先写入再调用模型，也可以调整为先调用模型再写入，取决于你是否希望模型参考当前轮的输入在上下文中再加工一次。这里选择先写入用户输入，后续生成时不重复添加用户消息。

5.7 如何运行与验证

假设你已经准备好一个公司制度文档 company_policy.txt，并配置好了 OpenAI 兼容接口的模型服务。运行步骤如下。

第一步，初始化知识库并导入文档：

python -c "from modules.rag import RAGModule; r = RAGModule(); r.ingest_document('./data/company_policy.txt')"

看到类似输出“已写入 42 个切块”，说明向量库构建成功。

第二步，运行一个交互式 Demo：

python demo.py

demo.py 的核心逻辑就是循环接收输入，调用 AssistantAgent.run()，打印输出。假设用户第一次输入“我用的是 Java 17 和 Spring Boot 3”，系统会把它写入长期记忆。第二次输入“帮我看看报销政策里提到发票要求吗”，RAG 会从制度文档中检索相关内容。第三次输入“我刚刚说的技术栈是什么来着”，Agent 就能从长期记忆中读出 Java 17 和 Spring Boot 3，完成记忆回放。

如果前几步跑通，你已经拥有了一个同时具备外部知识检索和长期记忆能力的 Agent 雏形。

6. 运行结果与效果验证方法

实际运行时，你可能想知道：RAG 到底有没有召回对？Memory 有没有写入和读到预期内容？这里给出三个层次的验证思路。

6.1 分模块验证

先把模块拆开单独测试，不要一上来就跑完整 Agent。RAG 模块可以用单独的检索脚本验证：

python -c " from modules.rag import RAGModule r = RAGModule() docs = r.search('差旅报销需要什么发票', k=3) for doc, score in docs: print(f'分数: {score:.4f}') print(doc.page_content[:200]) "

如果召回的内容明显不相关，优先检查切块策略和 embedding 模型选择。如果召回内容正确但分数都低于阈值，就需要调低阈值或优化文档。

Memory 模块可以用一组简单的读写操作验证：

python -c " from modules.memory import MemoryModule m = MemoryModule() m.set_long_term('user_1001_language', 'Java') print(m.get_long_term('user_1001_language')) print(m.get_relevant_context('1001')) "

6.2 端到端验证

完整 Agent 验证时，准备一组覆盖三类场景的测试用例：

如果知识型问题回答正确，但个性化问题回答不出来，说明 Memory 写入规则没触发，或者读取上下文的拼接有问题。如果混合问题回答混乱，说明系统提示词里对信息优先级的定义不够清楚。

6.3 失败排查第一步

端到端运行失败时，不要先怀疑模型。从最简单的日志入手：打印最终发给模型的 messages，看看里面是否真的包含 RAG 检索结果和 Memory 上下文。很多问题在这一步就能定位，比如检索结果为空、记忆没有写入、上下文顺序不对等。

7. 常见问题与排查思路

这里整理几个我在实践中常见的问题，供参考。

值得提醒的是，“上下文超长”这类问题在大型 Agent 系统里非常常见。很多人会误以为这是计算机内存（memory）不足，实际是上下文窗口或存储容量设计问题。排查时先分清是 API 报的上下文长度错误，还是本地进程 OOM，两者解决办法完全不同。

8. 最佳实践与工程建议

了解了概念和代码，最后把工程化建议汇总一下。这些建议不是底层原理，而是从真实项目中沉淀出来的经验。

8.1 先跑通最小闭环，再扩展功能

很多 RAG 项目一开始就追求大而全：文档解析系统、混合检索、重排模型、引用校验、权限控制、多租户隔离全部上齐。结果方案设计了一个月，连一条端到端链路都没跑通。正确的做法是先用一个小文档集跑通“加载、切块、检索、生成”的最小闭环，验证效果，再逐层叠加能力。Memory 也一样，先用键值对存几条偏好，观察模型行为是否符合预期，再引入向量记忆或摘要记忆。

8.2 明确信息源职责，避免重复存储

这是最容易犯的架构错误。同一个信息，既可以被放进知识库，也可以被写进记忆。要定一条规则：凡是外部资料里能查到的，优先走 RAG；凡是用户交互中产生的，走 Memory。例如用户当前使用的技术栈，属于交互产生的个性化信息，应该进 Memory；公司的技术选型规范，属于外部资料，应该进 RAG。如果两边都存，会造成来源混乱，回答时引用错误。

8.3 给记忆设计更新和遗忘机制

很多 Memory 系统只写不删，时间长了就变成“记忆垃圾场”。需要提前设计：

• 写入规则：什么信息值得记住？可以设置关键词规则，也可以用大模型在后台做记忆抽取和置信度打分。
• 更新规则：用户新说的信息与旧记忆冲突时，以谁为准？常见做法是覆盖旧值并记录时间戳，或者保留多版本并让模型判断。
• 遗忘规则：多久未更新的记忆需要弱化或删除？敏感信息是否需要定时清理？

8.4 RAG 检索结果必须做质量闸门

不要让所有检索结果都无脑进入上下文。至少要加一道过滤，相似度低的一律丢弃。更完善的方案还应该包括：

• 重排模型对候选片段重新打分。
• 去重和冗余消除，避免同一信息多次出现。
• 引用标注，让模型在输出时带上来源编号。
• 对高风险场景加入 Groundedness 校验，检查回答是否真的基于检索片段，而不是模型自行发挥。

8.5 日志和审计是 Agent 系统的基础设施

不管是 RAG 召回，还是 Memory 读写，每一步都要有日志。线上出问题时，没有日志就等于靠猜。日志至少包含：

• 用户请求了什么问题
• Agent 决策了调用哪些模块
• RAG 召回了哪些片段，分数是多少
• Memory 读写了哪些键，内容快照
• 模型最终用了什么上下文
• 回答内容的来源标注

这也是满足数据合规和审计要求的基础。尤其涉及企业内部资料和个人信息时，要明确哪些数据可以进入知识库、哪些记忆需要用户授权。

8.6 权限与安全边界要提前设计

RAG 的知识库往往包含企业内部敏感文档，Memory 往往包含用户个人信息。两个模块都要做权限控制：

• RAG 检索时要基于用户角色过滤可见文档。
• Memory 存储时要区分用户私有记忆和共享记忆。
• Agent 工具调用要有最小权限原则，不能因为检索文档，就获得整个数据库的访问权。
• 删除诉求要有接口支持，例如用户注销后清理其长期记忆。

8.7 评估体系比调参更重要

不要凭感觉判断“这次比上次好”。为系统建立一套离线评估集：知识型问题若干条、个性化问题若干条、混合问题若干条。每次调整切块策略、提示词、记忆规则后，跑一遍评估集，对比准确率、召回率、引用合规率和用户满意度。没有评估体系，一切优化都是盲目的。

9. 总结

RAG 和 Memory 不是“二选一”的竞争关系。RAG 让 Agent 知道外部世界的实时知识，Memory 让 Agent 记住用户的交互历史与偏好，Agent 则是把两者组织起来完成复杂任务的执行框架。理解这一点，很多基于“用哪个更好”的争论自然就消失了。

如果你正在做一个知识问答类应用，优先把 RAG 做好，重点关注文档解析、切块、召回质量和引用溯源；如果你正在做一个需要多轮个性化交互的 Agent，优先把 Memory 做好，从短期窗口和键值式长期记忆起步，逐步完善更新与遗忘机制；如果你的目标是企业级智能体，那么两者都要做，并且要在架构层面明确各自的边界，通过 Agent 统一调度。

下一步值得深入的方向包括：Agentic RAG 的自主检索策略、记忆抽取与大模型摘要的结合、知识库与记忆的权限治理、以及针对长窗口上下文的上下文压缩技术。建议收藏这篇，做项目时拿出来对着检查一下：你的系统里，知识从哪来，记忆存到哪，Agent 是否真的把它们编排清楚了。