大模型时代，很多人都在聊 LLM、RAG、AI Agent，但说实话，这三个词看起来热得发烫，真正能讲清楚它们之间到底是什么关系、各自解决什么问题、上手时从哪里切入最合适的人，其实并不多。作为一个在相关方向折腾了挺久的从业者，我想用这篇文章把这三件事一次性讲透——不是教科书式地堆概念，而是从实际开发和应用的角度，把“它们分别是什么、为什么需要、怎么落地、有哪些坑”完整地梳理一遍。

无论你是刚接触大模型的应用开发者、技术产品经理，还是被各种术语轰炸的爱好者，这篇文章都适合你。读完之后，你至少能明白：LLM 是大模型应用的“大脑底座”，RAG 是给大脑外挂知识库和记忆体的方案，AI Agent 则是让大模型从“回答问题”进化为“完成任务”的关键形态。三者的组合，构成了当前大模型应用开发最主流的技术骨架。

1. 内容整体设计与思路拆解：先理解三者各自的定位

1.1 什么是 LLM：大语言模型究竟是什么“物种”

LLM（Large Language Model，大语言模型）本质上是一个基于海量文本数据训练出来的概率预测模型。它的核心能力，是给定一段文字，预测接下来最可能出现的文字序列。听起来很简单，但当模型规模足够大、训练数据足够多之后，它会涌现出理解上下文、推理、生成连贯内容等一系列能力。

用个生活化的类比：LLM 像是一个读过海量书籍的“通识型学霸”。你问它任何问题，它都能凭借记忆和推理给出一个像模像样的回答。但问题在于，这个学霸的知识截止日期是固定的（取决于训练数据的时效），它的记忆也不是百分百精确的，而且它没有“实时查资料”的能力。如果你问它一个训练数据里没有、或者训练之后才发生的事情，它大概率会一本正经地“编造”一个答案——这就是大家经常听到的“幻觉”问题。

在实际开发中，LLM 是整个应用的核心引擎。当前主流的使用方式是通过 API 调用别人的模型，比如国内外各家大模型厂商提供的接口；也有团队会基于开源模型做私有化部署。选择的依据一般集中在模型能力、响应速度、成本、数据隐私这几个维度。

1.2 什么是 RAG：给大模型插上“外挂知识库”

RAG（Retrieval-Augmented Generation，检索增强生成）解决的是一个非常现实的问题：LLM 不知道你自己私有的知识，也不知道实时更新的信息。你公司的内部制度文档、产品使用手册、最新的行业动态、某个特定领域的数据——这些都不会出现在通用大模型的训练语料里。

RAG 的思路很直接：在模型回答问题之前，先从外部知识库中检索出相关的信息片段，把这些片段拼接到提示词里，再让模型基于这些信息生成答案。这样模型就不再是“凭空回答”，而是“基于给定的参考资料来回答”，准确性和可信度都会有明显提升。

还是用类比：如果说 LLM 是一个阅历丰富的通识学霸，那 RAG 就是给这个学霸配了一个可以随时翻查的图书馆。考试时，学霸先翻书找到相关章节，再结合自己的理解答题。这样即使书本内容超出了他的原有知识范围，他也能给出有依据的答案。

RAG 的经典工作流程如下：

1. 将私有文档/知识库切分成若干文本块；
2. 对每个文本块做向量化（embedding）处理，存入向量数据库；
3. 用户提问时，将问题也做向量化，检索出最相关的文本块；
4. 将检索到的文本块与用户问题一起拼到提示词中，交给 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 最后一步“生成答案”的效果。同样的检索结果，会写提示词的人和不会写的人，产出的答案质量可以差一个档次。

我常用的提示词结构是这样的：

1. 明确角色和任务：比如“你是企业内部客服助手，请根据提供的文档片段回答用户问题”；
2. 给出检索到的参考片段，并明确标注边界（如用 XML 标签包裹）；
3. 定义约束：比如“如果参考片段中没有对应答案，直接告诉用户‘说明书里未找到相关信息’，不要自行编造”；
4. 规定输出格式：比如“用简洁的条目式结构回答，不要附带与问题无关的内容”。

这里最重要的是第 3 点——当检索结果不足以回答问题时的“兜底逻辑”。如果你不写这一句，模型很可能会把检索到的部分信息“脑补”成一个完整答案，反而误导用户。明确的“不知道就说不知道”的约束，是减少幻觉最便宜、最有效的手段。

2.4 Agent 开发中的关键机制：ReAct 范式和工具定义

Agent 的实现方式有很多种，但目前工程上最主流的，是“思考-行动-观察”（ReAct）的循环范式。核心流程是：

1. LLM 分析当前状态，决定下一步行动；
2. 调用对应的工具（函数），传入参数；
3. 把工具返回结果作为新的观察，再次输入给 LLM；
4. 重复上述步骤，直到达到最终目标或触达最大轮数。

要支撑这个循环，最关键的一环是“工具定义”。给 LLM 提供的工具描述，本质上是模型的“操作手册”。工具描述写得好不好，直接决定模型能不能在合适的时机调用正确的工具。

我踩过最深的坑是：工具描述写得太模糊，导致模型频繁误用。比如某个数据分析工具，如果描述里只写了一句“这个工具可以执行数据分析”，模型就可能在各种场景里都尝试调用它。后来我把描述改成了“仅当用户要求做统计计算时使用，普通文本描述类问题不要使用”，误调用率立刻下降。

还要注意工具参数的约束说明。模型生成的参数经常会出现格式不合法的情况，所以工具解析层必须做防御式处理：参数校验、错误捕获、超时控制，一个都不能少。Agent 越复杂，调试越要花心思在“边界情况”上，而不是只盯着正常路径。

3. 实操过程与核心环节实现：搭一个能用的最小闭环

3.1 环境准备与依赖选型

在这个部分，我以一个“内置 RAG 能力、能查知识库并自主调用工具”的最小 Agent 原型为例，带你走一遍完整实现。当然，具体代码能力各家产品有差异，你完全可以根据自己熟悉的技术栈来替换。

基础依赖建议：

• Python 3.10 及以上版本；
• 一个可调用的 LLM 接口（API 形式为主）；
• 一个向量数据库（轻量测试场景用本地文件型实现即可，线上再上生产集群）；
• 常用的文本处理库（读取文档、切分文本时的辅助工具）。

3.2 一步步构建 RAG 检索链路：数据准备与索引构建

第一步，把知识文档处理好。假设你手头有一批内部 FAQ 文档，把它们读取出来后，我先按段落结构切分成若干文本块。这里我会参考原始文档的标题层级和自然段落边界，当一个段落过长时再按句子边界做二次拆分，每一块控制在适中长度。

第二步，把每个文本块向量化并写入向量数据库。在正式写库前，我会先用一小批样本跑通一遍，检查向量维度、写入速度、查询延迟是否符合预期。索引构建完成后，再随机挑几个问题做一次召回测试，验证“检索结果和问题是否真相关”。

第三步，查询侧同样要处理问题文本，用同一套向量模型转为向量，再执行检索。这一步要特别注意的是：训练和查询时必须使用同一个向量模型，否则向量空间不一致，召回结果就完全没有意义。这个低级错误我见过不止一次，所以提前提醒。

3.3 动手写一个 Agent 核心循环：工具定义与执行流程

我用一个非常简单的“知识库问答 + 天气查询”复合任务来演示流程。先定义两个外部工具：一个是“知识库检索”工具，用于把问题转化为向量后做召回；另一个是“天气查询”工具，通过调用内部天气服务获取指定城市的实时天气。

在这个场景里，用户输入“帮我查一下本地的天气情况，然后看看知识库里有没有关于下雨天出行的建议”。Agent 的循环过程大致是：

1. 第一轮推理发现：“用户需要天气信息，还需要查询知识库”；
2. 调用工具一，获取天气数据；
3. 调用工具二，在知识库中检索“下雨天出行建议”相关的文本片段；
4. 把两个工具返回的结果一起送入 LLM，生成最终回答。

在整个过程中，LLM 的职责是“决策和生成”，工具的职责是“获取数据和检索信息”，两者分工明确。实现时，最重要的是写好工具调用的协议格式，一般是通过模型返回的 JSON 结构来指定调用的工具名和参数。解析这个 JSON 时要做好容错——有时候模型会返回额外文本，有时返回的 JSON 里带有多余注释，这些都要在解析层兼容掉。

3.4 参数选择与调优实验记录

参数这块，我挑两个说得最多的：温度（temperature）和最大输出长度。在 Agent 的循环里，每次工具调用的格式和最后汇总回答的格式，对温度的需求是不一样——工具调用阶段，我更倾向于把温度调低，让模型输出更稳定、更符合指定格式；生成最终答复时，可以适当提高一点，让回答语气更自然一些。这种“分阶段调参”的思路，比全局用一个参数更符合实际需要。

另外一个容易忽略的参数是“最大迭代轮数”。Agent 如果陷入循环（比如反复调用同一工具、结果一直不满足条件），会造成资源浪费和响应超时。我在实践里通常把最大迭代轮数设置为 5~8 轮，超过后直接终止并返回当前已有的部分结果，同时提示用户“任务操作已结束，信息可能不完整”。这个兜底逻辑对线上体验非常重要。

3.5 一个真实场景的调试过程记录

有一次我尝试做一个“智能合同审查”的 Demo，用户上传一份合同后，Agent 需要抽取合同中的关键条款，并与公司标准条款库做对比，标记出风险项。

第一版效果非常差：模型经常把合同正文的大段文字直接复制到风险报告里，而不是做真正的“差异分析”。排查后发现两个问题：一是检索阶段没有召回真正相关的标准条款，因为合同文本里用的是“乙方应于...”，标准库里的表述却是“供应商应在...”，语义相近但字面差异很大；二是提示词里没有强调“必须基于标准条款逐条对比，不要输出原文”。

解决办法是：先对合同和标准库做了术语统一（简称“术语归一化”）的预处理；再引入重排序模型，对召回的候选片段做精细化过滤。调整之后，标注的准确率提升明显，误报率也降下来了。这个案例说明：Agent / RAG 的很多问题，不是模型不够强，而是检索链路和提示词之间的配合出现了断层。

4. 常见问题与排查技巧实录：这些坑，你大概率也会遇到

为了让你少走弯路，我把自己和周围同事踩过的典型问题整理成一张速查表，并给出实际的排查思路：

在实际排查中，我发现超过一半的“模型效果差”问题，根因都出在“数据准备阶段”，而不是模型本身。文档切分不合理、向量模型不匹配、知识库内容本身质量不高，这些“看不见的细节”最终都会反映到模型输出的质量上。所以调试时一定要有耐心，从前到后一步步排查，别一上来就换模型。

另外还有一个值得分享的经验：建立“评测集”意识。不要等系统上线了才发现效果不行，而是在开发阶段就准备几十条有代表性的问题进行测试。每次改动（换模型、调整切分策略、变更提示词）之后，都在同一组问题上跑一遍，对比看看效果是变好还是变差。这里面没有捷径，但却是保证应用质量最可靠的方法。

5. 实操总结：从最小原型到体系化落地的演进路径

大概给一个从零开始的推进路线：第一周先跑通一个极简的对话应用，感受一下 LLM 的基础交互；第二周加上一个基础的 RAG 链路，用自己的私有文档做问答；第三周开始引入工具调用，逐步把应用改造成一个能完成多步骤任务的 Agent。这条路线的好处是每一步都有具象的阶段性成果，不会一上来就被复杂概念拖垮。

我个人体会最深的一点是：与其纠结于“我的项目到底算不算 Agent”，不如先把底层能力打磨扎实——准确的检索、稳的工具调用、清晰的提示词约束，这些才是构成大模型应用的基本功。概念会不断刷新，但工程能力永远通用。

这篇内容就讲到这里。最后再分享两个小建议：一是所有参数和模型选择都不要盲从评测榜单，在你自己的数据上验证才是王道；二是尽量从最小的可运行版本开始迭代，每加一个功能就做一轮评测，这种做法在大模型应用开发里尤其管用。希望这些内容能帮你在入门的路上少踩一些坑。