RAG vs Agent：何时用检索，何时用工具？以及企业级知识库怎么把两者用对

很多团队做 AI 应用，第一步就容易纠结一个问题：这事到底该上 RAG，还是直接做 Agent？

说实话，这两个词现在都快被说烂了。结果就是不少项目一上来就堆概念，最后做出来的东西要么是“会聊天但不靠谱”，要么是“能检索但像个高级搜索框”。

我自己的判断很简单：RAG 解决的是“知道什么”，Agent 解决的是“接下来要做什么”。 这俩不是完全对立，但职责真不一样。

如果这个边界一开始没想清楚，后面系统大概率会越做越重。

先说结论：不要把所有问题都往 Agent 上塞

这是我最想先讲的一句。

现在很多人看到大模型能调用工具，就很容易上头，觉得“那我全部做成 Agent 不就完了”。但现实里，大量企业知识问答场景，本质上根本不需要一个会规划、会拆任务、会连续调用工具的 Agent。

用户只是想问：

• 差旅报销标准是多少
• 新员工入职流程在哪看
• 某个 API 的字段是什么意思
• 这个合同模板最新版本在哪

这种问题，核心矛盾不是“行动能力不够”，而是“能不能把对的资料捞出来，并且别胡说”。

这时候 RAG 往往比 Agent 更合适，也更便宜。

RAG 到底适合什么场景

如果用一句人话来解释，RAG 就是：先查资料，再基于资料回答。

它特别适合下面这类任务：

1. 答案主要藏在文档里

比如制度、手册、FAQ、产品文档、会议纪要、知识文章。

只要用户的问题能通过“检索相关片段 + 总结回答”解决，那就已经很接近 RAG 的甜区了。

2. 你最在意可追溯性

企业场景里，很多回答不能只求“像对的”，而是要能说明“依据是什么”。

RAG 的天然优势就在这里。你可以把检索到的文档片段、文档标题、更新时间、来源链接一起带出来，让用户知道这条答案不是模型凭空编的。

3. 问题大多是一问一答

哪怕问题稍微复杂一点，只要本质还是“查资料然后解释”，RAG 都能扛住。

比如：

• “远程办公申请需要经理审批还是总监审批？”
• “S3 存储费用里，标准存储和低频存储的差异是什么？”
• “我们公司采购流程里，超过 50 万的审批链路怎么走？”

这些问题会有一点推理，但推理是建立在检索结果上的，不需要外部动作。

4. 你的系统边界要尽量可控

RAG 的另一个优点是行为边界清楚。

它通常只做两件事：取资料，组织答案。不会随便帮你下单、发邮件、提交工单，也不会自己规划十几个步骤。对很多企业内部系统来说，这种克制反而是优点。

Agent 真正适合什么场景

轮到 Agent，问题就变了。

Agent 不是为了“知道更多”，而是为了“能处理更复杂的任务流”。也就是说，当系统不只是回答问题，而是要判断、调用、执行、串联多个系统时，Agent 才开始显出价值。

1. 需要调用外部工具或系统

比如：

• 查完政策后，顺手帮用户提交报销单
• 查完库存后，帮销售生成报价单
• 查完合同模板后，去法务系统里创建审批流程
• 分析监控告警后，调用工单系统自动建 ticket

这时候光检索文档已经不够了，因为答案不是静态文本，而是要和实时系统交互。

2. 任务有明确步骤，而且可能跨系统

比如用户说：

“帮我看一下这个客户最近三个月的购买记录，再判断要不要给他升级支持等级，如果符合条件就创建审批。”

这件事至少包含：

• 查询 CRM
• 汇总订单数据
• 匹配支持等级规则
• 生成判断结论
• 调用审批系统

这已经不是传统 RAG 能单独解决的问题了。

3. 问题需要动态决策

Agent 的价值之一，是能根据中间结果决定下一步。

比如先查权限文档，如果发现用户没有访问资格，就停在申请入口；如果有资格，再去查询具体资源；如果资源异常，再切故障排查路径。这个“看结果决定后续动作”的能力，才是 Agent 的核心。

4. 用户目标不是“知道”，而是“办成”

这是区分 RAG 和 Agent 最实用的一条。

如果用户是在问“告诉我是什么”，优先想 RAG。

如果用户是在说“帮我做完它”，那就该认真考虑 Agent 了。

一个粗暴但很好用的判断标准

如果你还在犹豫，我建议直接问自己这 4 个问题：

1. 用户的问题，能不能只靠文档回答？
2. 系统需不需要访问实时数据？
3. 回答之后，需不需要继续执行动作？
4. 任务过程中，是否要根据中间结果调整路径？

如果前两个问题答案基本是“能”，后两个问题基本是“否”，那大概率 RAG 就够了。

如果后两个问题开始频繁出现“是”，那就别硬拿纯 RAG 顶了，应该考虑 Agent 或者混合架构。

纯 RAG 最容易踩的坑

很多团队其实不是不会做 Agent，而是把本来该上 Agent 的问题，硬塞给了 RAG。

这样做常见会翻在这几个地方。

1. 检索到文档，不代表完成任务

比如用户问：“VPN 权限怎么开通，顺便帮我申请一下。”

RAG 最多把开通流程讲清楚，但“帮我申请一下”这半句，它做不了。你要是还假装自己能处理，体验就会很怪。

2. 文档正确，但数据过期

企业知识库很容易遇到这种情况：流程文档写得很完整，但真正审批链路已经变了，或者系统配置已经更新了。

纯 RAG 在这种场景下，可能会把“历史上正确的说明”答得特别自信。

3. 多跳问题开始失真

如果用户要同时结合制度、组织架构、实时订单状态和用户权限来判断，单纯靠检索多个片段再拼答案，模型非常容易漏条件、错条件，或者把不同来源的约束混掉。

纯 Agent 也不是银弹

反过来也是一样。

有些团队太迷信 Agent，结果做出来的系统特别重，延迟高、成本高、调试还痛苦。最后发现用户 80% 的问题，原本一个检索问答就能搞定。

纯 Agent 常见的问题有：

1. 能力过剩

明明只是问“差旅补贴标准”，结果系统先做意图识别，再规划，再调工具，再总结。用户等了 8 秒，最后看到一段本来 2 秒就能给出的答案。

这不是高级，这是浪费。

2. 不稳定性更高

Agent 涉及规划、工具选择、参数填充、错误恢复，链路一长，出错点就多。特别是在企业场景里，一旦工具调用权限没设计好，问题会非常麻烦。

3. 可解释性变差

RAG 至少还能告诉你引用了哪篇文档。

Agent 如果中间经过多次工具调用和状态变化，用户和运营同学会更难搞清楚：这条结论到底是根据什么来的，是文档规则，还是系统实时结果，还是模型自己做的判断。

企业级知识库里，最常见的正确答案其实是“RAG + Agent”

说到这儿，基本就到重点了。

现实里的企业知识库，很少永远停留在“单纯问答”。一开始大家做的是知识检索，做着做着就会碰到下面这些需求：

• 查到制度后，继续帮我发起流程
• 根据知识库规则，结合实时业务数据给建议
• 先在多个知识源里找信息，再自动整理成报告
• 发现问题后，直接触发通知、工单或审批

这时候最靠谱的路线，通常不是二选一，而是把 RAG 作为 Agent 的一个能力模块。

也就是：Agent 负责决策和编排，RAG 负责提供可信知识。

有哪些 RAG 与 Agent 结合的典型案例

这个答案是有，而且非常多，尤其在企业内部系统里。

下面这几个场景，基本都属于“RAG 单干不够，Agent 单干也不稳”的类型。

案例 1：企业 IT 服务台

用户问：“我电脑加域失败，顺便帮我重置下 VPN 权限。”

一个成熟系统通常会这样处理：

• 用 RAG 检索知识库里的故障排查文档
• 判断这是不是已知问题、有没有标准操作手册
• 如果需要身份校验或权限操作，Agent 调用 ITSM 或 IAM 工具
• 如果问题超出脚本处理范围，Agent 自动创建工单并附带诊断上下文

这里的关键点是，RAG 提供“怎么办”的知识，Agent 负责“接下来做什么”。

案例 2：企业采购或 HR 助手

比如员工问：

“我想报销这次出差费用，住宿超标一点点还能过吗？如果可以的话帮我提交流程。”

系统可以这样做：

• 先用 RAG 检索差旅制度、住宿标准、例外审批规则
• 再调用费用系统读取用户提交的实际金额
• 根据规则和实时数据判断是否超标、是否允许例外
• 如果满足条件，Agent 发起审批
• 如果不满足条件，返回依据条款并说明替代路径

这就是典型的“文档规则 + 实时数据 + 工具执行”。

案例 3：销售和客服知识助手

销售问：“这个客户过去半年买过哪些产品？结合最新产品政策，推荐我该推哪档续费套餐。”

这已经不是单纯检索文档了。

系统要：

• 从 CRM 拉客户历史数据
• 用 RAG 检索产品政策、价格规则、促销口径
• 让 Agent 结合客户画像和规则做推荐
• 必要时生成报价草案或下一步跟进任务

如果没有 RAG，推荐会缺少规则依据。如果没有 Agent，系统就只会把文档和数据摊给你看，不会帮你推进动作。

案例 4：企业级知识库问答升级版

很多公司一开始只做“智能搜索”，后面都会演进成“问答 + 操作”。

比如用户问：

“这个接口限流报错怎么处理？另外帮我查下我们线上集群是不是也命中过这个问题。”

这里前半句是知识问题，后半句是实时排查问题。

一个成熟系统会先：

• RAG 检索故障文章、Runbook、历史复盘
• Agent 调日志平台、监控平台、告警平台查实时信号
• 最后把知识依据和排查结论合并输出

这类场景现在在运维、SRE、内部研发助手里特别常见。

企业级知识库检索，为什么不能只靠向量库就完事

再往深一点说，企业知识库的难点，往往不在“有没有 Embedding”。

真正麻烦的是这几件事：

1. 权限隔离

不是所有人都能看到所有知识。

法务文档、销售策略、薪酬制度、内部事故复盘，权限边界都不一样。企业级 RAG 如果不做检索前过滤或检索后鉴权，迟早出事。

2. 文档版本管理

企业制度会更新，流程会变，知识文章会过期。

所以检索结果不能只看语义相似度，还要结合版本、发布时间、有效期、文档状态。旧文档召回得再准，也可能是错的。

3. 多源异构

真正的企业知识不会只躺在一个 wiki 里。

它可能散落在：

• Confluence / Notion / 飞书文档
• PDF 制度文件
• 工单系统
• 邮件公告
• FAQ 后台
• 数据库和业务系统

这意味着企业知识库不是简单“建个向量索引”就结束，而是要做清洗、切片、元数据治理、来源可信度排序。

4. 问题不只是语义匹配

很多企业问题其实带过滤条件。

比如“华东区、P6 及以上、2025 年之后入职的员工，远程办公权限怎么申请？”

这类问题如果只做朴素语义检索，效果通常不够。你需要结构化筛选、标签过滤，甚至混合检索。

我更推荐的企业级实现思路

如果你让我给一个相对务实的方案，我会建议这么分层：

第一层：知识检索层

负责文档解析、切片、索引、权限过滤、混合检索、重排。

这一层的目标不是“像 Agent”，而是稳定地把可信内容捞出来。

第二层：任务决策层

这里才是 Agent 的位置。

它根据用户请求判断：

• 只需要问答
• 需要结合实时系统
• 需要多步执行
• 需要人工介入

也就是说，Agent 最好做编排，不要替代底层检索基础设施。

第三层：工具执行层

这里放 CRM、ERP、工单、审批、监控、邮件、数据库查询等工具。

所有高风险动作都要有权限控制、审计日志和失败兜底，不然企业场景很难放心上线。

一个很好用的架构原则

我现在越来越倾向一句话：

能用 RAG 解决的，别急着上 Agent；必须跨系统决策和执行的，再让 Agent 出手。

这不是保守，是工程上更划算。

因为纯问答场景，RAG 更稳、更快、更容易控。等你真正碰到“理解完还要继续行动”的场景，再把 Agent 放上去，系统复杂度会上升得更可控。

写在最后

RAG 和 Agent，不是替代关系，更像是分工关系。

RAG 擅长把正确知识找出来，让模型少胡说。Agent 擅长把任务往前推进，让系统不只会答，还会做。

所以如果你的场景是企业级知识库检索，我的建议通常是：先把 RAG 打牢，把权限、版本、来源、重排这些基础问题解决掉。别一上来就被 Agent 的“全能感”带跑。

但如果你的目标已经不是“回答问题”，而是“根据知识做判断，再调用系统完成动作”，那就别再硬撑纯 RAG 了。这个时候最靠谱的路线，就是让 Agent 站在上层编排，让 RAG 作为它最重要的知识供给模块。

说白了，RAG 管“查得准”，Agent 管“做得成”。

两者结合，才是大多数企业应用真正能落地的样子。