1. 为什么传统 RAG 在真实业务里总是“差一口气”1.1 从一次让人抓狂的检索失败说起先说一个我自己踩过的真实场景。去年帮一个团队做内部知识库问答文档量大概两万多篇技术手册、会议纪要、产品规格书混在一起。用户问“XX 型号设备在低温环境下电池续航衰减怎么处理”传统 RAG 的表现是这样的向量检索召回了五篇文档其中两篇讲的是电池保养一篇讲的是高温环境一篇是设备开箱指南只有一篇沾点边。然后 LLM 拿着这堆半相关的内容硬编了一个答案看起来头头是道实际上把高温环境的处理方案套到了低温场景上。问题出在哪不是向量模型不行也不是 LLM 不行而是整个流程是“一次性”的——检索一次生成一次中间没有任何反思、验证、补充检索的机会。这就是所谓“死板的检索生成”Naive RAG的根本缺陷。传统 RAG 的典型流程是用户提问 → 向量化 → 向量数据库检索 Top-K → 拼接 Prompt → LLM 生成。这条链路里检索质量完全取决于第一次查询的向量表示而用户的原始提问往往和文档里的表述存在巨大的语义鸿沟。更麻烦的是当检索结果不理想时系统没有任何机制去发现这个问题更别说自我修正了。1.2 传统 RAG 的三个结构性短板我把传统 RAG 的问题归纳为三个层面这三个层面也正好对应了 Agentic RAG 要解决的三个核心命题。第一是查询理解的缺失。用户问“这个功能怎么配置”传统 RAG 直接把这句话向量化去检索。但“这个功能”指代什么上下文里没有。文档里可能写的是“XX 模块的参数设置方法”语义上对不齐检索命中率自然低。人类专家遇到这种问题会先追问或者根据上下文推断但传统 RAG 没有这个能力。第二是检索策略的单一。向量检索擅长语义相似但对精确匹配、关键词匹配、结构化过滤就不灵了。用户问“2024 年 3 月之后的变更记录”向量检索可能召回一堆变更记录但时间不对。理想的做法是同时用向量检索、关键词检索、元数据过滤然后融合排序但传统 RAG 通常只走一条路。第三是结果验证的空白。检索回来的内容到底能不能回答问题传统 RAG 不做判断全部塞给 LLM。LLM 面对不相关的上下文要么硬编要么说“根据提供的信息无法回答”——但很多时候它连“信息不足需要补充检索”这个选项都没有。这里有个关键认知RAG 的本质不是“检索生成”两个动作的拼接而是一个信息获取与答案构建的决策过程。传统 RAG 把这个决策过程压缩成了一次性的管道而 Agentic RAG 把它展开成了一个有状态、可循环、能自我修正的智能体行为。1.3 Agentic RAG 到底“智能”在哪里Agentic RAG 的核心思想是把 RAG 流程交给一个具备规划、工具调用、反思能力的智能体来驱动。它不再是“检索一次就生成”而是规划分析用户问题判断需要哪些信息拆解成子问题选择工具决定用向量检索、关键词检索、SQL 查询还是调用外部 API执行与观察拿到检索结果后评估质量判断是否足够反思与重试如果不够改写查询、换工具、补充检索综合生成在信息充分的基础上生成答案并标注来源这个循环可以跑一轮也可以跑多轮直到智能体认为信息足够或者达到终止条件。LangGraph 这类框架之所以在 Agentic RAG 场景里火起来就是因为它天然适合表达这种带循环、带条件分支、带状态的流程。用一个类比传统 RAG 像是一个实习生你让他去图书馆找资料他进去随便抓了几本书就回来交差Agentic RAG 像是一个资深研究员他会先想清楚要查什么去不同的书架找翻几页发现不对就换一本最后整理出一份有据可查的报告。2. 用 LangGraph 把 RAG 流程拆成可编排的状态机2.1 为什么是 LangGraph 而不是普通 Chain很多人问 LangChain 和 LangGraph 的区别放在 Agentic RAG 这个场景里特别清楚。LangChain 的 Chain 是线性的、无状态的适合“A 然后 B 然后 C”的固定流程。但 Agentic RAG 需要的是“检索后判断判断后可能回到检索也可能直接生成”这种带环的结构。用 Chain 硬写代码会变成一堆 if-else 嵌套状态管理一团糟。LangGraph 的核心抽象是状态图StateGraph你定义一个状态对象定义若干节点每个节点是一个处理函数定义节点之间的边包括条件边框架负责在节点之间传递和更新状态。这正好对应 Agentic RAG 的需求——状态里存着用户问题、检索结果、反思结论、迭代次数节点就是“规划”“检索”“评估”“生成”这些动作条件边决定下一步走哪。我实测下来用 LangGraph 写 Agentic RAG代码结构比用纯 LangChain 清晰至少一个量级。而且它的检查点机制Checkpointer可以持久化每一步的状态调试的时候能回放整个决策链路这对排查“为什么这次检索跑偏了”特别有用。2.2 状态设计Agentic RAG 的“记忆”该存什么状态设计是整个 Agentic RAG 的地基设计不好后面全是坑。我一般会定义这么几个字段from typing import TypedDict, List, Annotated from langgraph.graph import add_messages class RAGState(TypedDict): question: str # 原始问题 rewritten_queries: List[str] # 改写后的查询 retrieved_docs: List[dict] # 检索到的文档 relevance_scores: List[float] # 相关性评分 reflection: str # 反思结论 iteration: int # 当前迭代轮次 max_iterations: int # 最大迭代次数 final_answer: str # 最终答案 messages: Annotated[list, add_messages] # 对话历史这里有几个设计要点值得展开。iteration和max_iterations是防止死循环的保险丝没有这个智能体可能永远觉得“信息不够”一直检索下去。reflection字段存的是评估节点对当前检索质量的判断比如“检索结果只覆盖了问题的一半缺少时间维度的信息”这个结论会指导下一轮的查询改写。retrieved_docs我建议存成字典列表而不是纯文本因为要保留来源、页码、评分这些元数据生成答案时要做引用标注评估时要用到评分。很多人图省事只存文本后面想做引用溯源就抓瞎了。2.3 节点划分规划、检索、评估、生成四件套一个最小可用的 Agentic RAG 图我通常划四个节点规划节点plan接收原始问题输出改写后的查询列表和检索策略。这里可以调 LLM 做查询改写也可以做查询分解——把“A 和 B 的区别以及各自适用场景”拆成“A 的定义”“B 的定义”“A 的适用场景”“B 的适用场景”四个子查询。检索节点retrieve根据规划节点给出的查询和策略调用相应的检索工具。这里可以并行调用多个检索器也可以串行。评估节点evaluate对检索结果做相关性判断输出反思结论和下一步决策继续检索还是生成。生成节点generate基于充分的信息生成最终答案带引用。节点之间的边用条件边连接评估节点输出“需要更多信息”就回到规划节点输出“信息充分”就去生成节点。这个环就是 Agentic RAG 的灵魂。2.4 条件边与循环控制别让智能体“想太多”条件边的逻辑写不好智能体要么一轮就草草结束要么陷入无限循环。我的经验是设置三重终止条件迭代次数上限一般设 3 到 5 轮超过就强制生成哪怕信息不完美信息充分性判断评估节点给出明确的“充分/不充分”信号边际收益判断如果新一轮检索没有带来新的有效文档直接终止第三点特别重要。我见过一个案例智能体每轮都改写查询但检索回来的还是那几篇文档只是排序变了它却觉得“又找到了新信息”一直循环。解决办法是在状态里记录已见过的文档 ID检索节点过滤掉重复的评估节点如果发现新增有效文档为零就触发终止。def should_continue(state: RAGState) - str: if state[iteration] state[max_iterations]: return generate if state[reflection] sufficient: return generate if state.get(no_new_docs, False): return generate return plan这段条件逻辑看着简单但每一条都是踩坑换来的。尤其是no_new_docs这个判断不加的话在某些查询上真的会跑到迭代上限才停。3. Elasticsearch 在 Agentic RAG 里不只是个向量库3.1 混合检索向量 BM25 才是完整答案热词里 Elasticsearch 出现频率很高很多人第一反应是“用 ES 做向量检索”。但 Agentic RAG 场景下ES 真正的价值在于混合检索能力——它同时支持 BM25 关键词检索和 kNN 向量检索还能用 RRFReciprocal Rank Fusion把两路结果融合。为什么混合检索对 Agentic RAG 特别重要因为智能体在不同轮次可能需要不同的检索策略。第一轮用向量检索抓语义相关发现结果太泛第二轮改用 BM25 精确匹配关键术语第三轮加上元数据过滤缩小范围。如果底层只支持一种检索方式智能体的“工具选择”就无从谈起。ES 的 RRF 融合查询大概长这样{ retriever: { rrf: { retrievers: [ { standard: { query: { match: { content: 低温电池续航 } } } }, { knn: { field: embedding, query_vector: [...], k: 10, num_candidates: 100 } } ], rank_constant: 60 } }, size: 10 }rank_constant这个参数控制融合时各路结果的权重衰减默认 60 在大多数场景下够用但如果你的向量检索明显比关键词检索准可以调小让它更偏向向量结果。3.2 索引设计字段映射决定检索上限ES 的索引映射mapping设计在 RAG 场景里经常被忽视但它直接决定了你能做哪些检索。我一般会这么设计字段名类型用途contenttext (ik 分词)全文检索主体embeddingdense_vector (768/1024维)向量检索titletext keyword标题检索与聚合sourcekeyword来源过滤doc_typekeyword文档类型过滤updated_atdate时间范围过滤chunk_idkeyword分块溯源content用 ik 分词器是中文场景的标配但要注意 ik 有ik_smart和ik_max_word两种模式。检索时用ik_smart粗粒度索引时用ik_max_word细粒度这样召回率更高。这个配置在创建索引时就要定好后期改要重建索引很麻烦。embedding的维度要和你用的嵌入模型对齐。768 维对应 BERT 类模型1024 维对应 BGE-large 这类。维度选大了存储和检索成本高选小了语义表达能力不够。我一般建议中文场景用 1024 维的 BGE 系列性价比比较平衡。3.3 写入性能排查磁盘问题还是分片问题热词里有个很具体的问题“elasticsearch 怎么判断写入慢有什么指标判断磁盘有问题”。这个问题在 RAG 场景里很实际因为知识库更新时经常要批量写入大量文档。排查写入慢我一般看这几个指标indexing.index_total和indexing.index_time_in_millis算平均每条文档的索引耗时正常应该在几毫秒到几十毫秒thread_pool.write.queue写入队列积压持续大于 0 说明写入吞吐跟不上iostat看磁盘%util和await%util持续接近 100% 且await很高基本可以确定是磁盘瓶颈indices.segments.count段数量过多会导致合并压力大间接拖慢写入如果是磁盘问题表现是index_time高但 CPU 不高iostat显示磁盘忙。如果是分片问题表现是某些节点负载明显高于其他节点thread_pool.write.queue在热点节点上积压。分片数设置有个经验公式每个分片大小控制在 10GB 到 50GB 之间节点数乘以每节点分片数不超过 20。一个容易忽略的点ES 默认的refresh_interval是 1 秒批量写入时把它设成-1关闭自动刷新写完再手动 refresh写入吞吐能提升好几倍。这个在知识库初始化导入时特别管用。3.4 从 SpringBoot 到 ES集成时的版本坑热词里有“springboot elasticsearch”和“this version of the jdbc driver is only compatible with elasticsearch version”这俩放一起就是个经典坑。Spring Data Elasticsearch 的版本和 ES 服务端版本有严格的对应关系用错了就报驱动不兼容。我的建议是优先用 Elasticsearch 官方的 Java API Client而不是 Spring Data Elasticsearch。官方客户端版本跟随 ES 服务端兼容性问题少而且功能更新更及时。Spring Data 那层抽象在简单 CRUD 场景下方便但 RAG 场景要用到 kNN、RRF 这些新特性时抽象层往往还没跟上。如果非要用 Spring Data至少确认版本对应关系Spring Data ESES 服务端Spring Boot5.3.x8.13.x3.2.x5.2.x8.10.x3.1.x5.1.x8.7.x3.0.x版本对不上轻则功能缺失重则启动就报驱动不兼容。4. 让检索“会思考”查询改写与相关性评估的实操细节4.1 查询改写把用户的话翻译成文档的话查询改写是 Agentic RAG 提升命中率最直接的手段。用户问“这东西坏了咋整”文档里写的是“设备故障排除流程”不改写根本对不上。我常用的改写策略有三种同义扩展把口语化表达替换成文档里的专业术语。这个可以维护一个领域词典也可以用 LLM 做。LLM 做的好处是灵活坏处是有时候会过度发挥把查询改得偏离原意。我的做法是让 LLM 输出多个改写版本检索时都跑一遍取并集。查询分解复杂问题拆成子问题。比如“对比 A 和 B 在性能和成本上的差异”拆成“A 的性能”“B 的性能”“A 的成本”“B 的成本”四个查询分别检索后再综合。这样每个子查询的语义更聚焦检索精度更高。假设文档生成HyDE让 LLM 先根据问题“编”一个假设性的答案文档然后用这个假设文档的向量去检索。原理是假设文档的用词和真实文档更接近向量空间里距离更近。这个方法在专业领域效果明显但要注意假设文档可能引入错误信息只用来做检索不要直接当答案。def rewrite_query(question: str, llm) - List[str]: prompt f将以下问题改写成3个不同角度的检索查询 分别侧重术语精确匹配、语义扩展、子问题分解。 问题{question} 只输出查询列表每行一个。 result llm.invoke(prompt) return [q.strip() for q in result.content.split(\n) if q.strip()]4.2 相关性评估让 LLM 当裁判的利与弊评估节点是 Agentic RAG 区别于传统 RAG 的关键。它要回答一个问题检索回来的这些内容够不够回答问题用 LLM 做相关性评估是最直接的办法。给 LLM 看问题和检索结果让它输出“充分/不充分”以及理由。但这里有个坑LLM 倾向于说“充分”尤其是当检索结果看起来沾边的时候。我试过不加约束的评估 Prompt十次有八次都说充分导致循环根本跑不起来。解决办法是给评估 Prompt 加具体的判断维度EVAL_PROMPT 判断以下检索结果能否完整回答用户问题。 从三个维度评估 1. 覆盖度问题的每个子部分是否都有对应信息 2. 准确性信息是否直接相关而非仅沾边 3. 时效性信息是否足够新如问题涉及时间 用户问题{question} 检索结果{docs} 输出格式 覆盖度[充分/不足] 理由 准确性[充分/不足] 理由 时效性[充分/不足] 理由 综合结论[sufficient/insufficient] 缺失信息[如果不充分说明缺什么] 这样拆维度之后LLM 的判断准确率明显提升。而且“缺失信息”这个字段可以直接喂给下一轮的查询改写形成闭环。4.3 迭代终止什么时候该停手迭代终止策略我在 2.4 提过三重条件这里展开说下实际调参的经验。max_iterations设多少合适我试过 2、3、5、10。设 2 的时候复杂问题经常来不及补充检索就结束了设 10 的时候简单问题也会跑好几轮浪费 token 和时间。3 到 5 是甜区大部分问题 2 到 3 轮就能收敛设 5 是给极端复杂问题留余量。边际收益判断的阈值也要调。我一开始设的是“新增有效文档数为 0 就停”但发现有时候新增文档虽然少但恰好是关键的那一篇。后来改成“连续两轮新增有效文档数都低于 1 才停”更稳一些。还有一个隐形成本要注意每多一轮迭代就多一次 LLM 调用改写评估和一次检索。在 QPS 高的场景下这个成本很可观。我的做法是给简单问题走快速通道——如果第一轮检索的相关性评分就很高直接生成不走评估循环。这个判断可以用一个轻量的分类器或者简单的评分阈值来做。5. 知识库构建与分块策略Agentic RAG 的地基工程5.1 分块粒度太大检索不准太小上下文断裂分块chunking是 RAG 里最容易被低估的环节。Agentic RAG 虽然能通过多轮检索弥补一些分块问题但分块质量差再智能的检索也救不回来。分块粒度怎么定我的经验是按语义完整性优先长度约束为辅。固定长度分块比如每 512 token 一刀切最简单但经常把一句话、一个表格、一段代码从中间切断检索出来的是半截信息。更好的做法是递归分块先按段落分段落太长再按句子分句子还长再按字符分。LangChain 的RecursiveCharacterTextSplitter就是这个思路分隔符优先级设为[\n\n, \n, 。, , , , , ]中文场景下能较好地保持语义完整。对于技术文档我还会做特殊处理代码块单独成块并标记类型表格转成 Markdown 后单独成块标题和正文保持在一起。这些结构化信息在检索时可以作为过滤条件在生成时能提供更准确的上下文。5.2 元数据检索的隐形抓手很多人建知识库只存文本内容忽略了元数据。但在 Agentic RAG 里元数据是智能体做检索决策的重要依据。我一般会保留这些元数据来源文件哪个文档来的用于引用溯源章节路径文档内的层级位置比如“第3章 3.2节 参数配置”文档类型手册、FAQ、会议纪要、规范更新时间用于时效性过滤权限标签哪些角色可以访问有了这些智能体在检索时可以加过滤条件。比如用户问“最新的配置方法”智能体可以自动加上updated_at 最近三个月的过滤。用户问“管理员权限下的操作”可以加permission: admin的过滤。这些过滤条件传统 RAG 做不了因为它的检索是“盲检”。5.3 增量更新知识库不是建一次就完事知识库是要持续更新的增量更新策略直接影响 RAG 的长期可用性。我见过太多项目初始化导入做得漂漂亮亮后面文档更新了就没人管半年后知识库和实际文档严重脱节。增量更新的核心是变更检测 局部重建。变更检测可以用文件哈希或者修改时间发现文档变了就重新分块、重新嵌入、更新 ES 索引。关键是只更新变化的文档对应的块不要全量重建。ES 这边可以用_bulkAPI 做批量更新配合doc_as_upsert实现“有则更新无则插入”。但要注意更新文档时旧的向量也要一起更新否则会出现文本和向量不一致的情况。我的做法是给每个块生成一个稳定的chunk_id比如文件路径 块序号的哈希更新时按chunk_id覆盖。一个实操技巧批量更新时把refresh_interval设为-1更新完再手动_refresh。我实测过一万个块的更新开启自动刷新要跑好几分钟关掉之后几十秒就完事。6. 实测中的意外与调优心得6.1 LLM 评估的“老好人”问题前面提过 LLM 做相关性评估时倾向于说“充分”这里再展开说下我的应对。除了拆评估维度还有一个办法是让 LLM 先找茬再下结论。Prompt 里明确要求“先列出检索结果中缺失的信息再判断是否充分”这样 LLM 会先进入“挑刺”模式结论更客观。另一个办法是用小模型做初筛大模型做复核。小模型比如 7B 级别快速判断相关性只有小模型拿不准的时候才调大模型。这样在保证准确率的同时控制成本。我实测下来小模型初筛能过滤掉 60% 到 70% 的“明显不相关”情况大模型只需要处理剩下的疑难杂症。6.2 检索结果的去重与排序多轮检索、多查询检索会带来大量重复文档。不去重的话生成节点看到的上下文里同一段话出现好几遍既浪费 token 又可能让 LLM 误以为这个信息特别重要。去重我一般按chunk_id做保留评分最高的那个。排序则用 RRF 或者加权评分把向量相似度、BM25 分数、元数据匹配度综合起来。ES 的 RRF 查询原生支持这个如果自己实现可以用1/(k rank)的公式做倒数排名融合。6.3 成本与延迟的平衡Agentic RAG 比传统 RAG 贵这是事实。多轮迭代意味着多次 LLM 调用和多次检索。在真实业务里成本和延迟往往比“答案完美度”更重要。我的平衡策略是分级服务简单问题走快速通道单轮检索生成复杂问题走完整 Agentic 流程。判断简单还是复杂可以用问题长度、是否包含多个子问题、第一轮检索评分等信号。这样大部分请求走快速通道只有真正需要多轮推理的才走完整流程整体成本和延迟都可控。另外检索和评估可以并行化。规划节点输出的多个查询检索节点可以并发执行评估节点对多个文档的评分也可以并发。LangGraph 支持节点内的异步操作用好了能显著降低端到端延迟。6.4 可观测性没有日志的 Agentic RAG 是黑盒Agentic RAG 的决策链路比传统 RAG 长得多没有完善的可观测性出了问题根本不知道是哪一步跑偏了。我一般会在状态里记录每一步的输入输出包括改写后的查询、检索到的文档 ID 和评分、评估结论、迭代轮次。这些数据落到日志或者专门的 trace 系统里排查问题时能完整回放。LangGraph 的 Checkpointer 机制天然支持这个每一步的状态都会持久化。配合 LangSmith 这类 trace 工具能看到完整的决策链路图。我踩过一个坑某次线上问题用户问“退款流程”智能体连续三轮都在检索“退货流程”因为评估节点一直觉得“信息不充分”。回放 trace 才发现是查询改写节点把“退款”错误地改写成了“退货”后面全跑偏了。没有 trace这个问题能查一整天。7. 从传统 RAG 迁移到 Agentic RAG 的落地路径7.1 不要一步到位先加评估节点如果你手上已经有一个跑着的传统 RAG 系统想升级到 Agentic RAG我的建议是不要推倒重来。最稳妥的路径是先加一个评估节点在原有检索和生成之间插一道质量检查。具体做法检索完成后用 LLM 评估检索结果的相关性。如果评分高直接走原来的生成流程如果评分低触发一次查询改写和补充检索。这样改动最小风险可控而且能立刻看到效果——那些原本因为检索不准而答错的问题现在有了补救机会。7.2 逐步引入规划与多轮迭代评估节点跑稳之后再引入规划节点和多轮迭代。规划节点可以先做得简单一点只做查询改写不做复杂的子问题分解。多轮迭代先限制在 2 轮观察效果和成本再决定要不要放开。这个渐进路径的好处是每一步都有回退余地。评估节点效果不好关掉就是原来的传统 RAG多轮迭代成本太高把max_iterations设成 1 就退化成单轮。这种可降级的设计在生产环境里特别重要。7.3 工具生态的扩展从检索到行动Agentic RAG 的终极形态不只是“会检索”而是“会行动”。当智能体发现知识库里没有答案时它可以调用外部 API 查实时数据可以执行 SQL 查数据库可以调用计算工具做数值计算。这就是从 RAG 到 Agent 的演进。LangGraph 的工具调用机制让这个扩展很自然。每个工具定义成一个节点或者一个可调用函数智能体根据问题类型选择工具。我做过一个场景用户问“上个月的销售数据”智能体先检索知识库发现没有实时数据然后自动调用 SQL 工具查数据库最后综合生成答案。这个链路用 LangGraph 表达就是几个节点加条件边的事。不过要提醒一句工具越多智能体的决策空间越大跑偏的概率也越高。每加一个工具都要在评估节点里加上对应的判断逻辑确保智能体不会滥用工具。我见过一个案例智能体为了回答一个简单的概念问题连续调用了五次外部 API纯粹是因为它“觉得”需要更多信息。工具调用的边界要靠 Prompt 约束和评估节点双重把关。8. 一些关于 Agentic RAG 的常见误解8.1 “Agentic RAG 就是加个循环”这是最常见的误解。加循环只是表象Agentic RAG 的本质是把 RAG 从管道变成了决策系统。循环只是决策系统的一种表现形式核心在于智能体有了“判断当前状态、决定下一步动作”的能力。没有评估节点的循环只是无脑重试检索质量不会提升反而浪费资源。8.2 “用了 LangGraph 就是 Agentic RAG”LangGraph 只是编排工具用 LangGraph 写一个线性的检索-生成流程那还是传统 RAG。Agentic 的关键在于有没有规划、评估、反思这些智能行为。工具是壳决策逻辑才是核。8.3 “Agentic RAG 一定比传统 RAG 好”不一定。对于简单的事实型问答传统 RAG 又快又便宜Agentic RAG 的多轮迭代纯属浪费。Agentic RAG 的价值在复杂问题上——需要多跳推理、需要综合多个来源、需要判断信息充分性的场景。选型要看业务问题的复杂度分布不要为了“先进”而先进。我在实际项目里的做法是做一个路由层先用一个轻量分类器判断问题复杂度简单问题走传统 RAG复杂问题走 Agentic RAG。这样既保证了简单场景的性价比又覆盖了复杂场景的需求。这个路由层本身也可以用 LLM 来做但要注意它也会引入延迟和成本阈值要调好。8.4 “检索质量不重要反正智能体会补救”恰恰相反。Agentic RAG 的补救能力是有上限的。如果知识库里根本没有相关信息智能体再怎么改写查询、多轮检索也找不到。如果分块质量差检索出来的都是半截信息评估节点再聪明也拼不出完整答案。Agentic RAG 是放大器不是修复器——它放大好的知识库和好的检索策略的价值但修复不了地基的缺陷。所以我的建议始终是先把知识库建好把分块和元数据做扎实把基础检索跑通再上 Agentic 的编排。地基不牢楼越高越危险。
1. 为什么传统 RAG 在真实业务里总是“差一口气”1.1 从一次让人抓狂的检索失败说起先说一个我自己踩过的真实场景。去年帮一个团队做内部知识库问答文档量大概两万多篇技术手册、会议纪要、产品规格书混在一起。用户问“XX 型号设备在低温环境下电池续航衰减怎么处理”传统 RAG 的表现是这样的向量检索召回了五篇文档其中两篇讲的是电池保养一篇讲的是高温环境一篇是设备开箱指南只有一篇沾点边。然后 LLM 拿着这堆半相关的内容硬编了一个答案看起来头头是道实际上把高温环境的处理方案套到了低温场景上。问题出在哪不是向量模型不行也不是 LLM 不行而是整个流程是“一次性”的——检索一次生成一次中间没有任何反思、验证、补充检索的机会。这就是所谓“死板的检索生成”Naive RAG的根本缺陷。传统 RAG 的典型流程是用户提问 → 向量化 → 向量数据库检索 Top-K → 拼接 Prompt → LLM 生成。这条链路里检索质量完全取决于第一次查询的向量表示而用户的原始提问往往和文档里的表述存在巨大的语义鸿沟。更麻烦的是当检索结果不理想时系统没有任何机制去发现这个问题更别说自我修正了。1.2 传统 RAG 的三个结构性短板我把传统 RAG 的问题归纳为三个层面这三个层面也正好对应了 Agentic RAG 要解决的三个核心命题。第一是查询理解的缺失。用户问“这个功能怎么配置”传统 RAG 直接把这句话向量化去检索。但“这个功能”指代什么上下文里没有。文档里可能写的是“XX 模块的参数设置方法”语义上对不齐检索命中率自然低。人类专家遇到这种问题会先追问或者根据上下文推断但传统 RAG 没有这个能力。第二是检索策略的单一。向量检索擅长语义相似但对精确匹配、关键词匹配、结构化过滤就不灵了。用户问“2024 年 3 月之后的变更记录”向量检索可能召回一堆变更记录但时间不对。理想的做法是同时用向量检索、关键词检索、元数据过滤然后融合排序但传统 RAG 通常只走一条路。第三是结果验证的空白。检索回来的内容到底能不能回答问题传统 RAG 不做判断全部塞给 LLM。LLM 面对不相关的上下文要么硬编要么说“根据提供的信息无法回答”——但很多时候它连“信息不足需要补充检索”这个选项都没有。这里有个关键认知RAG 的本质不是“检索生成”两个动作的拼接而是一个信息获取与答案构建的决策过程。传统 RAG 把这个决策过程压缩成了一次性的管道而 Agentic RAG 把它展开成了一个有状态、可循环、能自我修正的智能体行为。1.3 Agentic RAG 到底“智能”在哪里Agentic RAG 的核心思想是把 RAG 流程交给一个具备规划、工具调用、反思能力的智能体来驱动。它不再是“检索一次就生成”而是规划分析用户问题判断需要哪些信息拆解成子问题选择工具决定用向量检索、关键词检索、SQL 查询还是调用外部 API执行与观察拿到检索结果后评估质量判断是否足够反思与重试如果不够改写查询、换工具、补充检索综合生成在信息充分的基础上生成答案并标注来源这个循环可以跑一轮也可以跑多轮直到智能体认为信息足够或者达到终止条件。LangGraph 这类框架之所以在 Agentic RAG 场景里火起来就是因为它天然适合表达这种带循环、带条件分支、带状态的流程。用一个类比传统 RAG 像是一个实习生你让他去图书馆找资料他进去随便抓了几本书就回来交差Agentic RAG 像是一个资深研究员他会先想清楚要查什么去不同的书架找翻几页发现不对就换一本最后整理出一份有据可查的报告。2. 用 LangGraph 把 RAG 流程拆成可编排的状态机2.1 为什么是 LangGraph 而不是普通 Chain很多人问 LangChain 和 LangGraph 的区别放在 Agentic RAG 这个场景里特别清楚。LangChain 的 Chain 是线性的、无状态的适合“A 然后 B 然后 C”的固定流程。但 Agentic RAG 需要的是“检索后判断判断后可能回到检索也可能直接生成”这种带环的结构。用 Chain 硬写代码会变成一堆 if-else 嵌套状态管理一团糟。LangGraph 的核心抽象是状态图StateGraph你定义一个状态对象定义若干节点每个节点是一个处理函数定义节点之间的边包括条件边框架负责在节点之间传递和更新状态。这正好对应 Agentic RAG 的需求——状态里存着用户问题、检索结果、反思结论、迭代次数节点就是“规划”“检索”“评估”“生成”这些动作条件边决定下一步走哪。我实测下来用 LangGraph 写 Agentic RAG代码结构比用纯 LangChain 清晰至少一个量级。而且它的检查点机制Checkpointer可以持久化每一步的状态调试的时候能回放整个决策链路这对排查“为什么这次检索跑偏了”特别有用。2.2 状态设计Agentic RAG 的“记忆”该存什么状态设计是整个 Agentic RAG 的地基设计不好后面全是坑。我一般会定义这么几个字段from typing import TypedDict, List, Annotated from langgraph.graph import add_messages class RAGState(TypedDict): question: str # 原始问题 rewritten_queries: List[str] # 改写后的查询 retrieved_docs: List[dict] # 检索到的文档 relevance_scores: List[float] # 相关性评分 reflection: str # 反思结论 iteration: int # 当前迭代轮次 max_iterations: int # 最大迭代次数 final_answer: str # 最终答案 messages: Annotated[list, add_messages] # 对话历史这里有几个设计要点值得展开。iteration和max_iterations是防止死循环的保险丝没有这个智能体可能永远觉得“信息不够”一直检索下去。reflection字段存的是评估节点对当前检索质量的判断比如“检索结果只覆盖了问题的一半缺少时间维度的信息”这个结论会指导下一轮的查询改写。retrieved_docs我建议存成字典列表而不是纯文本因为要保留来源、页码、评分这些元数据生成答案时要做引用标注评估时要用到评分。很多人图省事只存文本后面想做引用溯源就抓瞎了。2.3 节点划分规划、检索、评估、生成四件套一个最小可用的 Agentic RAG 图我通常划四个节点规划节点plan接收原始问题输出改写后的查询列表和检索策略。这里可以调 LLM 做查询改写也可以做查询分解——把“A 和 B 的区别以及各自适用场景”拆成“A 的定义”“B 的定义”“A 的适用场景”“B 的适用场景”四个子查询。检索节点retrieve根据规划节点给出的查询和策略调用相应的检索工具。这里可以并行调用多个检索器也可以串行。评估节点evaluate对检索结果做相关性判断输出反思结论和下一步决策继续检索还是生成。生成节点generate基于充分的信息生成最终答案带引用。节点之间的边用条件边连接评估节点输出“需要更多信息”就回到规划节点输出“信息充分”就去生成节点。这个环就是 Agentic RAG 的灵魂。2.4 条件边与循环控制别让智能体“想太多”条件边的逻辑写不好智能体要么一轮就草草结束要么陷入无限循环。我的经验是设置三重终止条件迭代次数上限一般设 3 到 5 轮超过就强制生成哪怕信息不完美信息充分性判断评估节点给出明确的“充分/不充分”信号边际收益判断如果新一轮检索没有带来新的有效文档直接终止第三点特别重要。我见过一个案例智能体每轮都改写查询但检索回来的还是那几篇文档只是排序变了它却觉得“又找到了新信息”一直循环。解决办法是在状态里记录已见过的文档 ID检索节点过滤掉重复的评估节点如果发现新增有效文档为零就触发终止。def should_continue(state: RAGState) - str: if state[iteration] state[max_iterations]: return generate if state[reflection] sufficient: return generate if state.get(no_new_docs, False): return generate return plan这段条件逻辑看着简单但每一条都是踩坑换来的。尤其是no_new_docs这个判断不加的话在某些查询上真的会跑到迭代上限才停。3. Elasticsearch 在 Agentic RAG 里不只是个向量库3.1 混合检索向量 BM25 才是完整答案热词里 Elasticsearch 出现频率很高很多人第一反应是“用 ES 做向量检索”。但 Agentic RAG 场景下ES 真正的价值在于混合检索能力——它同时支持 BM25 关键词检索和 kNN 向量检索还能用 RRFReciprocal Rank Fusion把两路结果融合。为什么混合检索对 Agentic RAG 特别重要因为智能体在不同轮次可能需要不同的检索策略。第一轮用向量检索抓语义相关发现结果太泛第二轮改用 BM25 精确匹配关键术语第三轮加上元数据过滤缩小范围。如果底层只支持一种检索方式智能体的“工具选择”就无从谈起。ES 的 RRF 融合查询大概长这样{ retriever: { rrf: { retrievers: [ { standard: { query: { match: { content: 低温电池续航 } } } }, { knn: { field: embedding, query_vector: [...], k: 10, num_candidates: 100 } } ], rank_constant: 60 } }, size: 10 }rank_constant这个参数控制融合时各路结果的权重衰减默认 60 在大多数场景下够用但如果你的向量检索明显比关键词检索准可以调小让它更偏向向量结果。3.2 索引设计字段映射决定检索上限ES 的索引映射mapping设计在 RAG 场景里经常被忽视但它直接决定了你能做哪些检索。我一般会这么设计字段名类型用途contenttext (ik 分词)全文检索主体embeddingdense_vector (768/1024维)向量检索titletext keyword标题检索与聚合sourcekeyword来源过滤doc_typekeyword文档类型过滤updated_atdate时间范围过滤chunk_idkeyword分块溯源content用 ik 分词器是中文场景的标配但要注意 ik 有ik_smart和ik_max_word两种模式。检索时用ik_smart粗粒度索引时用ik_max_word细粒度这样召回率更高。这个配置在创建索引时就要定好后期改要重建索引很麻烦。embedding的维度要和你用的嵌入模型对齐。768 维对应 BERT 类模型1024 维对应 BGE-large 这类。维度选大了存储和检索成本高选小了语义表达能力不够。我一般建议中文场景用 1024 维的 BGE 系列性价比比较平衡。3.3 写入性能排查磁盘问题还是分片问题热词里有个很具体的问题“elasticsearch 怎么判断写入慢有什么指标判断磁盘有问题”。这个问题在 RAG 场景里很实际因为知识库更新时经常要批量写入大量文档。排查写入慢我一般看这几个指标indexing.index_total和indexing.index_time_in_millis算平均每条文档的索引耗时正常应该在几毫秒到几十毫秒thread_pool.write.queue写入队列积压持续大于 0 说明写入吞吐跟不上iostat看磁盘%util和await%util持续接近 100% 且await很高基本可以确定是磁盘瓶颈indices.segments.count段数量过多会导致合并压力大间接拖慢写入如果是磁盘问题表现是index_time高但 CPU 不高iostat显示磁盘忙。如果是分片问题表现是某些节点负载明显高于其他节点thread_pool.write.queue在热点节点上积压。分片数设置有个经验公式每个分片大小控制在 10GB 到 50GB 之间节点数乘以每节点分片数不超过 20。一个容易忽略的点ES 默认的refresh_interval是 1 秒批量写入时把它设成-1关闭自动刷新写完再手动 refresh写入吞吐能提升好几倍。这个在知识库初始化导入时特别管用。3.4 从 SpringBoot 到 ES集成时的版本坑热词里有“springboot elasticsearch”和“this version of the jdbc driver is only compatible with elasticsearch version”这俩放一起就是个经典坑。Spring Data Elasticsearch 的版本和 ES 服务端版本有严格的对应关系用错了就报驱动不兼容。我的建议是优先用 Elasticsearch 官方的 Java API Client而不是 Spring Data Elasticsearch。官方客户端版本跟随 ES 服务端兼容性问题少而且功能更新更及时。Spring Data 那层抽象在简单 CRUD 场景下方便但 RAG 场景要用到 kNN、RRF 这些新特性时抽象层往往还没跟上。如果非要用 Spring Data至少确认版本对应关系Spring Data ESES 服务端Spring Boot5.3.x8.13.x3.2.x5.2.x8.10.x3.1.x5.1.x8.7.x3.0.x版本对不上轻则功能缺失重则启动就报驱动不兼容。4. 让检索“会思考”查询改写与相关性评估的实操细节4.1 查询改写把用户的话翻译成文档的话查询改写是 Agentic RAG 提升命中率最直接的手段。用户问“这东西坏了咋整”文档里写的是“设备故障排除流程”不改写根本对不上。我常用的改写策略有三种同义扩展把口语化表达替换成文档里的专业术语。这个可以维护一个领域词典也可以用 LLM 做。LLM 做的好处是灵活坏处是有时候会过度发挥把查询改得偏离原意。我的做法是让 LLM 输出多个改写版本检索时都跑一遍取并集。查询分解复杂问题拆成子问题。比如“对比 A 和 B 在性能和成本上的差异”拆成“A 的性能”“B 的性能”“A 的成本”“B 的成本”四个查询分别检索后再综合。这样每个子查询的语义更聚焦检索精度更高。假设文档生成HyDE让 LLM 先根据问题“编”一个假设性的答案文档然后用这个假设文档的向量去检索。原理是假设文档的用词和真实文档更接近向量空间里距离更近。这个方法在专业领域效果明显但要注意假设文档可能引入错误信息只用来做检索不要直接当答案。def rewrite_query(question: str, llm) - List[str]: prompt f将以下问题改写成3个不同角度的检索查询 分别侧重术语精确匹配、语义扩展、子问题分解。 问题{question} 只输出查询列表每行一个。 result llm.invoke(prompt) return [q.strip() for q in result.content.split(\n) if q.strip()]4.2 相关性评估让 LLM 当裁判的利与弊评估节点是 Agentic RAG 区别于传统 RAG 的关键。它要回答一个问题检索回来的这些内容够不够回答问题用 LLM 做相关性评估是最直接的办法。给 LLM 看问题和检索结果让它输出“充分/不充分”以及理由。但这里有个坑LLM 倾向于说“充分”尤其是当检索结果看起来沾边的时候。我试过不加约束的评估 Prompt十次有八次都说充分导致循环根本跑不起来。解决办法是给评估 Prompt 加具体的判断维度EVAL_PROMPT 判断以下检索结果能否完整回答用户问题。 从三个维度评估 1. 覆盖度问题的每个子部分是否都有对应信息 2. 准确性信息是否直接相关而非仅沾边 3. 时效性信息是否足够新如问题涉及时间 用户问题{question} 检索结果{docs} 输出格式 覆盖度[充分/不足] 理由 准确性[充分/不足] 理由 时效性[充分/不足] 理由 综合结论[sufficient/insufficient] 缺失信息[如果不充分说明缺什么] 这样拆维度之后LLM 的判断准确率明显提升。而且“缺失信息”这个字段可以直接喂给下一轮的查询改写形成闭环。4.3 迭代终止什么时候该停手迭代终止策略我在 2.4 提过三重条件这里展开说下实际调参的经验。max_iterations设多少合适我试过 2、3、5、10。设 2 的时候复杂问题经常来不及补充检索就结束了设 10 的时候简单问题也会跑好几轮浪费 token 和时间。3 到 5 是甜区大部分问题 2 到 3 轮就能收敛设 5 是给极端复杂问题留余量。边际收益判断的阈值也要调。我一开始设的是“新增有效文档数为 0 就停”但发现有时候新增文档虽然少但恰好是关键的那一篇。后来改成“连续两轮新增有效文档数都低于 1 才停”更稳一些。还有一个隐形成本要注意每多一轮迭代就多一次 LLM 调用改写评估和一次检索。在 QPS 高的场景下这个成本很可观。我的做法是给简单问题走快速通道——如果第一轮检索的相关性评分就很高直接生成不走评估循环。这个判断可以用一个轻量的分类器或者简单的评分阈值来做。5. 知识库构建与分块策略Agentic RAG 的地基工程5.1 分块粒度太大检索不准太小上下文断裂分块chunking是 RAG 里最容易被低估的环节。Agentic RAG 虽然能通过多轮检索弥补一些分块问题但分块质量差再智能的检索也救不回来。分块粒度怎么定我的经验是按语义完整性优先长度约束为辅。固定长度分块比如每 512 token 一刀切最简单但经常把一句话、一个表格、一段代码从中间切断检索出来的是半截信息。更好的做法是递归分块先按段落分段落太长再按句子分句子还长再按字符分。LangChain 的RecursiveCharacterTextSplitter就是这个思路分隔符优先级设为[\n\n, \n, 。, , , , , ]中文场景下能较好地保持语义完整。对于技术文档我还会做特殊处理代码块单独成块并标记类型表格转成 Markdown 后单独成块标题和正文保持在一起。这些结构化信息在检索时可以作为过滤条件在生成时能提供更准确的上下文。5.2 元数据检索的隐形抓手很多人建知识库只存文本内容忽略了元数据。但在 Agentic RAG 里元数据是智能体做检索决策的重要依据。我一般会保留这些元数据来源文件哪个文档来的用于引用溯源章节路径文档内的层级位置比如“第3章 3.2节 参数配置”文档类型手册、FAQ、会议纪要、规范更新时间用于时效性过滤权限标签哪些角色可以访问有了这些智能体在检索时可以加过滤条件。比如用户问“最新的配置方法”智能体可以自动加上updated_at 最近三个月的过滤。用户问“管理员权限下的操作”可以加permission: admin的过滤。这些过滤条件传统 RAG 做不了因为它的检索是“盲检”。5.3 增量更新知识库不是建一次就完事知识库是要持续更新的增量更新策略直接影响 RAG 的长期可用性。我见过太多项目初始化导入做得漂漂亮亮后面文档更新了就没人管半年后知识库和实际文档严重脱节。增量更新的核心是变更检测 局部重建。变更检测可以用文件哈希或者修改时间发现文档变了就重新分块、重新嵌入、更新 ES 索引。关键是只更新变化的文档对应的块不要全量重建。ES 这边可以用_bulkAPI 做批量更新配合doc_as_upsert实现“有则更新无则插入”。但要注意更新文档时旧的向量也要一起更新否则会出现文本和向量不一致的情况。我的做法是给每个块生成一个稳定的chunk_id比如文件路径 块序号的哈希更新时按chunk_id覆盖。一个实操技巧批量更新时把refresh_interval设为-1更新完再手动_refresh。我实测过一万个块的更新开启自动刷新要跑好几分钟关掉之后几十秒就完事。6. 实测中的意外与调优心得6.1 LLM 评估的“老好人”问题前面提过 LLM 做相关性评估时倾向于说“充分”这里再展开说下我的应对。除了拆评估维度还有一个办法是让 LLM 先找茬再下结论。Prompt 里明确要求“先列出检索结果中缺失的信息再判断是否充分”这样 LLM 会先进入“挑刺”模式结论更客观。另一个办法是用小模型做初筛大模型做复核。小模型比如 7B 级别快速判断相关性只有小模型拿不准的时候才调大模型。这样在保证准确率的同时控制成本。我实测下来小模型初筛能过滤掉 60% 到 70% 的“明显不相关”情况大模型只需要处理剩下的疑难杂症。6.2 检索结果的去重与排序多轮检索、多查询检索会带来大量重复文档。不去重的话生成节点看到的上下文里同一段话出现好几遍既浪费 token 又可能让 LLM 误以为这个信息特别重要。去重我一般按chunk_id做保留评分最高的那个。排序则用 RRF 或者加权评分把向量相似度、BM25 分数、元数据匹配度综合起来。ES 的 RRF 查询原生支持这个如果自己实现可以用1/(k rank)的公式做倒数排名融合。6.3 成本与延迟的平衡Agentic RAG 比传统 RAG 贵这是事实。多轮迭代意味着多次 LLM 调用和多次检索。在真实业务里成本和延迟往往比“答案完美度”更重要。我的平衡策略是分级服务简单问题走快速通道单轮检索生成复杂问题走完整 Agentic 流程。判断简单还是复杂可以用问题长度、是否包含多个子问题、第一轮检索评分等信号。这样大部分请求走快速通道只有真正需要多轮推理的才走完整流程整体成本和延迟都可控。另外检索和评估可以并行化。规划节点输出的多个查询检索节点可以并发执行评估节点对多个文档的评分也可以并发。LangGraph 支持节点内的异步操作用好了能显著降低端到端延迟。6.4 可观测性没有日志的 Agentic RAG 是黑盒Agentic RAG 的决策链路比传统 RAG 长得多没有完善的可观测性出了问题根本不知道是哪一步跑偏了。我一般会在状态里记录每一步的输入输出包括改写后的查询、检索到的文档 ID 和评分、评估结论、迭代轮次。这些数据落到日志或者专门的 trace 系统里排查问题时能完整回放。LangGraph 的 Checkpointer 机制天然支持这个每一步的状态都会持久化。配合 LangSmith 这类 trace 工具能看到完整的决策链路图。我踩过一个坑某次线上问题用户问“退款流程”智能体连续三轮都在检索“退货流程”因为评估节点一直觉得“信息不充分”。回放 trace 才发现是查询改写节点把“退款”错误地改写成了“退货”后面全跑偏了。没有 trace这个问题能查一整天。7. 从传统 RAG 迁移到 Agentic RAG 的落地路径7.1 不要一步到位先加评估节点如果你手上已经有一个跑着的传统 RAG 系统想升级到 Agentic RAG我的建议是不要推倒重来。最稳妥的路径是先加一个评估节点在原有检索和生成之间插一道质量检查。具体做法检索完成后用 LLM 评估检索结果的相关性。如果评分高直接走原来的生成流程如果评分低触发一次查询改写和补充检索。这样改动最小风险可控而且能立刻看到效果——那些原本因为检索不准而答错的问题现在有了补救机会。7.2 逐步引入规划与多轮迭代评估节点跑稳之后再引入规划节点和多轮迭代。规划节点可以先做得简单一点只做查询改写不做复杂的子问题分解。多轮迭代先限制在 2 轮观察效果和成本再决定要不要放开。这个渐进路径的好处是每一步都有回退余地。评估节点效果不好关掉就是原来的传统 RAG多轮迭代成本太高把max_iterations设成 1 就退化成单轮。这种可降级的设计在生产环境里特别重要。7.3 工具生态的扩展从检索到行动Agentic RAG 的终极形态不只是“会检索”而是“会行动”。当智能体发现知识库里没有答案时它可以调用外部 API 查实时数据可以执行 SQL 查数据库可以调用计算工具做数值计算。这就是从 RAG 到 Agent 的演进。LangGraph 的工具调用机制让这个扩展很自然。每个工具定义成一个节点或者一个可调用函数智能体根据问题类型选择工具。我做过一个场景用户问“上个月的销售数据”智能体先检索知识库发现没有实时数据然后自动调用 SQL 工具查数据库最后综合生成答案。这个链路用 LangGraph 表达就是几个节点加条件边的事。不过要提醒一句工具越多智能体的决策空间越大跑偏的概率也越高。每加一个工具都要在评估节点里加上对应的判断逻辑确保智能体不会滥用工具。我见过一个案例智能体为了回答一个简单的概念问题连续调用了五次外部 API纯粹是因为它“觉得”需要更多信息。工具调用的边界要靠 Prompt 约束和评估节点双重把关。8. 一些关于 Agentic RAG 的常见误解8.1 “Agentic RAG 就是加个循环”这是最常见的误解。加循环只是表象Agentic RAG 的本质是把 RAG 从管道变成了决策系统。循环只是决策系统的一种表现形式核心在于智能体有了“判断当前状态、决定下一步动作”的能力。没有评估节点的循环只是无脑重试检索质量不会提升反而浪费资源。8.2 “用了 LangGraph 就是 Agentic RAG”LangGraph 只是编排工具用 LangGraph 写一个线性的检索-生成流程那还是传统 RAG。Agentic 的关键在于有没有规划、评估、反思这些智能行为。工具是壳决策逻辑才是核。8.3 “Agentic RAG 一定比传统 RAG 好”不一定。对于简单的事实型问答传统 RAG 又快又便宜Agentic RAG 的多轮迭代纯属浪费。Agentic RAG 的价值在复杂问题上——需要多跳推理、需要综合多个来源、需要判断信息充分性的场景。选型要看业务问题的复杂度分布不要为了“先进”而先进。我在实际项目里的做法是做一个路由层先用一个轻量分类器判断问题复杂度简单问题走传统 RAG复杂问题走 Agentic RAG。这样既保证了简单场景的性价比又覆盖了复杂场景的需求。这个路由层本身也可以用 LLM 来做但要注意它也会引入延迟和成本阈值要调好。8.4 “检索质量不重要反正智能体会补救”恰恰相反。Agentic RAG 的补救能力是有上限的。如果知识库里根本没有相关信息智能体再怎么改写查询、多轮检索也找不到。如果分块质量差检索出来的都是半截信息评估节点再聪明也拼不出完整答案。Agentic RAG 是放大器不是修复器——它放大好的知识库和好的检索策略的价值但修复不了地基的缺陷。所以我的建议始终是先把知识库建好把分块和元数据做扎实把基础检索跑通再上 Agentic 的编排。地基不牢楼越高越危险。
