布吉岛 Agent

Appearance

1.1.5 RAG、知识库问答、搜索、Agent 的边界分别是什么？ ​

这几个概念经常一起出现，但它们不是一个层级的东西。

如果不先把边界理清，后面很容易出现两种问题：

  • 看到一个会回答问题的系统，就叫它 Agent
  • 看到一个接了知识库的系统，就默认它一定是 RAG
RAG、知识库问答、搜索、Agent 的边界

更清楚的理解方式是：它们分别强调的是不同层面的能力。

搜索：重点是找到资料 ​

搜索的核心目标，是把和问题最相关的信息找出来并排序。

一个搜索系统做得好不好，主要看：

  • 能不能找到相关内容
  • 结果排序是不是合理
  • 用户能不能据此自己继续判断

搜索不一定要生成答案。很多时候，它只需要把最有价值的结果呈现给你就够了。

知识库问答：重点是围绕某个知识范围回答问题 ​

知识库问答更像是一类应用形态，而不是某一种底层技术。

它强调的是：

  • 问题集中在一个知识范围内
  • 系统要围绕这批知识回答问题
  • 用户通常期待“直接得到答案”

知识库问答可以用很多方式实现：

  • 传统搜索 + 人工查看
  • 搜索 + 模板化回答
  • RAG
  • RAG + Agent

所以“知识库问答”是应用场景，“RAG”是其中一种常见实现方式。

RAG：重点是检索增强生成 ​

RAG 的重点不是“这个系统是不是知识库问答”，而是它有没有采用这样一条链路：

  • 先检索外部知识
  • 再基于检索结果生成回答

所以 RAG 更像是一种系统设计方法。

一个系统是不是 RAG，关键看它是不是在回答时使用了外部检索到的上下文，而不是只看它有没有知识库页面。

Agent：重点是规划、决策和工具协同 ​

Agent 关注的是另外一层能力：系统不只是回答一个问题，而是能够为了完成目标，去做一系列动作。

比如：

  • 判断该先查什么
  • 决定调用哪个工具
  • 分步骤执行任务
  • 根据中间结果调整下一步

所以 Agent 的重点是：

  • 任务分解
  • 工具调用
  • 状态管理
  • 动态决策

它不一定必须用 RAG，但很多 Agent 会把 RAG 作为其中一个能力模块。

这几个概念之间是什么关系 ​

可以把它们理解成下面这种关系：

  • 搜索：解决“找什么”
  • RAG：解决“找到以后怎么基于资料回答”
  • 知识库问答：解决“围绕一批知识为用户提供问答服务”
  • Agent：解决“为了完成目标，如何规划、调用工具、协同多个步骤”

它们之间不是互相排斥，而是经常组合出现。

比如一个企业问答助手可能是：

  • 应用形态上：知识库问答
  • 检索链路上：RAG
  • 能力上：带一点搜索
  • 高级形态上：再加上 Agent 来做多步推理和工具调用

真正判断时，可以按什么顺序区分 ​

读者最容易卡住的地方，通常不是“背不住定义”，而是遇到一个实际需求时，不知道该把它归到哪一类。

更实用的判断顺序通常是这样：

第一步：先问自己，这个系统的第一目标是什么 ​

如果第一目标是：

  • 把资料找给用户看
    那它更接近搜索

  • 基于资料直接给一个答案
    那它更接近 RAG

  • 围绕某一批知识做持续问答服务
    那它更接近知识库问答

  • 为了完成目标去做多步决策和执行
    那它更接近 Agent

很多概念混淆，本质上都是因为一开始没有先分清“系统的第一目标”。

第二步：再问系统有没有“执行动作” ​

如果系统主要在做：

  • 查资料
  • 排序资料
  • 组织答案

那它大概率还不是 Agent。

如果系统已经开始做：

  • 调 API
  • 调工具
  • 分步骤推进任务
  • 根据中间结果改下一步计划

那它才开始明显进入 Agent 范畴。

第三步：再看用户需不需要自己判断原始资料 ​

如果用户很在意：

  • 自己点开原文
  • 自己比较多个结果
  • 自己继续筛选

那搜索的重要性就更高。

如果用户主要想要：

  • 一个直接可读的答案
  • 最好顺手带引用

那 RAG 的价值通常更高。

第四步：最后看问题是不是围绕一个明确知识范围持续发生 ​

如果系统长期围绕一批固定知识服务用户，比如：

  • 企业内部制度
  • 产品手册
  • 帮助中心
  • 项目文档

那它在应用形态上就很接近知识库问答。

这时底层可能用搜索，也可能用 RAG，也可能再叠加 Agent。

也就是说，知识库问答更像“这个产品是干什么的”，而 RAG 更像“这个产品底层怎么回答”。

一个常见误区 ​

很多系统其实只是“带检索的问答”，但因为用了大模型，就容易被直接叫成 Agent。

这会导致设计思路过早复杂化。因为一旦按 Agent 去设计，你就会开始引入：

  • 规划
  • 多步执行
  • 工具路由
  • 状态管理

而有些问题其实只需要一条稳定的 RAG 链路就够了。

再具体一点：哪些信号说明你可能不需要 Agent ​

下面这些信号经常说明，问题更像 RAG 或搜索，而不是 Agent：

  • 用户每次只问一个知识问题
  • 系统不需要真的执行动作
  • 没有明显的多步决策过程
  • 回答主要取决于能不能找到正确资料

如果这些特征都成立，通常先把搜索或 RAG 做稳，比一开始上 Agent 更现实。

反过来，哪些信号说明可能已经超出 RAG ​

如果你开始遇到下面这些要求，就要警惕是不是已经超出“单纯知识问答”了：

  • 系统要自己决定先查什么、后查什么
  • 系统要调用多个工具组合完成任务
  • 系统要根据中间结果动态改计划
  • 系统要把“回答问题”升级成“完成目标”

这时再只把它当 RAG 去设计，往往就会开始吃力。

所以在实际判断时，可以先问：

  • 我现在是要“找资料”？
  • 还是“基于资料回答”？
  • 还是“完成一个多步骤任务”？

问题不同，系统重点就不同。

如果你想把这套判断再压缩成一句话，可以记成：

  • 想让用户自己看资料，优先想搜索
  • 想让系统基于资料直接回答，优先想 RAG
  • 想围绕一批知识长期服务用户，优先想知识库问答
  • 想让系统自己规划并执行任务，优先想 Agent