RAG 与 Agent 的分界线：检索增强何时足够

最近不少项目在纠结：到底用 RAG 还是上 Agent？两个都做检索、都答问题，但工程复杂度和成本差了好几倍。今天聊聊怎么判断。

一、先说结论：按任务复杂度选

如果任务是“已知问题、找已知答案”——比如查文档、问政策、产品问答——RAG 足够了。它的路径是固定的：检索 → 拼接上下文 → 生成答案，稳定、可控、便宜。

如果任务是“目标已知、路径未知”——比如“帮我出一份竞品分析报告”“查一下这批订单的异常原因”——就需要 Agent 做多步规划、调用多个工具、根据中间结果调整策略。

二、中间态：RAG + 工具调用

实际项目中还有大量灰色地带，一个实用的中间架构是“增强型 RAG”：

1. 路由型：在 RAG 前加一个意图分类，简单问题走 RAG，复杂问题转 Agent；
2. 检索型工具：把 RAG 封装成 Agent 的一个工具（search_docs），Agent 在需要时调用，兼顾两者的优点；
3. 多跳检索：问题需要串联多个文档时，先做查询改写和分解，再分别检索、合并答案，这已经是“轻量 Agent”的形态。

很多团队发现，60-70% 的“Agent 需求”用增强型 RAG 就能满足，成本只有全 Agent 方案的三分之一左右。

三、升级到 Agent 的四个信号

1. 需要写操作：不只是查，还要下单、发邮件、改配置——涉及状态变更的，Agent 更合适；
2. 工具超过 3 个且调用顺序不固定：流程图画不下去了，就该让模型自己规划；
3. 需要处理异常分支：检索不到、工具报错、数据缺失时要能换路走；
4. 用户要的是“结果”不是“答案”：比如“帮我把这事办了”，而不是“告诉我怎么做”。

四、决策清单

- [ ] 任务的输入输出是封闭的吗？是 → RAG
- [ ] 流程能画成固定流程图吗？能 → RAG
- [ ] 需要模型自主决定调用哪些工具吗？是 → Agent
- [ ] 有写操作或长链条依赖吗？有 → Agent
- [ ] 不确定？先做增强型 RAG，用真实流量验证后再升级

一个常见误区是“为了 Agent 而 Agent”：demo 很酷，但线上 80% 的流量都是简单问题，白白烧 token。建议的做法是分层——RAG 兜底简单流量，Agent 只处理真正复杂的那部分。

讨论：你们项目里有没有“本可以用 RAG 却上了 Agent”（或者反过来）的例子？最后成本/效果差了多少？

【管理员回复】按任务复杂度选的思路很对。补充一个判断信号：如果你发现需要在 RAG 里不断添加“多次检索”“根据结果再查”“调用计算器或数据库”等补丁，那么任务实际上已经是多步推理问题，适合转向 Agent。反之，如果问题大多能通过一次检索解决，引入 Agent 只会增加延迟和不确定性。也可以采用中间形态：RAG 为主，检索结果不足时再触发 Agent 式的多轮检索。大家的项目中，有多少比例的问题需要多步检索才能回答？