RAG与Agent的完美结合：知识增强型智能体构建指南

---

1. 核心概念：什么是RAG、什么是Agent，它们为什么“天生一对”

1.1 问题背景

1.1.1 生成式AI（GenAI）的黄金时代与致命缺陷

在2022年底ChatGPT横空出世之后，生成式AI迎来了史无前例的普及浪潮：从普通用户写邮件、创作小说，到开发者生成代码、构建应用，再到企业做市场分析、客户服务、研发辅助，LLM（Large Language Model，大语言模型）似乎无所不能。但随着应用场景的深入，一个致命缺陷逐渐暴露并成为所有企业和开发者的“拦路虎”——

知识的“封闭性”与“时效性”问题：
LLM的知识是基于预训练数据集构建的，这个数据集有明确的截止时间（比如GPT-4截止到2024年7月，Llama 3截止到2024年1月），任何在截止时间之后发生的事件（比如最新的科技新闻、实时的股票行情、企业内部的最新政策文档），LLM都“完全不知道”；
同时，预训练数据集里没有任何企业的私有知识（比如内部的产品手册、客户历史订单、研发代码库的注释规范），如果直接用通用LLM处理企业内部的业务问题，要么“答非所问”，要么“一本正经地胡说八道”（这就是业界常说的“幻觉/Hallucination”）。

1.1.2 早期解决方案的局限性

为了解决上述问题，开发者和企业尝试了两种最直接的方法，但它们都有明显的局限性：

方法1：微调（Fine-tuning）
微调是指用企业的私有数据或最新的公开数据，在预训练LLM的基础上进行二次训练，让LLM“记住”新的知识。但这种方法的问题在于：

• 成本高昂：微调一个7B参数的LLM，可能需要数万元的GPU算力（比如A100 GPU按小时收费约为10-20美元，微调一次可能需要几十到几百小时）；微调70B或更大参数的LLM，成本可能高达几十万元甚至上百万元；
• 时效性差：微调一次需要很长的时间（从数据准备、清洗、标注，到模型训练、验证、上线，可能需要几天到几周的时间），如果数据更新频繁（比如每天都有新的产品手册、客户订单），微调根本跟不上节奏；
• 知识遗忘：微调过程中，LLM可能会“遗忘”预训练数据集中的通用知识（这就是“灾难性遗忘/Catastrophic Forgetting”问题），导致模型在处理通用问题时的性能下降；
• 灵活性差：微调后的LLM是“固定”的，只能处理微调数据覆盖的特定场景，如果需要新增场景或修改现有场景的知识，必须重新微调。

方法2：上下文窗口（Context Window）填充
上下文窗口填充是指把需要的知识直接塞进LLM的输入提示词（Prompt）里，让LLM基于提示词里的知识生成回答。但这种方法的问题在于：

• 上下文窗口大小有限：目前主流的LLM上下文窗口大小从几千token（比如GPT-3.5-turbo是16K token，约12000个中文汉字）到几百万token（比如Claude 3 Opus是200K token，GPT-4o mini是128K token，GPT-4o是128K token（免费版）/1M token（付费API高级版））不等，但即使是1M token的上下文窗口，也只能容纳约750万中文汉字，对于大型企业的知识库（比如可能有几千万甚至几亿中文汉字的文档、代码、数据）来说，完全不够用；
• 成本高昂：LLM的API收费通常是按输入token和输出token分别计费的，比如GPT-4o的输入token收费是0.01美元/1K token，输出token收费是0.03美元/1K token（2024年10月的最新价格），如果每次都把几万个甚至几十万个token的知识塞进提示词里，成本会非常高；
• 处理效率低：LLM处理超大上下文窗口的速度非常慢，比如用GPT-4o处理1M token的输入，可能需要几分钟甚至更长的时间，这对于需要实时响应的应用场景（比如客户服务、在线问答）来说，完全不可接受；
• 信息过载：即使上下文窗口足够大，把所有相关的知识都塞进去，LLM也可能会“信息过载”，找不到真正需要的关键信息，导致生成的回答质量下降。

1.1.3 知识增强型智能体的诞生

在上述两种方法都无法完美解决问题的情况下，RAG（Retrieval-Augmented Generation，检索增强生成）和Agent（智能体）这两种技术逐渐走进了开发者和企业的视野，并被证明是解决GenAI知识问题的“黄金组合”——
RAG可以解决LLM的“封闭性”“时效性”“知识幻觉”问题，Agent可以解决RAG的“单一性”“被动性”问题，两者结合起来，就能构建出一个主动、智能、准确、可扩展、低成本、可解释的知识增强型智能体。

---

1.2 问题描述

在正式介绍RAG和Agent的核心概念之前，我们先来明确一下本文要解决的核心问题：

如何构建一个主动的、智能的、能够利用任意私有/公开/实时知识的、几乎没有知识幻觉的、可解释的、可扩展的智能体，用于处理企业内部或外部的复杂任务？

这个核心问题可以拆解成以下几个子问题：

1. 什么是RAG？它的核心原理是什么？它有哪些优点和局限性？
2. 什么是Agent？它的核心原理是什么？它有哪些优点和局限性？
3. RAG和Agent为什么可以“完美结合”？它们的结合方式有哪些？
4. 如何用数学模型来描述RAG与Agent的结合过程？
5. 如何用Python代码实现一个基础的RAG与Agent结合的知识增强型智能体？
6. 如何构建一个完整的、可用于生产环境的知识增强型智能体项目？
7. 知识增强型智能体有哪些实际应用场景？
8. 构建知识增强型智能体有哪些最佳实践和常见陷阱？
9. 知识增强型智能体的行业发展现状和未来趋势是什么？

本文的所有内容，都是围绕着解决这些核心问题和子问题展开的。

---

1.3 核心概念详解

1.3.1 RAG（Retrieval-Augmented Generation，检索增强生成）

1.3.1.1 什么是RAG？

RAG是由Meta AI的研究人员在2020年发表的论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中首次提出的一种知识增强的NLP（自然语言处理）技术框架。

简单来说，RAG的核心思想是：在让LLM生成回答之前，先从一个外部知识库（Knowledge Base）中检索出与用户问题最相关的若干条知识片段（Chunk），然后把这些知识片段和用户的原始问题一起塞进LLM的输入提示词里，让LLM基于这些“可信的、最新的、相关的”知识片段生成回答，而不是仅仅依赖预训练数据集中的知识。

1.3.1.2 RAG的核心组成部分

一个完整的、标准的RAG系统（也叫“RAG管道/RAG Pipeline”）通常由以下6个核心组成部分构成：

核心组成部分	英文全称	核心功能
知识源	Knowledge Sources	提供所有需要增强的知识，包括私有知识（企业内部文档、代码、数据）、公开知识（维基百科、行业报告）、实时知识（新闻API、股票API）等。
知识预处理与切分	Knowledge Preprocessing & Chunking	对知识源中的原始数据进行清洗（去除无关内容、格式错误、重复内容等）、标准化（统一格式、统一语言、统一编码等），然后切分成若干个大小合适的、语义相对完整的知识片段（Chunk）。
向量嵌入模型	Embedding Model	把切分好的知识片段和用户的原始问题（Query）转换成固定维度的、稠密的数值向量（也叫“嵌入向量/Embedding Vector”），向量的数值可以反映文本的语义信息——语义越相似的文本，它们的嵌入向量之间的距离（通常用余弦相似度Cosine Similarity或欧氏距离Euclidean Distance来衡量）就越小。
向量数据库	Vector Database	存储所有知识片段的嵌入向量和对应的原始文本，并且提供高效的语义相似度检索功能——当用户输入一个问题时，先把问题转换成嵌入向量，然后在向量数据库中查找与问题向量距离最小的前Top N个知识片段的嵌入向量，最后返回对应的原始文本。
检索器	Retriever	连接用户问题、向量嵌入模型、向量数据库，负责执行知识检索的整个流程——包括把用户问题转换成嵌入向量、在向量数据库中检索Top N个相关知识片段、对检索结果进行重排序（Reranking，可选但强烈推荐，因为可以进一步提高检索结果的相关性）。
生成器	Generator	连接用户问题、检索结果、预训练LLM，负责执行回答生成的整个流程——包括把用户问题和检索到的Top N个相关知识片段组合成一个结构化的提示词（Prompt Engineering，非常重要，直接影响生成回答的质量）、把提示词输入给预训练LLM、对LLM生成的回答进行后处理（比如去除冗余内容、添加引用来源、格式化为Markdown等，可选但强烈推荐，可以提高回答的可解释性和可读性）。

为了让大家更直观地理解RAG的核心组成部分和工作流程，我画了一个RAG标准工作流程的Mermaid流程图：

1.3.1.3 RAG的分类

根据不同的分类标准，RAG可以分成不同的类型：

按检索时机分类

分类类型	英文全称	核心原理	优点	缺点	适用场景
静态RAG	Static RAG	在知识索引构建完成之后，就不会再更新向量数据库了，检索到的知识片段都是固定的。	实现简单，成本低，处理速度快。	时效性差，无法处理实时更新的知识；灵活性差，无法根据查询的上下文动态调整检索策略。	知识更新频率很低（比如几个月甚至几年才更新一次）的场景，比如教科书知识库、历史文献知识库。
动态RAG	Dynamic RAG	在知识索引构建完成之后，会定期（比如每小时、每天）或实时（比如知识源更新时立即）更新向量数据库，检索到的知识片段是最新的。	时效性好，可以处理实时更新的知识。	实现复杂，成本较高，需要处理知识的同步、版本控制、冲突解决等问题。	知识更新频率较高（比如每天、每周更新一次）的场景，比如企业内部的产品手册知识库、行业报告知识库。
自适应RAG	Adaptive RAG	会根据用户查询的上下文（比如查询的类型、查询的难度、用户的身份等）动态调整检索策略（比如调整Top N的数量、调整检索的范围、调整重排序的算法等）。	灵活性好，检索结果的相关性更高。	实现非常复杂，成本很高，需要大量的训练数据和调优工作。	知识更新频率很高（比如实时更新）、查询类型复杂多变的场景，比如实时新闻问答系统、金融市场分析系统。

按生成方式分类

分类类型	英文全称	核心原理	优点	缺点	适用场景
Naive RAG	Naive RAG	就是我们前面介绍的“标准RAG”——先检索Top N个相关知识片段，然后直接把它们和用户问题一起塞进LLM的提示词里生成回答。	实现最简单，成本最低，上手最快。	检索结果的相关性可能不高（如果切分策略、嵌入模型、检索策略选得不好的话）；生成的回答可能没有引用来源，可解释性差；可能还是会有少量的知识幻觉。	适合初学者学习RAG的基本原理，或者知识量很小、查询类型很简单的场景。
Advanced RAG	Advanced RAG	在Naive RAG的基础上，增加了很多高级功能——比如知识预处理时的多模态处理（处理图片、视频、音频等非文本数据）、元数据提取（提取知识片段的作者、时间、来源、标签等元数据，用于提高检索的准确性）；知识切分时的混合切分策略（比如先按段落切分，再按句子切分，最后合并成大小合适的、语义完整的知识片段）、滑动窗口切分（Sliding Window Chunking，相邻的知识片段之间有重叠的内容，避免语义信息的丢失）；检索时的混合检索（Hybrid Retrieval，同时使用语义相似度检索和关键词检索，比如BM25算法，提高检索结果的召回率和准确率）、重排序（Reranking，用专门的重排序模型对语义相似度检索或混合检索得到的Top K个结果进行二次排序，只保留Top N个最相关的结果）、查询重写（Query Rewriting，用LLM或专门的查询重写模型对用户的原始问题进行重写，生成更清晰、更具体、更符合检索要求的问题，提高检索结果的相关性）；生成时的提示词模板化（用固定的提示词模板组合用户问题和检索结果，提高生成回答的质量和一致性）、引用来源标注（让LLM在生成回答时，标注出每一句话的引用来源，提高回答的可解释性）、事实核查（Fact Checking，用专门的事实核查模型或工具对LLM生成的回答进行核查，进一步减少知识幻觉）。	功能强大，检索结果的相关性更高，生成的回答质量更好、可解释性更强、知识幻觉更少。	实现复杂，成本较高，需要用到很多额外的工具和模型（比如重排序模型、查询重写模型、事实核查模型等）。	适合大多数生产环境的场景，是目前业界使用最广泛的RAG类型。
Modular RAG	Modular RAG	把RAG的各个核心组成部分（知识预处理、知识切分、向量嵌入、向量数据库、检索器、生成器等）都做成独立的、可插拔的模块，开发者可以根据自己的需求，选择不同的模块组合在一起，构建出一个定制化的RAG系统。	灵活性极强，可扩展性极强，开发者可以完全控制RAG系统的每一个环节。	实现非常复杂，成本很高，需要开发者对RAG的每一个核心组成部分都有深入的理解。	适合有特殊需求、需要高度定制化的场景，比如多模态RAG系统、多语言RAG系统、跨领域RAG系统等。

按知识源类型分类

分类类型	英文全称	核心原理	适用场景
文本RAG	Text RAG	知识源都是文本数据（比如文档、网页、代码等）。	大多数知识增强型应用场景，比如文档问答系统、代码辅助系统、客户服务系统等。
多模态RAG	Multimodal RAG	知识源不仅包括文本数据，还包括图片、视频、音频等非文本数据。	多模态知识增强型应用场景，比如产品图片问答系统、教学视频问答系统、语音转文字+知识增强系统等。
结构化RAG	Structured RAG	知识源主要是结构化数据（比如SQL数据库、Excel表格、CSV文件等）。	结构化数据知识增强型应用场景，比如销售数据分析系统、客户订单查询系统、库存管理系统等。
半结构化RAG	Semi-structured RAG	知识源主要是半结构化数据（比如JSON文件、XML文件、Markdown文件等）。	半结构化数据知识增强型应用场景，比如API文档问答系统、技术博客问答系统等。

1.3.1.4 RAG的优点和局限性

RAG的优点

1. 解决知识的“封闭性”和“时效性”问题：可以利用任意的私有/公开/实时知识，不需要重新微调LLM；
2. 几乎没有知识幻觉：因为生成的回答是基于“可信的、最新的、相关的”外部知识片段，而不是仅仅依赖预训练数据集中的知识；
3. 可解释性强：可以在生成的回答中标注出每一句话的引用来源，用户可以很容易地验证回答的准确性；
4. 成本低：相比于微调LLM，构建RAG系统的成本要低得多——不需要昂贵的GPU算力，只需要普通的服务器或云服务即可；
5. 时效性好：可以实时或定期更新向量数据库，让RAG系统始终使用最新的知识；
6. 灵活性强：可以根据自己的需求，选择不同的知识源、不同的嵌入模型、不同的向量数据库、不同的检索策略、不同的生成模型等；
7. 可扩展性强：可以很容易地添加新的知识源、新的知识片段、新的功能模块等。

RAG的局限性

1. 单一性：只能处理“单一的、被动的、查询式的”任务——比如用户问一个问题，RAG系统就检索相关知识并生成回答；但如果用户的任务是“复杂的、主动的、多步骤的”（比如“帮我写一份2024年第三季度的苹果公司财报分析报告，需要包括营收、利润、市场份额、竞争对手分析等内容，并且需要引用最新的新闻和数据”），单一的RAG系统就无法处理了；
2. 被动性：只能“被动地”响应用户的查询，不能“主动地”发现问题、解决问题——比如用户可能没有意识到自己需要什么知识，或者用户的查询不够清晰、不够具体，单一的RAG系统就无法主动地引导用户、帮助用户；
3. 无法处理非查询式的任务：比如“帮我把这份PDF文档翻译成中文，并且总结出每一章的核心内容”“帮我监控一下特斯拉的股价，如果股价跌破200美元，就给我发一封邮件通知我”，这些任务都不是“查询式的”，单一的RAG系统就无法处理了；
4. 检索结果的相关性可能不高：如果切分策略、嵌入模型、检索策略选得不好的话，检索到的知识片段可能和用户的问题不相关，或者相关性很低，导致生成的回答质量下降；
5. 上下文窗口大小的限制仍然存在：虽然RAG可以减少需要塞进LLM提示词里的知识量，但如果Top N的数量选得太大，或者每个知识片段的长度太长，仍然可能会超过LLM的上下文窗口大小；
6. 生成的回答可能不够连贯：因为生成的回答是基于多个独立的知识片段，这些知识片段之间可能没有逻辑联系，导致生成的回答不够连贯、不够流畅。

---

1.3.2 Agent（智能体）

1.3.2.1 什么是Agent？

“Agent（智能体）”这个概念最早起源于**人工智能（AI）和分布式系统（Distributed Systems）**领域，在不同的领域有不同的定义，但在当前的生成式AI（GenAI）时代，我们通常所说的“LLM Agent（大语言模型智能体）”的定义是：

LLM Agent是一个以LLM为核心大脑（Core Brain/Controller），能够感知环境（Perceive Environment）、做出决策（Make Decisions）、执行行动（Execute Actions）、观察结果（Observe Results）、迭代优化（Iterate Optimization）的自主系统。

简单来说，LLM Agent就是一个“会思考、会行动、会学习、会进化”的智能助手，它可以处理“复杂的、主动的、多步骤的”任务，而单一的RAG系统或单一的LLM都无法处理这些任务。

1.3.2.2 LLM Agent的核心组成部分

一个完整的、标准的LLM Agent系统通常由以下5个核心组成部分构成：

核心组成部分	英文全称	核心功能
核心大脑（控制器）	Core Brain (Controller)	整个Agent系统的核心，通常是一个预训练LLM（比如GPT-4o、Claude 3 Opus、Llama 3 70B等），负责感知环境、理解用户的任务、做出决策、规划行动步骤、执行行动（调用工具）、观察结果、迭代优化，直到任务完成。
感知模块	Perception Module	负责“感知”环境——包括用户的输入（比如文本、图片、语音、视频等）、外部环境的状态（比如当前的时间、天气、股票行情、API的返回结果等）、内部环境的状态（比如Agent之前执行的行动、观察到的结果、生成的中间产物等）。
记忆模块	Memory Module	负责“记忆”Agent的所有历史信息——包括短期记忆（Short-term Memory，也叫“上下文记忆/Context Memory”，用于存储Agent当前会话的所有信息，比如用户的输入、Agent的输出、执行的行动、观察到的结果等，通常存储在RAM里，会话结束后就会丢失）、长期记忆（Long-term Memory，也叫“知识库记忆/KB Memory”，用于存储Agent的所有历史会话信息、学习到的知识、经验等，通常存储在数据库或向量数据库里，会话结束后不会丢失）。
工具库	Toolkit (Tools)	是Agent可以调用的“外部工具”的集合，这些工具可以帮助Agent完成各种LLM本身无法完成的任务——比如数学计算工具（比如Calculator）、搜索引擎工具（比如Google Search、Bing Search）、代码执行工具（比如Python REPL、Jupyter Notebook）、文件操作工具（比如File Read、File Write、File Delete）、API调用工具（比如调用天气API、股票API、企业内部的业务API等）、RAG检索工具（这就是我们后面要讲的RAG与Agent结合的核心工具）等。
行动执行模块	Action Execution Module	负责“执行”核心大脑做出的决策——也就是调用工具库中的工具，执行具体的行动，然后把工具的返回结果（观察到的结果）反馈给核心大脑。

为了让大家更直观地理解LLM Agent的核心组成部分和工作流程，我画了一个LLM Agent标准工作流程的Mermaid流程图，这个流程图是基于目前业界最流行的LLM Agent框架——LangChain的“ReAct（Reasoning + Acting）”模式设计的：

1.3.2.3 LLM Agent的分类

根据不同的分类标准，LLM Agent可以分成不同的类型：

按任务类型分类

分类类型	英文全称	核心功能	适用场景
任务型Agent	Task-Oriented Agent	专门用于处理“特定的、单一的或有限的”任务，比如订机票、订酒店、点外卖、客服咨询等。	企业内部的业务自动化场景、To C的消费级应用场景。
通用型Agent	General-Purpose Agent	可以处理“任意的、复杂的、多步骤的”任务，比如写代码、写报告、做研究、规划旅行等。	开发者辅助场景、研究人员辅助场景、个人助理场景。

按自主性分类

分类类型	英文全称	核心功能	适用场景
交互式Agent	Interactive Agent	需要用户的不断交互和确认才能完成任务，自主性较低。	任务比较复杂、风险比较高的场景，比如医疗诊断辅助系统、金融投资辅助系统。
自主式Agent	Autonomous Agent	不需要用户的交互和确认，就可以自主地完成任务，自主性较高。	任务比较简单、风险比较低的场景，比如监控股价、整理文件、发送邮件等。

按架构模式分类

分类类型	英文全称	核心原理	优点	缺点	适用场景	代表框架/模型
ReAct模式	ReAct (Reasoning + Acting)	是目前业界最流行的LLM Agent架构模式，核心思想是“边思考边行动”——LLM每执行一个行动之前，都会先“思考”（Reasoning）一下为什么要执行这个行动、执行这个行动会得到什么结果、接下来应该怎么做，然后再“行动”（Acting）——调用工具执行具体的行动，然后再“观察”（Observing）行动的结果，然后再“思考”，直到任务完成。	实现简单，易于理解，生成的过程可解释性强，任务完成的成功率较高。	有时候会陷入“无限循环”（比如不断地调用同一个工具，却得不到有用的结果），有时候会“忘记”任务的目标，任务完成的速度较慢。	适合大多数复杂的、多步骤的任务，是目前业界使用最广泛的LLM Agent架构模式。	LangChain ReAct Agent、AutoGPT（早期版本）、BabyAGI（早期版本）
Plan-and-Execute模式	Plan-and-Execute	核心思想是“先规划后执行”——LLM先“规划”（Planning）一下完成任务的所有步骤，然后再“执行”（Executing）这些步骤，在执行的过程中，如果发现规划的步骤有问题，还可以“重新规划”（Re-planning）。	任务完成的速度较快，不容易陷入“无限循环”，不容易“忘记”任务的目标。	规划的步骤可能不够完善，需要“重新规划”的次数可能较多，生成的过程可解释性不如ReAct模式强。	适合任务目标比较明确、步骤比较清晰的场景。	LangChain Plan-and-Execute Agent、AutoGPT（最新版本）、BabyAGI（最新版本）
Reflection模式	Reflection (Reflexion)	核心思想是“思考-行动-观察-反思-迭代”——在ReAct模式的基础上，增加了“反思”（Reflection）的环节，LLM每执行完几个行动之后，都会“反思”一下之前的行动是否正确、是否高效、是否达到了预期的目标，如果发现有问题，就会“迭代”（Iteration）优化自己的行动策略，然后再继续执行任务。	任务完成的成功率更高，行动策略更高效，可以从错误中学习，不断进化。	实现复杂，任务完成的速度更慢，需要用到更多的LLM调用次数，成本更高。	适合任务比较复杂、难度比较高、需要从错误中学习的场景。	LangChain Reflection Agent、Reflexion（论文提出的模型）
Multi-Agent模式	Multi-Agent System	核心思想是“多个Agent协作完成任务”——系统中有多个不同功能的Agent（比如“规划Agent”“执行Agent”“反思Agent”“评审Agent”等），它们之间可以相互通信、相互协作、相互监督，共同完成一个复杂的任务。	任务完成的成功率最高，功能最强大，可以处理非常复杂的、需要多个专业领域知识的任务。	实现非常复杂，成本非常高，需要处理多个Agent之间的通信、协作、冲突解决等问题。	适合任务非常复杂、需要多个专业领域知识的场景，比如大型软件项目的开发、大型研究项目的研究、大型企业的业务自动化等。	LangChain Multi-Agent System、AutoGPT（最新版本支持）、MetaGPT、CrewAI

1.3.2.4 LLM Agent的优点和局限性

LLM Agent的优点

1. 可以处理复杂的、主动的、多步骤的任务：这是LLM Agent最大的优点，也是单一的RAG系统或单一的LLM无法做到的；
2. 主动性强：可以“主动地”发现问题、解决问题、引导用户，而不是“被动地”响应用户的查询；
3. 可以调用外部工具：可以调用各种外部工具（比如数学计算工具、搜索引擎工具、代码执行工具、RAG检索工具等），完成各种LLM本身无法完成的任务；
4. 可以记忆历史信息：可以记忆当前会话的所有信息（短期记忆）和所有历史会话的信息（长期记忆），更好地理解用户的需求；
5. 可以从错误中学习：如果采用Reflection模式或Multi-Agent模式，Agent可以从错误中学习，不断优化自己的行动策略，不断进化；
6. 可扩展性强：可以很容易地添加新的工具、新的功能模块、新的Agent等。

LLM Agent的局限性

1. 知识幻觉问题仍然存在：如果Agent没有调用RAG检索工具，而是仅仅依赖预训练LLM的知识，仍然可能会产生知识幻觉；
2. 成本较高：因为Agent需要多次调用LLM（比如ReAct模式可能需要调用几次到几十次LLM，Reflection模式可能需要调用几十次到几百次LLM），所以API调用成本较高；
3. 任务完成的速度较慢：因为Agent需要多次调用LLM、多次调用工具、多次观察结果，所以任务完成的速度较慢；
4. 有时候会陷入“无限循环”：比如ReAct模式可能会不断地调用同一个工具，却得不到有用的结果；
5. 有时候会“忘记”任务的目标：比如ReAct模式可能会在执行了几个行动之后，就忘记了最初的任务目标；
6. 工具调用的准确性可能不高：如果Agent的提示词工程做得不好，或者工具的接口定义得不够清晰，Agent可能会错误地调用工具，或者调用工具时传递错误的参数；
7. 实现复杂：相比于单一的RAG系统或单一的LLM，构建LLM Agent系统的实现复杂度要高得多。

---

1.3.3 RAG与Agent的“完美结合”：知识增强型智能体（Knowledge-Enhanced LLM Agent）

1.3.3.1 为什么RAG与Agent是“天生一对”？

我们前面分别介绍了RAG和Agent的核心概念、优点和局限性，现在我们来对比一下它们的优缺点，看看为什么它们是“天生一对”：

技术	优点	局限性	对方技术能否弥补局限性？
RAG	解决知识的“封闭性”“时效性”问题；几乎没有知识幻觉；可解释性强；成本低；时效性好；灵活性强；可扩展性强。	单一性：只能处理“单一的、被动的、查询式的”任务；被动性：只能“被动地”响应用户的查询；无法处理非查询式的任务；检索结果的相关性可能不高；上下文窗口大小的限制仍然存在；生成的回答可能不够连贯。	能！Agent可以弥补RAG的所有局限性： 1. Agent可以处理“复杂的、主动的、多步骤的”任务； 2. Agent可以“主动地”发现问题、解决问题、引导用户； 3. Agent可以处理非查询式的任务； 4. Agent可以用查询重写、混合检索、重排序等方法提高检索结果的相关性； 5. Agent可以把检索到的知识片段分成多个部分，分多次调用LLM处理，避免超过上下文窗口大小； 6. Agent可以把多个独立的知识片段组合成一个逻辑连贯的整体，生成更连贯、更流畅的回答。
Agent	可以处理复杂的、主动的、多步骤的任务；主动性强；可以调用外部工具；可以记忆历史信息；可以从错误中学习；可扩展性强。	知识幻觉问题仍然存在；成本较高；任务完成的速度较慢；有时候会陷入“无限循环”；有时候会“忘记”任务的目标；工具调用的准确性可能不高；实现复杂。	能！RAG可以弥补Agent的大部分局限性： 1. RAG可以解决Agent的知识幻觉问题； 2. RAG可以让Agent不需要多次调用LLM来“回忆”预训练数据集中的知识，从而减少LLM的调用次数，降低成本，提高任务完成的速度； 3. 虽然RAG不能直接解决Agent的“无限循环”“忘记任务目标”“工具调用准确性不高”“实现复杂”等问题，但RAG可以作为Agent的一个核心工具，帮助Agent更好地完成任务，从而间接减少这些问题的发生。

从上面的对比表格中我们可以看出，RAG和Agent的优缺点是完全互补的——RAG的优点正好是Agent的局限性，Agent的优点正好是RAG的局限性，所以它们是“天生一对”，结合起来就能构建出一个主动、智能、准确、可扩展、低成本、可解释的知识增强型智能体（Knowledge-Enhanced LLM Agent）。

1.3.3.2 什么是知识增强型智能体？

知识增强型智能体（Knowledge-Enhanced LLM Agent）的定义是：

知识增强型智能体是一个以LLM为核心大脑，以RAG为核心知识增强工具，能够感知环境、理解用户的任务、利用任意私有/公开/实时知识、做出决策、规划行动步骤、执行行动（包括调用RAG检索工具检索相关知识）、观察结果、迭代优化的自主系统。

简单来说，知识增强型智能体就是一个“有脑子（LLM）、有记忆（Memory Module）、有手脚（Toolkit，包括RAG检索工具）、有知识（RAG Knowledge Base）、会思考、会行动、会学习、会进化”的超级智能助手。

1.3.3.3 RAG与Agent的结合方式

RAG与Agent的结合方式主要有以下4种：

结合方式1：RAG作为Agent的一个“静态工具”（Static Tool）

这是最简单、最常见的结合方式——把RAG的整个检索流程（包括查询重写、语义相似度检索、混合检索、重排序等）封装成一个“静态工具”，Agent可以在需要的时候调用这个工具，从外部知识库中检索相关的知识片段，然后基于这些知识片段完成任务。

优点：

1. 实现最简单，成本最低，上手最快；
2. RAG和Agent的耦合度很低，可以独立开发、独立测试、独立部署、独立优化；
3. 可以很容易地替换RAG的各个组成部分（比如替换嵌入模型、替换向量数据库、替换检索策略等），而不需要修改Agent的代码。

缺点：

1. RAG是“静态的”，Agent无法根据任务的上下文动态调整RAG的检索策略（比如调整Top N的数量、调整检索的范围、调整重排序的算法等）；
2. Agent无法直接访问RAG的向量数据库或记忆模块，只能通过调用RAG工具获取检索结果；
3. RAG工具的返回结果可能不够灵活，无法满足Agent的所有需求。

适用场景：
适合大多数生产环境的场景，是目前业界使用最广泛的结合方式。

Mermaid架构图：
为了让大家更直观地理解这种结合方式，我画了一个RAG作为Agent静态工具的Mermaid架构图：