上一篇介绍 Structured Output 时我们解决了一个问题模型生成的结果怎样可靠地交给程序处理。但真正开发 Agent 时还会遇到另一个更基础的问题模型怎样获得自己原本并不知道的知识例如企业内部有产品文档、制度、合同、项目资料和会议纪要这些内容并不存在于通用大模型的训练数据中即使是公开信息也可能已经发生变化。如果用户问“公司目前北京地区的差旅住宿标准是多少”模型仅依靠自身知识很可能不知道答案甚至根据常见经验生成一个看起来合理但实际错误的数字。更合理的做法是先从企业知识库中找到最新的差旅制度再让模型基于这些资料回答。这就是RAGRetrieval-Augmented Generation检索增强生成。但进入 Agentic AI 之后还需要进一步理解RAG 并不等于 Agent知识库问答系统也不等于 Agent。RAG 是 Agent 获取外部知识的一种能力而 Agent 还需要决定什么时候检索、检索什么、是否继续检索以及获取知识以后下一步应该做什么。一、RAG 到底解决什么问题大模型虽然掌握大量通用知识但天然存在几个限制不掌握企业私有数据训练数据存在时间边界很难保证具体事实始终准确不适合把大量企业资料永久放进 Prompt。一个最直接的办法是把所有资料都放进上下文System Prompt 用户问题 企业制度 产品资料 历史文档。但随着资料越来越多很快就会遇到上下文窗口、Token 成本和无关信息干扰等问题。RAG 的核心思路不是把所有知识交给模型。而是先找到与当前问题最相关的少量知识再把它们放进本轮上下文。因此最基本的 RAG 流程可以表示为用户问题 ↓ 检索相关知识 ↓ 得到少量证据 ↓ 加入模型上下文 ↓ LLM 基于证据生成答案例如用户询问“北京员工出差酒店标准是多少”系统不需要把几十份公司制度全部交给模型而只需要检索出《2026 年差旅管理办法》中与北京住宿标准相关的几个段落。这就是 RAG 最核心的价值让模型按需获得知识而不是要求模型记住所有知识。二、一个完整的 RAG不只是“向量数据库 大模型”很多入门资料会把 RAG 简化为文档 → 向量数据库 → LLM这种理解没有错但对于生产系统来说还远远不够。一个比较完整的 RAG 通常包含两条链路。真正影响 RAG 效果的往往并不是最后一步调用哪个大模型而是前面的知识处理和检索链路。三、RAG 的第一步其实是把文档处理好假设知识库中有一份 200 页的《员工管理制度》。不能简单把整份 PDF 转成一个向量因为用户询问某一个具体问题时绝大多数内容都是无关的。通常需要先把文档拆成多个 Chunk员工管理制度 ├─ 第一章 总则 ├─ 第二章 考勤 │ ├─ 工作时间 │ ├─ 请假制度 │ └─ 加班管理 └─ 第三章 差旅 ├─ 交通标准 ├─ 酒店标准 └─ 报销流程这里就会遇到一个典型问题Chunk 应该切多大如果切得太大一个 Chunk 中可能同时包含大量无关内容降低检索准确率如果切得太碎又可能把一句完整规则的适用条件和具体标准分开。因此RAG 的文档切分正在从早期的固定字符数切分逐渐发展到按段落、标题、语义和文档结构进行切分。对于合同、制度、技术文档、表格等复杂文件还要尽量保留标题层级、表格结构、页码、章节和来源信息。否则即使后续 Embedding 和模型能力再强进入知识库的数据本身已经被破坏最终效果仍然不会理想。四、Embedding让“意思相近”也能够被找到Embedding 可以把文本转换成一组高维向量。例如“员工去北京出差住宿最多可以报销多少”可能被转换成[0.142, -0.287, 0.613, ...]知识库中的每个 Chunk 也会生成对应向量查询时通过计算 Query Vector 与文档向量之间的距离就可以找到语义最相近的内容。因此即使制度中写的是“北京地区住宿费标准上限为……”而用户问的是“去北京住酒店最多能报多少”。两句话的字面并不完全相同仍然可能通过语义向量被匹配到一起。这就是向量检索相对于传统关键词匹配的主要优势它不仅寻找相同的词还可以寻找相近的意思。五、为什么只有向量检索还不够向量搜索擅长语义匹配但对编号、产品型号、人名和精确术语并不一定最稳定。例如用户搜索“BM-2026-0148 合同审批记录”这里最重要的信息实际上是BM-2026-0148。传统关键词搜索反而更容易准确命中。因此生产级 RAG 越来越常见的方式是Hybrid Search——混合检索。同时运行┌─ 向量检索 用户 Query ──┤ └─ 关键词 / BM25 检索 ↓ 结果融合两种检索方式分别解决不同问题向量检索意思像不像关键词检索字面是不是它再配合 Metadata Filter可以进一步限制可以进一步限制文档类型、创建时间、部门、作者、项目、权限范围等。因此现代 RAG 的检索通常已经不再只是Vector Search而更接近Vector Search Keyword Search Metadata Filter六、Rerank检索之后为什么还要再排一次第一次检索的目标通常是尽量不要漏掉相关内容。因此系统可能先召回 2050 个 Chunk。但如果把几十个 Chunk 全部放入 LLM 上下文不仅 Token 消耗高也可能因为无关信息过多降低最终回答质量。因此通常会增加 RerankQuery ↓ Retriever ↓ Top 30 ↓ Reranker ↓ Top 5 ↓ LLM可以简单理解为Retriever 更关注“召回来”。Reranker 更关注“排得准”。Rerank 会重新判断 Query 与每一个候选 Chunk 之间的相关性然后只把最有价值的几个证据交给模型。因此生产 RAG 的典型链路往往是Retrieve → Merge → Rerank → Context → Generate而不是简单的Query → VectorDB → LLM七、引用和证据比“回答得像真的”更重要假设用户问“北京出差酒店标准是多少”系统回答“600 元 / 晚。”对于普通聊天来说这似乎已经完成了任务。但企业知识系统更应该继续告诉用户答案600 元 / 晚 来源 《2026 年差旅管理办法》 第三章第 12 条 第 8 页因此知识库中的 Chunk 不应该只有正文内容还应该保留documentId documentName page section chunkId score最终返回答案 Citation。尤其在合同、制度、法律、财务、研发规范等场景中用户往往更关心这个结论到底从哪里来的因此RAG 的目标不是单纯让模型“回答得更像真的”而应该让答案拥有可以追溯的证据链。八、多轮对话为什么需要 Query RewriteRAG 进入聊天和 Agent 后还会遇到多轮对话的问题。例如第一轮用户问“公司的差旅标准是什么”第二轮继续问“那北京呢”如果直接把“那北京呢”拿去搜索知识库检索系统很难知道用户究竟想查什么。因此需要 Query Rewrite把当前问题结合历史对话改写为“公司当前北京地区的差旅住宿标准是什么”然后再进行知识检索。完整过程就变成Conversation History Current Query ↓ Query Rewrite ↓ Standalone Query ↓ Retrieval这一步的价值主要是解决指代、省略和上下文依赖。在实际企业问答系统中Query Rewrite 往往会显著影响多轮 RAG 的稳定性。九、传统 RAG 为什么会继续演进到 Agentic RAG传统 RAG 通常是一条固定流水线Query → Retrieve → Rerank → Generate。无论问题简单还是复杂都执行一次检索然后生成答案。对于简单知识问答这种方式已经足够。但如果用户提出“比较 2025 年和 2026 年的销售政策变化并分析哪些调整会影响渠道合作伙伴。”一次检索往往很难拿到完整证据。系统可能需要分别查询2025 年销售政策然后2026 年销售政策接着发现渠道返点相关信息不足还需要继续检索2026 年渠道返点政策最后再将多轮结果进行综合。这时执行流程已经从一次检索变成分析 → 检索 → 判断 → 再检索 → 综合。这就是 Agentic RAG 开始发挥作用的地方。十、Agentic RAG让 Agent 决定“怎么查”Agentic RAG 可以把传统固定检索流程升级为动态决策过程典型执行方式是用户问题 ↓ Agent 分析问题 ↓ 判断是否需要检索 ↓ 生成 / 改写 Query ↓ 执行检索 ↓ Rerank ↓ 判断证据是否充分如果证据不足分析缺失信息 → 生成新 Query → 再次检索如果证据充分基于证据推理 → 生成答案。传统 RAG 与 Agentic RAG 对比二者最重要的区别不是使用了不同的向量数据库而是传统 RAG 的检索流程由程序提前决定Agentic RAG 的检索过程可以根据任务动态调整。十一、并不是所有问题都需要 Agentic RAGAgentic RAG 看起来比传统 RAG 更“智能”但并不意味着所有知识问答都应该升级。例如用户问“公司年假是多少天”一次普通 RAG 检索就可以完成Query → Retrieve → Answer。如果强行加入规划、反思、多轮检索反而会增加调用次数Token 消耗延迟不确定性。因此更合理的架构是简单问题 → Traditional RAG 复杂问题 → Agentic RAG例如单一制度查询。适合传统 RAG。而多文档对比、跨来源验证、复杂条件组合、多跳推理更适合 Agentic RAG。这仍然符合本系列一直强调的原则能用确定性流程解决的问题不必全部交给 Agent 自主判断。十二、RAG 也正在从向量检索继续扩展传统 RAG 最适合回答“哪个文档片段与这个问题最相关”但有些问题真正关注的是实体之间的关系。例如A 公司与 B 公司参与过哪些共同项目这些项目分别由谁负责这类问题往往需要跨多个文档建立公司 → 项目 → 人员 → 合同之间的关系。于是出现了 GraphRAG文档 ↓ 抽取实体 / 属性 / 关系 ↓ 构建知识图谱 ↓ 图关系检索 语义检索 ↓ 多跳推理因此目前 RAG 已经逐渐从最初的Chunk Embedding VectorDB扩展为Naive RAG ↓ Hybrid RAG ↓ Rerank RAG ↓ GraphRAG ↓ Agentic RAG这些方式并不是简单的版本替代而是针对不同问题复杂度增加新的检索和推理能力。十三、一个更完整的 Agentic RAG 实例假设用户告诉一个合同分析 Agent“分析这批供应商合同找出付款、违约和解除条款中与公司最新采购制度冲突的内容并给出修改建议。”这里已经同时使用了前几篇介绍的能力Context Engineering负责管理本轮模型应该看到什么。Function Calling负责调用合同解析、文件读取等程序能力。Structured Output负责把风险项输出成程序可以处理的数据。RAG负责获取企业制度知识。Agent负责把这些能力组合起来完成整个任务。这也是为什么进入 Agentic AI 后单独理解某一个技术还不够更重要的是理解这些能力如何在 Agent Loop 中协同。十四、RAG、Memory 和 Tool 到底有什么区别这是 Agent 开发中最容易混淆的几个概念。能力主要解决的问题典型内容RAG去哪里找外部知识文档、制度、合同、知识库Memory以前发生过什么用户偏好、历史任务、长期信息Tool如何获取实时数据或执行操作API、数据库、搜索、文件系统Context本轮模型实际看到什么Prompt、RAG、Memory、Tool ResultAgent下一步应该做什么判断、规划、选择能力例如用户说“按照公司差旅制度帮我规划下周去上海的行程我还是喜欢以前住过的安静型酒店。”系统可能这样处理公司差旅标准 → RAG喜欢安静型酒店 → Memory查询实时酒店价格 → Tool创建预订 → Tool是否需要检索、什么时候调用工具 → Agent因此可以用一句话区分RAG 提供知识Memory 提供历史Tool 提供行动能力而 Agent 决定如何使用它们。十五、为什么“知识库问答系统”不能直接等同于 Agent现在不少 AI 系统的流程实际上是上传 PDF ↓ 建立向量库 ↓ 用户提问 ↓ RAG ↓ LLM 回答如果流程始终是预先固定的每次问题都必须检索然后生成答案。它更准确的定位仍然是RAG Knowledge Assistant——知识库问答助手。真正进入 Agent 之后系统需要能够根据目标动态决定用户目标 ↓ Agent ├─ 不需要知识 → 直接处理 ├─ 需要企业知识 → RAG ├─ 需要历史信息 → Memory ├─ 需要实时数据 → Tool ├─ 证据不足 → 再次 RAG ├─ 需要业务操作 → Function Calling └─ 完成任务 → Structured Output因此RAG 是 Agent 可以使用的一种能力而不是 Agent 本身。这也是本篇最重要的概念边界。十六、生产级 RAG 真正应该关注什么真正建设企业 RAG 系统时与“选择哪个向量数据库”相比还有几个问题更值得关注。1. 知识质量如果知识库中存在过期制度、重复文档、错误版本和相互冲突的内容再好的检索算法也只能更加准确地找到错误知识。因此需要建立版本、有效期、来源和知识治理机制。2. 权限过滤用户只能检索自己有权限访问的文档。权限控制应该发生在检索阶段。而不是先把所有文档检索出来并送入 LLM再决定哪些答案不能显示。否则可能已经产生数据泄漏。3. 可观测性至少应该记录Original Query Rewritten Query Retriever Top-K Rerank Score 最终证据 引用来源 Token Latency当用户说“这个答案不对”。系统才能判断到底是文档没有入库、Chunk 切错、没有召回、Rerank 排错还是模型最终推理出了问题。4. 无证据时不要强行回答如果知识库没有足够证据更合理的结果应该是当前知识库没有找到足够信息。而不是要求模型利用常识补全一个答案。RAG 的目标之一本身就是减少模型脱离证据自由生成带来的幻觉风险。十七、本篇小结RAG 最核心的思想其实非常简单不要要求模型记住所有知识而是在需要时把正确的知识找到并加入当前上下文。真正需要记住的是RAG ≠ Knowledge Base ≠ Agent。知识库负责保存知识RAG负责找到知识Memory负责保存历史Tool负责获取实时数据和执行操作而Agent才负责根据目标决定什么时候需要知识、应该去哪里找、要找几次以及找到以后下一步应该做什么。到这里第 69 篇介绍的几项基础能力已经逐渐连接起来Context Engineering 如何给模型准备正确的上下文 Function Calling 如何让模型调用程序能力 Structured Output 如何让模型把结果可靠交给程序 RAG 如何让模型获得外部知识上一篇回顾【第二部分大模型应用开发基础】8.Structured Output——让模型输出可被程序可靠处理的数据-CSDN博客下一篇将真正进入 Agent 开发不使用框架手写一个最小 Agent到那时我们会把模型、上下文、Tool、RAG 和执行循环组合起来也会看到一个重要事实Agent Framework 并没有创造一种神秘的新能力它真正做的是把这些已经存在的基础组件组织成一个可以持续运行的 Agent Runtime。 
长河君 · 2026/8/18 11:29:03 · 阅读 1.2k 【第二部分：大模型应用开发基础】9. RAG 是什么，它与 Agent 有什么关系？——从知识库问答到 Agentic RAG
上一篇介绍 Structured Output 时我们解决了一个问题模型生成的结果怎样可靠地交给程序处理。但真正开发 Agent 时还会遇到另一个更基础的问题模型怎样获得自己原本并不知道的知识例如企业内部有产品文档、制度、合同、项目资料和会议纪要这些内容并不存在于通用大模型的训练数据中即使是公开信息也可能已经发生变化。如果用户问“公司目前北京地区的差旅住宿标准是多少”模型仅依靠自身知识很可能不知道答案甚至根据常见经验生成一个看起来合理但实际错误的数字。更合理的做法是先从企业知识库中找到最新的差旅制度再让模型基于这些资料回答。这就是RAGRetrieval-Augmented Generation检索增强生成。但进入 Agentic AI 之后还需要进一步理解RAG 并不等于 Agent知识库问答系统也不等于 Agent。RAG 是 Agent 获取外部知识的一种能力而 Agent 还需要决定什么时候检索、检索什么、是否继续检索以及获取知识以后下一步应该做什么。一、RAG 到底解决什么问题大模型虽然掌握大量通用知识但天然存在几个限制不掌握企业私有数据训练数据存在时间边界很难保证具体事实始终准确不适合把大量企业资料永久放进 Prompt。一个最直接的办法是把所有资料都放进上下文System Prompt 用户问题 企业制度 产品资料 历史文档。但随着资料越来越多很快就会遇到上下文窗口、Token 成本和无关信息干扰等问题。RAG 的核心思路不是把所有知识交给模型。而是先找到与当前问题最相关的少量知识再把它们放进本轮上下文。因此最基本的 RAG 流程可以表示为用户问题 ↓ 检索相关知识 ↓ 得到少量证据 ↓ 加入模型上下文 ↓ LLM 基于证据生成答案例如用户询问“北京员工出差酒店标准是多少”系统不需要把几十份公司制度全部交给模型而只需要检索出《2026 年差旅管理办法》中与北京住宿标准相关的几个段落。这就是 RAG 最核心的价值让模型按需获得知识而不是要求模型记住所有知识。二、一个完整的 RAG不只是“向量数据库 大模型”很多入门资料会把 RAG 简化为文档 → 向量数据库 → LLM这种理解没有错但对于生产系统来说还远远不够。一个比较完整的 RAG 通常包含两条链路。真正影响 RAG 效果的往往并不是最后一步调用哪个大模型而是前面的知识处理和检索链路。三、RAG 的第一步其实是把文档处理好假设知识库中有一份 200 页的《员工管理制度》。不能简单把整份 PDF 转成一个向量因为用户询问某一个具体问题时绝大多数内容都是无关的。通常需要先把文档拆成多个 Chunk员工管理制度 ├─ 第一章 总则 ├─ 第二章 考勤 │ ├─ 工作时间 │ ├─ 请假制度 │ └─ 加班管理 └─ 第三章 差旅 ├─ 交通标准 ├─ 酒店标准 └─ 报销流程这里就会遇到一个典型问题Chunk 应该切多大如果切得太大一个 Chunk 中可能同时包含大量无关内容降低检索准确率如果切得太碎又可能把一句完整规则的适用条件和具体标准分开。因此RAG 的文档切分正在从早期的固定字符数切分逐渐发展到按段落、标题、语义和文档结构进行切分。对于合同、制度、技术文档、表格等复杂文件还要尽量保留标题层级、表格结构、页码、章节和来源信息。否则即使后续 Embedding 和模型能力再强进入知识库的数据本身已经被破坏最终效果仍然不会理想。四、Embedding让“意思相近”也能够被找到Embedding 可以把文本转换成一组高维向量。例如“员工去北京出差住宿最多可以报销多少”可能被转换成[0.142, -0.287, 0.613, ...]知识库中的每个 Chunk 也会生成对应向量查询时通过计算 Query Vector 与文档向量之间的距离就可以找到语义最相近的内容。因此即使制度中写的是“北京地区住宿费标准上限为……”而用户问的是“去北京住酒店最多能报多少”。两句话的字面并不完全相同仍然可能通过语义向量被匹配到一起。这就是向量检索相对于传统关键词匹配的主要优势它不仅寻找相同的词还可以寻找相近的意思。五、为什么只有向量检索还不够向量搜索擅长语义匹配但对编号、产品型号、人名和精确术语并不一定最稳定。例如用户搜索“BM-2026-0148 合同审批记录”这里最重要的信息实际上是BM-2026-0148。传统关键词搜索反而更容易准确命中。因此生产级 RAG 越来越常见的方式是Hybrid Search——混合检索。同时运行┌─ 向量检索 用户 Query ──┤ └─ 关键词 / BM25 检索 ↓ 结果融合两种检索方式分别解决不同问题向量检索意思像不像关键词检索字面是不是它再配合 Metadata Filter可以进一步限制可以进一步限制文档类型、创建时间、部门、作者、项目、权限范围等。因此现代 RAG 的检索通常已经不再只是Vector Search而更接近Vector Search Keyword Search Metadata Filter六、Rerank检索之后为什么还要再排一次第一次检索的目标通常是尽量不要漏掉相关内容。因此系统可能先召回 2050 个 Chunk。但如果把几十个 Chunk 全部放入 LLM 上下文不仅 Token 消耗高也可能因为无关信息过多降低最终回答质量。因此通常会增加 RerankQuery ↓ Retriever ↓ Top 30 ↓ Reranker ↓ Top 5 ↓ LLM可以简单理解为Retriever 更关注“召回来”。Reranker 更关注“排得准”。Rerank 会重新判断 Query 与每一个候选 Chunk 之间的相关性然后只把最有价值的几个证据交给模型。因此生产 RAG 的典型链路往往是Retrieve → Merge → Rerank → Context → Generate而不是简单的Query → VectorDB → LLM七、引用和证据比“回答得像真的”更重要假设用户问“北京出差酒店标准是多少”系统回答“600 元 / 晚。”对于普通聊天来说这似乎已经完成了任务。但企业知识系统更应该继续告诉用户答案600 元 / 晚 来源 《2026 年差旅管理办法》 第三章第 12 条 第 8 页因此知识库中的 Chunk 不应该只有正文内容还应该保留documentId documentName page section chunkId score最终返回答案 Citation。尤其在合同、制度、法律、财务、研发规范等场景中用户往往更关心这个结论到底从哪里来的因此RAG 的目标不是单纯让模型“回答得更像真的”而应该让答案拥有可以追溯的证据链。八、多轮对话为什么需要 Query RewriteRAG 进入聊天和 Agent 后还会遇到多轮对话的问题。例如第一轮用户问“公司的差旅标准是什么”第二轮继续问“那北京呢”如果直接把“那北京呢”拿去搜索知识库检索系统很难知道用户究竟想查什么。因此需要 Query Rewrite把当前问题结合历史对话改写为“公司当前北京地区的差旅住宿标准是什么”然后再进行知识检索。完整过程就变成Conversation History Current Query ↓ Query Rewrite ↓ Standalone Query ↓ Retrieval这一步的价值主要是解决指代、省略和上下文依赖。在实际企业问答系统中Query Rewrite 往往会显著影响多轮 RAG 的稳定性。九、传统 RAG 为什么会继续演进到 Agentic RAG传统 RAG 通常是一条固定流水线Query → Retrieve → Rerank → Generate。无论问题简单还是复杂都执行一次检索然后生成答案。对于简单知识问答这种方式已经足够。但如果用户提出“比较 2025 年和 2026 年的销售政策变化并分析哪些调整会影响渠道合作伙伴。”一次检索往往很难拿到完整证据。系统可能需要分别查询2025 年销售政策然后2026 年销售政策接着发现渠道返点相关信息不足还需要继续检索2026 年渠道返点政策最后再将多轮结果进行综合。这时执行流程已经从一次检索变成分析 → 检索 → 判断 → 再检索 → 综合。这就是 Agentic RAG 开始发挥作用的地方。十、Agentic RAG让 Agent 决定“怎么查”Agentic RAG 可以把传统固定检索流程升级为动态决策过程典型执行方式是用户问题 ↓ Agent 分析问题 ↓ 判断是否需要检索 ↓ 生成 / 改写 Query ↓ 执行检索 ↓ Rerank ↓ 判断证据是否充分如果证据不足分析缺失信息 → 生成新 Query → 再次检索如果证据充分基于证据推理 → 生成答案。传统 RAG 与 Agentic RAG 对比二者最重要的区别不是使用了不同的向量数据库而是传统 RAG 的检索流程由程序提前决定Agentic RAG 的检索过程可以根据任务动态调整。十一、并不是所有问题都需要 Agentic RAGAgentic RAG 看起来比传统 RAG 更“智能”但并不意味着所有知识问答都应该升级。例如用户问“公司年假是多少天”一次普通 RAG 检索就可以完成Query → Retrieve → Answer。如果强行加入规划、反思、多轮检索反而会增加调用次数Token 消耗延迟不确定性。因此更合理的架构是简单问题 → Traditional RAG 复杂问题 → Agentic RAG例如单一制度查询。适合传统 RAG。而多文档对比、跨来源验证、复杂条件组合、多跳推理更适合 Agentic RAG。这仍然符合本系列一直强调的原则能用确定性流程解决的问题不必全部交给 Agent 自主判断。十二、RAG 也正在从向量检索继续扩展传统 RAG 最适合回答“哪个文档片段与这个问题最相关”但有些问题真正关注的是实体之间的关系。例如A 公司与 B 公司参与过哪些共同项目这些项目分别由谁负责这类问题往往需要跨多个文档建立公司 → 项目 → 人员 → 合同之间的关系。于是出现了 GraphRAG文档 ↓ 抽取实体 / 属性 / 关系 ↓ 构建知识图谱 ↓ 图关系检索 语义检索 ↓ 多跳推理因此目前 RAG 已经逐渐从最初的Chunk Embedding VectorDB扩展为Naive RAG ↓ Hybrid RAG ↓ Rerank RAG ↓ GraphRAG ↓ Agentic RAG这些方式并不是简单的版本替代而是针对不同问题复杂度增加新的检索和推理能力。十三、一个更完整的 Agentic RAG 实例假设用户告诉一个合同分析 Agent“分析这批供应商合同找出付款、违约和解除条款中与公司最新采购制度冲突的内容并给出修改建议。”这里已经同时使用了前几篇介绍的能力Context Engineering负责管理本轮模型应该看到什么。Function Calling负责调用合同解析、文件读取等程序能力。Structured Output负责把风险项输出成程序可以处理的数据。RAG负责获取企业制度知识。Agent负责把这些能力组合起来完成整个任务。这也是为什么进入 Agentic AI 后单独理解某一个技术还不够更重要的是理解这些能力如何在 Agent Loop 中协同。十四、RAG、Memory 和 Tool 到底有什么区别这是 Agent 开发中最容易混淆的几个概念。能力主要解决的问题典型内容RAG去哪里找外部知识文档、制度、合同、知识库Memory以前发生过什么用户偏好、历史任务、长期信息Tool如何获取实时数据或执行操作API、数据库、搜索、文件系统Context本轮模型实际看到什么Prompt、RAG、Memory、Tool ResultAgent下一步应该做什么判断、规划、选择能力例如用户说“按照公司差旅制度帮我规划下周去上海的行程我还是喜欢以前住过的安静型酒店。”系统可能这样处理公司差旅标准 → RAG喜欢安静型酒店 → Memory查询实时酒店价格 → Tool创建预订 → Tool是否需要检索、什么时候调用工具 → Agent因此可以用一句话区分RAG 提供知识Memory 提供历史Tool 提供行动能力而 Agent 决定如何使用它们。十五、为什么“知识库问答系统”不能直接等同于 Agent现在不少 AI 系统的流程实际上是上传 PDF ↓ 建立向量库 ↓ 用户提问 ↓ RAG ↓ LLM 回答如果流程始终是预先固定的每次问题都必须检索然后生成答案。它更准确的定位仍然是RAG Knowledge Assistant——知识库问答助手。真正进入 Agent 之后系统需要能够根据目标动态决定用户目标 ↓ Agent ├─ 不需要知识 → 直接处理 ├─ 需要企业知识 → RAG ├─ 需要历史信息 → Memory ├─ 需要实时数据 → Tool ├─ 证据不足 → 再次 RAG ├─ 需要业务操作 → Function Calling └─ 完成任务 → Structured Output因此RAG 是 Agent 可以使用的一种能力而不是 Agent 本身。这也是本篇最重要的概念边界。十六、生产级 RAG 真正应该关注什么真正建设企业 RAG 系统时与“选择哪个向量数据库”相比还有几个问题更值得关注。1. 知识质量如果知识库中存在过期制度、重复文档、错误版本和相互冲突的内容再好的检索算法也只能更加准确地找到错误知识。因此需要建立版本、有效期、来源和知识治理机制。2. 权限过滤用户只能检索自己有权限访问的文档。权限控制应该发生在检索阶段。而不是先把所有文档检索出来并送入 LLM再决定哪些答案不能显示。否则可能已经产生数据泄漏。3. 可观测性至少应该记录Original Query Rewritten Query Retriever Top-K Rerank Score 最终证据 引用来源 Token Latency当用户说“这个答案不对”。系统才能判断到底是文档没有入库、Chunk 切错、没有召回、Rerank 排错还是模型最终推理出了问题。4. 无证据时不要强行回答如果知识库没有足够证据更合理的结果应该是当前知识库没有找到足够信息。而不是要求模型利用常识补全一个答案。RAG 的目标之一本身就是减少模型脱离证据自由生成带来的幻觉风险。十七、本篇小结RAG 最核心的思想其实非常简单不要要求模型记住所有知识而是在需要时把正确的知识找到并加入当前上下文。真正需要记住的是RAG ≠ Knowledge Base ≠ Agent。知识库负责保存知识RAG负责找到知识Memory负责保存历史Tool负责获取实时数据和执行操作而Agent才负责根据目标决定什么时候需要知识、应该去哪里找、要找几次以及找到以后下一步应该做什么。到这里第 69 篇介绍的几项基础能力已经逐渐连接起来Context Engineering 如何给模型准备正确的上下文 Function Calling 如何让模型调用程序能力 Structured Output 如何让模型把结果可靠交给程序 RAG 如何让模型获得外部知识上一篇回顾【第二部分大模型应用开发基础】8.Structured Output——让模型输出可被程序可靠处理的数据-CSDN博客下一篇将真正进入 Agent 开发不使用框架手写一个最小 Agent到那时我们会把模型、上下文、Tool、RAG 和执行循环组合起来也会看到一个重要事实Agent Framework 并没有创造一种神秘的新能力它真正做的是把这些已经存在的基础组件组织成一个可以持续运行的 Agent Runtime。