我们从零手写搭建了具备对话交互、结构化输出、工具调用、循环防护的最小 Agent，完成了智能体的基础运行闭环。只是原生 Agent 仍面临三大痛点：

• 无法调用专业业务工具，导致业务场景落地受限；
• 缺乏长效外部知识库，信息过时且不易更新；
• 没有持续记忆能力，无法在多轮对话中保持上下文一致性。按理说，

Stage 进阶能力搭建：RAG 检索提高、自定义工具程序、长效记忆模块

本阶段目标是彻底摆脱大模型原生缺陷。让基础 Agent 迭代为可落地、可复用、可迭代的专业智能体：

• 检索提高生成：chunk、embed、retrieve、answer with citations。老实说，
• 将搜索、数据库、文件、浏览器、代码执行等接成工具。
• 区分短期上下文、会话记忆与长期记忆。
• 处理工具失败、空结果、重复调用与幻觉引用。
• 在回答中给出来源或证据。

Stage2 聚焦 RAG 检索提高生成

大模型天然存在知识滞后与幻觉编造等致命缺陷，使得纯原生 LLM 难以落地生产场景。RAG是一种低成本、高效率的方案，可实时更新知识并帮助私有知识库问答。是所有公司智能体和知识库问答程序的底层主要架构。说起来，

RAG 全套底层理论拆解

从 LLM 固有缺陷出发。拆解 RAG 的主要原理与三代技术范式；横向对比 Prompt 工程、RAG 与微调三大调整方法的适用场景；梳理全套专业主要名词，为后续手写实操和工业级落地筑牢理论基础。

一、检索提高生成前言

L​LM 的缺陷分析

L​LM虽具备强大的语言理解与生成能力。但其局限性表现在：

• 知识时效性不足：训练语料有时间“冻结点”，无法自动更新。从使用者痛点来看，业务规则变更频繁，却无法及时反映在回答中。
• 幻觉问题：模型可能生成看似合理但事实错误的内容。使用者痛点这方面，错误答案导致业务决策失误。
• 缺乏可控性和解释性：回答往往是“黑箱”，难以保证引用来源或解释推理过程。再看使用者痛点，合规审计时无法追溯答案来源。
• 限制：输入长度有限，难以直接处理大规模文档或数据库。再看使用者痛点，一次查询需要多份文件，却被截断导致信息不完整。

使用者痛点提示：如果你遇到上述问题。就该考虑引入 RAG 来补齐这些短板！说起来，

. RAG 的定义

检索提高生成: 结合信息检索与文本生成的混合范式。其主要思想是：

• 检索:  从外部知识库中找到这些内容。
• 提高:  将检索到的内容拼接为额外上下文注入提示词中。
• 生成:  LLM 在提高后的上下文基础上生成答案，并提供引用来源。

这样既能发挥 LLM 的语言生成能力，又能借助外部知识库保证答案准确性与可解释性。

. RAG 的三大范式

**使用者痛点提醒**：如果你需要在多轮对话里保持长期记忆，而且想让程序自动推理接下来操作，那么一定要考虑 Agentic RAG！如果只是单次问答，那 Naive 或 Advanced 就足够了。

. Naive RAG 主要流程拆解

1. 准备目标文档 :  收集产品手册、FAQ 等资料并导入程序；
2. 文档切片 :  将长文本切成小块便于后续处理；
3. 向量化 :  将每块文本转化为向量并存入向量数据库；
4. 问答检索 :  使用者提问时从向量库找出最相关块，并拼接到 Prompt 中交给 LLM 生成答案。怎么说呢，

. Prompt 工程 vs RAG vs Fine‑tuning **Prompt 工程** - **是否改动模型** ❌ - **成本** 低 - **优势** 简单灵活，可快速验证概念 - **局限** 难以解决知识缺失 **RAG** - **是否改动模型** ❌ - **成本** 中等 - **优势** 时效性强。可解释好依赖检索质量 - **局限** 架构复杂 **Fine‑tuning** - **是否改动模型** ✅ - **成本** 高需重新训练 - **优势** 针对领域性能提高显著 - **局限** 更新慢