很多同學在做大模型應用的時候常常會被這三個概念繞暈RAG、Memory、Agent。團隊里討論方案有人說用 RAG 做知識庫有人說要加 Memory 才能讓對話連貫還有人直接說上 Agent 就全解決了。結果一圈討論下來代碼一行沒寫方案已經改了三次。這篇文章就圍繞一個核心問題展開RAG、Memory、Agent 到底分別解決什么問題它們是不是非此即彼的關系落到實際項目里應該怎么選、怎么結合文章會先從概念入手把三者的邊界講清楚然后用一份完整的代碼示例演示“RAG Memory Agent”怎么在一個項目里協同工作最后給出選型建議、常見坑點和工程落地經驗。適合正在做 RAG 知識庫、AI Agent 開發、或者準備把大模型接入業務系統的開發者閱讀。1. 背景與核心概念在正式寫代碼之前先把三個概念放在同一個坐標系里看待。很多人會誤以為 RAG、Memory、Agent 是三個并列的技術方案選了 A 就不用 B。實際上它們屬于不同層次的能力模塊面對的是不同的問題。1.1 RAG 解決的是“模型不知道”的問題RAG 的全稱是 Retrieval-Augmented Generation檢索增強生成。它的核心思路很簡單大模型的知識是訓練時固化的無法覆蓋你業務里的私有數據。RAG 先把外部文檔切片、向量化建立索引等用戶提問時先從知識庫中檢索出相關片段再把片段和問題一起交給大模型生成答案。用一句話概括RAG 是給大模型裝了一個“外部知識庫”。RAG 適合的場景非常明確企業內部的規章制度、產品手冊、維修文檔問答。基于私有 PDF、Word、網頁內容構建問答系統。實時性要求高、需要引用來源的信息查詢。工程上RAG 有四個關鍵環節也是后續容易出現問題的四個環節文檔加載與解析、文本切塊、向量化與存儲、檢索與重排。1.2 Memory 解決的是“模型記不住”的問題大模型本身是無狀態的。你上一輪問了“北京明天天氣怎么樣”下一輪問“那后天呢”如果模型不記得“那”指代的是“北京”回答就會跑偏。Memory 模塊的作用就是讓 Agent 或對話系統具備“記憶能力”。它通常分為三類記憶類型類比典型實現短期記憶臨時記住當前對話上下文把最近幾輪對話拼進 Prompt長期記憶跨會話記住用戶偏好和歷史事實存入數據庫按用戶 ID 讀取工作記憶任務執行過程中臨時保存中間狀態Agent 執行計劃時維護狀態變量注意Memory 和 RAG 有一個容易混淆的點兩者都要“存取數據”。區別在于Memory 存的是“關于用戶、對話、任務狀態”的信息RAG 存的是“領域知識、文檔內容”。1.3 Agent 解決的是“模型不會做”的問題如果說 RAG 是讓模型“知道得更多”Memory 是讓模型“記得住”那么 Agent 是讓模型“動起來”。Agent 的核心是讓大模型充當一個“大腦”通過推理來決定調用哪些工具、按什么順序執行最終完成一個復雜任務。一個標準的 Agent 循環通常包含接收用戶目標。推理并拆解任務生成計劃。按計劃調用工具搜索、計算、調 API、操作數據庫等。觀察工具返回結果判斷是否繼續或結束。輸出最終答案。Agent 的出現解決的是“大模型只能生成文本不能完成操作”的問題。它把大模型從“問答機器”變成了“執行者”。1.4 三者不是三選一而是三層結構用一個生活化的例子來說明。你去醫院看病導診臺Agent先問你的癥狀根據你的描述決定讓你去內科還是外科醫生翻看你之前的病歷Memory遇到不確定的罕見病還會查閱醫學指南和文獻RAG。最終給出診斷和治療方案。看到沒有Agent、Memory、RAG 本來就在同一個系統里協同工作。這也引出了文章的核心觀點選擇不是“用 RAG 還是用 Agent”而是“這個環節需不需要檢索、需不需要記憶、需不需要行為決策”。2. 環境準備與版本說明下面進入實戰。本文的示例以一個“企業知識庫問答 多輪對話記憶 Agent”為業務背景使用 Python LangChain 體系來實現。先說明一下環境。大模型技術棧更新非常快具體版本建議以你本機為準。本文示例基于以下環境你實際使用時需要根據版本差異調整參數組件說明操作系統Windows 10/11、macOS、Linux 均可Python3.9 及以上LangChain0.1.x 或 0.2.x接口有差異注意兼容向量數據庫Chroma本地運行無需額外服務Embedding 模型使用 OpenAI 的 text-embedding-ada-002或本地 BGE/M3E 模型LLM以 OpenAI GPT 系列為例也可替換為 Qwen、DeepSeek 或本地 llama.cpp 部署的模型如果你在本地通過 llama.cpp Qwen2-7B 搭建過 RAG 知識庫會發現核心流程沒有區別只是 Embedding 和 LLM 的加載方式不同。2.1 安裝依賴創建項目目錄和虛擬環境mkdir rag-memory-agent-demo cd rag-memory-agent-demo python -m venv venv source venv/bin/activate # Windows 下執行 venv\Scripts\activate安裝依賴pip install langchain langchain-openai langchain-community chromadb faiss-cpu python-dotenv說明一下langchain-openai是 LangChain 官方維護的 OpenAI 集成包。chromadb作為本地向量數據庫零配置適合學習和原型驗證。faiss-cpu是可選依賴如果你只用 Chroma 可以不裝。python-dotenv用于管理環境變量。2.2 項目結構rag-memory-agent-demo/ ├── .env # 存放 API Key ├── data/ │ └── employee_handbook.md # 示例知識庫文檔 ├── rag_service.py # RAG 檢索模塊 ├── memory_service.py # 會話記憶模塊 ├── agent_service.py # Agent 編排模塊 └── main.py # 入口文件這個結構把 RAG、Memory、Agent 拆成三個獨立模塊方便你看清每一層做了什么。3. 核心原理拆解在把代碼串起來之前先分別拆解三個模塊的關鍵實現點。這樣后面看完整代碼時你能知道每一行是在做什么。3.1 RAG 檢索流程的四個關鍵環節RAG 的實現并沒有多玄妙核心就是“文檔進、答案出”的四步流水線文檔加載 → 文本切塊 → 向量化入庫 → 檢索并生成文檔加載從 PDF、Word、Markdown 等文件里提取純文本。這一步的坑最多尤其是 PDF 里的表格、掃描件需要 OCR 或者專門的表格解析工具。對 Markdown 和純文本來說直接讀取即可。文本切塊因為大模型有上下文窗口限制同時檢索單位太大也會導致“檢索到一大段無關內容”所以需要把長文本切成小塊。切塊策略直接影響檢索效果。向量化入庫把每個文本塊通過 Embedding 模型轉成向量存入向量數據庫。這里的“語義相近的文本向量距離也近”是檢索能工作的基礎。檢索并生成用戶提問時把問題也向量化然后從庫里找到最相似的 Top-K 個文本塊拼進 Prompt 交給大模型。切塊策略重點說一下。常見的切法有固定長度切塊例如每 500 個字符切一塊塊與塊之間重疊 50 字符。按結構切塊例如 Markdown 標題、段落、句子邊界。遞歸切塊先按大單位切再對超長塊按小單位切。在 LangChain 中推薦使用RecursiveCharacterTextSplitter它的邏輯是先按段落切段落太長再按句子切句子太長再按字符切。這比固定長度切塊更能保留語義完整性。3.2 Memory 的三種實現層次LangChain 的 Memory 體系經歷了比較大的演進。早期版本通過ConversationBufferMemory等類維護對話歷史新版本推薦直接使用langchain.memory里的不同組件或者干脆在Runnable/ Agent 里手動管理消息列表。實際項目中最簡單可靠的記憶實現方式有兩種第一種會話級消息列表。把歷史對話保存在一個列表里每次請求時拼到 Prompt 中。適合短期記憶。messages [] messages.append({role: user, content: 我住在杭州}) messages.append({role: assistant, content: 你好杭州是個好地方})第二種持久化長期記憶。把用戶的關鍵信息抽取出來存入 Redis 或 MySQL用戶下次訪問時加載。適合長期記憶。需要注意把全部歷史對話都塞進 Prompt 是不行的。上下文窗口有限、成本會線性增長、模型對過長的歷史反而會“迷失”。所以工程上要做“記憶壓縮”只保留最近幾輪對話或者對歷史做摘要。3.3 Agent 的執行循環一個最精簡的 Agent 循環可以這樣理解用戶問題 ↓ LLM 根據指令 工具描述決定是否調用工具、調用哪個、傳什么參數 ↓ 執行工具拿到結果 ↓ LLM 觀察結果決定繼續調用工具還是直接回答 ↓ 輸出最終答案這個“決策—執行—觀察—再決策”的循環就是 Agent 和普通 API 調用的本質區別。LangChain 中對這個模式做了高度封裝你只需要定義 Tool 的name、description、args_schema和funcAgent 框架就會讓 LLM 根據description來決定何時調用。這里有個關鍵經驗Tool 的 description 寫得好不好直接決定 Agent 的準確率。如果你寫“use this when user asks about anything”那 LLM 什么都會去調這個工具如果你寫“use this when user asks about company policies from the knowledge base”LLM 就知道這是知識庫專用工具。4. 完整實戰案例構建一個帶記憶的知識庫 Agent接下來我們將把三個模塊組合到一個項目中。業務場景是企業員工手冊問答 Agent。它需要做到用戶提問關于公司制度的問題如年假、報銷從知識庫中檢索回答。用戶進行多輪對話時Agent 記住用戶姓名、崗位、之前的問答內容。用戶可以要求 Agent 基于已知信息執行簡單操作例如“根據我的年假余額提醒我今年還剩幾天”。4.1 準備示例文檔創建data/employee_handbook.md# 員工手冊節選 ## 年假制度 員工入職滿一年后享有每年 5 天帶薪年假。工齡滿 10 年年假增加至 10 天。 年假需要提前 3 個工作日申請經部門主管審批后方可休假。 ## 報銷制度 員工因公出差產生的交通、住宿、餐飲費用可在回國后 7 個工作日內提交報銷申請。 報銷金額超過 5000 元需要總經理審批。 ## 遠程辦公 員工每周可申請最多 2 天遠程辦公。遠程辦公期間需要保持即時通訊在線并按時參加每日站會。4.2 編寫 RAG 模塊文件路徑rag_service.pyimport os from dotenv import load_dotenv from langchain_community.document_loaders import TextLoader from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_core.runnables import RunnableLambda load_dotenv() class RAGService: def __init__(self, doc_path: str, persist_dir: str ./chroma_db): self.persist_dir persist_dir self.embeddings OpenAIEmbeddings( modeltext-embedding-ada-002, api_keyos.getenv(OPENAI_API_KEY) ) self.vector_store self._build_or_load(doc_path) def _build_or_load(self, doc_path: str): # 如果本地已有向量庫直接加載 if os.path.exists(self.persist_dir): return Chroma( persist_directoryself.persist_dir, embedding_functionself.embeddings ) # 否則從文檔構建 loader TextLoader(doc_path, encodingutf-8) documents loader.load() text_splitter RecursiveCharacterTextSplitter( chunk_size200, chunk_overlap50, separators[\n\n, \n, 。, , , , ] ) docs text_splitter.split_documents(documents) return Chroma.from_documents( docs, self.embeddings, persist_directoryself.persist_dir ) def search(self, query: str, k: int 3): # 返回檢索到的文檔片段列表 return self.vector_store.similarity_search(query, kk) def as_tool_func(self): # 方便 Agent 直接調用 def search_func(query: str) - str: docs self.search(query, k3) return \n\n.join([doc.page_content for doc in docs]) return search_func幾點說明chunk_size200表示每個文本塊約 200 字符這個數值需要根據文檔情況調整。chunk_overlap50讓相鄰塊之間有 50 字符重疊避免切在語義邊界導致信息丟失。separators的優先級是從左到右先按段落切再按句號切。OpenAIEmbeddings需要你在.env里配置OPENAI_API_KEY。如果你使用本地模型可以替換成langchain_community.embeddings里的HuggingFaceBgeEmbeddings或OllamaEmbeddings。4.3 編寫 Memory 模塊文件路徑memory_service.py為了演示長期記憶和短期記憶的區別這里用 JSON 文件做簡單的長期記憶持久化同時在內存里維護短期會話歷史。import json import os from datetime import datetime class MemoryService: MEMORY_FILE ./memory_store.json def __init__(self, user_id: str): self.user_id user_id self.short_term_messages [] self._ensure_file() def _ensure_file(self): if not os.path.exists(self.MEMORY_FILE): with open(self.MEMORY_FILE, w, encodingutf-8) as f: json.dump({}, f) def _load_all(self): with open(self.MEMORY_FILE, r, encodingutf-8) as f: return json.load(f) def _save_all(self, data): with open(self.MEMORY_FILE, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) def add_long_term(self, key: str, value: str): 長期記憶記錄用戶的穩定信息如姓名、崗位、偏好 data self._load_all() if self.user_id not in data: data[self.user_id] {} data[self.user_id][key] { value: value, updated_at: datetime.now().isoformat() } self._save_all(data) def get_long_term(self, key: str None): 如果指定 key返回對應值否則返回該用戶的全部長期記憶 data self._load_all() user_data data.get(self.user_id, {}) if key: return user_data.get(key, {}).get(value, ) return {k: v[value] for k, v in user_data.items()} def add_short_term(self, role: str, content: str): 短期記憶保存當前會話的對話消息 self.short_term_messages.append({role: role, content: content}) # 只保留最近 6 條避免上下文過長 if len(self.short_term_messages) 6: self.short_term_messages self.short_term_messages[-6:] def get_short_term(self): return self.short_term_messages這里體現了一個很重要的工程思路長期記憶存的是“事實”短期記憶存的是“上下文”。事實需要跨會話保留上下文只需要當前會話內保持。4.4 編寫 Agent 編排模塊文件路徑agent_service.py我們用 LangChain 的 AgentTool Calling Agent來串聯 RAG 和 Memory。from langchain.agents import AgentExecutor, create_tool_calling_agent from langchain.tools import Tool from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain_openai import ChatOpenAI from rag_service import RAGService from memory_service import MemoryService class AgentService: def __init__(self, rag: RAGService, memory: MemoryService): self.rag rag self.memory memory self.llm ChatOpenAI( modelgpt-4o-mini, temperature0.1 ) self.agent_executor self._create_agent() def _create_agent(self): # 定義 Agent 可用的工具 tools [ Tool( nameknowledge_base_search, description( Search the employee handbook knowledge base. Use this when user asks about company policies, leave, reimbursement, remote work, or other HR rules. ), funcself.rag.as_tool_func() ), Tool( nameget_user_memory, descriptionGet the long-term memory of the current user. Use this when you need to recall users stored information like name, position, preferences., funclambda x: str(self.memory.get_long_term()) ), Tool( namesave_user_memory, descriptionSave a piece of user information into long-term memory. Use this when user tells you personal facts like their name, role, or preferences., funcself.memory.add_long_term ) ]等等這里有一個問題需要修正Tool的func要求接受一個參數。save_user_memory需要接收兩個參數key 和 value不能直接傳給 Agent。我們改造一下用一個參數接收字符串解析后再保存。修正后的代碼如下class AgentService: def __init__(self, rag: RAGService, memory: MemoryService): self.rag rag self.memory memory self.llm ChatOpenAI( modelgpt-4o-mini, temperature0.1 ) # 綁定內存服務到當前用戶 self.agent_executor self._create_agent() def _create_agent(self): def save_memory_func(arg: str): # 參數格式: keyvalue # 實際項目中建議用 JSON 格式 if not in arg: return Invalid format. Please use keyvalue. key, value arg.split(, 1) self.memory.add_long_term(key.strip(), value.strip()) return fSaved {key.strip()} to memory. tools [ Tool( nameknowledge_base_search, description( Search the employee handbook knowledge base. Use this when user asks about company policies, leave, reimbursement, remote work, or other HR rules. ), funcself.rag.as_tool_func() ), Tool( nameget_user_memory, descriptionGet the long-term memory of the current user. Use this when you need to recall users stored information like name, position, preferences., funclambda x: str(self.memory.get_long_term()) ), Tool( namesave_user_memory, descriptionSave a piece of user information into long-term memory. Use this when user tells you personal facts like their name, role, or preferences. Argument format: keyvalue, funcsave_memory_func ) ] prompt ChatPromptTemplate.from_messages([ (system, 你是一個企業員工助手。你的職責是 1. 當用戶詢問公司制度時調用 knowledge_base_search 獲取答案。 2. 記住用戶提供的個人信息調用 save_user_memory 保存。 3. 回答問題時結合當前對話歷史和長期記憶給出個性化回答。 ), MessagesPlaceholder(variable_namechat_history), (user, {input}), MessagesPlaceholder(variable_nameagent_scratchpad) ]) agent create_tool_calling_agent(self.llm, tools, prompt) return AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) def run(self, user_input: str): # 將短期記憶作為 chat_history 傳入 result self.agent_executor.invoke({ input: user_input, chat_history: self.memory.get_short_term() }) # 更新短期記憶 self.memory.add_short_term(user, user_input) self.memory.add_short_term(assistant, result[output]) return result[output]需要特別說明一個關鍵點為什么要把短期記憶單獨作為chat_history傳入而不是簡單拼在 system prompt 里因為 LangChain 的create_tool_calling_agent對于MessagesPlaceholder的處理方式不同。它會將這部分的對話內容作為“歷史消息”提供給 LLM而用戶當前輸入作為新的 user message。這種結構對模型來說更清晰哪些是歷史哪些是現在要處理的問題。4.5 編寫入口文件并運行文件路徑main.pyfrom rag_service import RAGService from memory_service import MemoryService from agent_service import AgentService def main(): # 初始化三個模塊 rag RAGService(./data/employee_handbook.md) memory MemoryService(user_idzhangsan) agent AgentService(rag, memory) print( 企業知識庫 Agent 已啟動 ) print(輸入 exit 退出\n) while True: user_input input(你: ) if user_input.lower() exit: break response agent.run(user_input) print(fAgent: {response}\n) if __name__ __main__: main()運行前在項目根目錄創建.env文件OPENAI_API_KEYsk-your-key然后運行python main.py4.6 預期效果演示我們模擬一段對話看看整體表現。第一輪你: 我叫張三是技術部的工齡五年了 Agent: 好的張三你好我已經記住了你的信息。請問有什么可以幫你這輪對話中Agent 應該調用save_user_memory工具。如果 verbose 模式開啟你會看到 Agent 的思考過程類似 Entering new AgentExecutor chain... Invoking: save_user_memory with {arg: name張三} Invoking: save_user_memory with {arg: department技術部} Invoking: save_user_memory with {arg: work_years5} Finished chain.第二輪你: 我的年假有幾天 Agent: 張三你好根據員工手冊入職滿一年后享有每年 5 天帶薪年假。工齡滿 10 年年假增加至 10 天。你目前工齡 5 年所以年假是 5 天。這輪中Agent 先調用get_user_memory查看了張三的工齡再調用knowledge_base_search檢索年假制度最后綜合兩者給出個性化回答。這就是 RAG Memory 結合的一個典型示例。第三輪你: 那我今年已經休了3天還剩幾天 Agent: 你今年年假是 5 天已經休了 3 天所以還剩 2 天。記得提前 3 個工作日申請哦。這里依賴的是短期記憶Agent 記得上一輪對話中“年假 5 天”的信息。如果你沒有短期記憶這一輪它就不知道“5 天”從哪里來的。5. 常見問題與排查思路在實際開發和部署過程中RAG、Memory、Agent 的組合會遇到很多問題。下面把頻率最高的幾類整理成表格并展開說明。問題現象常見原因解決思路Agent 不調用檢索工具直接胡編答案工具 description 不夠具體或 LLM 沒有理解意圖優化工具描述增加觸發條件示例RAG 檢索結果不相關文本切塊策略不當、Embedding 模型不匹配調整 chunk_size 和 overlap嘗試重排模型對話稍微變長回答就開始混亂短期記憶沒有做裁剪Prompt 過長只保留最近 N 輪或對歷史做摘要壓縮Agent 反復調用同一個工具陷入死循環Agent 的停止條件設置不當或工具返回內容讓 LLM 無法判斷設置 max_iterations檢查工具返回格式長期記憶寫入失敗或內容雜亂抽取信息時沒有做字段校驗用結構化格式保存信息增加校驗邏輯向量庫重建非常慢文檔量大且沒有增量更新分批次入庫使用增量索引5.1 “Agent 不調用檢索工具”的排查步驟這個問題最讓人頭疼明明知識庫里就有答案Agent 卻選擇自己編一個。排查順序如下第一步確認工具是否注冊成功。打印agent_executor.tools檢查工具列表里是否有knowledge_base_search。第二步確認工具描述是否足夠具體。實踐發現description中包含“use this when user asks about...”這類觸發詞能顯著提升工具的調用概率。第三步檢查 LLM 的 temperature 設置。如果設置得過高比如 0.7模型的決策行為會變得不穩定建議在 Agent 場景中設為 0.1 或 0。第四步開啟 verbose 模式觀察 Agent 的內部推理。LangChain 的AgentExecutor設置verboseTrue后會打印出 LLM 的每一步思考幫助你定位是沒理解問題還是理解后沒選對工具。5.2 “RAG 檢索結果不相關”的排查步驟如果你單獨測試 RAG 模塊時發現檢索結果不對按這三個方向排查第一檢查切塊參數。chunk_size過長可能使一個塊包含多個主題檢索時語義不夠聚焦過短則可能切斷完整句子。經驗值是 200-500 字符之間但需要根據文檔語言和類型調整。第二檢查文檔內容本身。比如員工手冊這種結構清晰的 Markdown 文檔可以直接按標題切塊而不是按固定字符數切。LangChain 里有MarkdownHeaderTextSplitter專門處理這類結構化文檔。第三檢查 Embedding 模型。如果你的文檔是中文建議使用中文表現更好的 Embedding 模型例如 BAAI/bge-large-zh-v1.5 或 M3E。使用 OpenAI 的text-embedding-ada-002雖然也能處理中文但對某些特定領域術語的匹配效果可能不如中文專用模型。6. 最佳實踐與工程建議把 RAG、Memory、Agent 組合起來做產品代碼只是最基礎的部分。真正決定項目能否上線的是工程化細節。下面結合實踐給出幾條高價值的建議。6.1 先模塊化再組合很多項目失敗不是因為技術選型錯了而是因為代碼耦合太嚴重。RAG、Memory、Agent 應該在代碼層面完全分離rag_service.py # 只管文檔加載、切塊、向量化、檢索 memory_service.py # 只管記憶的讀寫、裁剪、持久化 agent_service.py # 只管工具調度和任務編排這樣的好處是你可以單獨測試 RAG 的準確率而不用啟動整個 Agent 流程。未來替換向量數據庫從 Chroma 換成 Milvus時只改rag_service.py。Agent 框架升級或更換從 LangChain 換成 LlamaIndex 或自研時RAG 和 Memory 模塊可以復用。6.2 不要把整個對話歷史都塞進 Prompt這是新手最容易犯的錯誤。直接在 system prompt 里拼接全部歷史對話短期來看能用但當上下文長度增長到幾千 token 時會有三個問題成本線性上升。模型對早期信息的注意力大幅下降反而更注意最近內容。Agent 可能會從歷史中提取出錯誤的“用戶意圖”。推薦的做法是只保留最近 4-8 條消息。對早期對話做摘要把摘要作為一種長期記憶存儲。對每輪對話設置 token 上限超出則丟棄最舊消息或觸發摘要。6.3 RAG 的召回質量優先于生成質量一個 RAG 系統好不好60% 取決于檢索質量30% 取決于 Prompt 設計只有 10% 取決于 LLM 本身的生成能力。如果檢索出來的內容本身就是錯的再強的模型也生不成正確答案。所以在優化 RAG 時優先看召回率相關文檔有沒有被檢索出來準確率檢索出來的 Top-K 里有多少是真正相關的引用溯源生成的回答能否追溯到具體的文檔片段很多企業級 RAG 項目會引入重排模型Rerank在向量檢索之后再做一輪精細化排序。這是一個性價比很高的優化手段。6.4 對 Agent 設置嚴格的執行邊界Agent 在開發環境看起來一切正常一旦上生產就會出現各種意外行為。這是因為 Agent 本質上是“不確定的”它的每一步決策都由 LLM 推理生成而 LLM 有隨機性。生產環境必須設置以下保護措施設置最大工具調用輪數防止死循環。對工具返回結果做長度限制防止超大文本撐爆上下文。對 Agent 的最終輸出做格式校驗防止輸出 JSON 解析失敗。對危險操作刪除數據、發送郵件、支付增加人工確認環節。6.5 日志記錄是 Agent 項目的第一優先級Agent 的調試比傳統程序難得多因為同一個輸入可能產生不同的輸出。沒有日志你根本不知道 Agent 在內部“想”了什么。在開發階段開verboseTrue在生產階段把 Agent 的每一步決策記錄下來時間戳 | 用戶ID | 輸入 | 推理過程 | 調用的工具 | 工具參數 | 工具結果 | 最終輸出記錄這些內容既方便問題排查也是數據分析和效果評估的基礎。7. 總結與下一步學習方向回到文章開頭的問題RAG、Memory、Agent 到底該用哪個答案已經很明確了這不是一道選擇題。RAG 解決的是外部知識引入問題Memory 解決的是對話狀態與個性化問題Agent 解決的是任務執行與工具調度問題。它們面向的是不同維度的能力在完整的企業級 AI 應用中三者往往需要協同工作。如果你的業務只是“文檔問答”不需要多輪個性化那可以只用 RAG不必上 Agent。如果你的業務是“客服助手”需要記住用戶、多輪對話、查規則那 RAG Memory 就夠用。如果你的業務是“自動化處理”需要根據用戶需求查詢數據、調用 API、完成任務那才需要引入 Agent。從學習路徑的角度看建議按這個順序逐步深入先掌握 RAG搞清楚文檔加載、切塊、向量化、檢索、重排這是最基礎也最容易拿到業務價值的能力。再深入 Memory理解短期記憶、長期記憶、摘要記憶、向量記憶的區別學會在多輪對話中保持一致性。最后學習 Agent掌握工具定義、工具調用、任務規劃、異常恢復。在熟悉前兩者之后Agent 的學習曲線會平緩很多。動手建議先把文章的示例代碼跑通然后逐步替換組件——把 OpenAI 換成本地模型把 Chroma 換成 Milvus把文本切塊改成按 Markdown 標題切塊。每換一個組件你都會對這套技術棧有更深的理解。如果這篇文章對你有幫助建議收藏備用。后續也可以繼續關注 RAG 引用溯源、Agent 評估體系、長期記憶的向量化存儲等進階主題。 RAG、Memory與Agent：大模型應用三層架構實戰指南
很多同學在做大模型應用的時候常常會被這三個概念繞暈RAG、Memory、Agent。團隊里討論方案有人說用 RAG 做知識庫有人說要加 Memory 才能讓對話連貫還有人直接說上 Agent 就全解決了。結果一圈討論下來代碼一行沒寫方案已經改了三次。這篇文章就圍繞一個核心問題展開RAG、Memory、Agent 到底分別解決什么問題它們是不是非此即彼的關系落到實際項目里應該怎么選、怎么結合文章會先從概念入手把三者的邊界講清楚然后用一份完整的代碼示例演示“RAG Memory Agent”怎么在一個項目里協同工作最后給出選型建議、常見坑點和工程落地經驗。適合正在做 RAG 知識庫、AI Agent 開發、或者準備把大模型接入業務系統的開發者閱讀。1. 背景與核心概念在正式寫代碼之前先把三個概念放在同一個坐標系里看待。很多人會誤以為 RAG、Memory、Agent 是三個并列的技術方案選了 A 就不用 B。實際上它們屬于不同層次的能力模塊面對的是不同的問題。1.1 RAG 解決的是“模型不知道”的問題RAG 的全稱是 Retrieval-Augmented Generation檢索增強生成。它的核心思路很簡單大模型的知識是訓練時固化的無法覆蓋你業務里的私有數據。RAG 先把外部文檔切片、向量化建立索引等用戶提問時先從知識庫中檢索出相關片段再把片段和問題一起交給大模型生成答案。用一句話概括RAG 是給大模型裝了一個“外部知識庫”。RAG 適合的場景非常明確企業內部的規章制度、產品手冊、維修文檔問答。基于私有 PDF、Word、網頁內容構建問答系統。實時性要求高、需要引用來源的信息查詢。工程上RAG 有四個關鍵環節也是后續容易出現問題的四個環節文檔加載與解析、文本切塊、向量化與存儲、檢索與重排。1.2 Memory 解決的是“模型記不住”的問題大模型本身是無狀態的。你上一輪問了“北京明天天氣怎么樣”下一輪問“那后天呢”如果模型不記得“那”指代的是“北京”回答就會跑偏。Memory 模塊的作用就是讓 Agent 或對話系統具備“記憶能力”。它通常分為三類記憶類型類比典型實現短期記憶臨時記住當前對話上下文把最近幾輪對話拼進 Prompt長期記憶跨會話記住用戶偏好和歷史事實存入數據庫按用戶 ID 讀取工作記憶任務執行過程中臨時保存中間狀態Agent 執行計劃時維護狀態變量注意Memory 和 RAG 有一個容易混淆的點兩者都要“存取數據”。區別在于Memory 存的是“關于用戶、對話、任務狀態”的信息RAG 存的是“領域知識、文檔內容”。1.3 Agent 解決的是“模型不會做”的問題如果說 RAG 是讓模型“知道得更多”Memory 是讓模型“記得住”那么 Agent 是讓模型“動起來”。Agent 的核心是讓大模型充當一個“大腦”通過推理來決定調用哪些工具、按什么順序執行最終完成一個復雜任務。一個標準的 Agent 循環通常包含接收用戶目標。推理并拆解任務生成計劃。按計劃調用工具搜索、計算、調 API、操作數據庫等。觀察工具返回結果判斷是否繼續或結束。輸出最終答案。Agent 的出現解決的是“大模型只能生成文本不能完成操作”的問題。它把大模型從“問答機器”變成了“執行者”。1.4 三者不是三選一而是三層結構用一個生活化的例子來說明。你去醫院看病導診臺Agent先問你的癥狀根據你的描述決定讓你去內科還是外科醫生翻看你之前的病歷Memory遇到不確定的罕見病還會查閱醫學指南和文獻RAG。最終給出診斷和治療方案。看到沒有Agent、Memory、RAG 本來就在同一個系統里協同工作。這也引出了文章的核心觀點選擇不是“用 RAG 還是用 Agent”而是“這個環節需不需要檢索、需不需要記憶、需不需要行為決策”。2. 環境準備與版本說明下面進入實戰。本文的示例以一個“企業知識庫問答 多輪對話記憶 Agent”為業務背景使用 Python LangChain 體系來實現。先說明一下環境。大模型技術棧更新非常快具體版本建議以你本機為準。本文示例基于以下環境你實際使用時需要根據版本差異調整參數組件說明操作系統Windows 10/11、macOS、Linux 均可Python3.9 及以上LangChain0.1.x 或 0.2.x接口有差異注意兼容向量數據庫Chroma本地運行無需額外服務Embedding 模型使用 OpenAI 的 text-embedding-ada-002或本地 BGE/M3E 模型LLM以 OpenAI GPT 系列為例也可替換為 Qwen、DeepSeek 或本地 llama.cpp 部署的模型如果你在本地通過 llama.cpp Qwen2-7B 搭建過 RAG 知識庫會發現核心流程沒有區別只是 Embedding 和 LLM 的加載方式不同。2.1 安裝依賴創建項目目錄和虛擬環境mkdir rag-memory-agent-demo cd rag-memory-agent-demo python -m venv venv source venv/bin/activate # Windows 下執行 venv\Scripts\activate安裝依賴pip install langchain langchain-openai langchain-community chromadb faiss-cpu python-dotenv說明一下langchain-openai是 LangChain 官方維護的 OpenAI 集成包。chromadb作為本地向量數據庫零配置適合學習和原型驗證。faiss-cpu是可選依賴如果你只用 Chroma 可以不裝。python-dotenv用于管理環境變量。2.2 項目結構rag-memory-agent-demo/ ├── .env # 存放 API Key ├── data/ │ └── employee_handbook.md # 示例知識庫文檔 ├── rag_service.py # RAG 檢索模塊 ├── memory_service.py # 會話記憶模塊 ├── agent_service.py # Agent 編排模塊 └── main.py # 入口文件這個結構把 RAG、Memory、Agent 拆成三個獨立模塊方便你看清每一層做了什么。3. 核心原理拆解在把代碼串起來之前先分別拆解三個模塊的關鍵實現點。這樣后面看完整代碼時你能知道每一行是在做什么。3.1 RAG 檢索流程的四個關鍵環節RAG 的實現并沒有多玄妙核心就是“文檔進、答案出”的四步流水線文檔加載 → 文本切塊 → 向量化入庫 → 檢索并生成文檔加載從 PDF、Word、Markdown 等文件里提取純文本。這一步的坑最多尤其是 PDF 里的表格、掃描件需要 OCR 或者專門的表格解析工具。對 Markdown 和純文本來說直接讀取即可。文本切塊因為大模型有上下文窗口限制同時檢索單位太大也會導致“檢索到一大段無關內容”所以需要把長文本切成小塊。切塊策略直接影響檢索效果。向量化入庫把每個文本塊通過 Embedding 模型轉成向量存入向量數據庫。這里的“語義相近的文本向量距離也近”是檢索能工作的基礎。檢索并生成用戶提問時把問題也向量化然后從庫里找到最相似的 Top-K 個文本塊拼進 Prompt 交給大模型。切塊策略重點說一下。常見的切法有固定長度切塊例如每 500 個字符切一塊塊與塊之間重疊 50 字符。按結構切塊例如 Markdown 標題、段落、句子邊界。遞歸切塊先按大單位切再對超長塊按小單位切。在 LangChain 中推薦使用RecursiveCharacterTextSplitter它的邏輯是先按段落切段落太長再按句子切句子太長再按字符切。這比固定長度切塊更能保留語義完整性。3.2 Memory 的三種實現層次LangChain 的 Memory 體系經歷了比較大的演進。早期版本通過ConversationBufferMemory等類維護對話歷史新版本推薦直接使用langchain.memory里的不同組件或者干脆在Runnable/ Agent 里手動管理消息列表。實際項目中最簡單可靠的記憶實現方式有兩種第一種會話級消息列表。把歷史對話保存在一個列表里每次請求時拼到 Prompt 中。適合短期記憶。messages [] messages.append({role: user, content: 我住在杭州}) messages.append({role: assistant, content: 你好杭州是個好地方})第二種持久化長期記憶。把用戶的關鍵信息抽取出來存入 Redis 或 MySQL用戶下次訪問時加載。適合長期記憶。需要注意把全部歷史對話都塞進 Prompt 是不行的。上下文窗口有限、成本會線性增長、模型對過長的歷史反而會“迷失”。所以工程上要做“記憶壓縮”只保留最近幾輪對話或者對歷史做摘要。3.3 Agent 的執行循環一個最精簡的 Agent 循環可以這樣理解用戶問題 ↓ LLM 根據指令 工具描述決定是否調用工具、調用哪個、傳什么參數 ↓ 執行工具拿到結果 ↓ LLM 觀察結果決定繼續調用工具還是直接回答 ↓ 輸出最終答案這個“決策—執行—觀察—再決策”的循環就是 Agent 和普通 API 調用的本質區別。LangChain 中對這個模式做了高度封裝你只需要定義 Tool 的name、description、args_schema和funcAgent 框架就會讓 LLM 根據description來決定何時調用。這里有個關鍵經驗Tool 的 description 寫得好不好直接決定 Agent 的準確率。如果你寫“use this when user asks about anything”那 LLM 什么都會去調這個工具如果你寫“use this when user asks about company policies from the knowledge base”LLM 就知道這是知識庫專用工具。4. 完整實戰案例構建一個帶記憶的知識庫 Agent接下來我們將把三個模塊組合到一個項目中。業務場景是企業員工手冊問答 Agent。它需要做到用戶提問關于公司制度的問題如年假、報銷從知識庫中檢索回答。用戶進行多輪對話時Agent 記住用戶姓名、崗位、之前的問答內容。用戶可以要求 Agent 基于已知信息執行簡單操作例如“根據我的年假余額提醒我今年還剩幾天”。4.1 準備示例文檔創建data/employee_handbook.md# 員工手冊節選 ## 年假制度 員工入職滿一年后享有每年 5 天帶薪年假。工齡滿 10 年年假增加至 10 天。 年假需要提前 3 個工作日申請經部門主管審批后方可休假。 ## 報銷制度 員工因公出差產生的交通、住宿、餐飲費用可在回國后 7 個工作日內提交報銷申請。 報銷金額超過 5000 元需要總經理審批。 ## 遠程辦公 員工每周可申請最多 2 天遠程辦公。遠程辦公期間需要保持即時通訊在線并按時參加每日站會。4.2 編寫 RAG 模塊文件路徑rag_service.pyimport os from dotenv import load_dotenv from langchain_community.document_loaders import TextLoader from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_core.runnables import RunnableLambda load_dotenv() class RAGService: def __init__(self, doc_path: str, persist_dir: str ./chroma_db): self.persist_dir persist_dir self.embeddings OpenAIEmbeddings( modeltext-embedding-ada-002, api_keyos.getenv(OPENAI_API_KEY) ) self.vector_store self._build_or_load(doc_path) def _build_or_load(self, doc_path: str): # 如果本地已有向量庫直接加載 if os.path.exists(self.persist_dir): return Chroma( persist_directoryself.persist_dir, embedding_functionself.embeddings ) # 否則從文檔構建 loader TextLoader(doc_path, encodingutf-8) documents loader.load() text_splitter RecursiveCharacterTextSplitter( chunk_size200, chunk_overlap50, separators[\n\n, \n, 。, , , , ] ) docs text_splitter.split_documents(documents) return Chroma.from_documents( docs, self.embeddings, persist_directoryself.persist_dir ) def search(self, query: str, k: int 3): # 返回檢索到的文檔片段列表 return self.vector_store.similarity_search(query, kk) def as_tool_func(self): # 方便 Agent 直接調用 def search_func(query: str) - str: docs self.search(query, k3) return \n\n.join([doc.page_content for doc in docs]) return search_func幾點說明chunk_size200表示每個文本塊約 200 字符這個數值需要根據文檔情況調整。chunk_overlap50讓相鄰塊之間有 50 字符重疊避免切在語義邊界導致信息丟失。separators的優先級是從左到右先按段落切再按句號切。OpenAIEmbeddings需要你在.env里配置OPENAI_API_KEY。如果你使用本地模型可以替換成langchain_community.embeddings里的HuggingFaceBgeEmbeddings或OllamaEmbeddings。4.3 編寫 Memory 模塊文件路徑memory_service.py為了演示長期記憶和短期記憶的區別這里用 JSON 文件做簡單的長期記憶持久化同時在內存里維護短期會話歷史。import json import os from datetime import datetime class MemoryService: MEMORY_FILE ./memory_store.json def __init__(self, user_id: str): self.user_id user_id self.short_term_messages [] self._ensure_file() def _ensure_file(self): if not os.path.exists(self.MEMORY_FILE): with open(self.MEMORY_FILE, w, encodingutf-8) as f: json.dump({}, f) def _load_all(self): with open(self.MEMORY_FILE, r, encodingutf-8) as f: return json.load(f) def _save_all(self, data): with open(self.MEMORY_FILE, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) def add_long_term(self, key: str, value: str): 長期記憶記錄用戶的穩定信息如姓名、崗位、偏好 data self._load_all() if self.user_id not in data: data[self.user_id] {} data[self.user_id][key] { value: value, updated_at: datetime.now().isoformat() } self._save_all(data) def get_long_term(self, key: str None): 如果指定 key返回對應值否則返回該用戶的全部長期記憶 data self._load_all() user_data data.get(self.user_id, {}) if key: return user_data.get(key, {}).get(value, ) return {k: v[value] for k, v in user_data.items()} def add_short_term(self, role: str, content: str): 短期記憶保存當前會話的對話消息 self.short_term_messages.append({role: role, content: content}) # 只保留最近 6 條避免上下文過長 if len(self.short_term_messages) 6: self.short_term_messages self.short_term_messages[-6:] def get_short_term(self): return self.short_term_messages這里體現了一個很重要的工程思路長期記憶存的是“事實”短期記憶存的是“上下文”。事實需要跨會話保留上下文只需要當前會話內保持。4.4 編寫 Agent 編排模塊文件路徑agent_service.py我們用 LangChain 的 AgentTool Calling Agent來串聯 RAG 和 Memory。from langchain.agents import AgentExecutor, create_tool_calling_agent from langchain.tools import Tool from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain_openai import ChatOpenAI from rag_service import RAGService from memory_service import MemoryService class AgentService: def __init__(self, rag: RAGService, memory: MemoryService): self.rag rag self.memory memory self.llm ChatOpenAI( modelgpt-4o-mini, temperature0.1 ) self.agent_executor self._create_agent() def _create_agent(self): # 定義 Agent 可用的工具 tools [ Tool( nameknowledge_base_search, description( Search the employee handbook knowledge base. Use this when user asks about company policies, leave, reimbursement, remote work, or other HR rules. ), funcself.rag.as_tool_func() ), Tool( nameget_user_memory, descriptionGet the long-term memory of the current user. Use this when you need to recall users stored information like name, position, preferences., funclambda x: str(self.memory.get_long_term()) ), Tool( namesave_user_memory, descriptionSave a piece of user information into long-term memory. Use this when user tells you personal facts like their name, role, or preferences., funcself.memory.add_long_term ) ]等等這里有一個問題需要修正Tool的func要求接受一個參數。save_user_memory需要接收兩個參數key 和 value不能直接傳給 Agent。我們改造一下用一個參數接收字符串解析后再保存。修正后的代碼如下class AgentService: def __init__(self, rag: RAGService, memory: MemoryService): self.rag rag self.memory memory self.llm ChatOpenAI( modelgpt-4o-mini, temperature0.1 ) # 綁定內存服務到當前用戶 self.agent_executor self._create_agent() def _create_agent(self): def save_memory_func(arg: str): # 參數格式: keyvalue # 實際項目中建議用 JSON 格式 if not in arg: return Invalid format. Please use keyvalue. key, value arg.split(, 1) self.memory.add_long_term(key.strip(), value.strip()) return fSaved {key.strip()} to memory. tools [ Tool( nameknowledge_base_search, description( Search the employee handbook knowledge base. Use this when user asks about company policies, leave, reimbursement, remote work, or other HR rules. ), funcself.rag.as_tool_func() ), Tool( nameget_user_memory, descriptionGet the long-term memory of the current user. Use this when you need to recall users stored information like name, position, preferences., funclambda x: str(self.memory.get_long_term()) ), Tool( namesave_user_memory, descriptionSave a piece of user information into long-term memory. Use this when user tells you personal facts like their name, role, or preferences. Argument format: keyvalue, funcsave_memory_func ) ] prompt ChatPromptTemplate.from_messages([ (system, 你是一個企業員工助手。你的職責是 1. 當用戶詢問公司制度時調用 knowledge_base_search 獲取答案。 2. 記住用戶提供的個人信息調用 save_user_memory 保存。 3. 回答問題時結合當前對話歷史和長期記憶給出個性化回答。 ), MessagesPlaceholder(variable_namechat_history), (user, {input}), MessagesPlaceholder(variable_nameagent_scratchpad) ]) agent create_tool_calling_agent(self.llm, tools, prompt) return AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) def run(self, user_input: str): # 將短期記憶作為 chat_history 傳入 result self.agent_executor.invoke({ input: user_input, chat_history: self.memory.get_short_term() }) # 更新短期記憶 self.memory.add_short_term(user, user_input) self.memory.add_short_term(assistant, result[output]) return result[output]需要特別說明一個關鍵點為什么要把短期記憶單獨作為chat_history傳入而不是簡單拼在 system prompt 里因為 LangChain 的create_tool_calling_agent對于MessagesPlaceholder的處理方式不同。它會將這部分的對話內容作為“歷史消息”提供給 LLM而用戶當前輸入作為新的 user message。這種結構對模型來說更清晰哪些是歷史哪些是現在要處理的問題。4.5 編寫入口文件并運行文件路徑main.pyfrom rag_service import RAGService from memory_service import MemoryService from agent_service import AgentService def main(): # 初始化三個模塊 rag RAGService(./data/employee_handbook.md) memory MemoryService(user_idzhangsan) agent AgentService(rag, memory) print( 企業知識庫 Agent 已啟動 ) print(輸入 exit 退出\n) while True: user_input input(你: ) if user_input.lower() exit: break response agent.run(user_input) print(fAgent: {response}\n) if __name__ __main__: main()運行前在項目根目錄創建.env文件OPENAI_API_KEYsk-your-key然后運行python main.py4.6 預期效果演示我們模擬一段對話看看整體表現。第一輪你: 我叫張三是技術部的工齡五年了 Agent: 好的張三你好我已經記住了你的信息。請問有什么可以幫你這輪對話中Agent 應該調用save_user_memory工具。如果 verbose 模式開啟你會看到 Agent 的思考過程類似 Entering new AgentExecutor chain... Invoking: save_user_memory with {arg: name張三} Invoking: save_user_memory with {arg: department技術部} Invoking: save_user_memory with {arg: work_years5} Finished chain.第二輪你: 我的年假有幾天 Agent: 張三你好根據員工手冊入職滿一年后享有每年 5 天帶薪年假。工齡滿 10 年年假增加至 10 天。你目前工齡 5 年所以年假是 5 天。這輪中Agent 先調用get_user_memory查看了張三的工齡再調用knowledge_base_search檢索年假制度最后綜合兩者給出個性化回答。這就是 RAG Memory 結合的一個典型示例。第三輪你: 那我今年已經休了3天還剩幾天 Agent: 你今年年假是 5 天已經休了 3 天所以還剩 2 天。記得提前 3 個工作日申請哦。這里依賴的是短期記憶Agent 記得上一輪對話中“年假 5 天”的信息。如果你沒有短期記憶這一輪它就不知道“5 天”從哪里來的。5. 常見問題與排查思路在實際開發和部署過程中RAG、Memory、Agent 的組合會遇到很多問題。下面把頻率最高的幾類整理成表格并展開說明。問題現象常見原因解決思路Agent 不調用檢索工具直接胡編答案工具 description 不夠具體或 LLM 沒有理解意圖優化工具描述增加觸發條件示例RAG 檢索結果不相關文本切塊策略不當、Embedding 模型不匹配調整 chunk_size 和 overlap嘗試重排模型對話稍微變長回答就開始混亂短期記憶沒有做裁剪Prompt 過長只保留最近 N 輪或對歷史做摘要壓縮Agent 反復調用同一個工具陷入死循環Agent 的停止條件設置不當或工具返回內容讓 LLM 無法判斷設置 max_iterations檢查工具返回格式長期記憶寫入失敗或內容雜亂抽取信息時沒有做字段校驗用結構化格式保存信息增加校驗邏輯向量庫重建非常慢文檔量大且沒有增量更新分批次入庫使用增量索引5.1 “Agent 不調用檢索工具”的排查步驟這個問題最讓人頭疼明明知識庫里就有答案Agent 卻選擇自己編一個。排查順序如下第一步確認工具是否注冊成功。打印agent_executor.tools檢查工具列表里是否有knowledge_base_search。第二步確認工具描述是否足夠具體。實踐發現description中包含“use this when user asks about...”這類觸發詞能顯著提升工具的調用概率。第三步檢查 LLM 的 temperature 設置。如果設置得過高比如 0.7模型的決策行為會變得不穩定建議在 Agent 場景中設為 0.1 或 0。第四步開啟 verbose 模式觀察 Agent 的內部推理。LangChain 的AgentExecutor設置verboseTrue后會打印出 LLM 的每一步思考幫助你定位是沒理解問題還是理解后沒選對工具。5.2 “RAG 檢索結果不相關”的排查步驟如果你單獨測試 RAG 模塊時發現檢索結果不對按這三個方向排查第一檢查切塊參數。chunk_size過長可能使一個塊包含多個主題檢索時語義不夠聚焦過短則可能切斷完整句子。經驗值是 200-500 字符之間但需要根據文檔語言和類型調整。第二檢查文檔內容本身。比如員工手冊這種結構清晰的 Markdown 文檔可以直接按標題切塊而不是按固定字符數切。LangChain 里有MarkdownHeaderTextSplitter專門處理這類結構化文檔。第三檢查 Embedding 模型。如果你的文檔是中文建議使用中文表現更好的 Embedding 模型例如 BAAI/bge-large-zh-v1.5 或 M3E。使用 OpenAI 的text-embedding-ada-002雖然也能處理中文但對某些特定領域術語的匹配效果可能不如中文專用模型。6. 最佳實踐與工程建議把 RAG、Memory、Agent 組合起來做產品代碼只是最基礎的部分。真正決定項目能否上線的是工程化細節。下面結合實踐給出幾條高價值的建議。6.1 先模塊化再組合很多項目失敗不是因為技術選型錯了而是因為代碼耦合太嚴重。RAG、Memory、Agent 應該在代碼層面完全分離rag_service.py # 只管文檔加載、切塊、向量化、檢索 memory_service.py # 只管記憶的讀寫、裁剪、持久化 agent_service.py # 只管工具調度和任務編排這樣的好處是你可以單獨測試 RAG 的準確率而不用啟動整個 Agent 流程。未來替換向量數據庫從 Chroma 換成 Milvus時只改rag_service.py。Agent 框架升級或更換從 LangChain 換成 LlamaIndex 或自研時RAG 和 Memory 模塊可以復用。6.2 不要把整個對話歷史都塞進 Prompt這是新手最容易犯的錯誤。直接在 system prompt 里拼接全部歷史對話短期來看能用但當上下文長度增長到幾千 token 時會有三個問題成本線性上升。模型對早期信息的注意力大幅下降反而更注意最近內容。Agent 可能會從歷史中提取出錯誤的“用戶意圖”。推薦的做法是只保留最近 4-8 條消息。對早期對話做摘要把摘要作為一種長期記憶存儲。對每輪對話設置 token 上限超出則丟棄最舊消息或觸發摘要。6.3 RAG 的召回質量優先于生成質量一個 RAG 系統好不好60% 取決于檢索質量30% 取決于 Prompt 設計只有 10% 取決于 LLM 本身的生成能力。如果檢索出來的內容本身就是錯的再強的模型也生不成正確答案。所以在優化 RAG 時優先看召回率相關文檔有沒有被檢索出來準確率檢索出來的 Top-K 里有多少是真正相關的引用溯源生成的回答能否追溯到具體的文檔片段很多企業級 RAG 項目會引入重排模型Rerank在向量檢索之后再做一輪精細化排序。這是一個性價比很高的優化手段。6.4 對 Agent 設置嚴格的執行邊界Agent 在開發環境看起來一切正常一旦上生產就會出現各種意外行為。這是因為 Agent 本質上是“不確定的”它的每一步決策都由 LLM 推理生成而 LLM 有隨機性。生產環境必須設置以下保護措施設置最大工具調用輪數防止死循環。對工具返回結果做長度限制防止超大文本撐爆上下文。對 Agent 的最終輸出做格式校驗防止輸出 JSON 解析失敗。對危險操作刪除數據、發送郵件、支付增加人工確認環節。6.5 日志記錄是 Agent 項目的第一優先級Agent 的調試比傳統程序難得多因為同一個輸入可能產生不同的輸出。沒有日志你根本不知道 Agent 在內部“想”了什么。在開發階段開verboseTrue在生產階段把 Agent 的每一步決策記錄下來時間戳 | 用戶ID | 輸入 | 推理過程 | 調用的工具 | 工具參數 | 工具結果 | 最終輸出記錄這些內容既方便問題排查也是數據分析和效果評估的基礎。7. 總結與下一步學習方向回到文章開頭的問題RAG、Memory、Agent 到底該用哪個答案已經很明確了這不是一道選擇題。RAG 解決的是外部知識引入問題Memory 解決的是對話狀態與個性化問題Agent 解決的是任務執行與工具調度問題。它們面向的是不同維度的能力在完整的企業級 AI 應用中三者往往需要協同工作。如果你的業務只是“文檔問答”不需要多輪個性化那可以只用 RAG不必上 Agent。如果你的業務是“客服助手”需要記住用戶、多輪對話、查規則那 RAG Memory 就夠用。如果你的業務是“自動化處理”需要根據用戶需求查詢數據、調用 API、完成任務那才需要引入 Agent。從學習路徑的角度看建議按這個順序逐步深入先掌握 RAG搞清楚文檔加載、切塊、向量化、檢索、重排這是最基礎也最容易拿到業務價值的能力。再深入 Memory理解短期記憶、長期記憶、摘要記憶、向量記憶的區別學會在多輪對話中保持一致性。最后學習 Agent掌握工具定義、工具調用、任務規劃、異常恢復。在熟悉前兩者之后Agent 的學習曲線會平緩很多。動手建議先把文章的示例代碼跑通然后逐步替換組件——把 OpenAI 換成本地模型把 Chroma 換成 Milvus把文本切塊改成按 Markdown 標題切塊。每換一個組件你都會對這套技術棧有更深的理解。如果這篇文章對你有幫助建議收藏備用。后續也可以繼續關注 RAG 引用溯源、Agent 評估體系、長期記憶的向量化存儲等進階主題。