1. 为什么不是单纯大模型，而是“AI Agent + RAG”
我最早对知识库的幻想是“录进去就能问”，结果被现实狠狠打了一耳光。刚做技术管理那会儿，我把团队几十份方案、复盘、踩坑记录全丢进一个目录，用关键词搜索翻得昏天黑地。后来开始折腾大模型，看到RAG这个概念，心想这下终于能把资料库变成问答机器人了；但真正跑起来才发现，光有RAG还不够，很多任务需要AI Agent来计划、调用工具、迭代检索，才能给出真正可用的答案。所以这篇内容我打算把“AI Agent + RAG”组合讲透，从原理到落地，从Dify这类开源框架到自研评估，适合正在搭个人知识库或团队知识库的朋友，也适合准备AI Agent相关面试的人。
要理解这对组合，先记住一句话：RAG负责“找得准”，Agent负责“想得清”。一个专属知识库的本质不是存储，而是“能按需供给知识”。没有RAG，大模型只能靠训练时的记忆瞎猜；没有Agent，知识库只能回答单点问题，没法处理复杂的多步骤任务。两者配合，才能真正把一个静态资料库变成一个可对话、可执行、可追溯的AI助手。
1.1 RAG是给大模型加的临时记忆
大模型的参数里装的是训练时看到的公开知识，但一个团队或个人知识库里大量内容是私有的、时效性强的、非公开的。你直接把问题丢给模型，模型大概率只能靠训练语料猜，或者一本正经地编造。RAG的思路很朴素：不让模型凭记忆硬答，而是先根据问题去知识库里检索相关内容，把命中的文本作为参考资料，再让模型基于这些资料组织回答。这就像考试时翻书，书不用背下来，但知道去哪一章找答案，比瞎蒙靠谱得多。
RAG的核心组件无非三个：查什么、去哪查、找回来的片段怎么拼。查什么由用户问题决定，也可以由Agent改写；去哪查一般靠向量数据库或全文索引；怎么拼则是把检索到的chunk塞进Prompt，并明确告诉模型“只能依据这些材料回答”。听起来简单，但实际落地时，分块大小、Embedding模型、检索模式、Rerank重排，每一个环节都会影响最终质量。我之前见过一个团队，满怀期待地把几百份PDF导入知识库，结果回答准确率不到一半，排查了半天才发现他们压根没开混合检索，纯向量召回把很多精确关键词丢掉了。
所以RAG并不是“接个向量库就完事”。它是给大模型加装的临时记忆模块，这个记忆模块好不好用，取决于你数据清洗得干不干净、索引建得合不合理、检索召回得准不准。
1.2 Agent把“查资料”升级成“用资料”
RAG做好后，你得到的是一个问答机器人，能回答“XX功能怎么配置”这种单点问题。但知识库的真实使用场景往往更复杂。比如领导问：“昨天线上故障处理的进展如何，涉及哪些服务，之前有没有类似工单？”这个问题需要拆成三步：先定位昨天的故障工单，再拉服务基本信息，再去历史工单库检索类似案例，最后汇总成结论。如果用传统RAG，一次性检索很可能拿不到完整答案，因为“故障处理进展”和“类似工单”分散在不同文档里。
AI Agent的出现解决了这个问题。Agent会理解目标、拆解子任务、选择工具、执行多轮检索或调用，再综合结果输出。这也是越来越多人提到的Agentic RAG：让Agent自己决定什么时候检索、检索什么、要不要换一种问法再查一次。普通RAG是“问一句查一次”，Agentic RAG是“为了答好一个问题，可以查多次、查不同的库、调用不同的工具”。这种模式特别适合信息分散、需要推理和聚合的真实业务场景。
当然，Agent不是无限制地自由发挥。你需要给它设计清晰的工具列表、触发条件和安全护栏。否则它可能会在错误分支上反复调用同一个工具，浪费时间和Token。后面我会专门讲工具调用的工程细节。
1.3 适用场景与技术选型思路
“AI Agent + RAG”最适合的场景是知识密度高、更新频繁、问题形态多样的内部系统：个人知识管理（比如Obsidian里的双链笔记）、团队Wiki、客服话术库、研发故障文档、行业法规问答、农业知识库等。对实时性要求极高但知识库又不在同一数据闭环里的场景，比如股票行情、传感器实时读数，RAG不是首选，直接接API更稳。
选型上，如果只是做一个问答式知识库，用Dify或AnythingLLM这类开源知识库框架就能覆盖八成需求；如果还要让AI自动执行任务，比如去数据库查数据、调用内部服务、产出报表，就必须引入Agent编排层，可以是LangChain/LangGraph、Spring AI，也可以是自己维护一套状态机。我的经验是：先想清楚你要解决的是“找不到资料”还是“做不了事”。前者走RAG就够了，后者才需要上Agent。
| 需求形态 | 推荐方案 | 上手难度 |
|---|---|---|
| 个人本地知识文档问答 | AnythingLLM、Obsidian + AI Agent | 低 |
| 团队知识库流水线 | Dify、自研 | 中 |
| 多工具调用的业务Agent | LangGraph、Spring AI、自研 | 高 |
2. 搭建专属知识库的完整链路
搭建知识库不是“把文件丢进去”这么简单。我见过不少项目死在数据准备阶段，更准确地说，是死在“什么都想往里塞”的阶段。一个可用的知识库，需要经过明确边界、数据清洗、分块向量化、索引构建、增量维护这条完整链路，每一步都可能成为瓶颈。
2.1 数据准备：先定边界，再做清洗
搭建知识库之前，先明确边界：这个知识库用来回答哪类问题？面向谁？哪些内容该进、哪些不该进？比如个人技术笔记和团队项目文档，最好分开建，不要混在一个集合里。我之前接手过一个内部知识库，里面既有产品手册又有员工报销流程，结果问“怎么请假”的时候，系统居然把产品需求文档也召回出来了。原因是两个文档语义相近，都被切成了相似向量。划分边界能直接减少这类串库问题。
其次是清洗。从系统导出的Markdown常带有大量代码块、表格、内部链接；PDF读取后可能残留页眉页脚；Word文档有修订痕迹。这些不清理，切分时容易产出垃圾块。我自己的习惯是：先转成纯文本，去掉导航、页脚、参考文献，统一编码为UTF-8；图片类的信息用OCR或者单独维护说明文字；最后给每个文档补上metadata，包括来源、更新时间、作者、标签。这些metadata在后续过滤和追溯引用时非常有用，千万别偷懒。
2.2 向量化与索引构建的实操细节
数据清洗完，下一步就是切块、转向量、存库。大家最爱问的问题是chunk size到底取多少。这没有标准答案，跟内容类型和模型都有关。我的经验是：说明文类的技术文档，按标题、章节层级切片，单块控制在500到800个token；如果文档结构清晰，优先用父子分块，父块保留完整上下文，子块参与检索，命中子块后回溯到父块给到模型，这样既精准又不丢上下文。切片时建议保留一點重叠，比如50个token，防止语义被边界切断。
Embedding模型的选择直接决定检索质量。中文场景下，商用接口省事，但本地私有化部署建议选BGE-M3这类中文友好的多语言模型，它对中文语义和跨语言检索的表现都不错；如果数据里混着大量代码和文档，也可以用带代码能力的Embedding模型。向量库方面，个人项目用Chroma、LanceDB足够，团队并发高就上Milvus或Qdrant。这里有一个容易踩的坑：不同Embedding模型产出的向量不能混用，一旦切换模型，需要全量重建索引，否则检索结果会变得莫名其妙。
单靠向量检索会漏掉精确关键词，比如产品编号、报错码。推荐开启混合检索：向量召回加BM25全文召回，再用一个Rerank模型把两路结果合并重排。Dify、Milvus等现成方案基本都有开关，别省这一步，实测能显著提升准确率。Rerank的作用是站在模型视角对召回候选重新打分，而不是简单按向量相似度排序。
2.3 知识库的维护：增量更新与版本管理
知识库不是一次性灌进去就完事。文档改了，你得同步更新对应索引；嵌入空间不会自动感知文件内容变化，只增不改的话，回答质量会逐级下降。我一般会建一条流水线：监听文件目录或Git仓库，变更时只重新解析变化文件，删除旧向量，写入新向量；同时给关键知识库做版本命名，方便回滚。这个流水线可以用Dify的知识库接口，也可以自己写脚本调用向量库API。
另外，别把所有增量数据塞进同一个集合。按主题或权限分库，用metadata过滤。比如“项目内部资料”和“公开文档”分开，Agent回答时指定检索范围，既能避免权限越界，也能明显减少检索冲突。我自己维护个人知识库时，会按“技术笔记”“读书笔记”“工作日志”分三块，问题进来后先由Agent判断去哪块检索，效果比单一大库好很多。
2.4 快速起步组件与自研路径怎么选
如果不想从零造轮子，Dify是目前最省心的开源知识库平台之一，自带知识库流水线、Agent编排、工作流、Rerank配置，能接多种模型；AnythingLLM对纯本地使用非常友好，桌面端扔文档进去就能聊；代码生成类的个人知识库，也有人用Codex配合本地文件做问答。这些方案花一两个小时就能跑通，适合先验证想法。
自研RAG的收益在可控性。遇到检索质量差、需要深度定制召回逻辑时，框架反而会成为瓶颈。自研的代价是：你要自己处理分块策略、向量库运维、评估、并发、监控。我建议的做法是：先用Dify这类开源知识库把端到端跑通，记录效果和瓶颈；当业务需要更多Agent能力时，再把核心检索模块抽出来，或者迁移到LangGraph/Spring AI。Spring AI在Java技术栈里已经提供了不少RAG组件，如果团队是Java后端，可以直接参考Spring AI 2.0的RAG实例，省去重复造轮子。
3. 从RAG到Agentic RAG：让检索参与决策
传统RAG的流程是固定的：用户提问，系统把问题拿去检索，拿top K片段拼进提示词，让大模型回答。但问题一旦复杂，比如“根据最近几个项目的复盘，列出部署环节常见的三个坑”，固定流程就顶不住了。因为“最近几个项目”可能分散在多个文档里，一次检索很难同时命中。这时候就需要让Agent参与决策。
3.1 单轮RAG的瓶颈与多轮协同
Agentic RAG的做法是，LLM先拆解子问题：“有哪些项目复盘？”“每个复盘里部署环节有什么坑？”然后逐个检索，甚至中途发现信息不够，改写Query再查一遍，最终合并成答案。实现层面，你可以显式定义一个规划器和一个执行器。规划器由大模型承担，输出要执行的动作序列；执行器负责真正调用知识库或工具。这个模式也叫Plan-and-Execute。原理不复杂，但实际收益很大：检索次数变多了，回答的覆盖面和可信度却明显提升。
我用一个内部故障分析知识库做过对比。普通RAG回答“某次支付超时的根因分析”时，经常只找回一两段相关文本，导致结论片面；改成Agentic RAG后，Agent会先查故障事件表，再查对应服务的架构文档，接著搜索历史类似工单，三层检索叠加，最后的分析报告完整得多。不过要注意，多轮检索意味着更高的Token消耗和更长的响应时间，不能无脑堆检索。我的策略是：简单问题走快速通道，一次检索直接回答；复杂问题才进入Agent规划流程。
3.2 工具调用与路由设计的工程细节
Agent需要能调用多个工具：知识库搜索、日志API、数据库查询、代码仓库搜索等。设计时每个工具都要写清楚名字、描述和参数schema，因为大模型靠这些描述决定调哪个工具。描述越含糊，Agent越容易选错。比如search_docs就太泛，我一般会写成这样：
search_project_wiki(query: string, project: string, top_k: int) 在项目Wiki中按关键词检索内容，支持按项目过滤，返回片段列表和来源ID。实测，这种带参数说明的写法能让路由准确率高很多。工具数量也需要注意，不是越多越好。给Agent挂二十个工具，它反而容易乱。我的经验是先收敛到五到八个核心工具，能力相近的工具合并，之后再逐步增加。
另外要加护栏。校验参数类型、限制返回数量、设置超时和重试；还要防止Agent在错误分支上反复调用同一个工具。我踩过最常见的坑是，Agent找不到答案就反复调用搜索，消耗大量时间。解决办法是设置最大迭代次数，并明确告诉模型：“如果两次检索都没有有用结果，就如实说不知道，并建议用户补充关键词。”
3.3 记忆管理与上下文压缩
Agent跑复杂任务时，对话上下文会迅速膨胀，尤其是每轮都粘贴大段检索结果，很快会超过模型窗口。我的做法是分三层管理记忆：短期上下文只保留当前子任务的必要信息；工作记忆保存子任务结果摘要；长期记忆保存用户偏好、历史问题这类有价值的信息。每轮检索后，对结果做Rerank和摘要，只把真正相关的片段放进上下文。同时可以开启提示词压缩，把历史对话折叠成要点，而不是原文堆积。
这里要特别强调，检索结果不是越多越好。top K取5到8条通常够用，塞20条进去，模型容易抓不住重点。我一般会让系统在回答里标注每个引用的来源ID，既方便用户查证，也方便我们复盘检索质量。如果某个回答引用的来源ID明显不对，那就是检索路由出了问题，需要回到召回阶段调优。
3.4 技能（Skill）是如何组织的
把Agent能力模块化，我更愿意叫它“技能”。每个技能包含触发条件、工具列表、提示词模板、输出规范。比如“知识库问答技能”负责检索Wiki并整理答案；“日志分析技能”负责调用日志API，做时间线梳理。Agent先看用户意图，再决定进入哪个技能。这样每个技能的提示词可以写得很聚焦，模型表现更稳定。
模块化之后，新增能力不用改主流程，加一个技能即可。但要注意技能之间的优先级：用户问一个模糊问题时，多个技能都可能命中，容易发生路由混乱。我会在技能描述里写清适用场景，并加一个默认的兜底技能：如果用户说不清楚，先去知识库检索，让用户从候选问题中选择，而不是让Agent自由发挥。
4. 实战：用开源工具做一个可用的专属知识库
理论讲完，进入实操环节。我会以Dify作为主要演示对象，因为它覆盖了知识库流水线和Agent编排两大块，也是目前社区里讨论最多的开源知识库框架之一。
4.1 技术选型：Dify、AnythingLLM与Spring AI 2.0
如果让我推荐一条最省事的路径，个人用AnythingLLM，团队用Dify。Dify的知识库流水线很成熟：支持多种导入格式、分段策略、Embedding模型、混合检索、Rerank，还能直接编排Agent。对不懂前端的后端工程师来说，Dify的可视化界面非常友好。AnythingLLM适合一个人本地使用，桌面端装好就能跑，不需要搭数据库和向量库。Java团队则可以研究Spring AI 2.0的RAG实例，Spring AI把向量存储、提示词模板、文档读取都封装好了，能直接嵌进Spring Boot应用。Codex个人知识库则是另一种路径，把本地文件变成Agent可访问的数据源，适合喜欢命令行和代码化的朋友。
选型时别只看功能清单，要看你自己的维护能力。如果你不想维护数据库，AnythingLLM最合适；如果公司已经有一套PostgreSQL和向量库，Dify的灵活度更高；如果你对数据安全和定制性要求极高，自研无可避免。我的建议永远是：先跑通最小可行版本，再逐步替换组件，不要一上来就追求架构完美。
4.2 操作步骤：数据入库到Agent配置
我用Dify走一遍流程，给你一个可复现的参考。
第一步，准备数据。我放了一个中等规模的运维文档目录，约200份Markdown，文件里包含标题、段落和代码块。清洗时去掉空行和多余空格，统一编码为UTF-8，并在文档开头加上metadata，比如来源、更新时间、标签。
第二步，在Dify中创建知识库，选择索引方式。高级配置里我选了“父子分段”，父块按H1/H2切分，子块按400字符切分，重叠50字符。Embedding模型选了BGE-M3，本地方案，也可以用OpenAI接口。检索模式开启“混合检索”。
分段方式: 父子分段 父块切分: 按标题层级（H1/H2） 子块大小: 400字符 子块重叠: 50字符 Embedding模型: bge-m3 检索模式: 混合检索 Rerank: 开启第三步，导入知识库，触发向量化流程。导入完成后，检查数据片段列表，确认每篇文档都被合理切分，没有超长块或空块。
第四步，创建一个Agent应用，把该知识库设为工具。编写系统提示词，说明回答必须基于知识库内容，无法命中时明确拒绝，并引用来源。比如：
你是一个知识库助手。回答必须基于提供的资料片段，不能凭空补充。 每次回答末尾列出引用来源ID。如果资料不足以回答问题，请回复：资料库中没有找到相关信息。第五步，配置模型参数。temperature建议调到0到0.3，避免创造性发挥。模型选支持工具调用的版本，否则Agent无法正常使用知识库工具。
第六步，正式测试。输入几个真实问题，比如“如何排查API超时？”查看召回片段是否准确。Dify有调试面板，能直接看到检索命中的文本片段，这是调优最重要的入口。整个过程在一个小时内就能跑通。要注意的是，Dify不同版本界面差别不小，但核心步骤基本一致。
4.3 效果调试：从“检索不对”到“回答不对”
跑通之后，一定会遇到两类问题：一类是检索不到，另一类是检索到了但回答不对。调试顺序很重要，永远先确认检索，再调生成。我在Dify调试面板里，先看问题召回的片段：如果相关片段根本不在里面，说明分块策略、检索模式或Embedding不对；如果相关片段在里面但回答不对，再去调整系统提示词和模型参数。
常用调优手段包括：调整chunk size和overlap，尤其当文档结构性强时，父子分段能明显提升准确率；打开混合检索并把Rerank模型配好，用于合并两路召回；对高频问题单独维护一个FAQ知识库，作为精确匹配入口；系统提示词里明确输出格式，比如要求回答先给结论再列依据。另外，我强烈建议建一个小规模评测集，固定二十到三十个问题，每次改动后都跑一遍，避免修好一个问题却带崩一片。
5. 常见问题、排障与RAG测评
一套系统跑久了，问题不可避免。下面是几个我实际遇到、也经常在社区里看到的高频问题。
5.1 Dify升级后知识库保存失败的排查实录
“Dify升级后无法保存知识库，或者修改知识库时直接报Internal Server Error”，这个话题在社区里非常常见。我遇到过几次，原因大多出在配置迁移上。升级过程中，数据库表结构会变化，如果迁移脚本没有跑完整，知识库的元数据字段就会缺失，保存时后端抛500。另外，一些版本升级后，预设的Embedding模型配置或向量数据库连接信息会失效，导致写入失败。
排查步骤一般是这样：先看容器或应用的错误日志，确认是数据库报错还是向量库报错；再到PostgreSQL里确认所有迁移记录是否成功；接着检查Embedding模型配置，重新选择一次模型并保存；最后确认向量数据库版本是否与Dify兼容。如果升级前有备份，直接回滚是最快的方案。所以我的建议是：任何Dify升级前，先备份数据库和向量库索引，这个习惯能省掉大半麻烦。
5.2 检索质量变差时从哪里开始查
检索变差是个很模糊的症状。我的排查清单是这样排列的：先确认新文档是否成功完成索引，向量库里是否真的写入了对应片段；再检查查询是否被某层改写带偏，比如Agent写子问题时把关键词改了；接着验证Embedding模型是否一致，有没有某个环境还在用旧的向量；同时检查Metadata过滤条件是否过严，把候选文档过滤掉了；最后做AB对比，关掉混合检索只看向量召回，再切换成全文召回，判断是哪一路召回拖后腿。这个顺序能过滤掉八成问题。
提示：千万别一上来就怀疑模型不行。很多错误答案的根因是检索阶段根本没召回正确内容，后面再怎么调提示词也没用。
5.3 RAG测评怎么做：评测集、指标与回归
RAG测评不是拍脑袋看几个回答好不好。我建议这样攒基线：准备30到50条真实问题，每条对应正确答案和参考文档ID；问题要覆盖正常问题、模糊问题和无答案问题。指标上，关注召回率、命中率、忠实度（回答是否忠于召回片段）、答案正确率。手动评估太慢，可以用RAGAS这类评估框架跑，它利用LLM自动打分。我在实际项目中更看重“引用来源是否正确”：如果答案引用了错误的文档，说明检索路由出了问题，比内容正确还值得警惕。
维护一套评测集后，每次改分块、换模型、调提示词，都跑一遍回归，对比前后指标。这能帮你发现很多隐蔽问题。比如新增一个知识库之后，Agent开始串库回答，评测集马上能暴露出来。RAG测评方案不是一次性的，它需要跟着知识库内容一起迭代。
6. 面试常考题与下一步进阶
如果你正在准备AI Agent相关岗位的面试，或者想系统性学习RAG知识，这一章可以当作查漏补缺的清单。
6.1 高频RAG/Agent面试题速答
最常被问到的问题包括：RAG和微调怎么选？RAG流程包含哪些环节，chunk size怎么定？什么是混合检索，为什么需要Rerank？什么是Agentic RAG，与普通RAG的区别？如何评估一个RAG系统的好坏？知识库数据更新后如何保证一致性？怎么防止模型编造知识库没有的答案？
回答思路很简单：RAG解决知识时效和私域知识问题，轻量可回滚；微调解决特定风格或能力问题，成本高。chunk大小要看文档和模型，按语义块切分更合理。混合检索结合语义和关键词，Rerank对两路结果合并重排。Agentic RAG强调多轮规划和动态检索。评估要建评测集，覆盖召回和生成两端。更新用增量索引和metadata过滤。防幻觉靠严格限制回答依据和强制拒答。按这个框架去准备，已经能应付大多数面试。
面试官更愿意听你讲实际踩坑，比如检索调优、Dify升级故障、评测集回归，这些比背书有价值。如果你连一次真实的RAG项目经验都没有，强烈建议先用Dify跑一个个人知识库，把过程中的问题记录下来，面试时就是最好的素材。
6.2 进阶方向：Ontology RAG、SAG与本地笔记联动
再往深走，RAG有几个值得关注的方向。Ontology RAG是把领域本体或知识图谱引入检索过程，先根据实体关系确定检索路径，再返回结构化信息，适合实体密集、关系复杂的专业领域，比如医疗、法律、农业知识库。和普通RAG相比，它能减少实体混淆，提高多跳问题的准确率。SAG这类概念现在还没有统一标准，我理解核心方向是让生成模型对“自己知道什么、还缺什么”有感知，能主动补充检索、修正答案，这和Agentic RAG是相通的。
对个人知识管理来说，Obsidian搭配AI Agent是很舒服的入口。你本地的双链笔记可以通过MCP或插件暴露给Agent，Agent回答问题时动态读取相关笔记，相当于给自己建了一座越用越聪明的第二大脑。我现在的日常是：一边记笔记，一边用Agent查询自己的笔记库，很多以前记过但忘掉的想法，又能被重新捞出来用。
我真正把使用习惯固定下来，是在建好评测集之后。现在每新增一批文档，我会先跑一遍基线里几十个问题，对比引用命中率，确认没有把旧问题的答案带偏，才会放心开放给团队使用。这个习惯帮我避免了很多“看起来能用、用起来翻车”的情况。另外一个小技巧：在文档的metadata里写清楚来源和更新时间，Agent引用过期内容时能明显看出来。如果你正准备搭建类似知识库项目，我的建议是先用Dify或AnythingLLM快速跑通，再从一次检索失败开始调优，别追求一步到位的完美方案。
