大模型时代很多人都在聊 LLM、RAG、AI Agent但说实话这三个词看起来热得发烫真正能讲清楚它们之间到底是什么关系、各自解决什么问题、上手时从哪里切入最合适的人其实并不多。作为一个在相关方向折腾了挺久的从业者我想用这篇文章把这三件事一次性讲透——不是教科书式地堆概念而是从实际开发和应用的角度把“它们分别是什么、为什么需要、怎么落地、有哪些坑”完整地梳理一遍。无论你是刚接触大模型的应用开发者、技术产品经理还是被各种术语轰炸的爱好者这篇文章都适合你。读完之后你至少能明白LLM 是大模型应用的“大脑底座”RAG 是给大脑外挂知识库和记忆体的方案AI Agent 则是让大模型从“回答问题”进化为“完成任务”的关键形态。三者的组合构成了当前大模型应用开发最主流的技术骨架。1. 内容整体设计与思路拆解先理解三者各自的定位1.1 什么是 LLM大语言模型究竟是什么“物种”LLMLarge Language Model大语言模型本质上是一个基于海量文本数据训练出来的概率预测模型。它的核心能力是给定一段文字预测接下来最可能出现的文字序列。听起来很简单但当模型规模足够大、训练数据足够多之后它会涌现出理解上下文、推理、生成连贯内容等一系列能力。用个生活化的类比LLM 像是一个读过海量书籍的“通识型学霸”。你问它任何问题它都能凭借记忆和推理给出一个像模像样的回答。但问题在于这个学霸的知识截止日期是固定的取决于训练数据的时效它的记忆也不是百分百精确的而且它没有“实时查资料”的能力。如果你问它一个训练数据里没有、或者训练之后才发生的事情它大概率会一本正经地“编造”一个答案——这就是大家经常听到的“幻觉”问题。在实际开发中LLM 是整个应用的核心引擎。当前主流的使用方式是通过 API 调用别人的模型比如国内外各家大模型厂商提供的接口也有团队会基于开源模型做私有化部署。选择的依据一般集中在模型能力、响应速度、成本、数据隐私这几个维度。1.2 什么是 RAG给大模型插上“外挂知识库”RAGRetrieval-Augmented Generation检索增强生成解决的是一个非常现实的问题LLM 不知道你自己私有的知识也不知道实时更新的信息。你公司的内部制度文档、产品使用手册、最新的行业动态、某个特定领域的数据——这些都不会出现在通用大模型的训练语料里。RAG 的思路很直接在模型回答问题之前先从外部知识库中检索出相关的信息片段把这些片段拼接到提示词里再让模型基于这些信息生成答案。这样模型就不再是“凭空回答”而是“基于给定的参考资料来回答”准确性和可信度都会有明显提升。还是用类比如果说 LLM 是一个阅历丰富的通识学霸那 RAG 就是给这个学霸配了一个可以随时翻查的图书馆。考试时学霸先翻书找到相关章节再结合自己的理解答题。这样即使书本内容超出了他的原有知识范围他也能给出有依据的答案。RAG 的经典工作流程如下将私有文档/知识库切分成若干文本块对每个文本块做向量化embedding处理存入向量数据库用户提问时将问题也做向量化检索出最相关的文本块将检索到的文本块与用户问题一起拼到提示词中交给 LLM 生成回答。这个流程听起来不复杂但每个环节都有坑——文本怎么切、向量模型怎么选、检索结果怎么排序、提示词怎么组织这些细节直接决定了最终效果的上限。后面我会展开细讲。1.3 什么是 AI Agent从“回答问题”到“完成任务”AI Agent智能体是目前最热、也最容易让人一头雾水的概念。一句话说清楚Agent 是能感知环境、做出决策、执行动作并在执行过程中根据反馈调整策略的系统。放到大模型语境下Agent 就是让 LLM 不但能“说”还能“做”。传统的聊天机器人是你问一句、它答一句。Agent 则更进一步你给它一个目标它可以自己拆解任务、制定计划、调用工具搜索、计算器、代码解释器、第三方 API 等并在执行过程中根据结果动态调整下一步行动。举个例子你让一个 Agent “帮我调研一下本周行业头部公司的动态并整理成一份对比报告”。它可能会先调用搜索工具获取各家公司的新闻再对新闻做摘要然后调用表格工具生成对比数据最后把报告写到本地文件里。整个过程它自己拆解、自己执行、自己汇总。这里的关键词是“工具调用”和“循环决策”。Agent 不仅仅依赖 LLM 的文本生成能力它还依赖模型对“应该调用什么工具、调用结果是否满足需求”的判断能力。很多时候一个任务需要多轮“思考-行动-观察”的循环才能完成这也是 Agent 和普通对话应用最本质的区别。1.4 三者的关系不是替代而是分层协作很多初学者搞不清 LLM、RAG、Agent 的区别以为这是三个互相竞争的技术路线。实际上它们是不同层次的东西完全可以叠加使用LLM 是底层引擎提供语言理解和生成能力RAG 是增强手段给引擎补充外部知识和实时信息Agent 是应用形态通过任务拆解和工具调用把引擎与外部世界连接起来。一个成熟的 Agent 应用内部往往会同时用到 LLM 和 RAG用 LLM 做推理和文本生成用 RAG 让 Agent 能查私有资料或实时资讯。三者不是“谁替代谁”的关系而是协作关系——理解到这一层你就不会再被各种概念炒作带偏了。2. 核心细节解析与实操要点每一步都是经验活2.1 模型选型的参考框架不是越贵越合适选择 LLM 时很多人只看榜单分数但实际落地时分数高并不代表最合适。我的参考框架是四步走先看评测集是否贴近你的场景再对比单次调用的成本然后测试响应延迟是否符合产品需求最后检查数据安全要求是否允许数据出域。一个很典型的教训是某次我们做一个文档摘要功能换了好几个在综合榜单上排名很高的模型结果发现摘要风格太重、提炼感过强反而把原文中关键的表格信息给“润色”掉了。最后换成一个参数规模较小、但指令跟随能力扎实的模型效果反而更符合业务预期。对于私有化部署也不要盲目追求几十亿上百亿参数的大模型。参数越大对显存和推理速度的要求越高。如果业务场景只是分类、抽取、简单问答一个较小模型加上好的提示词往往比大模型更划算。先明确任务复杂度再决定模型规模这个顺序不能颠倒。2.2 RAG 落地中的切分、向量化与检索技巧RAG 能不能真正发挥作用老实说多数人踩的坑都集中在“细节不到位”上。以下是我梳理的几条核心经验第一文档切分是重灾区。切得太粗检索出来一大块内容很多是无关信息影响生成质量切得太细又可能把完整语义切断检索出来的片段零碎不全。实践上优先按结构切分比如根据文档的标题层级、段落边界来切而不是死板地按固定字数切。同时切分时让相邻文本块保留一部分重叠内容可以减少切断语义的风险。第二向量化的效果决定了检索质量的瓶颈。市面上常见的 embedding 模型各有偏向。选 model 时还是那句老话在你的真实数据上做评测不要盲目看榜单。有些模型擅长英文中文效果一般有些模型对长文档理解好对短查询效果则一般。最稳妥的做法是先拿几十条真实问题做召回测试把每个候选模型的结果拉出来对比再定。第三检索之后不是“谁相似度高就用谁”。常见的优化手段有rerank重排序先向量检索出 Top N 个候选片段再用一个重排序模型对这些候选做精细化打分可以有效过滤掉语义相似但实际不相关的片段查询改写用户的问题往往模糊可以先用 LLM 把问题改写得更精确再做检索混合检索在向量检索的同时结合关键词精确匹配两条路并行再合并排序。这些手段单独看都不复杂但组合起来效果差异很大。实践中我通常建议优先把“切分、向量模型、检索后重排序”这三板斧做扎实再考虑更复杂的优化。2.3 提示词组织RAG 效果的后半段提示词的构造质量直接影响 RAG 最后一步“生成答案”的效果。同样的检索结果会写提示词的人和不会写的人产出的答案质量可以差一个档次。我常用的提示词结构是这样的明确角色和任务比如“你是企业内部客服助手请根据提供的文档片段回答用户问题”给出检索到的参考片段并明确标注边界如用 XML 标签包裹定义约束比如“如果参考片段中没有对应答案直接告诉用户‘说明书里未找到相关信息’不要自行编造”规定输出格式比如“用简洁的条目式结构回答不要附带与问题无关的内容”。这里最重要的是第 3 点——当检索结果不足以回答问题时的“兜底逻辑”。如果你不写这一句模型很可能会把检索到的部分信息“脑补”成一个完整答案反而误导用户。明确的“不知道就说不知道”的约束是减少幻觉最便宜、最有效的手段。2.4 Agent 开发中的关键机制ReAct 范式和工具定义Agent 的实现方式有很多种但目前工程上最主流的是“思考-行动-观察”ReAct的循环范式。核心流程是LLM 分析当前状态决定下一步行动调用对应的工具函数传入参数把工具返回结果作为新的观察再次输入给 LLM重复上述步骤直到达到最终目标或触达最大轮数。要支撑这个循环最关键的一环是“工具定义”。给 LLM 提供的工具描述本质上是模型的“操作手册”。工具描述写得好不好直接决定模型能不能在合适的时机调用正确的工具。我踩过最深的坑是工具描述写得太模糊导致模型频繁误用。比如某个数据分析工具如果描述里只写了一句“这个工具可以执行数据分析”模型就可能在各种场景里都尝试调用它。后来我把描述改成了“仅当用户要求做统计计算时使用普通文本描述类问题不要使用”误调用率立刻下降。还要注意工具参数的约束说明。模型生成的参数经常会出现格式不合法的情况所以工具解析层必须做防御式处理参数校验、错误捕获、超时控制一个都不能少。Agent 越复杂调试越要花心思在“边界情况”上而不是只盯着正常路径。3. 实操过程与核心环节实现搭一个能用的最小闭环3.1 环境准备与依赖选型在这个部分我以一个“内置 RAG 能力、能查知识库并自主调用工具”的最小 Agent 原型为例带你走一遍完整实现。当然具体代码能力各家产品有差异你完全可以根据自己熟悉的技术栈来替换。基础依赖建议Python 3.10 及以上版本一个可调用的 LLM 接口API 形式为主一个向量数据库轻量测试场景用本地文件型实现即可线上再上生产集群常用的文本处理库读取文档、切分文本时的辅助工具。3.2 一步步构建 RAG 检索链路数据准备与索引构建第一步把知识文档处理好。假设你手头有一批内部 FAQ 文档把它们读取出来后我先按段落结构切分成若干文本块。这里我会参考原始文档的标题层级和自然段落边界当一个段落过长时再按句子边界做二次拆分每一块控制在适中长度。第二步把每个文本块向量化并写入向量数据库。在正式写库前我会先用一小批样本跑通一遍检查向量维度、写入速度、查询延迟是否符合预期。索引构建完成后再随机挑几个问题做一次召回测试验证“检索结果和问题是否真相关”。第三步查询侧同样要处理问题文本用同一套向量模型转为向量再执行检索。这一步要特别注意的是训练和查询时必须使用同一个向量模型否则向量空间不一致召回结果就完全没有意义。这个低级错误我见过不止一次所以提前提醒。3.3 动手写一个 Agent 核心循环工具定义与执行流程我用一个非常简单的“知识库问答 天气查询”复合任务来演示流程。先定义两个外部工具一个是“知识库检索”工具用于把问题转化为向量后做召回另一个是“天气查询”工具通过调用内部天气服务获取指定城市的实时天气。在这个场景里用户输入“帮我查一下本地的天气情况然后看看知识库里有没有关于下雨天出行的建议”。Agent 的循环过程大致是第一轮推理发现“用户需要天气信息还需要查询知识库”调用工具一获取天气数据调用工具二在知识库中检索“下雨天出行建议”相关的文本片段把两个工具返回的结果一起送入 LLM生成最终回答。在整个过程中LLM 的职责是“决策和生成”工具的职责是“获取数据和检索信息”两者分工明确。实现时最重要的是写好工具调用的协议格式一般是通过模型返回的 JSON 结构来指定调用的工具名和参数。解析这个 JSON 时要做好容错——有时候模型会返回额外文本有时返回的 JSON 里带有多余注释这些都要在解析层兼容掉。3.4 参数选择与调优实验记录参数这块我挑两个说得最多的温度temperature和最大输出长度。在 Agent 的循环里每次工具调用的格式和最后汇总回答的格式对温度的需求是不一样——工具调用阶段我更倾向于把温度调低让模型输出更稳定、更符合指定格式生成最终答复时可以适当提高一点让回答语气更自然一些。这种“分阶段调参”的思路比全局用一个参数更符合实际需要。另外一个容易忽略的参数是“最大迭代轮数”。Agent 如果陷入循环比如反复调用同一工具、结果一直不满足条件会造成资源浪费和响应超时。我在实践里通常把最大迭代轮数设置为 5~8 轮超过后直接终止并返回当前已有的部分结果同时提示用户“任务操作已结束信息可能不完整”。这个兜底逻辑对线上体验非常重要。3.5 一个真实场景的调试过程记录有一次我尝试做一个“智能合同审查”的 Demo用户上传一份合同后Agent 需要抽取合同中的关键条款并与公司标准条款库做对比标记出风险项。第一版效果非常差模型经常把合同正文的大段文字直接复制到风险报告里而不是做真正的“差异分析”。排查后发现两个问题一是检索阶段没有召回真正相关的标准条款因为合同文本里用的是“乙方应于...”标准库里的表述却是“供应商应在...”语义相近但字面差异很大二是提示词里没有强调“必须基于标准条款逐条对比不要输出原文”。解决办法是先对合同和标准库做了术语统一简称“术语归一化”的预处理再引入重排序模型对召回的候选片段做精细化过滤。调整之后标注的准确率提升明显误报率也降下来了。这个案例说明Agent / RAG 的很多问题不是模型不够强而是检索链路和提示词之间的配合出现了断层。4. 常见问题与排查技巧实录这些坑你大概率也会遇到为了让你少走弯路我把自己和周围同事踩过的典型问题整理成一张速查表并给出实际的排查思路常见问题可能原因排查与解法回答总出现编造内容检索结果为空或提示词未约束“不知道”情况检查召回前 Top N 结果的相似度分数在提示词中明确兜底话术知识库内容没被问到切分粒度过大语义被稀释改用按结构切分缩小文本块大小或增加重叠区域检索结果看似相关却不准确向量模型与领域数据不匹配换一个向量模型并在真实语料上做召回评测Agent 反复调用同一个工具决策模型不明确工具调用边界重写工具描述明确“什么时候该用、什么时候不该用”工具参数频繁报错提示词中未给出参数格式示例在工具定义中加入完整的参数示例并在解析层做防御式校验响应速度太慢迭代轮数过多或检索链路过长限制最大迭代次数对向量库加索引可考虑缓存热门查询在实际排查中我发现超过一半的“模型效果差”问题根因都出在“数据准备阶段”而不是模型本身。文档切分不合理、向量模型不匹配、知识库内容本身质量不高这些“看不见的细节”最终都会反映到模型输出的质量上。所以调试时一定要有耐心从前到后一步步排查别一上来就换模型。另外还有一个值得分享的经验建立“评测集”意识。不要等系统上线了才发现效果不行而是在开发阶段就准备几十条有代表性的问题进行测试。每次改动换模型、调整切分策略、变更提示词之后都在同一组问题上跑一遍对比看看效果是变好还是变差。这里面没有捷径但却是保证应用质量最可靠的方法。5. 实操总结从最小原型到体系化落地的演进路径大概给一个从零开始的推进路线第一周先跑通一个极简的对话应用感受一下 LLM 的基础交互第二周加上一个基础的 RAG 链路用自己的私有文档做问答第三周开始引入工具调用逐步把应用改造成一个能完成多步骤任务的 Agent。这条路线的好处是每一步都有具象的阶段性成果不会一上来就被复杂概念拖垮。我个人体会最深的一点是与其纠结于“我的项目到底算不算 Agent”不如先把底层能力打磨扎实——准确的检索、稳的工具调用、清晰的提示词约束这些才是构成大模型应用的基本功。概念会不断刷新但工程能力永远通用。这篇内容就讲到这里。最后再分享两个小建议一是所有参数和模型选择都不要盲从评测榜单在你自己的数据上验证才是王道二是尽量从最小的可运行版本开始迭代每加一个功能就做一轮评测这种做法在大模型应用开发里尤其管用。希望这些内容能帮你在入门的路上少踩一些坑。