从懵到通LLM、RAG与Agent它们到底在争什么这段时间被问得最多的问题不是某个模型又刷榜了而是“我已经接了LLM的API为什么还要搞RAG”“Agent是不是以后会把RAG干掉”“这三样东西放到项目里到底该怎么选、怎么搭”说实话这些问题背后反映的不是工具焦虑而是概念体系的混乱——LLM、RAG和Agent被包装成了三个互不相干的“产品”但实际上它们是解决不同层级问题的技术方案彼此之间不是替代关系而是配合关系。这篇文章我想把三者的本质差异、各自解决的核心问题、在真实项目中的选型边界以及组合使用时的常见坑一次性讲透。内容不追新、不追热只讲那些放到两年后回头看依然成立的东西。适合正在做技术选型的开发者、刚接触大模型应用的产品经理以及所有被“RAG已死”“Agent为王”这类论调搞糊涂的朋友。1. 三者的本质差异一个管记忆一个管知识一个管行动1.1 大语言模型不是“知识库”是“模型”很多人对LLM最大的误解是把它当成一个可以随时检索的百科全书。实际上大语言模型本质上是一个参数化的概率模型——它在训练阶段把海量文本中的统计规律压缩进几十亿、几百亿甚至上千亿的参数里在推理阶段根据你给的上下文逐字预测下一个token。这个机制的优点是“什么都懂一点”缺点是三个硬伤知识有截止日期训练数据采集截止那天就是它知识的“保质期”终点。之后的新闻、产品更新、内部制度它一概不知道。会一本正经地胡说八道因为它生成的是“听起来合理的文本”而不是“查证后的事实”所以遇到没见过的内容它更倾向于编造而不是承认不知道。无法自主获取外部信息它的所有输出都基于参数和上下文窗口内的内容没有主动去读数据库、调接口、查文档的能力。我用一个类比来理解LLM像一个记忆力超强、读过很多书但与社会脱节的“学者”。你问它理论问题它能引经据典你问它“公司最新的报销流程是什么”它只能凭印象瞎编。所以如果你的应用场景只需要模型具备通用常识、文案生成、代码补全、逻辑推理能力那直接用LLM就够了。但一旦牵涉到“最新信息”或“私有数据”它必须借助外部机制。1.2 RAG给“学者”配一本随时可查的参考书检索增强生成Retrieval-Augmented Generation解决的就是上面说的第二和第三个硬伤。它的核心思路非常朴素模型不知道没关系你先从外部数据库里把相关内容找出来塞进上下文里让它基于这些材料来回答。所以RAG的本质不是修改模型本身而是在“用户提问”和“模型生成”之间加了一个检索层。这个检索层负责把用户的问题转成向量到文档库里找最相似的片段再把片段作为上下文拼接进Prompt最后交给LLM生成回答。这里有个关键认知RAG改变的不是模型的“大脑”而是模型的“输入”。模型还是那个模型但因为拿到了相关资料它就能答出准确、可追溯的内容并且可以随时更新外部文档库——换资料就等于换知识不需要重新训练模型。如果继续用类比RAG就是给学者配了一间资料室。学者本身没变但他回答问题时可以先翻资料再开口不再凭空瞎编。这也是为什么RAG成为目前企业落地大模型应用的最常用方案——它用最小的改造成本解决了“私有知识注入”和“知识实时更新”这两个最痛的问题。1.3 Agent从“回答问题”到“完成任务”如果说LLM是“能思考的大脑”RAG是“资料室”那Agent就是“能动手做事的人”。智能体的核心特征在于它不只是根据输入生成一次输出而是能够自主进行多步决策调用外部工具观察结果调整策略直到完成一个目标。一个典型的Agent工作循环是这样的接收一个较为宏观的目标比如“帮我订一张下周去上海的火车票预算500以内靠窗位置”。模型先做任务拆解查车次→筛选价格→看座位图→下单。每拆出一个子步骤就调用一次对应的工具查票API、下单API。工具返回结果模型判断这一步成没成、下一步怎么做比如“没有靠窗票那就换一个车次再查”。直到所有子任务完成汇总输出最终结果。注意这个过程不是预先写死的脚本而是模型基于当前状态动态生成的决策序列。同一个目标给不同模型或不同上下文拆解出的步骤可能完全不一样。这种“自主规划工具调用结果反馈”的能力才是Agent和普通API调用的本质区别。继续用类比Agent是一个既懂业务、又会使用工具、还能自己做判断的员工。他不只是问什么答什么而是会主动规划、执行、纠错。1.4 一句话总结三者的关系维度LLMRAGAgent解决的问题语言理解与生成知识与信息的实时获取任务规划与自主执行核心机制参数化概率生成检索上下文注入决策循环工具调用输入用户指令用户指令检索结果用户目标环境反馈输出文本有依据的文本行动结果可能含文本类比专家大脑参考书/资料室动手干活的员工典型难点幻觉、知识过期检索质量、切分策略决策可靠性、错误恢复LLM是底座RAG是知识插件Agent是行为框架。它们不会互相取代因为解决的不是同一层的问题。理解了这一点后面的选型和架构问题就都好谈了。2. 拆开RAG看细节从检索到注入整条链路的每一环都可能掉链子RAG听起来简单——查资料、拼上下文、让模型回答。但在真实项目里把这三个词展开成工程实现会牵出一大堆决定成败的细节。我做过的每个RAG项目踩坑的地方基本都集中在下面几个环节。2.1 文档切分这一刀切不好后面全白搭RAG的第一步是把文档库“切”成可供检索的片段。切分策略直接决定了两件事检索命中率以及上下文的有效性。切得太粗比如把整个章节切成一个块检索时相关片段会混入大量无关内容既浪费上下文窗口又稀释答案的准确性。切得太细比如按单句话切又会导致语义不完整同一个知识点被腰斩成好几段模型拿到的是信息的碎片。我的经验是先按文档原有结构粗切再按语义边界细调。以一份技术手册为例第一步按标题或章节切保证每块有相对完整的主题。第二步检查每块的长度超过1000字或低于200字的再根据段落语义做合并或拆分。第三步对表格、代码块这类特殊格式做单独处理因为它们天然不适合按纯文本切分。切分的本质是“保留语义完整性的同时把检索粒度控制在合理范围”。现在有很多智能切分工具按句子嵌入相似度动态切分但我个人建议在项目初期先用固定长度标题层级就够了先跑通流程再优化切分策略。2.2 向量化与检索Embedding选型、相似度算法与重排切好的文档块接下来要被Embedding模型转换成向量。选Embedding模型时最关键的指标不是它的名气而是和你的中文语料的适配度。不同模型在通用文本、法律文书、代码片段上的表现差异很大建议拿你们真实的业务文档做小范围评测后再定。检索阶段最常见的是余弦相似度或向量数据库自带的近似最近邻搜索。这里有个坑TopK召回不等于模型能答对。比如技术FAQ场景里一个问题往往涉及多个方面——“这个功能怎么开启支持哪些平台有什么限制”——单靠最相似的1~2段内容极容易漏掉信息。所以在Retrieval之后我强烈建议加重排序Rerank环节。初次召回可以取Top 20再用重排序模型或基于规则的过滤精挑到Top 3~5作为上下文。这一步通常能让准确率上一个台阶尤其是文档库规模上来之后效果差异会非常明显。# 示意检索与重排的完整调用流程 from utils import get_embedding, vector_search, rerank query 如何开通企业版有哪些限制 query_vector get_embedding(query) # 第一步向量检索召回 Top 20 candidates vector_search(query_vector, top_k20) # 第二步重排序压缩到 Top 5 作为上下文 final_context rerank(query, candidates, top_k5) # 第三步拼装 Prompt 并调用模型 prompt f请基于以下资料回答问题\n{final_context}\n\n用户问题{query} response call_llm(prompt)2.3 上下文注入的格式远比想象中重要文档检索回来以后怎么“喂”给模型是个看似简单、实则讲究的活。直接在Prompt开头堆资料和精心设计资料的组织格式效果差距可能大到离谱。我习惯的做法是在Prompt里为每个文档块标注来源元数据比如“以下内容来自《产品帮助文档》第2.3节《权限说明》”然后明确告诉模型优先参考资料内容资料中未提及的部分要明确说明“资料中没有提到”绝不允许自行补充或编造。还有一个容易被忽略的细节是上下文顺序。把最相关的文档块放在离问题更近的位置对答案质量有正向影响。很多模型对长上下文的“注意力分布”并不是均匀的中间部分的信息容易被忽略头部和尾部的信息留存率更高。基于这个特性我会把最核心的检索结果放在Prompt的尾部紧挨着用户问题那一段。2.4 RAG落地时最容易忽视的三个评估指标大多数RAG项目上线前只测“回答得对不对”这远远不够。我至少会关注三个指标检索命中率Recall正确答案是否出现在召回的Top K里。如果答案根本不在上下文里模型再强也巧妇难为无米之炊所以这一步是RAG效果的天花板。答案忠实度Faithfulness模型回答的内容是否都来源于资料有没有“自由发挥”。这一项需要人工判断或另用模型打分。回答完整率Completeness用户问题涉及的多个子问题是否都被回答到不能漏点。这三个指标分别对应RAG链条上的不同环节——命中率管检索忠实度管注入和生成完整率管整体流程设计。上线之前至少拿50条真实问题跑这三项评估再谈效果优化。否则上线之后一堆“答非所问”和“看似正确实则编造”的翻车案例会让你怀疑人生。3. Agent不是“写个Function Calling就行”核心是决策循环和状态管理3.1 重新理解“工具调用”这只是一个起点很多朋友一听说Agent就说“不就是Function Calling嘛我给模型注册几个函数它能选着调用就完事儿了”。这话只对了一半。Function Calling确实是Agent的技术底座——它让模型具备了“发出工具调用指令”的能力。但这个能力本身只是一个“动作”Agent真正难的是怎么决定在当前状态下该调用哪个工具、怎么解读返回结果、下一步该干什么。举个很常见的例子用户问“帮我查下订单号A10086的物流信息如果已经签收了就不用再提醒我了。”这个任务看似简单但Agent需要判断先查物流信息这是一个工具调用。看返回结果是“已签收”触发一个条件判断——既然不用提醒那后续步骤就不要再执行了。把“不提醒”这个决定以合适的语气回复给用户。如果只是机械地调用工具、把原始结果吐给用户那就不叫智能体只是一个“接口封装器”。真正的决策能力体现在根据上一轮结果动态规划下一轮动作甚至在发现条件不满足时主动调整计划。3.2 一个可运行的Agent核心循环ReAct模式目前业界最主流、也最适合作为起点的Agent模式是ReAct——Reasoning Acting即“思考行动”的循环。它的流程可以简化为观察Observation当前的用户输入或工具返回结果思考Thought下一步该怎么办行动Action调用某个工具或者直接给出最终答复循环直到任务完成。下面我用一个非常简化的Python示意来说明这个循环的结构重点不在于完整实现而在于理解它的组织方式# Agent核心循环简化示意 import json def run_agent(user_request, tools, max_steps10): messages [{role: user, content: user_request}] for step in range(max_steps): response llm_with_functions(messages, toolstools) # 如果模型直接给出最终答复则结束 if response.get(finish_answer): return response[finish_answer] # 否则模型会请求调用某个工具 tool_name response[tool_call][name] tool_args response[tool_call][arguments] # 执行工具拿到结果 tool_result run_tool(tool_name, tool_args) # 把工具结果作为“观察”带回给模型 messages.append({role: tool, content: json.dumps(tool_result)}) return 步骤超过上限强制退出这里有几个容易被忽略的工程细节每轮工具结果都要追加进messages因为模型下一次决策必须基于上一轮的观察结果不能丢掉状态。必须设置最大步数防止Agent陷入死循环这在真实生产系统里是保命条款。工具结果要结构化成精简文本别把几十KB的原始JSON全部塞回上下文那会把模型“淹死”。3.3 工具怎么设计决定了Agent的天花板Agent的能力边界很大程度取决于你给它配了哪些工具。一个只会写代码、但没法执行代码的Agent和能编译运行并读取测试结果的Agent是两种完全不同的生物。我在设计工具集时有三个原则接口尽量原子化一个工具只干一件事。比如“查天气”和“查空气质量”分开“发送邮件”不做“同时抄送给多人”的复杂参数。粒度越细Agent按需组装的空间越大。返回结果带状态和错误码工具不仅要返回数据还要返回执行成功与否。Agent需要知道“这个动作有没有生效”才能决定下一步。工具描述必须写清楚适用场景比如一个“根据产品ID查生产状态”的工具描述里要写明“当用户询问生产进度或物流发货状态时使用”。描述写得模糊模型就不知道该在什么时候选这个工具。3.4 Agent的三个经典翻车场景与规避规划幻觉模型把任务拆成了能力之外的步骤比如让它搜索实时信息但根本没给搜索引擎工具。结果它编造了一个“搜索成功”的结果继续往下走。规避方法所有子任务必须映射到实际存在的工具模型输出计划时要做一次“工具可用性校验”。状态丢失Agent在第三步的时候忘了第一步的结论导致重复提问或前后矛盾。规避方法把关键约束在每一轮思考中都重复注入一次或者用结构化记忆块保存中间结论。错误恢复能力差工具返回“权限不足”或“查无此单”模型就愣住了。规避方法在工具描述中为常见错误结果提前写清楚后续建议动作。比如“权限不足时应当向用户说明当前账号没有该操作权限并询问是否需要更换账号”。Agent的上限不是模型聪明与否而是工程化程度有多高。工具设计、状态管理、错误恢复和强制终止条件这四件事做扎实了Agent才能真正进入生产环境。4. 实战选型推演同一个项目三种架构的答案完全不同理论讲得再多不如推演一个落地的场景来得直观。我们用一个很典型的企业应用来做对比某企业内部知识库问答助手用于回答员工关于报销流程、IT支持、人事政策等问题。4.1 方案A只用LLM不加RAG也不做Agent你把员工的提问直接发给通用大模型让它回答。优点搭建最快一个小时就能出Demo成本最低。适应于“公司规章制度变化不大、问题多为通用概念解释”的场景比如“什么是年假”“报销单要填哪些字段”。后果也很直接问“2025年第一季度最新差旅标准”这类涉及具体时效性信息的问题时模型大概率会给出过期或不准确的答案。更麻烦的是它可能把A制度里的一条内容套到B流程的提问上员工照着做就出错。结论适合做演示和低风险场景不能用于真实的企业制度查询。4.2 方案BLLM RAG注入制度文档把公司全部制度、流程文档做好切分、向量化员工提问时先检索再让模型回答。这个方案能覆盖大部分真实问答场景而且有几个看得见的好处答案可追溯到具体制度原文员工如果不信可以附上“来源报销管理制度第3.2节”。制度更新时只需要重新索引新文档不需要动模型。回答“不知道”的时候可以明确说“资料中没有相关内容”避免瞎编。代价是你要维护一套文档切分、向量库、检索服务的链路还要持续做评估优化。但对大多数知识库场景来说这个复杂度是值得的。结论目前性价比最高的方案是知识库问答类应用的最优起点。4.3 方案CLLM RAG Agent加一层“会办事”的能力在这个场景里光答问题是不能满足所有需求的。员工除了“问政策”还希望“办事情”“我的报销单被退回了帮我看看驳回原因并起草一份补充说明。”“帮我查一下我去年还剩几天年假如果今年安排了培训我想约在3月的某个周五。”这些诉求就不再是“查资料回答”而是“查数据、写文档、走流程”的组合任务。这时候需要给系统接入公司内部系统比如OA系统单据查询接口、假勤系统余额接口、日程管理接口。然后让Agent拆解任务、调用工具、逐步完成。4.4 三个方案的效果对比表维度纯LLMLLM RAGLLM RAG Agent问题类型通用知识、常识文档知识问答多步骤业务办理知识更新需要重新训练更新文档库即可更新文档库即可多步操作不支持不支持支持工程复杂度极低中高典型成本API调用费向量库检索服务工具开发流程编排推荐场景原型、泛聊知识问答、客服辅助业务联动、流程自动化推演到这里你就明白了选型不是“哪个更高级就选哪个”而是“根据任务类型选架构”。80%以上的企业对话场景其实用B方案就够了。为了显得“先进”硬上Agent反而引入更多不确定性和维护成本。5. 组合使用与避坑实录把RAG和Agent真正放进一个系统里最后聊一个我实践中反复使用、也反复踩坑的架构Agent外部挂RAGRAG内部养Agent。这句话听起来玄乎拆开讲就很清楚了。5.1 两种组合方式外挂式与内嵌式第一种组合是“Agent作为主控RAG作为工具”。Agent负责理解用户目标、拆解任务RAG作为其中一个子能力被调用。比如用户说“写一篇关于公司年度团建方案的提案”Agent先规划然后调用RAG检索公司往年的团建记录和预算制度再结合LLM的文案能力生成完整提案。第二种组合是“RAG作为主链路Agent作为深度追问处理器”。先走RAG答一轮如果模型判断“资料不足以回答”就触发Agent去查关联系统、做多步检索、回来整合答案。这种设计适合文档库很大、且经常需要跨多个文档综合回答的场景。两种组合不冲突关键看谁当主控。我的经验是对多数应用让Agent当主控更自然因为它能自主决定“什么时候该查、该查什么、查完以后怎么处理”。5.2 上下文窗口的分配这个坑我进过三次把RAG和Agent组合起来后最大的坑是上下文窗口不够用而且不够用的方式和你想的不一样——不是“塞不下”而是“塞进去但模型处理不过来”。一个Agent流程可能有8到10轮工具调用每轮的工具结果都要留在上下文里加上RAG检索回来的文档块Tokens消耗非常快。更麻烦的是模型在大量历史信息中生成最终答案时早先的观察结果的“记忆权重”会被稀释。我采用的三个对策中间过程摘要化每完成一个子任务把详细执行结果压缩成一段摘要再放回上下文原始结果存外部存储不占据上下文空间。上下文窗口预留配额专门为RAG结果预留窗口空间比如总窗口是32K tokens最多只允许RAG部分占8K超出则做摘要或分批处理。分阶段对话超长任务拆成多个短对话每个对话重新建立上下文关键信息通过结构化笔记跨阶段传递。5.3 评测是组合架构的“逃生舱”RAG和Agent组合起来后链路变长任何一个环节出错都会导致最终结果不对。这时候没有评测体系排查问题无异于大海捞针。我的做法是建立三层评测单环节评测单独测检索命中率、工具调用正确率、任务拆解合理性每个环节独立打分。端到端评测用一个包含200条真实业务问题的问题集跑完整链路人工或模型打分。回归评测每次更新文档、换模型、改Prompt后跑一遍同样的测试集对比分数变化。这一步能帮你及时发现“改了这个影响了那个”的隐形连锁反应。没有评测体系的RAGAgent系统就像一个没有仪表盘的飞行员——飞得起来但永远不知道什么时候会出事。5.4 另一个容易忽略的问题多轮对话的记忆边界很多人在组合架构里栽在“多轮对话”上用户第一轮说“帮我查一下上海出差补贴标准”第二轮说“那杭州的呢”——如果系统没有把“出差补贴标准”这个主题跨轮保存下来第二轮的“那杭州的呢”就变成了一个孤立的问题。处理办法是给每个用户会话维护一个“对话记忆槽”把用户的目标、关键实体、已经确认的条件以结构化字段存下来。每一轮处理时把记忆槽内容和当前问题一起发给Agent。注意这个记忆槽是一个离散的、结构化的信息块不是把历史聊天记录整个拼进Prompt。5.5 成本控制组合架构烧钱烧得比你想象快最后提醒一个务实的问题——成本。RAGAgent的组合单次用户请求的Token消耗量往往是纯LLM方案的5到10倍。原因是多轮工具调用会产生大量中间结果检索到的文档块也占Token最终的汇总输出反而只占一小部分。如果不做成本控制一个To C产品上线后光是模型调用费就能吃掉相当可观的利润空间。我能给出的实操建议是对每个Agent任务设定工具调用次数上限比如最多5次超出则强制收敛到“基于已有信息回答”。对不同的任务类型使用不同规模的模型——简单问答用轻量模型复杂规划才用大模型。建立Token消耗的按会话监控出异常及时干预。一些真正落地的体会把LLM、RAG和Agent放到同一个工程体系里我最大的感受是概念边界越清晰工程落地越从容。很多项目烂尾不是因为技术不够新而是从一开始就把“知识检索”和“任务执行”混为一谈——该用RAG的地方非要上Agent该用Agent的任务偏偏只接了个Prompt。选型之前先问清楚自己的业务问题到底是“不知道”还是“不会做”答案自然就浮出水面了。最后分享一个我最近常挂在嘴边的小技巧当团队为一个功能应该用RAG还是Agent争论不休时让他们各自用一句话回答“这个功能的核心是获取信息还是执行动作”——如果语气偏向获取信息就规规矩矩走RAG如果偏向执行动作再谈Agent的规划链。大多数争论到这一步就散了。
