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