做 AI Agent 做到第四期我越来越确认一件事Agent 的能力边界很大程度上不是模型决定的而是“它能看到什么”决定的。你如果没有给 Agent 配一条好用的知识获取管道它就算脑子再好也只能靠训练时那点记忆硬撑——你问它你们公司最新的产品手册它只能睁眼说瞎话。这期我们聊的就是这条管道的地基RAGRetrieval-Augmented Generation检索增强生成。前几篇我们分别聊了 Agent 的整体框架、规划和工具调用到了这一篇终于到了很多人体感最强的部分——知识从哪来。网上关于 RAG 的教程一大堆但大部分都是直接甩一段 LangChain 代码让你“照着跑就行”跑完了还是一头雾水。这篇不一样我会把 RAG 这条管道从原理到代码再到坑位完整地讲一遍。你会发现RAG 不是某一个组件而是一整套“知识流转”的设计思路而搞清楚它之后你再看任何 RAG 项目、面试题、甚至 Agent 产品架构都会有一种“原来如此”的通透感。1. 为什么 AI Agent 需要一条“知识获取管道”1.1 知识割裂模型脑子里那点存货根本不够用先说个最基础的问题大语言模型到底“知道”什么它知道的是训练数据里出现过的东西而且是训练完成那一刻的快照。你拿 2026 年 1 月发布的模型去问 2026 年 3 月的新政策它答不上来这不是它笨是因为它压根没见过这些内容。更麻烦的是企业内部的知识。你公司的财务报销流程、某个产品的私有参数、售后团队整理的故障手册、设计规范里写的那条“Logo 最小使用尺寸是 24px”——这些内容从未出现在任何公开数据集里模型没有理由知道。你硬问它只能编编得还挺像真的这就是我们常说的“一本正经地胡说八道”。知识割裂的本质就是模型手里有的不是你要用的你要用的模型手里没有。这个矛盾不解决Agent 就只能是个“聪明的空壳”。所以你需要一条管道把外部知识送进模型的推理过程中。这条管道要能在用户提问的时候“临时”把相关的资料找出来拼到上下文里让模型看着资料回答。这就是 RAG 的基本形态也是“知识获取管道”这个说法的来源。1.2 RAG 在 Agent 架构里的位置它是记忆更是行动的前提先捋一下 Agent 的经典架构感知Perception——记忆Memory——规划Planning——行动Action。很多人会把记忆简单理解成“聊天记录的上下文”其实那是短期记忆。真正支撑 Agent 专业能力的是长期记忆——而 RAG 就是长期记忆里最重要的一种实现方式。你可以把 RAG 理解为 Agent 的“外接大脑硬盘”平时它安静地躺着当 Agent 遇到一个不确定的问题时就去硬盘里查资料查完再回答。这个“查资料”的动作对 Agent 来说既是一种记忆的读取也是一种行动的触发。我们在做 Agent 练手项目时最常见的进阶路径就是先用纯模型做问答 - 发现它总是胡编 - 接上 RAG - 再发现它只会“查一次”不会“查完再追问” - 于是升级成 Agentic RAG让 Agent 自己决定查什么、什么时候查、查完怎么用。这条路径走到头你就把“知识获取”从一条死板的管道变成了 Agent 自带的一项能力。这也就是为什么我这篇要先讲“基础 RAG”。地基不打牢后面所有花活都白搭。2. RAG 的完整链路从原始文档到自然答案的四个环节2.1 文档加载与切分为什么“怎么切”比“切多大”更关键RAG 的第一步是把乱七八糟的源文档变成模型可以检索的“小块”。这一步在框架里通常叫 Loader 和 Splitter听起来很简单实际上恰恰是决定 RAG 效果好坏的第一道分水岭。先说加载。PDF、Word、Markdown、网页、数据库表……不同格式解析的坑完全不一样。PDF 最常见的问题是“表格乱掉”“多栏文章串行”“扫描件没有文字层”Word 里则经常混着批注和修订记录。这个环节没有银弹核心思路就一句话尽量保留文档的结构信息比如标题层级、表格结构、列表关系。很多第一版 RAG 项目效果差不是检索有问题而是文档加载阶段就把信息搞丢了。再说切分。一段几千字的文档能不能直接塞给模型技术上能但效果一定差。原因是向量检索的核心是“语义相似度”如果一块文本太长里面包含的主题太多它的向量就变成了“四不像”跟谁都不太像检索时就容易跑偏。所以我们要把文档切成 chunk块每一块尽量只讲一个完整意思。切分有两条核心参数一个是 chunk_size也就是每块多长另一个是 overlap也就是相邻块之间重叠多少字。为什么要重叠呢想象一条新闻被切成两块第一块结尾停在“嫌疑人已被警方”第二块开头是“控制案件正在进一步调查中”。如果不重叠“控制”这个关键信息就被孤零零地甩在了下一块开头检索时很容易漏掉。overlap 的作用就是让信息在交界处“留个影”减少断裂带来的信息丢失。切多长算合理没有标准答案但我给一个经验区间如果回答需要强上下文连贯性比如论文讨论、法律条款分析chunk 在 400~600 字比较稳如果内容是碎片化的比如产品 FAQ、接口文档chunk 在 200~400 字更灵活如果单篇文档特别长比如一本技术手册建议先按章节切再在章节里按段落切形成“层级块”。很多人一上来就纠结选哪个 Embedding 模型其实前期更应该花时间在切分上。切分没做好再好的向量模型也救不回来。2.2 向量化Embedding 是怎么把文字变成坐标的文档切好之后就要把文本变成模型能“比较”的东西。文本本身不能直接算相似度但我们可以用 Embedding 模型把一段文字映射成一个向量一串几百甚至上千维的浮点数语义相近的文本向量在空间里距离也更近。这里有个经典类比把每个句子想象成多维空间里的一个点Embedding 模型干的事就是“把意思相同的点挪近意思不同的点推远”。比如“今天天气真好”和“外面阳光明媚”它们向量的距离会非常近而“今天天气真好”和“这款手机电池续航很强”就离得很远。检索的时候我们把用户问题也转成向量然后在向量空间里找最近的几个点也就是最相关的几个 chunk。选 Embedding 模型时国内开发者通常有三种选择纯开源模型比如 BAAI/bge 系列、m3e 系列部署在自己机器上数据不出内网隐私可控但需要一定算力云厂商 API比如阿里、百度、智谱等平台提供的向量化接口效果好、省事但按量收费且数据要过一遍云本地轻量方案如果文档量不大几万条以内用小模型甚至用一些轻量级脚本也能跑但语义理解能力会明显弱一些。我的建议是企业级数据敏感场景优先本地开源模型 GPU 推理个人练手或知识库体量不大直接调云 API 最划算。不用一上来就追“最强模型”先保证“够用”。另外要注意向量维度的匹配你入库时用哪个模型检索时也必须用同一个模型因为不同模型产出的向量空间不互通混用等于让一个只说中文的人和一个只说英文的人对话检索结果必然稀烂。2.3 检索从“找到相关内容”到“找到对的内容”检索是 RAG 管道里最值得花心思调优的环节。基础做法是向量检索把用户问题向量化在向量库里用相似度算法比如 cosine 距离找出 Top-K 条最相近的 chunk然后丢给模型。但纯向量检索有两个明显短板第一个短板是“只问语义不管关键词”。比如用户搜“接口返回 500 错误”如果知识库里的文章写的是“HTTP 状态码为 Internal Server Error”语义上虽然相关但向量距离可能不够近结果就不稳定。这时候就需要关键词检索来兜底也就是把 BM25 这类传统检索方法也跑一遍再把两路结果合并。这就是大家常说的“混合检索”Hybrid Search。第二个短板是“检出来未必排得对”。向量检索给你的是“粗略的语义相似”但文档里的相关性往往是分主次的。比如用户问“怎么退款”检索出来的 chunk 里可能有一条在讲“退款的完整流程”另一条在讲“退款后多久到账”时顺带提了一句“必须先申请退款”。如果只看向量相似度后者可能排得还靠前。解决思路是加一层 rerank重排序把向量检索拿回来的前 20 条用更强的模型逐条和问题算了再排一遍最后只保留 Top-5。这层重排会让效果明显上一个台阶代价是增加一点时延。你的流程可以这样搭向量检索召回 Top-20BM25 关键词检索召回 Top-20合并去重取 Top-20 到 30用 rerank 模型精排取 Top-4 到 6把最终结果拼进 Prompt。这样做下来同样的知识库回答质量通常会有“能感觉到”的提升。2.4 生成把检索结果组装成合格的上下文检索之后就是生成环节也就是把搜索到的内容塞进 Prompt让模型参考着回答。这一步看起来只是“拼接字符串”其实有很多容易被忽略的细节。最核心的一条你要明确告诉模型哪些是参考资料哪些是问题以及“超纲”的时候怎么办。一个比较稳的 Prompt 骨架长这样系统指令说明你是知识库问答助手只依据参考资料回答如果资料里没有答案明说“资料中未找到”不要编造参考资料区把检索到的 chunk 逐条编号放进去比如“【资料 1】……【资料 2】……”用户问题区正常提问输出要求要求答案引用资料编号方便溯源。为什么要编号因为当模型参考多条资料时如果你不给它“可引用的抓手”它可能把几条资料的信息混在一起甚至自己脑补。编号之后你可以要求它“在提到某个结论时标注出自【资料 3】”这样后期谁都能一眼看出回答来自哪里排查错误信息也方便得多。还有一个容易踩的坑不要把所有检索结果一股脑全塞进去。模型对上下文里混入的噪声非常敏感如果你把前 20 条都塞给它哪怕其中 10 条都是噪音模型也会被带偏。宁可只给 4 条高质量的也不要给 20 条“好像相关但又不完全相关”的。到这里一条完整的 RAG 管道就已经成型了文档加载 - 切分 - 向量化 - 入库 - 检索 - 重排 - 生成。下一步我们就用代码把它串起来。3. 实操用 LangChain 快速搭建一条基础 RAG 管道3.1 环境准备与框架选型思路先说明一下我下面用 LangChain 举例但思路完全适用于其他框架。你如果用 Spring AI 或者 LangChain4j或者干脆自己写核心步骤也是一样的加载 - 切分 - 向量化 - 检索 - 生成。框架只是封装别被工具绑架。环境上你需要三样东西一个 Python 环境Python 3.10 以上就可以一个 LLM 的 API或本地模型用来做最终回答一个 Embedding 模型 向量库用来做文本向量化和存储。我本地实际测试用的是一份“2026 年某产品用户手册”500 多页格式比较杂有表格有备注。下面所有的参数我都基于这份手册调过你可以直接参考。安装依赖pip install langchain langchain-openai langchain-community chromadb bm25s jieba fastapi uvicorn注意如果你用的是国内云厂商的大模型 API和 OpenAI SDK 兼容的通常可以直接通过配置 base_url 来接入不需要额外装太多包。向量库我先用 Chroma因为它零配置、开箱即用适合本地练手等数据量到了百万级再考虑 Milvus、pgvector 这类生产级方案。3.2 核心代码五步串起整条管道下面是一份可以直接运行的最小实现我把每一步都做了详细注释。你照着跑通之后再根据自己的知识库格式去改 Loader 和 Splitter 就好。from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain_community.vectorstores import Chroma from langchain_core.runnables import RunnablePassthrough from langchain_core.output_parsers import StrOutputParser from langchain_core.prompts import ChatPromptTemplate # ---------- 第一步加载文档 ---------- loader PyPDFLoader(2026_product_manual.pdf) documents loader.load() print(f加载完成共 {len(documents)} 页) # ---------- 第二步切分文档 ---------- text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每块约 500 字 chunk_overlap80, # 相邻块重叠 80 字 separators[\n\n, \n, 。, , ], # 优先按段落、再按句子切 ) chunks text_splitter.split_documents(documents) print(f切分完成共 {len(chunks)} 个块) # ---------- 第三步向量化并入库 ---------- # 这里以 OpenAI SDK 兼容接口的云厂商为例 embeddings OpenAIEmbeddings( modelyour-embedding-model, # 改成你实际用的 embedding 模型 base_urlhttps://your-api-endpoint, # 使用兼容接口 api_keyyour-api-key, ) vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db, # 本地持久化 ) print(向量化完成数据已存入 Chroma) # ---------- 第四步构建检索器 ---------- retriever vectorstore.as_retriever( search_typesimilarity, search_kwargs{k: 5} # 每次检索取回 5 块 ) # ---------- 第五步组装生成链路 ---------- prompt_template ChatPromptTemplate.from_messages([ (system, 你是一个严谨的知识库问答助手。请基于【参考资料】回答用户问题。 如果参考资料中没有相关信息请直接回答资料中未找到相关内容。 回答时请在关键结论后标注对应的【资料x】编号。), (human, 【参考资料】\n{context}\n\n【用户问题】\n{question}), ]) llm ChatOpenAI( modelyour-llm-model, base_urlhttps://your-api-endpoint, api_keyyour-api-key, temperature0.2, # 低温度减少随机编造 ) rag_chain ( {context: retriever, question: RunnablePassthrough()} | prompt_template | llm | StrOutputParser() ) # ---------- 测试 ---------- response rag_chain.invoke(这个产品如何开启自动备份) print(response)这个代码跑通之后你就拥有了一条最基础的 RAG 问答链路。它虽然朴素但完整地实现了“知识获取”的全部流程你可以在这个骨架上不断加肉。3.3 你需要重点调优的四个参数代码能跑只是第一步真正决定效果的是下面这四个参数。我挨个说全是我实测过的心得。第一个是 chunk_size。我试过 300、500、800 三档。300 字时检索很灵活但上下文碎片感强模型有时抓不住前因后果800 字时语义完整但检索粒度太粗一个问题容易召回到好几个不同主题的大块噪声变大。最终 500 字左右最适合我这份手册。你的文档如果句子普遍偏长可以适当调大但建议别超过 800。第二个是 k 值召回数量。k3 时答案最干净但容易漏k10 时信息全但噪声也多。我建议在没加重排的时候 k 设 5~6加了重排之后 k 可以放大到 20重排后再砍到 4~5。记住一个原则模型吃进去的信息质量远比数量重要。第三个是 temperature。做知识库问答我强烈建议设在 0.1~0.3 之间。温度越高模型越“放飞”哪怕参考资料写得很明白它也可能自由发挥。知识型问答不是写诗要的是确定性。第四个是相似度阈值score threshold。如果你发现检索结果里混着大量无关内容可以在检索引擎上加一个 score_threshold 参数比如只有相似度超过 0.5 的 chunk 才进入候选。但这个参数很敏感设太高会召回为空设太低等于没设。调试时建议先用一个测试问题反复跑观察相似度分布再来定阈值。3.4 用 LangGraph 给管道加上简单流程控制如果你不想止步于“问一句答一句”下一步就是给管道加流程控制。LangGraph 是 LangChain 推出的一个轻量编排框架特别适合把 RAG 从“一次检索”升级成“可多轮检查”的流程。举个例子用户问“自动备份失败怎么办”基础 RAG 只会检索一次、回答一次。但如果我们要做得更专业可以让它先检索自动备份的常见故障生成初步答案同时用一个检查节点判断“答案里有没有提到错误码”如果没提到就追加检索“错误码列表”再补一次。这就是 LangGraph 擅长的场景把“检索-生成-检查-再检索”编排成状态机。LangGraph 里最核心的概念是 State状态和 Node节点。State 是共享的数据结构Node 是一个个处理函数节点之间可以按条件跳转。我搭过的一个简化版 QA Agent 流程是这样的parse_question解析问题提取关键词retrieve执行向量检索 关键词检索合并结果check_sufficiency判断检索到的材料是否覆盖问题要点如果不充分则走 refine_query 重写检索词再回 retrievegenerate生成最终答案output输出并附上资料引用。parse_question - retrieve - check_sufficiency - generate - output ^ | |____refine____ |实现思路不复杂核心收益是Agent 不再是一条直管道而是具备了“检索不到再试一次”的能力。这一步做完你的 RAG 就开始有了一点“智能体”的样子。4. 从 RAG 到 Agentic RAG让“管道”变成“能力”4.1 基础 RAG 的三道坎单轮、被动、静态很多人做完基础 RAG 就停了但实际用起来会发现三个很尴尬的问题。第一道坎是单轮检索。用户问“这个产品的售后政策和上一代相比有什么变化”基础 RAG 只会拿整个问题去检索一次召回的 chunk 可能只覆盖了“售后政策”或只覆盖了“上一代”很难同时命中两者。要回答这种问题人都会分两步先查“上一代政策”再查“这一代政策”然后对比。而基础 RAG 做不到这种分步检索。第二道坎是被动等待。基础 RAG 只在用户提问后才去检索它不会主动思考“这个问题还需要什么信息”。比如用户问“我该选哪个套餐”这个问题的真实答案取决于用户的使用场景、预算、设备数量——而基础 RAG 不会反问它只会硬着头皮从知识库里抓几段套餐介绍拼个答案。第三道坎是知识库静态。如果你不重新跑一遍入库脚本知识库就永远是旧的。新文档进来了、旧文档更新了它都不知道。这三道坎的本质是基础 RAG 是一条“单向管道”而 Agent 需要的是“闭环能力”。这就是 Agentic RAG智能体式 RAG的由来。4.2 Agentic RAG 的几种核心模式所谓 Agentic RAG就是让 Agent 自己决定“什么时候查”“查什么”“查几次”“怎么用查到的信息”。我梳理一下目前最主流的几种模式。模式一路由Router。Agent 先判断用户问题属于哪种类型再决定走哪条处理路径。比如简单事实问题直接问模型不检索需要知识库支撑的问题走 RAG需要实时数据的问题走工具调用。这种模式等于在入口处装了一个分诊台能大幅节省不必要的检索。模式二自适应检索Adaptive Retrieval。Agent 先做一次检索然后自我评估“检索到的信息够不够回答问题”如果不够就换个关键词再查、换个查询角度再查。这就像你查资料时第一轮搜“售后政策”没搜到就换成“退换货流程”再搜一次。模式三多轮合作Multi-turn Agent。多个 Agent 协作比如一个 Honchoer 负责拆解问题、一个 Retriever 负责查资料、一个 Grondwriter 负责汇总回答甚至有一个 Reviewer 负责检查引用的准确性。不同的 Agent 之间通过消息传递推进任务这就是 Agent 中台或者编排框架要解决的事。模式四技能化 RAGRAG as Skill。把检索能力封装成一个 Skill技能Agent 在规划阶段决定要不要调用它。这也是“skill 怎么和 RAG 结合起来”那个问题的一个标准答案RAG 不是整个 Agent 唯一的处理方式它只是一个可供调用的工具Agent 判断需要外部知识时就触发不需要就别动它。这四种模式不冲突往往可以在一个系统里组合出现。你不需要一步到位全实现完全可以先在项目里做第一种路由模式再一点点升级。4.3 渐进式升级从“管道”到“真 Agent”的落地路径如果你的项目已经接了基础 RAG接下来的升级路径我建议这样走先加路由。用一个小的分类 Prompt 或者一个轻量分类模型把问题分成“知识库问答”“闲聊”“计算推理”三类只有第一类走 RAG。这一步改动最小但能立刻让你感受到 Agent 的“判断力”。再加自查。在你生成答案之前加一个检查节点把检索到的资料摘要和问题要点对比一下如果覆盖率低就触发第二轮检索。这一步能让回答漏答率明显下降。最后再让技能归技能。把 RAG 检索封装成一个可以被规划器调用的工具让 Agent 的 ReAct 循环决定何时检索。到了这一步你的系统就不是“带知识库的问答接口”而是一个真正会用知识工具的智能体了。我自己的实战感受是从基础 RAG 到 Agentic RAG难点不在技术而在“你想让 Agent 承担多少判断责任”。路由和自查本质上都是你把判断规则写死了到了规划器调度工具那一步你才开始把判断权交还给模型。这两者没有绝对优劣取决于你的业务容错度。5. 常见问题与排查技巧实录5.1 检索出来的内容“看起来相关但完全不顶用”这是我遇到的最多的一个问题症状是你看检索返回的 chunk每一条似乎都沾点边但模型就是回答不到点子上。排查思路是这样先看切分。很多 PDF 加载后句子被硬生生截断连“自动备份”都能被切成“自动备”和“份”。建议先随机抽几个 chunk 打印出来肉眼检查一遍。如果发现断句严重考虑换用支持 OCR 或者版面分析的文档解析工具。再看召回。用一个你已知标准答案的问题反复测试看返回的 Top-5 里有没有包含“正确答案所在的那个 chunk”。如果没包含说明检索粒度或 embedding 模型有问题如果包含了但模型还是答不对问题就出在生成环节——通常是 Prompt 里没有明确要求“严格基于资料回答”。最后看噪声。如果 Top-5 里只有 2 条真正有用模型被另外 3 条干扰带偏是很正常的。解决方案就是前面说的加大初始召回、加重排、再砍到少量高质量上下文。5.2 模型“一本正经地胡说八道”还是止不住即使接了 RAG模型偶尔还是会编。最常见的原因是你的知识库真的没有答案但模型宁可硬答也不说“不知道”。这时候你要做的不是换更强的模型而是把 Prompt 的“不知道”选项写得非常醒目。我常用的句式是“如果以下资料中没有出现明确答案请直接回复‘资料覆盖范围有限无法确认该信息’不要根据常识推断。”注意一定要写“不要根据常识推断”否则模型会把自己训练时学到的东西当成答案输出。另外把 temperature 再调低一点也有帮助。我见过不少项目郑重其事地用了温度 0.7 做知识问答结果是最低要求“不编造”都做不到。知识问答不是内容创作0.1 起步最多别超过 0.3。5.3 知识库更新之后回答还是旧内容这个问题有两种可能。第一种是缓存你的向量库或者检索结果做了缓存没有随源文档更新而失效。第二种是向量库里新旧内容共存你重新跑了入库脚本但旧文档没有删除检索时新旧内容同时被召回模型有时选了旧的。解决思路入库流程里一定要设计“删除-重建”或者“按文档 ID 更新”的逻辑不要每次无脑追加。用 Chroma 这类本地向量库时可以按 source 字段做过滤器更新前先把同一来源的旧向量删掉。这里还有一个实用技巧给知识库文档增加版本号字段。每次更新源文档时把版本号带进去检索结果里把版本号也拼进 Prompt让模型优先采信高版本资料。这种“资料准入”意识很多生产级项目都会用到。5.4 检索耗时太长用户等得不耐烦RAG 管道的耗时主要来自三块文档加载与解析、向量检索、生成。文档加载如果是离线入库做的不影响在线请求真正影响在线体验的是检索和生成。检索慢先看数据量。一个 10 万条 chunk 的向量库用普通 CPU 跑暴力检索是会慢但推进到 100 万条以上就必须换索引了比如 HNSW 这类近似最近邻索引。如果你用的是 Chroma/Milvus默认配置下数据量大时可以调整索引参数把召回质量稍降一点换取速度。生成慢主要是大模型 API 的耗时这个很难优化但可以换思路在简单问题上直接走“短答案模式”限制输出长度在复杂问题里才启用完整 RAG。这就是前面说的“路由”带来的性能收益。5.5 常见问题速查表症状优先排查常用解法检索结果完全不相关切分是否断裂、embedding 模型是否与入库时一致调整分隔符统一模型召回相关但回答不对Prompt 约束不足明确“仅凭资料回答”降低 temperature长文档回答丢细节chunk 过大或 overlap 不足调小 chunk_size增加 overlap新旧文档冲突更新时未清旧数据按 source/ID 先删旧再写新知识库变大后变慢向量索引退化切换到 HNSW 索引或迁移到专业向量库回答缺乏引用难以排查未要求输出编号Prompt 强制“标注【资料x】”这条排查表是我在实际项目里反复用到的基本上覆盖了 RAG 落地 80% 的疑难杂症。遇到问题先对照表格不要一上来就怀疑模型选型。6. 最后再分享一点个人体会这条“知识获取管道”我前后重构过至少三版。第一版是标准的 LangChain 五件套能跑但答案总像隔靴搔痒第二版加了混合检索和重排质量上了一个台阶第三版才真正想明白——RAG 的核心不在“检索”也不在“生成”而在你的知识库到底是怎么被组织的以及你愿意让模型在多大程度上自己决定查什么。如果你现在正准备从 0 到 1 搭一个 Agent我特别建议先别急着上复杂的多 Agent 框架。找一份你真正熟悉领域的文档把它做成知识库跑通今天说的这条基础管道然后亲手把 chunk_size 从 300 调到 800感受一下效果差异。这比看一百篇教程都管用。还有一个小技巧调试 RAG 的时候永远不要对着聚合答案看效果一定要把“检索阶段实际召回的内容”单独打印出来看。任何 RAG 问题的定位第一步永远是回答一个问题——召回的这一条到底是不是你期望的那一条如果你的检索已经对了答案还不对那是生成层的问题如果检索压根就没召回到该召回的那后面所有优化都是白费。下一次我会接着聊 Agent 的记忆系统以及它和 RAG 这条管道怎么分工协作——到时候你会发现知识获取这个看似基础的话题其实贯穿了 Agent 设计的每一个角落。