RAG vs Agent 架构示例

以下对比示例展示了在真实场景中如何在 RAG 与 Agent 之间选择——纯 RAG 用于有依据的问答、纯 Agent 用于多步任务，以及 Agent 自行决定何时检索的混合 Agentic RAG。

真实案例

使用场景: 构建帮助中心或文档机器人的团队

每个问题一次 LLM 调用

检索把提示词收窄到相关片段

成本和延迟可预期

无工具使用，不对世界采取行动

失败模式：检索不相关，而非推理糟糕

这样组织的原因: 纯 RAG 适合「找到这个事实并解释它」类工作——图表只有一次 LLM 调用且无循环，让成本和延迟可预期，但意味着 RAG 无法执行行动或串联多步推理。

使用场景: 自动化触达多个系统的工作流的团队

Agent 推理、调工具、观察、重复

工具：搜索、代码执行、外部 API

记忆保存到目前为止的任务轨迹

成本不可预期（取决于走了多少步）

失败模式：推理错误、无限循环

这样组织的原因: 纯 Agent 适合需要多个决策和行动的任务——图表的循环正是其精髓，但也带来比单次 LLM 调用更不可预期的成本、更长的延迟和更难的调试。

使用场景: Agent 自行决定何时检索的团队

Agent 循环按纯 Agent 方式运行

Agent 的工具之一是「从知识库检索」

Agent 每轮决定是否检索

首次检索效果不好时可用重写的查询再检索

检索没帮助时回退到其他工具

这样组织的原因: Agentic RAG 把检索放进 Agent 循环——图表把 RAG 展示为多个工具之一，Agent 只在需要时投入检索调用，并能在检索不佳时绕开到其他工具。

使用场景: 正在选择架构的工程师

单轮事实问答 → RAG

需要行动的多步任务 → Agent

偶尔需用工具的知识工作 → Agentic RAG

严格成本上限 → 先用 RAG；必要时再加 Agent

审计 / 合规需求 → RAG（更易追踪）

这样组织的原因: 选择很少是哪个「更好」——而是任务能否装进一次 LLM 调用。图表帮你带干系人走过「这事需要循环吗？」这个问题，这正是决定因素。

回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。