生产级Agentic RAG落地指南：架构选型、检索优化与持续观测

1. 先泼一盆冷水：RAG Demo和生产线之间隔着一条河

过去这一年，我见过太多团队在同一个地方栽跟头：本地跑通了一个RAG问答demo，效果惊艳，老板看了很满意，结果一上生产环境，就各种卡顿、答非所问、响应慢，最后变成一个需要十几个提示词补丁硬撑的脆弱系统。搜索热词里那个"building for production卡住"，我太有共鸣了——这不是你一个人遇到的问题，这是Agentic RAG从实验走向落地时最普遍的阵痛。

先说清楚一个概念。传统RAG是一条固定流水线：用户提问，系统检索知识库，塞进提示词，让大模型生成答案。Agentic RAG则不一样，它把"决定权"交给了大模型——模型需要自己判断"这个问题要不要查资料""先查什么再查什么""查回来的结果矛盾怎么办""要不要再追问用户"。听起来很智能，但自由度越大，越容易翻车。打个比方，传统RAG像你去快餐店点一个固定套餐，Agentic RAG像是请了一位有主见的私厨，他不用你指挥，自己会去菜市场挑菜、搭配、试味，但你要是没交代清楚忌口，他可能端上一盘你不吃的东西。

这篇文章不聊理论到天边，就聊实际落地。我会按自己做项目的路径，拆解生产级Agentic RAG的关键决策点：Agent架构怎么搭、知识库怎么选型、检索质量怎么评估、延迟和成本怎么控制、上线之后怎么持续观测。适合正在做RAG项目、准备把实验系统推向生产环境、或者想从传统RAG升级到Agentic RAG的工程师、架构师和AI应用开发者参考。

2. Agentic RAG与传统RAG的分水岭：从固定管线到自主决策

2.1 固定流水线到底卡在哪里

传统RAG的流程是标准四步：query -> retrieve -> augment -> generate。在受控的评测集上，这个流程通常够用。但生产环境的用户问法非常野，你精心设置的"检索"环节会频繁失效。

举一个我实际遇到的案例。当时做一个设备运维知识问答系统，知识库里存了大量手册和故障处理记录。传统RAG流程下，用户问"设备A报警代码E002怎么处理"，系统检索到相关手册片段，生成答案，效果不错。但用户换了一个问法："设备A又报错了，代码跟上次一样，我这会儿人在现场，能不能先告诉我第一步该干嘛？" 这其实是在问故障处理步骤，而且隐含了"要按紧急程度排序"的意图。固定流水线完全无法处理这种问题，它只会把"设备A""报错""代码"这些词拿去做向量相似度检索，结果可能召回一堆设备参数表，根本答非所问。

再比如多跳问题："上个月采购的那批配件，它们的供应商哪几家是A类评级？" 这句话里有"上个月采购""配件""供应商评级"三个信息点，任何一个都没法靠单次检索并行解决。固定流水线没有"拆解问题再逐步检索"的能力，这是它最大的天花板。

2.2 Agent在工作循环里做什么

Agentic RAG把核心从"检索"转移到"决策"。一次完整的Agent工作循环通常是这样的：

1. 意图判断：用户提问先进入路由层，判断是闲聊、需要检索知识库、需要调用API，还是需要追问澄清。
2. 任务拆解：如果是一个复合问题，Agent会把它拆成多个子任务，决定先查哪个、后查哪个、哪些可以并行。
3. 工具调用：Agent输出一个结构化的调用请求，比如search_knowledge_base(query="设备A E002故障处理", top_k=5)，由框架执行检索并把结果返回给Agent。
4. 结果评估：Agent根据检索结果的置信度判断"够不够回答了"，不够就改写查询词，或者换一个工具，再查一轮。
5. 生成与收尾：确认信息充分后，综合多轮结果生成最终答案，并附上引用来源。

这个循环不是无限跑下去，必须设置"最大迭代次数"。我见过最离谱的配置是有人让Agent最多循环20次，结果一个简单问题烧了几万token，最后还死循环了。生产环境我习惯限制在3到5轮，超过就强制走兜底。

2.3 三个核心组件：路由、工具、记忆

生产级Agentic RAG能不能稳定，主要看这三个东西设计得好不好。

**路由（Routing）**是Agent的第一个决策点。它本质上是个分类器，把用户输入分到预设的路径里。实现方式有两种：一种是用一个小的、便宜的模型做意图分类；另一种是直接在主模型里给路由指令，让它自己选。第一种更可控、更好评测，我推荐生产环境用独立路由，不要什么都让大模型自由发挥。

**工具（Tools）**是Agent的可操作边界。每个工具必须有清晰的名字、描述和参数规范。这个描述特别关键——它不是给代码看的，是给大模型看的。大模型靠描述来判断"什么时候该调这个工具"。写工具描述有个铁律：讲清楚触发条件和不用它的情况。比如一个工具叫search_enterprise_policy，描述里要写"当用户询问公司制度、员工政策、报销流程时使用；如果是闲聊、计算、天气类问题不要使用"。我之前就是因为工具描述写得含糊，Agent经常在不该检索的时候检索，白白浪费延迟。

**记忆（Memory）**决定Agent能不能理解上下文。短期记忆就是对话历史，存最近几轮的用户消息和Agent回复，超过窗口就做摘要压缩。长期记忆通常指用户档案、偏好等跨会话信息，在第一次交互时提取并存储，后续会话直接读取。生产环境需要把记忆和向量检索解耦，不要把全部对话历史都塞进提示词，否则上下文一长，模型注意力漂移，答案质量明显下降。

3. 知识库工程才是真正的护城河：向量库、知识图谱与本体怎么选

3.1 三类知识形态对应三种存储方案

很多做RAG的人一开始就把所有东西一股脑扔进向量库，这是最大的误区。知识库选型不是看哪个技术时髦，而是看你的数据长什么样、要被怎么查询。

如果数据是大量非结构化文本——操作手册、会议纪要、技术博客、客服聊天记录——向量库是主力存储，靠embedding做语义相似度召回。但如果数据天然有强结构，比如一张包含订单号、客户ID、金额、时间的销售表，用向量库就非常笨拙。你问"上个月华东区销售额最高的五个客户是谁"，向量检索永远给不出准确数字，这种问题就适合走SQL查询。

如果数据是高度关联的实体关系——比如公司股权结构、药物相互作用、供应链上下游——知识图谱是更好的选择。图谱把实体建模成节点，把关系建模成边，可以支持多跳推理："A公司的实际控制人是否同时控股了B公司？"这种问题在纯向量库里近乎无解，但在图谱里就是一次两跳遍历。

我做一个对比表，方便你直接判断：

3.2 什么时候应该上知识图谱

我判断要不要上图谱，就看三个问题：用户会不会问多跳问题？答案需不需要强一致性？业务方有没有明确的实体关系定义？

如果三个答案都是"是"，图谱值得投入。举个例子，做企业合规问答，用户会问"K公司在我们最新版保密协议里的违约条款，是否覆盖了这家公司所有的子公司？"这需要沿着"公司-子公司-协议条款"的关系链做精确推理。纯向量检索会把"K公司""保密协议""违约条款"拆成词嵌入去匹配，即使召回了相关片段，也无法保证逻辑上扣得准。图谱方案是把协议、公司、条款作为实体，沿着[公司]-[适用]->[协议]-[包含]->[条款]的关系路径走一遍，答案的可解释性和一致性都强得多。

但图谱的代价是建模和维护成本高。你需要定义实体类型、关系类型、属性，还要设计从原始文档到图谱的抽取管线。小团队如果业务场景不需要强多跳推理，老实先把向量库做好。

3.3 Ontology RAG：给Agent一张关系地图

有个热词叫"ontology RAG"，就是基于本体论的RAG。本体论听起来玄乎，其实就是"事先定义好的概念体系和关系规则"。比如你做医疗问答，本体里定义："药物'可能引起'副作用'，'适应症'用于治疗'疾病'"。有了这张地图，Agent在回答问题的时候，不是大海捞针找文档，而是沿着已知的关系路径去定位知识。

我做过一个实验对比同一批医疗知识数据：纯向量RAG回答"这个药和那个药能不能一起吃"，经常把两段没有交集的说明文字拼在一起，产生看似合理实则错误的答案。换成ontology RAG之后，先确定两种药分别对应哪个本体节点，再查它们是否共享"相互作用"关系，准确率提升了快30个百分点。

选择建议是这样的：如果你的领域有相对固定的关系模式，比如医疗、金融、法律、制造，本体层非常值得做。要是电商客服这种开放域文本，本体反而会限制灵活性，向量库加一个重排模型更实在。

3.4 一个容易被问懵的问题：RAG知识库能存图片吗

搜索热词里有"rag知识库能存储图片嘛"，这个问题我几乎每隔两周就被问一次。直接回答：向量数据库本质上存的是向量，不是图片文件。图片可以通过多模态模型转成描述文本，再和文件路径一起进库。用户问图里的内容时，系统检索到描述文本，Agent可以引导用户查看原图，或者再调一次视觉模型做细粒度识别。

比如一份设备图纸，你让多模态模型把"型号、接口位置、关键参数"描述成一段结构化文本，和图纸URL一起存到向量库。用户问"这个设备的网络接口在哪个位置"，检索命中描述文本后返回给用户，同时附上图纸URL。这套方案在生产环境已经被验证过多次，成本远低于直接对图片做向量索引，效果又够用。别纠结图片往向量库里塞，要把"图片先文字化"当成一个预处理步骤。

4. 在Mac上从零搭一套可上生产的Agentic RAG：我的一套基础配置

4.1 环境准备与关键选型理由

讲完设计层面，给一套可以直接在Mac上复现的落地配置。我自己用的是Apple Silicon MacBook Pro，M系列芯片，内存建议至少16G，因为要同时跑本地模型和基础设施。

选型上我有明确的偏好，不跟风：

• 编程环境：Python 3.11 +uv管理依赖。uv比pip快太多，锁依赖也干净。
• 向量库：本地开发用Chroma，零配置、嵌入式；生产我用Qdrant，Docker一条命令起服务，支持过滤索引和内存模式，性能上限高。
• Embedding模型：本地用Ollama跑nomic-embed-text或者bge-m3，中文效果都还不错。做原型阶段就本地跑，别每次都调云端API，迭代速度快很多。
• 编排框架：LangGraph。它的StateGraph模型非常适合Agent循环——把每个步骤定义成节点，节点之间用边连接，可以精确控制"什么时候该检索、什么时候该生成"。
• 主模型：开发阶段用Ollama上的qwen2.5系列或llama3.1系列。上生产如果追求效果，换云端API，但开发期本地模型调试成本低太多。

安装基础依赖的命令很简单：

# 创建虚拟环境 uv venv source .venv/bin/activate # 安装核心包 uv pip install langgraph langchain-core langchain-qdrant chromadb ollama python-dotenv

4.2 数据摄取管线：怎么切分文档最合理

这一步决定了后面所有检索质量的上限。我的经验是不要用定长token切分，要先按文档结构切，再处理长块。Markdown的标题、PDF的章节、表格的边界，这些都是天然语义单元。先按二级标题切，如果切出来的块还超过800 token，再往下切，并且保留一个和相邻块重叠的窗口，重叠量控制在15%以内。重叠的目的是防止语义在切口处被截断，但重叠太大会导致检索重复结果膨胀。

另一个很多人忽略的点是元数据设计。每条向量不仅要存text和embedding，还要存document_id、section_title、page_number、source_url、last_updated。生产环境里"按部门过滤""按日期过滤""按文档类型过滤"的需求太常见了，没有元数据，你只能靠向量距离硬扛，效果很差。

摄取管线的伪代码骨架：

from langchain_community.document_loaders import TextLoader from langchain_text_splitters import MarkdownHeaderTextSplitter from langchain_qdrant import QdrantVectorStore from langchain_ollama import OllamaEmbeddings loader = TextLoader("./docs/operations_manual.md") doc = loader.load() splitter = MarkdownHeaderTextSplitter( headers_to_split_on=[("#", "H1"), ("##", "H2")], ) chunks = splitter.split_text(doc[0].page_content) store = QdrantVectorStore.from_documents( chunks, embedding=OllamaEmbeddings(model="bge-m3"), path="./local_qdrant", collection_name="articles", )

4.3 Agent编排层：用LangGraph搭最小闭环

接着是Agent层。我搭的最小的可用闭环包含五个节点：route（路由意图）、rewrite（改写查询）、retrieve（并行检索）、grade（评估检索结果是否可用）、generate（生成最终答案）。节点之间的边有条件判断，这比单纯往前跑的DAG更能体现"Agentic"。

一个大致的代码骨架，帮助你理解结构：

from langgraph.graph import StateGraph, END from typing import TypedDict, List class AgentState(TypedDict): query: str rewritten_query: str documents: List[str] answer: str iterations: int graph = StateGraph(AgentState) # 节点定义 graph.add_node("route", route_node) graph.add_node("rewrite", rewrite_node) graph.add_node("retrieve", retrieve_node) graph.add_node("grade", grade_node) graph.add_node("generate", generate_node) # 入口从路由开始 graph.set_entry_point("route") # 路由节点后：需要检索去rewrite，纯闲聊去generate graph.add_conditional_edges( "route", decide_after_route, {"need_search": "rewrite", "no_search": "generate"} ) # 检索结束后评估是否够用 graph.add_conditional_edges( "retrieve", should_continue, {"grade_pass": "generate", "grade_fail": "rewrite", "max_iter": END} ) graph.add_edge("rewrite", "retrieve") graph.add_edge("generate", END)

这里最核心的是grade节点，它是一个小的LLM调用，让模型自己判断"这些检索片段能否充分回答用户问题"。可以用一个很小的模型比如qwen2.5:3b，成本很低。这一步是防止Agent在错误的方向上反复检索最后答非所问的关键闸门。

4.4 为什么我这样选型

选LangGraph而不是LangChain的AgentExecutor，是因为LangGraph把状态流转显式化了。生产环境里你必须要能回答"这个Agent上次走到哪一步""为什么它调了这个工具"，显式状态图让调试和日志追踪都变得容易。LangChain的AgentExecutor更像是黑盒循环，出了问题很难定位。

选Qdrant而不是Chroma上生产，是因为Qdrant有真正的过滤机制——你可以用元数据预过滤，比如"只搜最近30天的文档""只搜权限内的文档"。Chroma在小规模场景很爽，但数据量过百万向量，并发查询一多，性能和稳定性差距就出来了。

选独立路由节点而不是让主模型自己判断，是为了可评估性。路由是Agent系统里最底层的一环，如果连路由都依赖主模型临时发挥，整个系统的稳定性就悬了。独立路由节点可以用一个小模型精调，也可以直接用提示词约束，至少每次行为是可复现的。

5. 上线前必须过的三道坎：检索质量、延迟、成本

5.1 检索质量的坑：不是检索越多越好

我做过的生产项目里，最隐蔽的质量问题不是"检索不到"，而是"检索到的东西看着相关，实则是噪音"。这跟分块质量、embedding模型、重排策略都有关系。

分块太小的典型问题是语义碎片化。比如一份设备手册里，"严禁在通电状态下插拔模块"这句话如果被单独切成一个块，检索"维护安全注意事项"时可能召回它，但上下文缺失导致模型无法合理使用。分块太大则引入过多噪音，一条块里混杂了三四个话题，模型容易被干扰。

embedding模型的选择也直接影响效果。通用英文模型处理中文法律文书、中文技术文档，效果衰减非常明显。我踩过的坑是用一个以英文为主的模型去做中文客服问答，查出来的结果谁都看不懂，换成中文优化过的bge-m3之后才正常。这个变量平常不容易被重视，但它影响的是所有检索的底层质量。

重排（rerank）是检索链条里性价比最高的一个环节。先让向量检索召回Top 20候选，再用cross-encoder逐对计算查询和文档的相关性分数，取Top 5进上下文。虽然多了一次模型推理，但最终质量提升明显。实测下来，有一个重排环节的系统比没有重排的系统，用户满意度评分高出大概15%。

5.2 延迟的坑：Agent的自主性会放大单点延迟

很多人接受单次RAG延迟300到500毫秒，但Agentic RAG不一样——它可能要检索两三轮，每轮还要重排，累积起来直接飙到两三秒，用户等得起才怪。

控制延迟我优先做三件事。第一，并行化工具调用。如果一个问题要查资料和查实时数据，两个工具调用互相独立，就同时发出去，别串行等。LangGraph天然支持多个节点并行执行。第二，热点查询缓存。用户提问的分布其实高度集中，80%的请求集中在20%的常见问题上。对这类查询，把Agent生成的答案缓存起来，命中缓存直接返回，省掉整个Agent循环。第三，限制重排规模。不是所有查询都值得做Top 20重排，简单、低风险的问题直接Top 5进上下文，跳过重排节点。用一个小的判断器决定，延迟能降一大截。

5.3 成本的坑：Agent是token消耗放大器

Agent循环每多走一步，就意味着多一次模型调用。你精心设计的各种中间节点，都在烧token。我见过一个团队，一个简单的"查资料"问题居然触发了一套完整Agent流程，单次查询成本堪比写一篇长文。

成本控制要从设计上开始。第一，路由层尽量用便宜小模型。第二，避免所有工具结果都全文进入上下文。检索到的文档可以做一步"压缩"——让一个LLM提取最相关信息，只保留精华部分传给主模型。这样上下文短了，主模型的输出质量反而可能更高，因为噪音少了。第三，在grade节点确认信息充足之后，立即截断后续检索，不要把整个循环跑完。这里我特别强调一句，成本问题不是上线后出了问题再优化，而是在业务指标里就要定义"单次对话的预算上限"，一旦超了就强制结束，走兜底话术。

5.4 一个完整的排查链路案例

遇到"Agent答非所问"这个问题，不要一上来就调整提示词，按这个链路排查：

1. 先看日志里的路由结果——用户的查询被路由到了哪条路径？如果该走检索却走到了闲聊，问题在路由节点。
2. 看检索的召回内容——把检索返回的Top 5片段打出来，人眼判断这些片段是否跟问题相关。如果不相关，检查分块策略和embedding模型。
3. 看重排后的排序——如果召回内容里面有正确答案，但重排后位置靠后被截断了，问题在重排模型或Top K设置。
4. 看生成前的最终上下文——如果召回和重排都没问题，但生成的答案仍然跑偏，那是主模型的指令遵循出了问题，这时才去调提示词。
5. 最后看是不是记忆污染——多轮对话场景，之前的上下文里可能有误导性信息，导致Agent本轮判断失效。这时要检查记忆摘要策略和无关对话的过滤逻辑。

这个链路我至少用了十几次，每次都快速定位了根因。它背后的逻辑就是：Agent系统是一层层流水线，哪一层出问题都会在最终结果上呈现，但表现往往一样——都是"答错了"。排查时必须逐层确认，而不能靠猜。

6. 发布是起点不是终点：灰度、兜底与持续观测

6.1 灰度发布：不要把所有流量一次性交给Agent

Agent系统的不确定性是它和传统软件最大的区别。传统服务你可以通过单元测试保证基本正确性，Agent系统的行为是概率性的，同样的输入今天答得好明天可能答偏了。所以上线策略必须保守。

我的做法是分三层灰度。第一层，只放5%流量给真实用户，把Agent的回答和线上原有系统的回答同时展示，但Agent的回答不直接暴露——用一个评测模型给两侧答案打分，积累几百条对比数据。第二层，如果Agent的胜率超过一个阈值，比如60%，把流量提升到30%，并开始收集用户显式反馈。第三层，确认稳定后放量到100%。整个过程大概需要一到两周，但能规避很多灾难性事故。

6.2 兜底策略：Agent也有不会的时候

不管系统做得多好，总有Agent回答不了的问题。生产级系统必须有明确的兜底，而不是让Agent硬编。我的兜底分三级：

• 检索结果置信度低于阈值：直接回复"我没有在知识库中找到足够相关的资料"，不强行作答，同时引导用户换个说法或者联系人工。
• Agent多轮循环后仍未找到答案：触发人工客服转接流程，把检索到的部分相关信息一起附上，方便人工接手。
• 用户情绪负面识别：当用户明确表达不满或者问题超范围时，立即终止Agent循环，转人工。这个在前置路由里加一个情绪分类节点就能做。

我见过最糟糕的做法是Agent每次都说"我还在思考中，请稍等"，让用户等了好几轮最后给一个错答案。兜底不是示弱，是对系统能力边界的清醒认识。

6.3 持续观测：不只看业务指标，要看过程指标

上线之后观测什么？很多人只看"回答采纳率""用户满意度"，这些指标太滞后，问题发生后的反馈周期太长。我更看过程指标：路由准确率、检索召回率、重排命中率、Agent平均迭代轮数、单次对话平均延迟和成本。

这些过程指标能帮你及早发现退化。比如某个大模型版本升级后，Agent的检索调用频率突然下降，真实原因是新版模型越来越"自信"，不检索就编答案。如果不看过程指标，只盯着最终满意度，可能要过好几天用户大量流失后才反应过来。

日志里还要记录每一步Agent的行为轨迹——路由选择、工具调用参数、检索结果摘要、评分结果、最终决策。有了这套调用链，每一次线上事故都能回放复盘。这套可观测性体系，才是"生产级"和"demo级"最本质的差别。

我个人在实际项目中最深的体会是：Agentic RAG真正困难的地方，不在于把Agent循环跑通，而在于让你能解释清楚Agent每一步为什么这么做。只要做到这一点，前面所有的坑都只是工作量问题——检索质量差就去调分块和模型，延迟高就去加缓存和并行，成本高就去压缩上下文和控迭代。把这些环节一点点打磨扎实，系统自然就立住了。