跳到主要内容

一个完整的 RAG Agent 案例

学到 RAG、Tool Use 和 Agent 之后，很多人最自然会问的一句就是：

这些东西在一个真实系统里，到底是怎么一起工作的？

单篇看时：

  • RAG 很清楚
  • Tool Use 很清楚
  • Agent 很清楚

但真到落地时，大家最容易卡住的是：

怎么把它们装进同一个系统，而不是只会分别讲概念。

这篇文档就用一个完整的 RAG Agent 案例，把这些能力串起来。

1. 先定义一个案例场景​

我们先假设要做这样一个系统：

企业内部知识调研助手

用户可能会提这类问题：

  • 帮我整理某个产品方案的已知约束
  • 帮我调研某个功能上线前的依赖和风险
  • 帮我从多份内部文档里提炼结论

这个场景为什么适合做 RAG Agent？

因为它同时具备：

  • 私有知识依赖
  • 多步信息收集
  • 过程中的动态判断
  • 最终需要整合输出

也就是说：

  • 只用普通 prompt 不够
  • 只用单次 RAG 也不一定够
  • 但它又不需要一开始就上特别重的多 Agent

2. 这个系统的核心目标​

目标不是“让模型看起来聪明”，而是：

围绕一个调研问题，主动检索、补信息、整理证据，并输出有依据的总结。

所以这个系统至少要能做 4 件事：

  1. 理解调研目标
  2. 检索内部知识
  3. 判断信息够不够
  4. 整理结论并说明依据

3. 系统由哪些部分组成​

一个比较实用的最小 RAG Agent 可以拆成下面几层：

3.1 User Goal Layer​

接收用户问题和目标。

3.2 Agent Orchestration Layer​

负责：

  • 判断下一步
  • 进入多步循环
  • 管状态

3.3 Retrieval Layer​

负责：

  • 文档切分
  • 检索
  • rerank
  • 证据返回

3.4 Tool Layer​

除了检索，还可以接额外工具，比如：

  • 文档详情读取
  • 数据查询
  • 链接解析

3.5 State Layer​

负责记录：

  • 当前目标
  • 已拿到的证据
  • 已排除的信息
  • 当前缺口
  • 已做过的动作

3.6 Output Layer​

负责：

  • 汇总结论
  • 标出依据
  • 输出结构化结果

4. 先看一张整体图​

可以这样理解：

  1. 用户提目标
  2. Agent 判断现在缺什么
  3. 去检索或调工具
  4. 把结果变成证据
  5. 更新状态
  6. 判断还需不需要继续
  7. 最终输出

5. 一个典型执行流程​

5.1 第一步：理解目标​

系统先判断：

  • 用户要的到底是概览、对比，还是风险梳理
  • 需要查哪些维度

5.2 第二步：发起第一轮检索​

比如检索：

  • 相关产品方案
  • 历史设计文档
  • 风险记录

5.3 第三步：判断证据是否够用​

这一点很关键。

如果只是普通 RAG，很多系统在拿到第一批文档后就直接回答了。

但 Agent 会继续判断：

  • 有没有关键维度缺失
  • 检索结果是否冲突
  • 是否需要深入读某份文档

5.4 第四步：调附加工具或更细粒度检索​

比如：

  • 读取文档全文
  • 查某个依赖项
  • 查看某条记录的上下文

5.5 第五步：更新状态​

系统记录：

  • 已确认结论
  • 仍然不明确的点
  • 当前手头证据

5.6 第六步：收束输出​

当信息基本足够后，系统再整理：

  • 核心结论
  • 风险点
  • 缺口项
  • 依据来源

6. 为什么这里一定要有 State​

如果没有状态，这个系统会出现两个常见问题：

  • 查过什么很快忘掉
  • 缺什么信息也说不清

对 RAG Agent 来说，State 通常至少要包含：

  • 当前目标
  • 已获得证据列表
  • 未解决问题列表
  • 已做过的检索 / 工具调用
  • 当前步数

这是它和单次 RAG 的关键区别之一。

7. RAG 在这里到底负责什么​

很多人容易把 RAG Agent 理解成：

  • RAG 就是 Agent

其实不是。

在这个案例里：

  • RAG 负责提供知识
  • Agent 负责决定怎么推进任务

所以：

  • RAG 解决“去哪里拿资料”
  • Agent 解决“现在该拿什么资料、还要不要继续拿、什么时候结束”

8. Tool Use 在这里扮演什么角色​

检索不是唯一工具。

在真实系统里，RAG Agent 往往还会需要：

  • 文档详情读取工具
  • 链接跳转工具
  • 内部 API 查询工具

这样 Agent 才不会停留在“拿几段文本拼一拼”，而能在需要时做进一步探索。

9. 这个案例里最该评估什么​

对 RAG Agent 来说，评估不能只看最后答案。

至少应该看下面几层。

9.1 Retrieval Quality​

检索到的东西是否相关。

9.2 Evidence Usage​

拿到的证据是否真的被正确使用。

9.3 Task Completion​

最终调研任务有没有完成。

9.4 Step Efficiency​

是不是跑了很多无效步骤。

9.5 Groundedness​

答案是不是基于证据，而不是模型自己编。

10. Harness 在这个案例里怎么用​

如果你想把这个案例做稳，就最好给它一层最小 Harness。

至少要准备：

  • 一组典型调研问题
  • 每次运行的轨迹记录
  • 最终结果与依据
  • 不同版本之间的对比

这样你才能知道：

  • prompt 改了之后，是不是真的更好了
  • 检索策略变了之后，哪些任务提升了

11. 一个最小版本应该做到什么程度​

如果你想自己先做一个 0 到 1 版本，我建议控制在下面这个级别：

  • 1 个明确调研场景
  • 1 套内部知识源
  • 1 个检索链路
  • 1 到 2 个工具
  • 1 个简单状态对象
  • 1 个基础 Agent Loop
  • 1 组固定问题样本

先把这个跑顺，比一开始追求全能更重要。

12. 常见坑​

12.1 检索到第一批资料就直接回答​

这会让系统看起来像 RAG，而不像 Agent。

12.2 没有显式状态​

多步执行里会很容易丢失“还缺什么”。

12.3 只看答案，不看证据链​

你会很难判断是检索错了，还是整合错了。

12.4 工具过多​

第一个版本工具太多，只会让系统更难调。

13. 一句话总结​

一个完整的 RAG Agent，本质上不是“把检索接进模型”那么简单，而是：

让系统围绕目标，动态决定该检索什么、何时继续探索、如何整合证据，并最终输出有依据的结论。

这正是它和单次 RAG 系统的关键差别。