RAG + Agent：下一代 AI 应用架构

上周有个朋友找我吐槽。他们公司花三个月搭的 RAG 系统，上线第一周就被老板点名批评——“这玩意儿怎么连个简单的差旅报销问题都答不对？”

说实话，这种情况我见得多了。传统 RAG 就像那种只会查字典的学生，你问什么它就翻什么，完全不会思考问题背后的意图。用户问”我上个月的差旅报销被拒了，原因是什么”，传统 RAG 可能会检索出一堆差旅政策文档，却根本不知道先去查用户的具体报销记录。

这就是 Agentic RAG 想要解决的问题。

这篇文章里，我想和你聊聊 RAG + Agent 融合架构——这套正在重塑企业 AI 应用的技术方案。我们会从架构演进讲到框架选型，再落到具体的实施路线。对了，我还会分享一个智能客服的实战案例，希望能给你一些启发。

从传统 RAG 到 Agentic RAG：架构演进

传统 RAG 的工作原理其实很简单：用户提问 → 向量检索 → 取回相关文档 → 扔给 LLM 生成答案。三步走，完事。

这套架构的优点很明显：快、便宜、容易实现。但问题也跟着来了。

检索不准。用户问个模糊问题，向量相似度检索可能找出一堆”看起来像但其实不相关”的文档。比如问”怎么配置数据库连接”，检索结果可能混了 MySQL 和 PostgreSQL 的文档，用户还得自己分辨。

不会推理。传统 RAG 只会做”检索-生成”这个动作，遇到需要多步骤的问题就傻眼了。你要是问”对比一下方案A和方案B的优缺点”，它可能只检索到其中一个方案的文档，然后一本正经地胡说八道。

"McKinsey 调研显示：47% 的 GenAI 用户经历过负面后果，只有 27% 的用户会审查所有输出"

Agentic RAG 带来的改变

Agentic RAG 的核心思路是：让 AI 主动”思考”怎么解决问题，而不是机械地执行检索-生成。

它的核心循环是这样的：

Plan → Retrieve → Act → Reflect → Answer

我来逐个解释：

Plan（规划）：先分析用户问题，拆解成子任务。“我上个月的差旅报销被拒了”这个问题，可以拆成：查用户的报销记录、查差旅政策、对比分析拒签原因。

Retrieve（检索）：根据规划，决定去哪里检索、检索什么。可能需要同时查知识库、数据库、甚至调用外部 API。

Act（行动）：执行检索，调用工具，获取信息。这个阶段可能会发现新问题，需要再次规划。

Reflect（反思）：评估检索结果是否充分，答案是否合理。如果不够好，可能要回到 Plan 阶段重新来过。

Answer（回答）：最终生成答案，附带引用来源。

说白了，传统 RAG 就像查字典，Agentic RAG 就像有个研究助手——它会帮你分析问题、查资料、核对信息，然后给你一个靠谱的答案。

这个数据背后，是企业对 AI 能力的期待正在从”能用”升级到”好用”。Agentic RAG，正是这个升级的关键一步。

10 种 RAG 架构模式详解

这块内容比较多，我挑重点讲。完整的架构对比表放在后面，你可以先有个整体印象。

Naive RAG：入门级选择

最简单的架构：用户提问 → 向量检索 → 生成答案。适合快速验证想法，但生产环境基本不够用。

典型问题：检索准确率低，上下文窗口浪费，幻觉问题严重。我个人建议只在做 POC 或者内部工具时用这个。

Hybrid RAG：企业生产标配

这个模式现在基本是企业生产的基准了。核心思路是结合两种检索方式：词汇检索（关键词匹配）和语义检索（向量相似度）。

为啥？因为两种检索方式各有优势：词汇检索擅长精确匹配，语义检索擅长理解意图。结合起来，效果自然好。

实现上，可以用 BM25 做词汇检索，用向量数据库（Pinecone、Weaviate、Milvus 都行）做语义检索，然后通过倒数排名融合（RRF）合并结果。

Graph RAG：多跳推理利器

如果你的业务场景需要回答”为什么”、“怎么关联”这类问题，Graph RAG 值得考虑。

它把文档实体抽取出来构建知识图谱，支持多跳推理。比如问”哪些产品使用了这个供应商的零件”，Graph RAG 可以沿着图谱关系链找到答案。

代价是成本比基础 RAG 高 3-5 倍——知识图谱的构建和维护都不便宜。

Agentic RAG：主动思考型

前面已经讲过核心循环了。这里补充一点：Agentic RAG 的灵活性是把双刃剑。

好处是能处理复杂问题，坏处是延迟高、成本难控制。一个简单问题可能触发多次检索和工具调用，API 调用费用蹭蹭往上涨。所以实际部署时，通常会配合路由策略——简单问题走传统 RAG，复杂问题才进 Agentic 流程。

Self-RAG：自我纠错型

这个模式的核心是让模型评估自己的输出。检索的文档够不够相关？生成的答案有没有幻觉？

如果评估不通过，模型会主动重新检索或修正答案。听起来很美好，但增加了推理成本，而且评估本身也可能出错。

Agentic Graph RAG：天花板级别

目前最先进的模式。把 Agent 编排能力嵌入到知识图谱检索中，既有多跳推理能力，又有主动规划能力。

当然，成本也是天花板级别——建议只在核心业务场景使用。

架构模式对比表

架构模式	复杂度	适用场景	相对成本	延迟
Naive RAG	低	快速验证、内部工具	1x	<1s
Hybrid RAG	中	企业生产标配	1.5x	1-2s
Graph RAG	高	多跳推理、知识密集型	3-5x	2-4s
Agentic RAG	高	复杂决策、多步骤任务	3-8x	3-10s
Self-RAG	中高	高准确率要求场景	2-3x	2-4s
Agentic Graph RAG	极高	核心业务、复杂推理	5-10x	5-15s

我建议从 Hybrid RAG 起步，根据实际需求逐步升级。别一上来就追求最先进的架构，容易翻车。

框架选型：LangChain vs LlamaIndex vs CrewAI vs AutoGen

这块我踩过坑。之前有个项目，我们一开始选了某个框架，做到一半发现生态不够完善，不得不重构。浪费时间不说，团队士气都受影响。

所以框架选型真的很重要。我把主流框架的特点和使用场景整理了一下，希望能帮你少走弯路。

LangChain / LangGraph：生态最全

如果你不知道选哪个，选 LangChain 基本不会错。它是目前生态最完善的框架，文档齐全，社区活跃，GitHub stars 超过 25K（LangGraph）。

LangGraph 是 LangChain 团队推出的图状态机框架，专门用于构建有状态的 Agent 工作流。它的核心优势是支持生产级持久化——Agent 的状态可以保存到数据库，支持断点续传、时间旅行调试。

适合场景：生产级工作流、需要持久化状态、复杂的 Agent 编排。

# LangGraph 简化示例：查询规划代理
from langgraph.graph import StateGraph

def plan_query(state):
    """分析用户问题，规划检索步骤"""
    query = state["query"]
    # 拆解问题、生成子查询
    sub_queries = decompose(query)
    return {"sub_queries": sub_queries}

def retrieve(state):
    """执行检索"""
    results = []
    for q in state["sub_queries"]:
        docs = retriever.invoke(q)
        results.extend(docs)
    return {"context": results}

# 构建工作流
workflow = StateGraph(AgentState)
workflow.add_node("plan", plan_query)
workflow.add_node("retrieve", retrieve)
workflow.add_edge("plan", "retrieve")

LlamaIndex：数据密集型首选

如果你的业务场景涉及大量非结构化数据（文档、数据库、API），LlamaIndex 是更优的选择。

它的查询引擎设计得很好，支持多种检索策略：向量检索、关键词检索、混合检索、知识图谱检索。而且对各种数据源的连接器支持很完善。

适合场景：数据密集型 RAG 应用、需要对接多种数据源、注重检索质量。

CrewAI：快速原型利器

CrewAI 的卖点是”角色驱动的多代理团队”。你可以定义多个 Agent 角色，让它们协作完成任务。

比如设计一个内容创作团队：研究员负责搜集资料，作者负责写作，编辑负责审稿。每个角色有自己的目标和工具。

适合场景：快速原型验证、业务流程自动化、角色分工明确的任务。

目前 CrewAI 的开发者社区超过 10 万人，GitHub stars 超过 20K，生态发展很快。

AutoGen：微软背书的多代理框架

AutoGen 是微软研究院开源的多代理框架，主打对话式协作。多个 Agent 通过对话完成任务，适合需要多轮交互的场景。

它的特点是支持人机协作——真人可以随时介入对话，纠正 Agent 的方向。

适合场景：研究项目、需要人机协作的复杂任务、对话式交互。

GitHub stars 超过 50K，是目前 stars 数最多的 Agent 框架。

选型决策树

我画了个简单的决策逻辑：

你的项目是什么类型？
├── 生产级持久化工作流 → LangGraph
├── 数据密集型 RAG → LlamaIndex
├── 快速原型/业务流程 → CrewAI
├── 研究/对话式多代理 → AutoGen
└── 不确定/需要最大灵活性 → LangChain + LangGraph

话说回来，框架选型没有标准答案。建议根据团队技术栈和项目需求来选，同时关注框架的更新频率和社区活跃度——这块会直接影响后期的维护成本。

企业级实施路线图

这块我整理了一个 90 天的实施模板，基于多家企业的实践经验。当然，每个公司的节奏不一样，你可以根据实际情况调整。

第一阶段：Day 0-15，定义问题和 KPI

很多人一上来就搞技术选型，这是错的。应该先想清楚：我们要解决什么问题？

几个关键问题要回答：

1. 用户是谁？内部员工还是外部客户？
2. 核心场景是什么？问答、搜索、还是复杂推理？
3. 成功指标怎么定？准确率、响应时间、用户满意度？

这个阶段我建议做个简单的用户调研，收集 50-100 个真实问题。这些问题后面会成为测试集和评估基准。

第二阶段：Day 16-45，数据准备和检索层

数据准备是个体力活，但决定了系统的上限。

数据清洗：去掉重复、过时、敏感的内容。这一步很容易被忽视，但脏数据会严重影响检索质量。

分块策略：根据文档类型选择合适的分块大小。技术文档可能 500-1000 字一块，法律条文可能需要按条款切分。

Embedding 选型：OpenAI 的 text-embedding-3 系列、Cohere、BGE 都不错。建议先在小数据集上对比测试。

检索层搭建：从 Hybrid RAG 开始，结合 BM25 和向量检索。

第三阶段：Day 46-75，Agent 编排和工具集成

这个阶段开始引入 Agent 能力。

路由策略：不是所有问题都需要 Agent。简单的 FAQ 问题直接走传统 RAG，复杂问题才进 Agent 流程。这样可以控制成本和延迟。

工具集成：通过 MCP 协议连接内部系统。可能包括：数据库查询、API 调用、文档检索等。

编排设计：用 LangGraph 或者类似的工具设计工作流。建议从简单的 ReAct 模式开始，逐步增加复杂度。

第四阶段：Day 76-90，评估、测试和加固

评估这块，我建议用 RAGAS 框架，主要关注三个指标：

• Faithfulness（忠实度）：生成的答案是否忠于检索的文档，目标 >= 0.8
• Answer Relevance（答案相关性）：答案是否回答了用户的问题
• Context Relevance（上下文相关性）：检索的文档是否足够相关

另外还有几个技术指标：

• Recall@K >= 0.85：检索前 K 个结果的召回率
• P95 latency <= 2.5s：95% 的请求响应时间
• 成本控制：每请求的 API 调用次数和 Token 消耗

常见陷阱

最后提醒几个容易踩的坑：

1. 访问控制绕过：Agent 可能通过工具调用绕过权限控制，安全测试要做足
2. 上下文过期：长对话中，早期信息可能丢失，需要设计上下文管理策略
3. 成本失控：Agent 可能触发多轮检索，API 调用费用会迅速累积

实战案例：智能客服助手架构设计

这个案例是之前帮一个企业做的，效果还不错。

场景：企业客服需要回答用户关于产品、订单、售后、政策等多方面的问题。这些信息分散在知识库、CRM 系统、订单系统、ERP 系统中。

问题：传统 RAG 只能检索知识库，无法查询用户的订单状态、历史记录等个性化信息。

架构设计

我们设计了三层 Agent 架构：

第一层：Routing Agent（路由代理）

分析用户问题，决定下一步走哪个分支。比如：

• “产品怎么使用” → 走知识库检索
• “我的订单到哪了” → 走订单系统查询
• “退款政策是什么” → 走政策文档检索

第二层：Query Planning Agent（查询规划代理）

对于复杂问题，拆解成多个子查询。比如用户问”我上个月买的手机能退吗”，需要：

1. 查询用户的订单记录
2. 查询退货政策
3. 对比订单日期和政策时效

第三层：ReAct Agent（推理行动代理）

执行具体的检索和工具调用，支持多轮迭代。

工具集成

通过 MCP 协议连接内部系统：

tools:
  - name: knowledge_search
    type: vector_retrieval
    source: product_docs

  - name: order_query
    type: api_call
    endpoint: /api/orders/{user_id}

  - name: policy_search
    type: hybrid_retrieval
    sources: [policy_docs, faq]

效果对比

上线后对比了传统 RAG 和 Agentic RAG 的效果：

指标	传统 RAG	Agentic RAG
问题解决率	45%	78%
平均响应时间	1.2s	3.5s
用户满意度	3.2/5	4.1/5
人工介入率	55%	22%

问题解决率提升了 33 个百分点，人工介入率下降了一半多。代价是响应时间增加了——这是 Agent 架构的必然代价，需要在体验和效率之间权衡。

结论

RAG + Agent 正在成为企业 AI 应用的标准架构。从被动检索到主动推理，这套架构让 AI 能够处理真正复杂的问题。

几点建议：

1. 从简单开始。别一上来就追求 Agentic Graph RAG，从 Hybrid RAG 起步，验证价值后再升级。

2. 关注成本控制。Agent 的灵活性是有代价的，API 调用费用很容易失控。路由策略和缓存机制必不可少。

3. 重视评估体系。没有量化指标，你永远不知道系统是好是坏。RAGAS 框架 + 自建测试集，这是基本功。

4. 关注开放协议。MCP 正在成为工具连接的标准，A2A 协议也在解决跨框架协作问题。这些协议会深刻影响 Agent 生态的发展。

嗯，大概就是这些。如果你正在搭建 RAG 系统，希望这篇文章能给你一些参考。有问题可以留言讨论。

常见问题

Agentic RAG 和传统 RAG 的核心区别是什么？

传统 RAG 是被动检索模式：用户提问 → 向量检索 → 生成答案。Agentic RAG 则引入了主动推理能力，核心循环是 Plan → Retrieve → Act → Reflect → Answer，能够拆解复杂问题、多轮检索、自我纠错。

企业应该选择哪种 RAG 架构？

建议从 Hybrid RAG 起步，它是企业生产标配，成本可控且效果好。根据业务需求逐步升级：需要多跳推理选 Graph RAG，需要复杂决策选 Agentic RAG，核心业务场景可考虑 Agentic Graph RAG。

LangChain、LlamaIndex、CrewAI 怎么选？

根据项目类型选择：

• 生产级持久化工作流 → LangGraph
• 数据密集型 RAG → LlamaIndex
• 快速原型/业务流程 → CrewAI
• 研究/对话式多代理 → AutoGen

Agentic RAG 的成本和延迟如何控制？

关键策略：1）路由策略——简单问题走传统 RAG，复杂问题才进 Agent 流程；2）缓存机制——对高频查询结果缓存；3）限制迭代次数——防止 Agent 无限循环；4）监控 API 调用——设置成本告警阈值。

实施 RAG + Agent 项目需要多长时间？

建议分 4 个阶段：Day 0-15 定义问题和 KPI；Day 16-45 数据准备和检索层；Day 46-75 Agent 编排和工具集成；Day 76-90 评估测试和加固。总计约 90 天，可根据团队规模和项目复杂度调整。

如何评估 RAG 系统的效果？

推荐使用 RAGAS 框架，关注三个核心指标：

• Faithfulness（忠实度）&gt;= 0.8
• Answer Relevance（答案相关性）
• Context Relevance（上下文相关性）

技术指标：Recall@K &gt;= 0.85，P95 延迟 &lt;= 2.5s

15 分钟阅读 · 发布于: 2026年3月22日 · 修改于: 2026年3月22日