【收藏】小白也能学会：LLM、RAG、Agent三层栈详解与实战应用

最新推荐文章于 2025-12-05 11:17:30 发布

原创最新推荐文章于 2025-12-05 11:17:30 发布 · 897 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#语言模型 #人工智能 #自然语言处理 #大模型 #ai #转行 #程序员

LLM、RAG、Agent：AI从业者必懂的三层栈指南

首先声明：这不是纸上谈兵的概念科普，而是基于国内产品落地的实战笔记！如果你正在做AI产品，这篇文章能帮你少走不少弯路。

先说结论

很多人把 LLM、RAG、Agent 看成三个竞争选项，或者是三选一 or 三选二的选项，而实际上，它们是同一个AI系统的三个能力层：

① LLM 是大脑

② RAG 是记忆

③ Agent 是”行动“，也就是决策和执行系统

生产级AI产品的标准做法是：按需叠加。不是"选一个"，而是根据场景的复杂度，逐层加上去。

在这里插入图片描述

第一层：LLM——最强大脑，但这个脑子是"冻结"的

LLM 的本质是什么？

LLM 最强的能力是意图理解 → 结构化生成，说人话就是：能听懂你的需求，还能用各种格式（文本、JSON、SQL、代码）给你吐出来。

LLM 的真实能力边界：

擅长的事：文案生成、代码辅助、逻辑推理、多轮对话、角色扮演、长文本理解
不擅长的事：实时信息（停留在训练数据的时间点，比如：你截一张股票的分时图发给deepseek，让它猜股票，你看它的推理过程，肯定是2024年的股票数据。所以顺带提醒各位，不要迷信AI炒股！）、专有数据（从没见过的企业内部文档）、数值计算（尤其是复杂四则运算）

国内产品案例：腾讯混元/deepseek + 微信

腾讯混元大模型在微信生态中的纯 LLM 应用场景很典型。比如你在微信里搜索"周末旅游的行程"，搜索结果最顶部就是AI的回答↓（默认是混元，你也可以选择ds深度思考模型）

AI输出的计划虽然很详细，包括酒店推荐、景点顺序等，但是这个场景里只要有LLM就够了，完全**不需要 RAG，不需要 Agent。从它的回答你也能看的出来，它给出来的信息，没有那种实时的内容。**因为我只是需要一个信息输出作为参考，没有让它给我具体到时间、金钱、地点、出行方式等这样一个详细规划。

而且出于成本的考虑，微信也好，小红书也好，它们的内置搜索都集成了大模型能力，但是很少会调用RAG，更不用说Agent了。

因此即使你输入了详细的出行要求，默认的AI回答依然是LLM为主，他不会通过实时检索，关联最新的票价、路况、住宿费用等动态信息，你真要”新鲜有效的信息“，那就只能看下面最近发布的具体文章、笔记了。

所以LLM这个大脑很聪明，但它一旦涉及到一些新鲜信息，就会有一些脱节，因为它的学习”进度“跟当下这个时间点，是存在一定的时间差的。但是，这并不影响它是一个高手这个事实。

第二层：RAG——记忆，把"冻结的脑子"接上实时数据库

为什么需要 RAG？

这是最常见的场景：企业的 AI 客服系统不能每次都"胡说八道"，用户问"你们产品保修期是多久"，系统得从产品手册里查到真实答案再回答。

RAG（Retrieval-Augmented Generation）做的事就是：

把用户的问题转成"向量"（数值化表示）
到知识库（向量数据库）里找最相关的文档/信息
把这些文档作为"上下文"，一起送给 LLM
LLM 基于这些真实信息生成答案

流程简图

用户问题     ↓[向量化] ← 用Embedding模型    ↓[向量数据库检索] ← 找Top K相关文档    ↓[RAG上下文拼接] → "这是我们的产品手册，基于以下信息回答问题..."    ↓[LLM生成答案] ← 带有引用出处    ↓用户 ✓ 得到准确、可验证的答案

产品案例：字节豆包 + 云搜索 RAG

字节跳动的豆包大模型内置了基于云搜索的百亿级向量检索能力。生产环境下，毫秒级召回，秒级索引更新。这意味着：

企业把最新的产品文档、政策手册导入
用户随时问，豆包都能查出最新信息
不需要每次人工更新 FAQ

典型场景：保险代理的知识库。某保险公司用豆包+RAG，自动生成产品解释和销售话术，人均提效 50%。

RAG 的关键工程细节

做好 RAG 系统，最常见的坑：

问题	常见错误	正确做法
检索不准	用的 Embedding 模型太烂，把"保修期"和"维修费"混为一谈	用领域特定的 Embedding 或做微调，必要时用混合检索（BM25 + 向量）
幻觉依然高	把相关文档 dump 进去，LLM 还是随意编	用"Chain-of-Thought"让 LLM 先列出依据，再生成答案
数据不新	只更新了 RAG 库，没同步到向量索引	自动化索引更新，或定期全量重建向量库
成本爆表	每个请求都检索 Top 100 文档	分层检索（先快速粗筛，再精排），设置文档数量上限

第三层：Agent——手脚和自主决策系统

LLM + RAG 的天花板

还是周末游的例子，你这么问AI，即使是LLM+RAG也解决不：

“帮我规划个周末上海两日游，包括订酒店、订餐厅、规划路线，最后给我一份PDF”

这个需求涉及：

查询事实景点信息库（用 RAG）
调用酒店推荐和预订接口
调用餐厅推荐和预订接口
生成 PDF 并发送
如果酒店没房了，自动重试其他酒店

纯 LLM + RAG 做不到这些，因为 LLM 不会"真正去做"这些事，只会生成一个todolist。

而”做“，Do这个动作，就是 Agent 的精髓和它的用武之地了。

Agent 的工作流程简图

用户意图  ↓[意图解析] ← LLM理解"我要订酒店+订餐厅"  ↓[规划] ← 拆分成步骤序列  ↓[调用工具1] ← 查酒店库 → 得到候选列表  ↓[反思] ← "酒店太贵？需要换条件吗？"（这一步很关键！）  ↓[调用工具2] ← 调用预订接口 → 完成预订  ↓[调用工具3] ← 推荐餐厅 → 返回名单  ↓[最终执行] ← 生成行程单，发送 PDF  ↓[结束] 或 [需要改进？回到反思步骤]

这里面最关键的是"反思环"！因为我们都知道大模型是存在幻觉的，如果你赋予了大模型”做“这个权利，那么，整个流程里面，一步错，可能后面就步步错了！

所以，Agent 在每一步之后都要问自己"我做对了吗？是否偏离原始目标？需要改策略吗？"。没有这个循环，Agent 很大概率会一条路走到黑！

产品案例：阿里飞猪旅行 Agent

荣耀新发布的手机，AI智能助理集成了飞猪旅行 Agent。所以用户跟手机说"帮我规划三天xx出行计划"后，语音助理初步识别后就会调用Agent，然后后续跟用户的交互流程大概是这样：

意图理解：识别出"旅行规划+需要预订"
信息收集：问用户"预算多少？几个人？什么时间？出行方式？…"
多源查询：同时查景点库、酒店库、航班库…
智能过滤：基于用户预算+评分，自动筛选最优组合
一键预订：用户确认后，Agent 调用支付接口完成预订
反思检查：预订成功？如果失败，自动选择备选方案

整个流程中，Agent 不只是"建议"，而是真实地"代理执行"了用户的意愿。所以在这一类场景中，Agent 在整个思考过程中，会基于用户需求做多次相关外部数据源的联动和决策，这是LLM或LLM+RAG 所不具备的能力。

⭐️关键决策：什么时候用哪一层？

决策树

用户问题来了    ↓问题是"纯语言处理"吗？     ├─ YES → 只用 LLM ✓    │  例子：写文案、改邮件、翻译、总结    │    └─ NO        ↓        需要准确的、可核查的事实吗？        ├─ YES → LLM + RAG ✓        │  例子：产品问答、政策查询、文档QA、知识库问答        │        └─ NO            ↓            需要跨多步执行、调用外部系统、最后产出实际结果吗？            ├─ YES → LLM + RAG + Agent ✓✓✓            │  例子：旅行规划、订单处理、自动化工作流、智能客服            │            └─ NO                → 可能不需要 AI...

举个例子：大家都用deepseek会知道，现在这类ai助手工具基本都有一个”联网“的按钮，其实这就是RAG。就是这个功能打开后，它会根据我们问的问题，判断是否需要实时检索。如果不需要，它就直接动一动自己这个LLM大脑，就直接回答你了。如果它发现你的问题涉及一些实时的数据或八卦、新闻什么的，那它就得借助RAG去联网搜索一下相关的网页等，最后把搜索结果给回LLM大脑，大脑综合这些信息后，再给你一个最终的答案。

延迟与准确度对比（仅供参考）

方案	响应时间	准确率	复杂度
纯 LLM	<1秒	60-70%	低 ⭐
LLM + RAG	1-3秒	85-95%	中 ⭐⭐
LLM + RAG + Agent	3-10秒（多步）	70-90%*	高 ⭐⭐⭐

*准确率取决于工具调用的成功率和反思机制的质量

工程实现的三个痛点与解决方案

痛点 1：向量检索的"语义漂移"

问题：用户问"手机屏幕碎了怎么修"，系统检索出了"屏幕保护膜怎么贴"的文档。

原因：Embedding 模型没有理解"修"和"贴"的本质区别。

解决方案：

用国产的中文 Embedding 模型，而不是通用英文模型
对关键领域词做"同义词扩展"：修 = 维修/修理/返修
用混合检索：BM25（精确词匹配）+ 向量（语义匹配）

痛点 2：Agent 的"死循环"

问题：Agent 陷入无限重试，一直在重复调用同一个失败的接口。

解决方案：

设置最大步数限制（比如最多 10 步）
每次失败后，强制 Agent"反思为什么失败"，然后改策略
设置"降级策略"：如果智能流程失败，直接转人工
记录失败案例，定期做 Agent 的"微调"

痛点 3：长尾问题的"超预期成本"

问题：99% 的用户问题用 LLM 或 RAG 解决，但剩下 1% 的奇葩问题，Agent 要调用 10 个接口才能搞定，成本爆表。

解决方案：

用"分层策略"：先用便宜的 LLM 试试，不行再上 RAG，最后才激活 Agent
对频繁出现的"长尾"，做专项优化（比如常见的 5 个奇葩场景）
一旦 Agent 成本超过"转人工"的阈值，立即转人工处理

给产品经理的五条军规

1. 不要一开始就想搞 Agent

很多团队看到 Agent 的酷炫效果，就想一步到位。结果投入 3 个月工程资源，最后 Agent 的成功率只有 50%，不如简单的 RAG。

正确做法：用"功能演进"的思路，从 LLM → RAG → Agent 逐层加。每一层都要有明确的用户价值验证。

2. RAG 的效果取决于知识库质量，不是 Embedding 模型

很多团队觉得"用了高端 Embedding 模型就能解决问题"。实际上，50% 的效果来自数据准备，40% 来自 Embedding，10% 来自模型选择。

正确做法：投入人力做好知识库的清洗、分类、去重，比盲目升级模型有效 10 倍。

3. 别忘了"反思循环"

Agent 之所以比 RAG 强，核心在于有"反思"能力。用 LangGraph 等框架，把"检查→纠正→继续"的循环固化到系统里。

代码示例（伪代码）：

while step < MAX_STEPS:    # 执行当前任务    result = call_tool(task)        # 反思（这是关键！）    reflection = llm.reflect(original_goal, step, result)        if reflection.is_complete():        return result    elif reflection.needs_correction():        task = reflection.corrected_task        step += 1    else:        # 失败或需要人工        return escalate_to_human(task)