RAG 还是 Agentic RAG？架构与权衡对比

检索增强生成（RAG）之所以占有一席之地，是因为它让语言模型基于外部数据生成回答，而不是凭空猜测。但经典 RAG 会以相同方式处理每一个查询；一旦某个问题需要进行多次检索，这个前提就会失效。

RAG 与 Agentic RAG 之争，本质上是在讨论生产负载下的正确性、可追溯性和韧性。另一个关键问题是：让 AI Agent 分析每个查询并自行选择检索策略，是否值得为此承担额外的复杂度。

经典 RAG：简单 RAG 如何工作

经典 RAG 遵循一条直接且可预测的路径。用户查询会触发检索步骤，从外部知识源获取相关上下文。根据系统的不同，在模型生成答案之前，检索过程可能会使用向量相似度搜索、关键词搜索、混合检索和 SQL 查询。整个流水线是无状态的：它不会回到之前的步骤，而且每次请求一结束，就会忘记这次请求。

这种简单性本身就是优势。由于每个请求都执行相同的固定步骤，延迟始终可预测。基础设施开销也很低——你只需维护一个 retriever、一个 embedding 模型，以及 retriever 所需的索引基础设施，例如用于 embedding 搜索的向量数据库，或用于词法检索的关键词索引。当答案出错时，需要调试的范围足够小，可以人工逐项检查。一个基于单一知识库回答常见问题的 RAG 客服聊天机器人，正是这种线性设计最能发挥价值的场景。对于稳定的语料库，它通常也是现有方案中成本最低且足够可靠的选择。

当答案无法完整地存在于一个整洁的 chunk 中时，问题就出现了。由于流水线只检索一次，并直接相信检索结果，相关性较低的结果很容易悄无声息地变成信心十足的幻觉。以下三种故障模式会反复出现：

• 多跳问题会让它失效：如果提问“我们在 SOC 2 审计之后引入了哪些供应商？”，系统就需要从一份文档中找到审计日期，再从另一份文档中找到供应商列表，但单次检索只能完成其中一跳。

• 词汇不匹配会让 retriever 无从下手：用户询问“休假”，而制度文件中使用的却是“带薪假期”。如果 embedding 无法对齐，即使是语义搜索，也可能遗漏相关段落。结合关键词和 embedding 的混合搜索能够降低这种风险，但经典 RAG 流水线通常只依赖一种检索方法。

• chunk 边界会割裂证据：当一个答案横跨两个 chunk，而 retriever 只返回其中一个时，模型不会补上缺失的另一半，而是会用看似合理的虚构内容填补空白。

Agentic RAG：将检索变成控制循环

RAG Agent 是一个配备了一组工具，并有权自主决定如何使用这些工具的大语言模型。经典 RAG 只会提出一个范围很窄的问题：哪些 chunk 与这个查询匹配？Agentic RAG 则会提出一个更宽泛的问题：要回答这个问题，我需要哪些信息，又有哪些工具能够提供这些信息？这就是人们所说的 agentic retrieval。

这种变化将检索从一个独立步骤转变成控制循环，也最清楚地解释了什么是 agentic AI RAG，以及它如何工作。Agent 会执行检索、阅读返回内容、评估现有证据是否充足，然后决定下一步行动——重新表述查询、切换数据源、调用 API，或者停止检索并给出答案。这就是 ReAct 模式的实际应用：推理、行动、观察、重复。如果配置了 memory，Agent 就能在多轮迭代之间保留上下文，因此它不会在每一轮都从零开始，而是能够逐步构建一个涵盖多个方面的答案。

SOC 2 的例子清楚地体现了这种差异。Agentic 系统首先检索审计日期，意识到自己仍然需要供应商列表，随后针对另一个数据源发起第二次查询，最后将两部分信息整合成一个有依据的回答。这是单次检索的 retriever 根本无法完成的工作。n8n 中基于 LangChain 构建的 AI Agent 节点等工具，就是为了将这个循环连接起来。以下三种能力将它与固定流水线区分开来：

• 它能够分解问题并制定计划：一个宽泛的问题会被拆分成多个子查询，由 Agent 依次处理，每一步的结果都会成为下一步的输入。

• 它能够自我评估并重新表述查询：当第一次检索返回的信息不足时，Agent 会改写查询并再次尝试，而不是利用薄弱的上下文强行生成答案。

• 它能够自适应路由：定价问题交给 SQL 数据库，制度问题交给向量存储，实时问题交给 web search——Agent 会针对每个查询选择合适的数据源。正是这种在不同专业知识库之间进行路由的能力，让一个 Agent 可以同时处理账单和安全问题，又不会混淆两者。

RAG 与 Agentic RAG：关键差异

RAG 与 Agentic RAG 的区别，并不是一次由新事物淘汰旧事物的代际升级，而是一种架构层面的权衡。经典 RAG 为你带来速度和可预测性。Agentic RAG 为你带来适应能力和多步推理能力，但代价是更高的延迟、成本，以及为了追踪 Agent 实际执行了哪些操作而必须具备的可观测性。正确的选择取决于查询的复杂度、你的延迟预算，以及你愿意为监控这个循环投入多少资源。

RAG 与 Agentic RAG 的最佳实践

优秀的 AI 流水线都会设置 RAG guardrails，用于防范恶意输入、减少幻觉并限制数据访问。但由于这两种模式的故障点不同，它们需要的 guardrails 也有所不同。经典 RAG 的问题主要出在检索质量上，因此它的 guardrails 重点保护索引。Agentic RAG 还可能因为自主性而失败，所以它的 guardrails 还必须限制 Agent 可以执行哪些操作。

• 按权限限定检索范围：retriever 只能返回发起请求的用户有权查看的文档，而且权限必须在查询时强制执行，而不是等检索完成后再过滤。

• 使用混合搜索建立索引：结合语义检索和关键词检索，可以覆盖仅凭 embedding 容易遗漏的情况，例如 SKU 或错误代码等需要精确匹配的词语。

• 管理 chunk 切分和重叠范围：保持一致的 chunk 大小并设置合理的重叠区域，可以避免答案恰好落在边界上，从而丢失一半上下文。

• 使用 allowlist 限制工具：Agent 只能访问策略明确允许的数据源，避免因错误理解 prompt 而触发你从未授权的操作。

• 强制设置停止条件：通过限制最大迭代次数和 token 预算，可以防止推理循环在无法收敛时持续空转，并不断消耗成本。

• 为整个循环建立监控：逐步运行历史和分布式追踪，可以将不透明的 Agent 变成可审计的系统；使用测试集评估 RAG，则能把“看起来没问题”转化为一个经得起检验的量化指标。

要按照生产标准构建这两种模式，就必须从一开始将治理和可观测性纳入系统。n8n 填补了这方面的空白：你可以在可视化画布上组装 Agentic RAG，而不必通过代码将多个库拼接在一起；无论是在云端运行 OpenAI、Anthropic 或 Cohere，还是在本地运行 Ollama，都可以置于同一个 workflow 之中。

决策标准：经典 RAG 与 Agentic RAG

不存在普遍适用的赢家，只有架构与工作负载是否匹配。真正有效的检验方式，是查看你的真实查询——而不是演示中的查询——并判断单次检索究竟有多大概率能够满足这些查询。

选择经典 RAG 的情况

• 查询范围明确、定义清晰——例如单一数据源检索、FAQ 回答，或者答案完整存在于一个 chunk 中的参考页面。

• 延迟是硬性约束，任何额外的推理步骤都会带来你无法接受的成本。

• 知识库稳定且 chunk 切分合理，因此如何构建 RAG 流水线本身，就成为你提升可靠性的主要手段。

选择 Agentic RAG 的情况

• 查询经常需要整合多个系统中的证据——例如在同一个答案中同时使用日志、文档和 API。

• 用户经常提交含糊或信息不足的查询，必须先重新表述，检索才真正有意义。

• 你无法接受悄无声息的幻觉，并且需要 Agent 在证据不足时升级给人工处理或明确标记，而不是凭空猜测。

大多数团队都付出了昂贵代价之后，才明白这一点。他们从传统 RAG 起步，撞上它的能力边界，然后迁移到 Agentic 框架，并从头重建整个系统。如果两种模式可以共存于同一张画布上，你就能在熟悉的技术栈内扩展现有 workflow；从社区提供的 RAG workflow 库开始，也比面对一个空白文件更高效。

选择正确的架构

应该把它视为一项架构决策，而不是需要追赶的潮流。真正的问题不在于 Agentic RAG 是否更新，而在于你的查询是否复杂到足以证明引入控制循环是合理的——因为在引入之后，你还必须对这个循环进行观测和治理。当答案是肯定的时，你选择的底层平台将决定这种治理工作究竟有多痛苦。

n8n 可以在同一张可视化画布上运行线性流水线和 Agentic 循环，并提供执行历史和逐步可观测性，让自主 Agent 成为你能够放心用于生产环境的系统。

同时搭建两种模式

让最棘手的查询决定你真正需要哪一种模式。

n8n 用户拥有各种各样的背景、经验水平和兴趣。我们一直希望在博客文章中介绍不同的用户及其项目。如果你正在使用 n8n，并且愿意为社区带来启发，请联系我们 💌