1. 从RAG到Agent的架构演进逻辑
1.1 为什么单纯RAG不够用了
我最早接触RAG是在做一个企业知识库问答项目的时候。当时的思路很直接：把文档切块、向量化、存进向量数据库，用户提问时检索最相似的几个片段，拼进Prompt让大模型生成答案。这套流程跑通之后，Demo效果确实惊艳，但一上生产环境就露馅了。
最典型的问题是：用户问“帮我对比一下A产品和B产品在售后政策上的差异”，传统RAG检索回来的片段可能只覆盖了A产品的售后条款，B产品的信息因为语义相似度不够高被排在了后面。模型拿到残缺的上下文，要么硬编一个答案，要么说“根据现有信息无法回答”。这不是检索算法的问题，而是单轮检索+单轮生成这个架构本身的局限——它没有“意识到自己缺什么信息”的能力，更没有“主动去补全信息”的能力。
另一个让我头疼的场景是多跳推理。比如“我们公司去年Q3签的那个框架协议里，约定的违约金比例是多少”，这个问题需要先找到“去年Q3签的框架协议”是哪份文件，再去那份文件里定位违约金条款。传统RAG一次性检索，很难同时命中这两个层次的信息。
这些痛点指向同一个结论：RAG解决的是“知识获取”问题，但没有解决“知识运用”问题。而Agent架构的核心价值，恰恰在于它引入了“行动决策”的能力——模型可以自己判断当前信息够不够、下一步该做什么、调用什么工具、是否需要追问用户。
1.2 Agent架构中RAG的角色转变
在Agent体系里，RAG不再是唯一的“知识入口”，而是变成了Agent可以调用的一个工具。这个定位转变非常关键。
打个比方：传统RAG像是一个图书馆管理员，你问什么他就去书架找什么，找到就给你，找不到就说没有。而Agent架构下的RAG更像是一个研究助理，你给他一个任务，他会先判断需要哪些资料，然后主动去图书馆查、去数据库搜、去网上找，查完之后还会判断信息是否充分，不充分就换个关键词再查，或者直接来问你。
具体到技术实现上，RAG在Agent中通常以Function Calling的形式暴露给模型。模型看到用户的问题后，会自主决定是否调用search_knowledge_base这个函数，传入什么查询参数，拿到结果后如何整合。如果第一次检索结果不理想，模型可以调整查询词再次调用，这就是所谓的Agentic RAG。
我实测下来，这种架构在复杂问答场景下的准确率比传统RAG提升了至少30个百分点。代价是Token消耗和响应延迟都会增加，因为模型需要多轮“思考-行动-观察”的循环。所以关键是在效果和成本之间找到平衡点，不是所有场景都需要上Agent。
1.3 融合架构的核心设计原则
从RAG到Agent的融合，我总结下来有三个核心设计原则：
第一，检索必须可编排。不要把检索写死在流程里，而是要让模型能够决定“什么时候检索”“检索什么”“检索几次”。这意味着你需要把检索封装成标准的工具接口，让模型通过Function Calling来调用。
第二，决策必须有依据。Agent的每一步行动都应该基于当前已有的信息。如果模型决定调用检索工具，它应该能说清楚“我为什么要检索”“我期望检索到什么”。这需要在Prompt设计中加入思维链的引导，让模型的决策过程可追溯、可调试。
第三，边界必须清晰。不是所有问题都需要Agent化。简单的事实性问答，传统RAG就够了；只有涉及多跳推理、多工具协同、动态决策的场景，才值得上Agent架构。我在实际项目中会先做一个场景分级，把问题按复杂度分成L1到L4，L1-L2用传统RAG，L3-L4才走Agent流程。
2. 核心组件拆解与技术选型
2.1 检索增强模块的细化设计
在Agent架构下，检索增强模块需要比传统RAG做得更细。我通常会把检索拆成三个子模块：
查询理解与改写。用户原始问题往往不适合直接拿去检索。比如“那个什么来着，就是上次说的那个方案”，这种问题直接向量化检索基本废掉。我一般会在检索前加一个查询改写步骤，用一个小模型或者规则引擎把口语化问题转成结构化查询。实测下来，这一步对检索召回率的提升非常明显，尤其是在多轮对话场景下。
混合检索策略。纯向量检索在语义匹配上强，但在精确匹配（比如产品型号、人名、特定术语）上弱。我通常采用向量检索+关键词检索的混合方案，用RRF（Reciprocal Rank Fusion）做结果融合。具体参数上，向量检索取Top 20，关键词检索取Top 20，融合后取Top 10送入重排序。
重排序与过滤。检索回来的片段不能直接塞给模型，需要经过重排序模型精排。我常用的是Cross-Encoder架构的重排序模型，虽然推理速度比双塔慢，但精度提升显著。重排序之后还要做相关性阈值过滤，低于阈值的片段直接丢弃，避免噪声干扰模型判断。
# 混合检索+重排序的简化流程 def hybrid_retrieve(query, top_k=10): # 向量检索 vector_results = vector_store.search(query, top_k=20) # 关键词检索 keyword_results = bm25_index.search(query, top_k=20) # RRF融合 fused = rrf_fusion(vector_results, keyword_results) # 重排序 reranked = reranker.rerank(query, fused[:20]) # 阈值过滤 filtered = [r for r in reranked if r.score > 0.6] return filtered[:top_k]2.2 行动决策模块的实现要点
行动决策是Agent区别于传统RAG的核心。这个模块要解决的核心问题是：模型如何决定下一步做什么。
我的实现方案是基于ReAct框架做扩展。ReAct的核心是“思考-行动-观察”的循环，但在实际落地时，我发现纯ReAct有几个坑：
坑一：无限循环。模型可能反复调用同一个工具，陷入死循环。我的解决方案是设置最大迭代次数（通常5-8次），同时加入重复检测——如果连续两次调用的工具和参数高度相似，强制中断并返回当前结果。
坑二：工具选择困难。当可用工具超过10个时，模型的选择准确率会明显下降。我的做法是工具分组，先让模型选择工具类别，再在类别内选择具体工具。比如先选“知识检索类”，再选“向量检索”或“关键词检索”。
坑三：决策不可解释。模型为什么选这个工具、为什么传这个参数，如果不记录下来，出了问题根本没法调试。我强制要求模型在每次Function Calling前输出一段决策理由，这段理由会记入日志，方便后续分析。
# 行动决策的Prompt模板（简化版） DECISION_PROMPT = """ 你是一个智能助手，需要根据当前对话历史和已有信息，决定下一步行动。 当前已知信息： {context} 用户问题：{question} 可用工具： {tools_description} 请按以下格式输出你的决策： 思考：分析当前信息是否充分，还需要什么信息 行动：选择要调用的工具名称 参数：传给工具的参数（JSON格式） 理由：为什么选择这个工具和参数 """2.3 Function Calling的工程化落地
Function Calling是把RAG和行动决策粘合起来的关键技术。但很多人在落地时只关注“能不能调通”，忽略了工程化细节。
工具描述的质量决定调用准确率。我见过太多项目把工具描述写得极其简略，比如search(query: string)，结果模型根本不知道什么时候该用这个工具。我的经验是，工具描述要包含：功能说明、适用场景、参数含义、返回值格式、使用示例。描述越详细，模型调用越准确。
参数校验不能省。模型生成的参数不一定合法，比如传了不存在的字段、类型不对、值超出范围。我通常在工具执行前加一层参数校验，校验失败时返回明确的错误信息给模型，让模型重新生成参数。这比直接抛异常要好得多，因为模型有机会自我修正。
异步执行与超时控制。检索工具可能耗时较长，如果同步执行会阻塞整个Agent流程。我通常把工具调用设计成异步的，同时设置超时时间（一般5-10秒），超时后返回“检索超时”让模型决定是否重试或换策略。
| 工程化要点 | 常见问题 | 我的解决方案 |
|---|---|---|
| 工具描述 | 过于简略导致误调用 | 包含功能、场景、参数、示例五要素 |
| 参数校验 | 模型生成非法参数 | 执行前校验，失败返回错误让模型重试 |
| 超时控制 | 工具执行阻塞流程 | 异步执行+超时中断+降级策略 |
| 结果格式化 | 返回值模型看不懂 | 统一返回结构化JSON，附带自然语言摘要 |
| 调用日志 | 出问题无法追溯 | 记录每次调用的输入、输出、耗时、决策理由 |
2.4 记忆模块与上下文管理
Agent架构下，记忆模块的重要性被严重低估。传统RAG基本不涉及记忆，但Agent需要维护对话历史、工具调用记录、中间结果等多层状态。
我的做法是把记忆分成三层：
短期记忆（Working Memory）。当前对话轮次内的上下文，包括用户问题、模型思考、工具调用结果。这部分直接放在Prompt里，但要注意Token预算控制，超过阈值时做摘要压缩。
长期记忆（Long-term Memory）。跨对话轮次的信息，比如用户偏好、历史任务结果。我通常用向量数据库存储，需要时检索召回。这里有个坑：长期记忆的检索要和知识库检索区分开，否则会互相干扰。
程序性记忆（Procedural Memory）。Agent在执行任务过程中积累的“经验”，比如“这类问题用A工具效果更好”。这部分我一般用规则引擎或者小模型来实现，不直接放进大模型上下文。
上下文管理的核心是Token预算分配。我的经验值是：系统Prompt占20%，对话历史占30%，检索结果占40%，工具描述占10%。超过预算时，优先压缩对话历史，检索结果做摘要，工具描述只保留当前可能用到的。
3. 完整实操流程与核心环节实现
3.1 环境准备与基础组件搭建
动手之前，先把基础环境搭好。我以Python技术栈为例，列出核心依赖：
# 核心依赖 pip install langchain langchain-openai chromadb sentence-transformers pip install fastapi uvicorn # 如果需要暴露API pip install rank-bm25 # 关键词检索向量数据库我选Chroma，原因是轻量、本地可跑、API简单。生产环境可以考虑Milvus或Qdrant，但开发阶段Chroma足够。Embedding模型我用的是BGE-M3，中文效果好，而且支持多语言。重排序模型用BGE-Reranker-v2，和Embedding模型配套。
# 初始化核心组件 from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma from sentence_transformers import CrossEncoder # Embedding模型 embedding_model = HuggingFaceEmbeddings( model_name="BAAI/bge-m3", model_kwargs={'device': 'cuda'}, encode_kwargs={'normalize_embeddings': True} ) # 向量数据库 vector_store = Chroma( collection_name="knowledge_base", embedding_function=embedding_model, persist_directory="./chroma_db" ) # 重排序模型 reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")注意：Embedding模型和重排序模型不要用同一个。Embedding负责粗筛，重排序负责精排，两者分工不同。用同一个模型会导致精度下降。
3.2 知识库构建与切块策略
切块策略直接决定检索质量。我试过固定长度切块、按段落切块、按语义切块，最后发现混合切块效果最好。
具体做法是：先按文档结构（标题、段落）做粗切，再对超过阈值的长段落做语义切分。切块长度我一般控制在300-500字，重叠50-100字。太短了语义不完整，太长了检索精度下降。
from langchain.text_splitter import RecursiveCharacterTextSplitter # 混合切块策略 text_splitter = RecursiveCharacterTextSplitter( chunk_size=400, chunk_overlap=80, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""], length_function=len, ) # 对文档做切块 chunks = text_splitter.split_documents(documents) # 存入向量库 vector_store.add_documents(chunks)这里有个细节：切块时要保留元数据。比如chunk来自哪个文档、哪个章节、第几页。这些元数据在检索后可以用来做过滤和引用标注。我见过很多项目切完块只存文本，结果检索回来不知道出处，没法给用户展示引用来源。
3.3 Agent主循环的实现
Agent主循环是整个架构的心脏。我用的是ReAct+Function Calling的混合模式，核心逻辑如下：
import json from typing import List, Dict class RAGAgent: def __init__(self, llm, tools, max_iterations=6): self.llm = llm self.tools = {t.name: t for t in tools} self.max_iterations = max_iterations def run(self, question: str, history: List[Dict] = None): history = history or [] context = [] for i in range(self.max_iterations): # 构建决策Prompt prompt = self._build_prompt(question, history, context) # 模型决策 response = self.llm.generate(prompt) decision = self._parse_decision(response) # 如果模型决定直接回答 if decision["action"] == "final_answer": return decision["answer"] # 执行工具调用 tool_name = decision["action"] tool_args = decision["params"] if tool_name not in self.tools: context.append(f"错误：工具 {tool_name} 不存在") continue try: result = self.tools[tool_name].execute(**tool_args) context.append(f"工具 {tool_name} 返回：{result}") except Exception as e: context.append(f"工具 {tool_name} 执行失败：{str(e)}") # 超过最大迭代次数，强制生成答案 return self._force_answer(question, context) def _build_prompt(self, question, history, context): # 构建包含工具描述、历史、上下文的Prompt pass def _parse_decision(self, response): # 解析模型输出的决策 pass这个循环的核心是：模型每轮都可以选择“继续调用工具”或“给出最终答案”。我通常会在Prompt里明确告诉模型：“如果你认为当前信息已经足够回答问题，请直接输出最终答案；如果还需要更多信息，请调用相应工具。”
3.4 检索工具的具体实现
检索工具是Agent最常调用的工具。我的实现包含三个子功能：向量检索、关键词检索、混合检索。模型可以根据问题类型选择不同的检索方式。
class RetrievalTool: name = "retrieve_knowledge" description = """ 从知识库中检索相关信息。 适用场景：需要查找事实、定义、流程、政策等知识性内容时使用。 参数： query (str): 检索查询词，建议使用完整的问题或关键词组合 top_k (int): 返回结果数量，默认5，最大10 search_type (str): 检索方式，可选 vector/keyword/hybrid，默认hybrid 返回：相关文档片段列表，每个片段包含内容和来源 """ def execute(self, query: str, top_k: int = 5, search_type: str = "hybrid"): if search_type == "vector": results = vector_store.similarity_search(query, k=top_k) elif search_type == "keyword": results = bm25_search(query, top_k=top_k) else: results = hybrid_retrieve(query, top_k=top_k) # 格式化返回结果 formatted = [] for r in results: formatted.append({ "content": r.page_content, "source": r.metadata.get("source", "未知"), "score": r.metadata.get("score", 0) }) return json.dumps(formatted, ensure_ascii=False)提示：工具描述里的“适用场景”非常重要。模型会根据这个描述判断什么时候该调用这个工具。如果描述写得太泛，模型可能会在不该检索的时候也去检索，浪费Token和时间。
3.5 多轮对话与上下文压缩
多轮对话场景下，上下文会越来越长。我的处理策略是滑动窗口+摘要压缩。
具体做法：保留最近3轮完整对话，更早的对话做摘要。摘要用一个小模型生成，控制在200字以内。检索结果如果超过Token预算，也做摘要处理。
def compress_context(history, max_tokens=2000): """压缩对话历史，保留最近3轮完整，更早的做摘要""" if len(history) <= 3: return history recent = history[-3:] older = history[:-3] # 对更早的对话做摘要 summary_prompt = f"请用200字以内总结以下对话的核心信息：\n{older}" summary = llm.generate(summary_prompt) return [{"role": "system", "content": f"历史对话摘要：{summary}"}] + recent实测下来，这种压缩策略能在保持90%以上信息完整度的同时，把Token消耗降低60%左右。
4. 常见问题与排查技巧实录
4.1 检索质量问题的排查思路
检索质量差是RAG+Agent项目最常见的问题。我一般按以下顺序排查：
第一步：检查切块质量。把检索回来的片段打印出来，看是否语义完整。如果片段被切得支离破碎，说明切块策略有问题。我遇到过把一句话切成两半的情况，检索回来两个片段各半句话，模型根本看不懂。
第二步：检查Embedding模型。用几个典型问题测试Embedding的相似度计算。如果明显相关的文本相似度很低，可能是模型选错了，或者没有做归一化。BGE系列模型必须做normalize_embeddings=True，否则相似度计算会偏。
第三步：检查检索参数。Top K设太小会漏召回，设太大会引入噪声。我一般先用Top 20做召回，再用重排序精排到Top 5。如果重排序后仍然不准，说明重排序模型需要换。
第四步：检查查询改写。用户原始问题可能不适合直接检索。我通常会在检索前加一步查询改写，把口语化问题转成结构化查询。这一步对多轮对话场景尤其重要。
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 检索结果不相关 | Embedding模型不匹配 | 测试相似度计算 | 换模型或微调 |
| 漏召回关键信息 | Top K太小或切块太碎 | 检查召回列表 | 增大Top K，调整切块 |
| 检索结果重复 | 切块重叠过大 | 检查chunk_overlap | 减小重叠或去重 |
| 多轮对话检索漂移 | 查询未改写 | 对比原始查询和改写查询 | 加入查询改写步骤 |
| 检索速度慢 | 向量库索引未优化 | 检查索引类型 | 换HNSW索引或加缓存 |
4.2 Agent决策异常的调试方法
Agent决策异常通常表现为：该检索的时候不检索、不该检索的时候乱检索、反复调用同一个工具、参数传错。
我的调试方法是全链路日志。每次Agent决策，我都记录以下信息：当前轮次、模型输入Prompt、模型输出决策、工具调用参数、工具返回结果、耗时。把这些日志按时间线排列，基本能定位到问题出在哪一环。
# 决策日志记录 def log_decision(iteration, prompt, decision, tool_result, elapsed): log_entry = { "iteration": iteration, "prompt_tokens": count_tokens(prompt), "decision": decision, "tool_result_preview": str(tool_result)[:200], "elapsed_ms": elapsed } logger.info(json.dumps(log_entry, ensure_ascii=False))我遇到最多的一个坑是：模型在信息已经足够的情况下仍然继续检索。原因是Prompt里没有明确告诉模型“什么时候可以停止”。后来我在Prompt里加了一句：“如果你已经能够回答问题，请直接输出最终答案，不要继续调用工具。”这个问题就基本解决了。
另一个坑是工具参数格式错误。模型有时候会传{"query": "xxx", "top_k": "5"}，top_k是字符串而不是整数。我的解决方案是在工具执行前做参数类型转换和校验，不合法就返回错误让模型重试。
4.3 性能优化的实战经验
Agent架构的性能瓶颈通常在两个地方：LLM调用次数和检索延迟。
减少LLM调用次数。每次Agent循环都要调一次LLM，如果循环5次就是5次LLM调用。我的优化策略是：简单问题走快速通道，不进入Agent循环，直接检索+生成。只有复杂问题才走完整Agent流程。判断标准可以用一个小的分类模型，或者用规则引擎（比如问题长度、是否包含多个实体、是否涉及比较/推理）。
降低检索延迟。向量检索的延迟主要来自Embedding计算和向量相似度搜索。Embedding计算可以用GPU加速，向量搜索可以用HNSW索引。我实测下来，HNSW索引比暴力搜索快10倍以上，精度损失在可接受范围内。
缓存策略。高频问题的检索结果可以缓存。我用Redis做检索结果缓存，Key是查询词的哈希，Value是检索结果。缓存命中率在真实场景下能达到30%左右，对降低平均延迟帮助很大。
import hashlib import redis cache = redis.Redis(host='localhost', port=6379) def cached_retrieve(query, top_k=5): cache_key = hashlib.md5(f"{query}_{top_k}".encode()).hexdigest() cached = cache.get(cache_key) if cached: return json.loads(cached) results = hybrid_retrieve(query, top_k) cache.setex(cache_key, 3600, json.dumps(results, ensure_ascii=False)) return results注意：缓存要设置合理的过期时间。知识库更新后，旧缓存会导致检索结果过时。我一般设置1小时过期，同时在知识库更新时主动清除相关缓存。
4.4 边界控制与降级策略
Agent架构不是万能的，必须设置边界和降级策略。
最大迭代次数。我一般设5-8次。超过之后强制生成答案，即使信息不完整。这比无限循环要好，至少能给用户一个响应。
工具调用超时。每个工具调用设置超时时间，一般5-10秒。超时后返回“工具执行超时”，让模型决定是否重试或换工具。
降级到传统RAG。如果Agent流程失败（比如超过最大迭代次数、工具全部超时），降级到传统RAG流程，直接检索+生成。虽然效果可能差一些，但至少能给出答案。
人工兜底。对于Agent无法处理的问题，提供人工入口。我在实际项目中会记录所有Agent失败的问题，定期分析，看是知识库缺失还是Agent能力不足，针对性优化。
def agent_with_fallback(question): try: # 尝试Agent流程 result = agent.run(question) if result and result.get("confidence", 0) > 0.7: return result except Exception as e: logger.error(f"Agent执行失败：{e}") # 降级到传统RAG try: return traditional_rag(question) except Exception as e: logger.error(f"传统RAG也失败：{e}") # 最终兜底 return {"answer": "抱歉，我暂时无法回答这个问题，请尝试换个问法或联系人工客服。"}5. 融合架构的边界与选型建议
5.1 什么场景适合Agentic RAG
不是所有场景都值得上Agent架构。我根据项目经验，总结了一个场景分级表：
| 场景级别 | 问题特征 | 推荐架构 | 理由 |
|---|---|---|---|
| L1 | 单事实查询，如“XX是什么” | 传统RAG | 一次检索足够，Agent反而增加延迟 |
| L2 | 多事实查询，如“XX和YY的区别” | 传统RAG+多路检索 | 需要多路召回，但不需要动态决策 |
| L3 | 多跳推理，如“XX政策对YY业务的影响” | Agentic RAG | 需要多轮检索和推理 |
| L4 | 多工具协同，如“查数据+做分析+生成报告” | 完整Agent | 需要工具编排和动态决策 |
我的建议是：从L1-L2做起，跑通之后再逐步扩展到L3-L4。不要一上来就搞完整Agent，复杂度太高，调试成本太大。
5.2 成本与效果的平衡点
Agent架构的成本主要来自LLM调用次数和Token消耗。我实测过一个中等复杂度的L3问题，传统RAG消耗约2000 Token，Agentic RAG消耗约8000 Token，是前者的4倍。但准确率从60%提升到了85%。
这个账怎么算？我的经验是：看业务价值。如果是客服场景，准确率提升25个百分点意味着人工介入率大幅下降，省下来的人力成本远超Token成本。但如果是内部工具，用户对准确率要求没那么高，传统RAG可能更划算。
另一个优化方向是模型分级。Agent的决策环节可以用小模型（比如7B参数），只有最终生成答案用大模型。这样能在保持效果的同时降低成本。
5.3 后续扩展方向
这个架构跑通之后，有几个自然的扩展方向：
多模态检索。除了文本，还可以检索图片、表格、PDF。我最近在试的是用多模态Embedding模型做图文混合检索，效果还在验证中。
主动学习。记录Agent失败的问题，定期人工标注，用来微调检索模型或决策模型。这是一个持续优化的闭环。
多Agent协同。复杂任务可以拆给多个Agent，每个Agent负责一个子领域。比如一个负责检索，一个负责分析，一个负责生成报告。这需要设计Agent之间的通信协议和任务分配机制。
评估体系。Agent的效果评估比传统RAG复杂得多。我目前在用的是端到端评估+过程评估结合的方式。端到端看最终答案质量，过程评估看每一步决策是否合理。过程评估的数据来自全链路日志。
我个人在实际操作中的体会是：Agent架构的复杂度是传统RAG的3-5倍，但能解决的问题范围也是3-5倍。关键是想清楚你的业务场景到底需要哪一档的能力，不要为了技术而技术。先把传统RAG做到极致，如果确实遇到了天花板，再考虑上Agent。这个顺序不能反。
