别再跟我提"Demo 跑通"这种话了。如果你正在做 RAG，并且已经意识到单次"检索-生成"根本扛不住真实业务的复杂指令，那你应该对 Agentic RAG 这个名字不陌生。我过去半年把三个 RAG 项目从原型拖进了生产环境，最大的体会是：凡是把 agentic RAG 当作"魔法补丁"的团队，基本都在上线后一个月内开始返工；凡是把它当作"一套需要重新设计的系统"的团队，反而走得稳。这篇文章不聊 PPT 架构图，只聊我在 production 环境里实际跑过的 agentic RAG 设计、拆解过的瓶颈、以及踩过的坑。适合已经跑通过基础 RAG、正打算引入 Agent 编排的开发者，也适合刚接手知识库项目、想知道该不该上知识图谱的同学。
1. 从"检索增强"到"推理增强"：Agentic RAG 到底解决了什么问题
1.1 传统 RAG 的隐形天花板
传统 RAG 的流程大家都很熟：用户提问，系统把问题向量化，从向量数据库里召回 Top-K 相关片段，拼进 prompt，交给大模型生成答案。这个流程在文档质量高、问题类型单一的场景下表现不错，但一旦进入生产，你会遇到三类用户根本不会同情你的问题。
第一类是"多跳问题"。比如用户问"我们上季度营收增长最快的产品线，它的负责人是谁？"这个问题的答案分散在三份文档里：一份是季度财报，一份是组织架构调整通知。单次检索最多只能命中其中一个片段，大模型拿到不完整信息，只能硬编。第二类是"带约束的问题"。用户说"不要用 2023 年之前的数据，也不要考虑已经停产的SKU"，传统 RAG 的检索器根本不理解这个约束，照旧把过期文档捞上来。第三类是"需要对比分析的问题"。用户拿两份合同让你找差异，传统流程需要先定位两份文档，再逐条比，这不是一次向量检索能完成的。
这些问题的共性是：单次"检索-生成"循环表达能力不够。传统的做法是通过更复杂的 prompt 硬撑，或者把检索到的更多片段一次性塞进去，但前者不稳定，后者不但成本高，而且超过上下文窗口后反而引入噪声。本质上，传统 RAG 是一个"开环"系统——检索完就生成，没有校验，没有反馈，错了就错了。
1.2 Agentic RAG：把"一次问答"变成"多步工作流"
Agentic RAG 的核心变化，是给 RAG 加上了推理、规划、决策和验证的循环。它不再是一次检索就收工，而是把用户问题拆解成子任务，按需调用不同的工具（向量检索、知识图谱查询、SQL 查询、外部 API），每拿到一步结果，先判断信息够不够、冲不冲突，再决定是继续检索还是直接回答。
我用一个实际例子说明。用户的问题是"对比 A 和 B 两份合同在付款条款上的差异，并指出对我方不利的地方"。在 Agentic RAG 架构下，系统首先规划出三个子任务：定位合同 A、定位合同 B、提取并比对付款条款。然后它调用检索工具分别找到两段文本，再交给大模型做结构化对比。如果比对过程中发现某段原文缺失或模糊，Agent 会主动发起补充检索，而不是硬着头皮生成。
这个"主动补充检索"的能力就是关键。传统 RAG 是被动的，用户给什么就答什么；Agentic RAG 是主动的，系统自己评估当前信息是否充分，再决定下一步动作。这个动作可能是一次新的检索，可能是一个知识图谱查询，也可能只是向用户确认意图。
1.3 哪些场景真正需要 Agentic RAG
不是所有场景都值得上 Agentic RAG。我在实际项目中总结过一个判断清单：
- 问题是否天然多跳？如果 80% 的问题都能靠单次检索命中，那你需要的不是 Agentic RAG，而是更好的分块和 embedding 调优。
- 是否涉及多个异构数据源？比如同时要查文档库、数据库、API 接口，这类场景适合用 Agent 做统一的路由和调度。
- 是否需要多轮交互澄清？如果用户的问题常常信息不全，Agent 可以通过反问来补全信息，这是传统 RAG 做不到的。
- 答案的准确率要求有多高？如果错误答案会造成严重业务影响，那 Agent 的验证和纠错环节就是刚需。
我的建议是：先用普通 RAG 跑通基线，把能优化的问题都优化一遍（分块策略、embedding 模型、重排序），发现仍有 15%-20% 的难题解不掉，再引入 Agentic 编排。直接一上来就做 Agentic RAG，等于在没学会走之前先学跑，后面排查问题会非常痛苦。
2. 核心设计思路拆解：Agent 如何"会查资料、会判断、会兜底"
2.1 检索策略：从"单路召回"到"多路融合"
Agentic RAG 的检索层和传统 RAG 有个本质区别：它不是一次检索就把所有希望寄托在上面，而是每次检索都带着明确的任务目标。我在生产项目里的做法是设计一个"多路召回 + 重排"的检索策略。
多路召回一般包含三路：关键词检索（BM25），向量检索（Embedding），如果接入了知识图谱，还有图谱查询。BM25 保证精确匹配，向量检索保证语义泛化，图谱查询保证关系推理。三路结果拿回来后，用一个重排模型（cross-encoder）做融合。我测试下来，这个策略对比单纯向量检索，在真实业务数据上的 Recall@10 能提升 12-18 个百分点。
但多路召回也带来一个头疼的问题：延迟。三路查询如果串行跑，一次检索就是三次响应时间。我的优化方案是使用并行调用（asyncio.gather），同时发起三路查询，取最慢的一路作为总延迟基准。实测下来，在单路 200ms 的典型耗时下，并行多路召回的总延迟可以控制在 280-350ms，几乎和单路向量检索差不多，但召回质量提升明显。
2.2 路由与工具调用：别让 Agent 瞎拿锤子
Agentic RAG 里最容易被忽视的是路由器（Router）。路由器决定了一个问题该走哪条工具链——是直接向量检索，还是先做 SQL 查询，还是调外部 API，还是干脆不需要检索，大模型直接回答（比如闲聊类问题）。
我在生产环境踩过一次大坑：最初我用一个大模型 prompt 同时做路由和回答，结果复杂问题来了，模型经常"图省事"，只做一次向量检索就急着回答，导致答案质量大幅下降。后来我把路由独立出来，成了一个专门的小模型任务——一个参数只有 70 亿的模型，专门用来做意图分类和工具选择，效果反而比大模型混合路由稳定得多。
关于工具设计，我给一个建议：工具的粒度要"中等"。工具太粗（比如只提供一个"搜索全部资料"），Agent 无法精细控制；工具太细（比如提供 20 个细分类别的检索工具），Agent 的决策空间太大，容易选错。我最终收敛到 4-6 个工具，比如"检索产品文档""检索合同条款""查询数据库指标""获取实时价格"，每个工具的 description 写清楚它擅长什么、不擅长什么。这个 description 比工具本身还重要，因为大模型是靠 description 来选工具的。
2.3 推理循环与控制：设置刹车，别让 Agent 无限跑
Agentic RAG 引入了一个传统 RAG 没有的问题：你的 Agent 可能陷入死循环。比如它反复检索同一份文档，或者在一个问题上无限细化，每次都生成"再查一下"的结论。这不仅浪费 token，更糟糕的是会把延迟拖到用户无法忍受。
我给生产环境设定的控制参数是：最大迭代步数 5 步。每步到达后，系统会做一个"信息充分度判断"——把当前所有检索到的上下文拿到大模型那里，让它判断这些信息是否足以回答用户问题，输出 yes/no。如果 yes，停止循环进入生成阶段；如果 no，才继续下一步检索。为什么要设 5 步？因为我在离线评测里统计过，95% 的测试问题都能在 3 步内解决，5 步是留的缓冲。超过 5 步的问题，大多数是检索策略不对，靠无限循环解决不了。
另外，每个 Agent 循环步都有一个"证据覆盖检查"：检查当前答案的每一个陈述点，是否对应上了某段检索到的原文。如果某个陈述点找不到原文支撑，就标记为"unverified"并要求 Agent 补充检索。这个检查就像一个工程质量检查员，能够显著降低幻觉比例。
2.4 记忆与上下文管理：别把上下文窗口当仓库
Agentic RAG 每多跑一步，就会多产生一些中间结果。如果不加管理，几轮迭代下来上下文里全塞满了检索片段，到最后一步，真正重要的信息可能只占很小一部分。
我的做法是引入"上下文压缩器"（context compressor）。每一轮检索完，所有新检索到的片段不是直接追加到对话历史里，而是经过一个压缩步骤：把可能相关的关键句提取出来，去掉无关部分，只保留与当前任务相关的 2-3 个片段。压缩器本身可以用一个小模型，或者复用路由器的模型。实测这个做法能把最终生成阶段的上下文缩减 60% 以上，而且答案质量不降反升——因为噪声少了。
另外一个经验是关于"长期记忆"与"短期记忆"的区分。短期记忆是当前任务的查询历史和中间结果，长期记忆可以是用户的历史偏好或项目级知识库。Agentic RAG 生产系统应该把这两者分开存储，否则长期记忆的噪声会影响短期任务的判断。我在项目里用的是向量库存长期偏好，用 Redis 存短期会话状态，两者不混用。
3. 生产环境实战：从 Demo 到线上系统的关键一跃
3.1 延迟预算与异步架构设计
Agentic 四步循环，每步涉及一次 LLM 调用 + 一次检索，叠加起来最坏情况可能超过 15 秒。用户根本等不了。生产环境必须做延迟预算管理。
我的经验是按照"用户预期"把延迟分成三档：简单问题需要 2 秒内回答，中等问题 5 秒内，复杂问题可以接受 10 秒但要有流式输出兜底。为此，我在路由阶段就根据意图打了"复杂度预估"标签，不同复杂度走不同策略：简单问题直接走单次检索，不做循环；中等问题最多跑 2 步；复杂问题才允许完整的 5 步循环。
另一个关键技术是流式输出。Agent 在执行循环时，前端可以先把"正在检索合同一……正在比对条款……"这样的事件流推给用户。用户看到的不是一片空白，而是 Agent 的工作过程。体感上，就算总延迟 8 秒，有流式中间态也比什么都没看到等 5 秒强得多。这个实现不算复杂，本质是后端从 REST 换成 WebSocket 或 SSE，把 Agent 的每一步状态作为事件推送。
3.2 评测体系：没有指标，别谈上线
生产环境的 Agentic RAG 必须做评测。但评测维度和传统 RAG 不太一样，我把它拆成三层指标。
第一层是检索指标：Recall@K、MRR。第二层是生成指标：答案的忠实度（faithfulness，找出答案中哪些陈述没有得到原文支持）、答案完整性（completeness，对比参考答案检查是否漏掉了关键点）、答案有用性（helpfulness，人工标注或 LLM-as-judge 打分）。第三层是流程指标：平均迭代步数、工具调用成功率、死循环率、超时率。
这里我想提一个坑。最初我们用 LLM-as-judge 做生成质量打分，结果得分虚高——大模型给同为大模型的回答"手下留情"。后来我们引入了参考标准答案，用 RAGAS 框架的忠实度指标做自动化评测，再配合每个月人工抽检 100 条，才得到真实的质量数据。建议所有做 agentic RAG 的团队，至少搭一个 200 条以上的回归测试集，每次改动知识库或 prompt 后跑一遍全量回归，防止"按下葫芦浮起瓢"。
3.3 性能优化：缓存、并发与资源控制
Agentic RAG 的生产成本是普通 RAG 的 3-5 倍。一个查询可能产生 8-10 次大模型调用，如果遇到恶意刷接口，账单直接起飞。我的第一道防线是缓存。对检索结果做语义缓存：如果用户的新问题和某个历史问题的 embedding 相似度超过 0.92，可以直接复用当时的回答。实测下来这类重复问题的命中率在 10%-20% 之间，能省不少 token。
第二道防线是并发控制。Agent 的每一步都可能调 LLM，而 LLM 接口有 QPS 限制。我用的是令牌桶算法做限流，每个用户的并发 Agent 执行数不超过 2，全局并发不超过 20。超出限制直接排队，而不是让用户无限等下去。第三道防线是成本告警。对每个 Agent 循环的 token 消耗做追踪，当单次查询的 token 数超过预设阈值（比如 5000）时，自动降级为"精简模式"——跳过压缩器，缩短最大步数，甚至直接走单次 RAG 兜底，保证用户能拿到答案而不是吞掉一个超贵账单。
3.4 Embedding 与知识库运维：上线之后才是开始
很多团队的 RAG 项目死在"上线后没人管"。文档更新了、旧版本内容变了，但向量库里的 embedding 还是旧的。用户问的都是新内容，检索出来的全是旧片段。对这个问题，我现在的运维标配是"定时重建+增量更新"两条腿走路：对于新增文档，走增量管道做 embedding 入库；对于大规模改版（比如季度文档整体更新），每月做一次全量重建。同时给每个 embedding 打上版本号，知识库的每条记录都记录是哪个 embedding 模型生成的。这样模型升级时能精确找出需要重新 embedding 的记录，而不是盲目全量重建，省下大量算力。
Mac 本地搭建时，同样的思路也适用。我有段时间在 MacBook Pro 上直接跑知识库测试，用 Ollama 跑 embedding 模型（比如 nomic-embed-text）加 SQLite-VSS 做向量存储，几百条测试文档完全跑得动。所以如果你只是验证 RAG 逻辑，先在 Mac 本地用小规模数据把链路跑通，再上云扩展，这比一上来就搭分布式向量库要务实得多。
4. 知识库选型：RAG、知识图谱与结构化知识库到底怎么选
4.1 RAG 知识库：最适合非结构化文本的默认选择
项目里最常被问到的一个问题：RAG 知识库到底能存图片吗？答案是——能，但不是你以为的那种存法。向量库存图片的思路是"图生文"：先让一个多模态模型把图片转成文本描述（caption），再把这个描述文本 embedding 入库。查询时用户用自然语言检索，命中文本描述，再把原图返回给用户展示。这种方案的优点是实现简单，缺点是精度受限于模型对图片的理解能力。如果你的场景是"按内容搜图片"，这个方式基本够用；但如果你要按像素特征搜图（比如找相似 logo），那就该用真正的多模态 embedding 模型了，比如 CLIP 这类模型直接对图片和文本做联合向量化。做 RAG 知识库时，文档类（PDF、Word、网页）永远是主力，图片和音频只能算"附件型知识"。
4.2 知识图谱（KG）知识库：多跳关系的救星
知识图谱和 RAG 的区别在哪里？一句话：RAG 是"找一段话"，KG 是"找一条关系路径"。当你的业务问题集中在关系推理上，比如"某供应商还给我们哪些项目供过货""两个部门之间有哪个项目重叠""这个异常指标是否和近期的组织调整有关"，RAG 往往会因为信息分散而答得模模糊糊，而知识图谱可以直接沿着关系边做多跳查询，给出精确路径。
但知识图谱有个生产环境的大坑：构建和维护成本极高。你需要从非结构化文档里抽取实体和关系，做实体对齐（解决"张三"和"张总"是同一个人的问题）、做关系消歧、设计本体（ontology）。我在项目里给客户做过一个供应商关系图谱，光实体抽取和清洗就跑了两周，后续每次新文档进来还要跑增量抽取和冲突检测。
我的建议是：RAG 和 KG 不是替代关系，而是配合关系。当问题是一个"纯文本理解"型问题（比如合同条款的含义），走 RAG；当问题是一个"关系查询"型问题（比如组织架构里的汇报关系），走 KG。在 Agent 的工具列表里同时挂上这两个工具，让路由器决定调用哪个。这个方案业内有个名字叫 GraphRAG，本质就是"非结构化文档做索引 + 结构化关系做推理"的混合架构。
4.3 结构化知识库：为什么我还是留了一张 SQL 表
这里要提醒一件事：不要什么知识都往向量库里塞。我看到太多团队把业务数据库里的表格数据（比如销售明细、库存数量）也做 embedding 进 RAG，然后让大模型做计算。先不说计算的准确性没有保障，单是"哪个月销量最高"这类问题，向量检索根本不适合——它适合文本相似度，不适合数值聚合。
正确的做法是：能查结构化数据库的，直接让 Agent 生成 SQL 查询。我的工具列表里始终保留一个"数据库查询"工具，Agent 根据用户问题生成 SQL，执行后把结果集交给大模型做总结。实测这个方案查"上季度销量 Top3 的产品"这类问题的准确率接近 100%，而走向量检索的方案正确率只有 60% 左右，还得靠大模型硬算。所以分清楚场景：精确查询走 SQL，非结构化理解走 RAG，关系路径走 KG。三者通过 Agent 统一编排，才是一个生产级系统该有的形态。
4.4 本体（Ontology）设计：给知识图谱套上"骨架"
知识图谱里的本体设计，很容易被忽略但很关键。ontology 其实就是知识图谱的"类型系统"——规定有哪些实体类型（人、组织、产品、项目）、哪些关系类型（属于、负责、参与、供应），以及每种关系连接哪些实体类型。没有 ontology，知识图谱就是一团乱麻；用 ontology 约束，知识图谱才能稳定成长。
一个实用的最小化 ontology 设计案例：供应商项目场景可以用四类实体（供应商、项目、产品、区域）、五种关系（供应商供应产品、项目使用产品、项目归属区域、供应商负责区域、产品属于产品线）。就这么简单的本体，配合 LLM 从文档中抽取，知识图谱就能回答"某区域下用到的所有产品有哪些供应商"这类问题。
Agent 与知识图谱的交互方式我用了两种。一种是先让 Agent 把自然语言问题转成图谱查询语句（比如 Cypher 查询），直接查询。另一种是把图谱的 schema 描述给大模型，大模型根据 schema 自己决定怎么遍历。前者精确但依赖转换质量，后者灵活但容易跑偏。生产我推荐前一种为主，加上 schema 描述作为 Agent 的上下文，让转换质量更高一些。
5. 常见问题排查实录与避坑清单
5.1 检索召回率低：多半不是模型问题，是切分问题
如果你发现检索出来的片段和问题有关系但不精准，八成问题出在 chunk 切分上。我在项目里的经验是，chunk 切分必须考虑文档结构，而不是按固定字数硬切。对于合同类文档，按条数和章节切；对于技术文档，按标题层级切；对于 FAQ，按问答对切。
另一个容易被忽视的是元数据。给每个 chunk 打上文档来源、章节标题、页码、更新时间等元数据，检索时就可以做前置过滤。举个例子：用户查 2024 年的政策，检索时直接通过元数据过滤掉 2023 年的 chunk，比纯靠语义匹配精准得多。这类以metadata 为主的过滤，比多塞几个 chunk 更好用，既省钱又提升精度。
5.2 幻觉控制不住：引入引用溯源和忠实度检查
关于幻觉控制，我会坦诚我试过很多土办法都不算太理想。如果你用的是普通 RAG，幻觉的发生是因为大模型生成时带着上下文不自觉"补充细节"。在 Agentic 循环里，我们可以多做两个动作：生成前要求模型"只根据检索到的内容作答，禁止引入外部知识的表述"；生成后用忠实度检查模型（用一个独立小模型，对比生成答案中每个陈述和检索片段的匹配度）自动重查一遍。这两招能显著压低幻觉率，但没法归零。若业务要求"零幻觉"，恐怕只能在工具设计上做硬约束，比如要求以原文引用为主、把需要推理的部分交给确定性代码而不是模型拿主意。
5.3 Mac 本地搭建 RAG 知识库的神坑与捷径
很多同学在 Mac 上搭建 RAG 知识库，卡住的通常不是思路，而是环境细节。这里分享几个我试出来的贴合 Mac 的要点：embedding 模型建议选小一点的，比如 nomic-embed-text 或 bge-small，我的 MacBook Air 实测跑几百个文档毫无压力。向量库先用 SQLite-VSS 或 Chroma 就能起步，别一上来就上 Milvus 这类重组件。
另外一个 Mac 特有问题：有些原生库（比如某些分词器）在 arm64 架构下编译很慢甚至失败。我的建议是尽量用 Python 3.10+ 的预编译 wheel，避免从源码编译。实测这样能把"搭环境"时间从一晚上缩短到半小时。还有一点，Mac 上跑本地 LLM（Ollama）做生成，速度和 API 差距很大，建议 Mac 上验证逻辑，生产还是得用 GPU 推理。
5.4 效果不稳定：Agentic RAG 的"薛定谔"问题
你可能会发现，同一个问题跑十次，五次答案很好，五次非常差。这种不稳定大多数时候源自 LLM 的随机性。我的对策是把大模型的 temperature 降到 0.1 以下，特别是做工具选择和路由的模型，直接设 0。另外，prompt 里的工具描述必须写得非常明确，不能让模型"自由发挥"。如果你发现某些问题经常走错工具，就去检查工具 description 是不是有歧义。
还有一个团队容易犯的错：Agentic RAG 上线后还要持续维护 prompt。每周用真实用户 query 跑一遍评测集，看看路由准确率有没有下降。LLM 服务提供商更新模型后，哪怕版本号不变，行为也可能漂移。如果不做持续评测，你很难发现"为什么这周答案突然变差了"。
5.5 我最后悔的一次架构决策
最后分享一个真实教训：我曾在一个项目里把"用户是否满意当前答案"的判断完全交给大模型自己，没加任何规则兜底。结果 Agent 非常自信地回答了错误答案，而且因为"信息充分度判断"给了 yes，循环直接终止，用户拿到一个漂亮但错误的结论。后来我加了一条硬规则：凡是涉及数字、日期、金额的答案，必须经过一层"确定性校验"——用正则或代码把关键数值抽取出来，和原文片段比对，不一致就强制进入补充检索环节。
这个经历让我意识到，Agentic RAG 的生产质量，不是靠模型自觉，而是靠"模型做决策、代码兜底线"这套组合。现在的架构里，凡是能写进代码的硬逻辑（格式校验、数值比对、超时控制）我绝不丢给模型；模型只做它擅长的事——语义理解、意图判断、文本生成。基于这个原则重构之后，系统的稳定性提升非常明显，我建议每个做 Agent 应用的团队都把这条写在架构原则里。
