AI应用三大支柱：Workflow、RAG与Agent的协作关系解析

April 5, 2026

上周我们探讨了Workflow的重要性，随后有许多读者私下联系，希望我能深入剖析Workflow、RAG与Agent之间的关联。这个问题起初让我有些为难，一方面觉得这三者之间的关系似乎不言而喻，另一方面又觉得它们之间并没有绝对的、排他性的联系。

然而，经过一番思考，我意识到这恰恰反映了一个普遍的AI认知现状：我们这些频繁接触AI项目的人视作常识的概念，对大多数人而言却相当陌生，这种信息鸿沟远比想象中要大。 就像我每天分享AI文章，我的家人可能选择忽略甚至感到厌烦。因此，我们认为理所当然的知识，对他人来说可能真的需要清晰的解释。

三大支柱概述

广义而言，Workflow（工作流）、RAG（检索增强生成）和Agent（智能体）可以被视为AI项目落地的三大技术支柱。它们分别对应着不同的业务场景需求：

Workflow：适用于流程明确、步骤固定的场景，如HR效率提升（自动筛选简历、录入身份信息）。
RAG：适用于需要基于特定、最新或私有知识库进行问答的场景，如智能客服。
Agent：适用于目标复杂、步骤不确定、需要自主规划和调度的场景，如根据指令自动搜索网络信息并生成PPT或博客文章。

由此可见，它们本质上是三种不同的技术路径或架构模式，并且并非互斥。一个RAG系统中很可能包含多个Workflow；一个复杂的Agent则很可能同时整合了Workflow的流程控制和RAG的知识检索能力。

如果用更抽象的概念来对应，它们依次关联着算法、数据与泛化能力。通俗的解释是：

Workflow 解决“如何做”的问题，它将任务分解为可控的、顺序执行的步骤。
RAG 解决“用什么数据做”的问题，它为模型提供完成任务所需的外部知识。
Agent 解决“如何灵活应对”的问题，它赋予系统一定的自主能力，能够自行组合合适的Workflow并调用所需的数据。

下面我们将对这三大支柱进行详细展开。

Workflow → SOP：流程化的基石

Workflow，或称工作流，核心是解决“如何一步步完成特定任务”的问题。许多人认为“工作流”一词过于简单，难以体现业务的复杂性，因此在实际交流中更倾向于使用“SOP（标准作业程序）”这个概念，后者在管理者听来也更具专业性。

SOP对应着我们常说的行业Know-How（技术诀窍）。它定义了为达成优质结果所应遵循的标准化流程，是一套可被设计和编码的策略，将人的经验与操作转化为机器可执行的语言，即算法实现或业务系统化。

Workflow的核心是“梳理”，其背后涉及大量的沟通、设计和流程优化等管理工作，这本身极具挑战。如果聚焦于“Workflow + 大语言模型”的具体应用，最常见的有两种形式：

一、关键词提取（实体/槽位填充）

一个经典案例是：“请问北京明天的天气情况如何？” 工作流程序会执行两个核心操作：关键信息提取与流程执行。具体来说，就是先提取出“明天”（时间）和“北京”（地点）这两个关键实体，然后调用相应的天气查询接口。这是早期利用模型能力最普遍的方式，也是提升AI产品稳定性的关键，专业上称为“实体提取”或“槽位填充”，我个人更倾向于“关键词提取”这个说法。

二、意图识别

同样以“请问北京明天的天气情况如何？”为例，为什么程序调用的是天气接口，而不是机票查询接口？这背后依赖的是LLM的自然语言理解能力，即意图识别。这正是Agent进行工具（Function Calling/Tool Calling）调用的准确性基石。何时调用天气接口、何时调用旅游规划接口，这些都需要提前被清晰地定义和设计。如果模型识别不准，我们可以通过微调或优化提示词等方式进行针对性处理。这也引出了一个关键点：

我们常讨论的模型可观测性，很大程度上就体现在意图识别这个环节。

为什么说“仅有Workflow还不够”？

既然Workflow模式如此稳定，而当前大模型最被诟病的就是其不稳定性，按理说企业应该非常青睐Workflow才对。事实确实如此：目前运行在生产环境中的AI应用，超过80%都基于Workflow构建。 真正对Workflow模式“不满”的主要是两类人：

专注于Agent方向、需要融资或售卖课程的人。
一线的研发与工程人员。

为什么研发人员会不喜欢？答案是：维护成本太高，这是一个极其复杂的工程问题。 下图展示了一个维护三年后的Workflow可能呈现的复杂状态：

Workflow的挑战不在于技术实现难度，而在于维护难度。它需要持续应对：

不断新增的用户意图。
频繁变更的业务策略（需求）。
用户千奇百怪、难以穷尽的表达方式。

本质上是有限的、预设的Workflow需要去覆盖和处理无限的用户意图与表达。 最终结果往往是维护成本呈指数级增长，到达某个临界点后，任何修改都可能引发新的错误。

至此，相信大家对Workflow的概念及其优缺点有了比较清晰的认识。接下来我们探讨RAG。

RAG：知识的桥梁

模型本身的知识受限于训练语料，无法满足信息快速更新、领域高度专业或数据严格保密的需求。为了获取更新、更专业、更私密的知识，RAG技术应运而生。

RAG常用的数据源包括本地结构化知识库和网络信息，同时也支持PDF、Word、Excel、图片等多种格式。

RAG的难点表面上在于“如何精准检索出用户所需的知识”，但真正的挑战在于其背后的一系列工程问题：如何进行数据结构设计、如何有效清洗数据、如何处理和优化用户提问等。

到这里，大家应该能看出：RAG系统必然离不开Workflow。 因为数据清洗、存储、用户问题重写、检索结果排序等每一个环节，都是一个具体的小Workflow。

尽管RAG的整体框架看起来简单，但实现一个可用的系统却非常困难。很多开发者可以快速掌握Workflow，但一旦要求构建一个简单的AI客服（RAG应用），就会感到无从下手。以下简述一个RAG项目的基本策略（不涉及具体代码），一次完整的RAG流程是：

用户提问 → 检索操作 → 返回结果

许多开发者在此遇到的最大问题是：检索返回了大量不相关的“垃圾信息”，导致整个流程失败；即使返回了相关内容，若噪音信息过多，也难以算作成功。

确保检索成功的核心有两点：

用户输入（查询）的优化：用户的原始提问是不可控的，因此，用于检索的关键词必须经过重写和优化。
数据源的质量保证：在输入（优化后的查询词）无误的前提下，必须能检索到正确答案，这就要求在数据处理的源头下功夫。

这两点分别对应着查询改写和高质量的数据入库处理：

一、查询改写

这个问题并非RAG独有，在Agent的工具调用中同样存在：用户表达模糊、包含多重意图，对模型的泛化理解能力要求极高，目前只有大模型能较好地解决。

核心矛盾在于：无限的、随机的用户意图需要被有限的工具或知识库边界所收敛和处理。例如，用户的一句话可能包含多个问题，但系统只能处理知识库内有明确答案的部分，对于超出范围的问题则应妥善拒答。

因此，在检索前对用户查询进行语义重写和聚焦，能极大提升检索精度。当前常见的策略是查询分解，有时也会用到HyDE（假设性文档嵌入）：

查询分解：核心思想是“分而治之”，将复杂的、多意图的查询拆分为多个独立的原子性子问题。
HyDE：策略是“先脑补，后检索”，让LLM基于原问题生成一份“假设的答案”，然后用这份蕴含丰富语义的假设文档去进行检索，以找到真正相关的材料。

二、查询效果评估

查询改写后进入实际检索阶段，随之而来的问题是：如何评估每次检索的效果？ 这是一个非常经典的工程与评估课题。常见的评估指标包括：

检索召回率（Recall@k）：优化后的查询，能否在返回的前k个结果中包含正确答案所在的文档。
查询意图保持度：通过人工抽样检查，判断改写是否扭曲了用户的原始意图。
下游任务准确率提升：最终生成答案的准确性是否因为查询改写而得到显著提高。

也有更通俗的问题归类方式：

没召回（问题可能出在数据入库、文本切分或索引构建环节）。
召回了但没选对（问题在于结果的重排序策略）。
选对了但答歪了（问题在于提示词设计或生成约束）。
本来就不该答（问题属于知识库边界外、需要调用工具或应转交人工处理）。

为了更清晰地定位问题，我们需要将评估细化到RAG的每一个环节：

路由正确 - 用户问题是否被分配到了正确的处理模块（意图识别）。
召回可靠 - 关键的证据文档是否被检索系统找到。
排序合理 - 正确的证据是否排在检索结果的前列。
回答可证 - 生成的答案是否严格基于被检索到的证据。
边界清晰 - 对于无法回答的问题，是否进行了恰当的处理（如拒答、澄清或转人工）。

这是一个循序渐进、持续优化的过程。下表通过一个简单案例，帮助大家理解不同环节的问题与修复方向：

错误类型	常见现象	修复方向
路由错误	意图识别漏标或多标；多意图查询未被拆分；路由到错误模块导致检索空间完全错误。	优化意图分类体系与描述；补充训练样本/处理难例；调整路由阈值与多标签策略；增加澄清追问机制；在路由后设置“兜底检索”流程。
搜不到（召回缺失）	前k个结果中完全无相关证据；因同义词或别名无法命中；长文档被切分过碎导致证据分散。	调整文本块（Chunk）策略（大小、重叠率、按结构切分）；将标题、摘要、条款编号等关键信息单独入库；利用元数据进行过滤；采用混合检索（如BM25+向量检索）；构建同义词与别名映射表。
搜到但没排上来（排序问题）	正确证据在前k个结果内，但不在最靠前的位置（如前3名）；冲突条款被旧版本信息压制；相似文本块重复占位。	引入重排模型或规则进行二次排序；为版本信息和适用范围添加权重；对检索结果进行去重与聚合；扩展首次检索的top-k数量，然后进行二次精筛。
证据对但回答错（生成失真）	引用了正确证据但结论计算错误或遗漏；错误地拼接了多个文本块的信息；对存在冲突的条款未声明冲突。	在生成时施加“严格基于证据”的约束；采用逐条引用或引用-断言绑定的方式；设计冲突处理模板（列出差异并请求用户确认）；对于计算或规则类问题，走结构化解析或专用工具流程。
边界处理错误	不该答的却回答了；该答的却拒绝回答或过度追问；缺少关键信息时不追问直接编造。	明确定义知识边界并制定范围外问题处理策略；设计缺失槽位（关键信息）的追问模板；调整拒答置信度阈值；设定明确的转人工条件；对“可答但信息不全”的情况设置最小化追问集合。

RAG的复杂性远不止于此，但以上内容应足以清晰阐明其与Workflow之间紧密的协作关系。最后，我们来探讨Agent。

Agent：自主的调度者

如前所述，用户无穷的意图难以用有限的、预设的Workflow或固定的知识表述来完全覆盖，否则无论Workflow还是RAG（数据层）的维护成本都将变得难以承受，最终导致AI项目失败。

在此背景下，Agent应运而生。虽然它的描述听起来颇具颠覆性——一种能够自主规划、执行并最终交付结果的智能系统——但其核心理念相对直接：旨在解决Workflow泛化能力不足的问题。本质上是通过增加推理循环和Token消耗，来动态生成更合理的任务执行步骤，从而缓解静态Workflow带来的工程维护压力。

同理，Agentic RAG的出现也是为了解决类似问题。 传统的RAG流程（检索→排序→生成）同样是写死的Workflow，一旦需求或数据格式稍有变化，就需要修改硬编码。而Agent的引入为流程的动态调整提供了可能。

不过目前来看，Agent在解决通用Workflow泛化上效果尚可，但在Agentic RAG领域的实践仍处于早期阶段。

以一个常见问题为例：“请问明天成都天气怎么样，我明天飞机到成都，要去旅游。” 用户在此表达了多重意图：

明确的天气查询需求。
隐含的接送机、酒店预订、旅游规划等潜在需求。

这正是Agent擅长处理的场景：目标开放、需求模糊、执行步骤不确定。基于ReAct等架构，Agent可以利用大模型的能力自行生成并执行一个动态的Workflow：

对于初学者，可以粗略地将ReAct框架视为Agent的典型代表：

ReAct框架

从模型能力的演进来看，LLM长期存在一个短板：只能“思考”和“对话”，无法直接“行动”。Function Calling / Tool Calling的出现，本质是为模型挂接了外部能力。但在实际复杂场景中，问题很快暴露：工具一旦增多、问题稍显模糊，模型就可能出现乱调用、错调用，整体稳定性差。

这既有模型自身理解能力的局限，也与一次性生成的“执行计划”（即Workflow）质量不高有关。ReAct架构的价值在于，它通过一个固定的推理-行动循环，强制将“思考”与“行动”耦合在一起： 推理（Thought） → 行动（Action） → 观察（Observation） → 再推理……

与传统模型一次性生成最终答案不同，Agent是“边想边做”，根据每一步的行动结果决定下一步。复杂的任务被拆解为多个可验证的小步骤，每一步都有明确的输入、输出和环境反馈。例如，回答“2018年世界杯冠军国家的总统是谁”，Agent会先查询并确认冠军国家（法国），再查询法国当时的总统信息。通过多轮“思考→行动→观察”得到可靠答案。

这种方式的意义不在于步骤增多，而在于错误不会被一次性放大，这也是ReAct能显著降低模型幻觉的重要原因。

但必须清醒认识到：ReAct并非万能解药。 它本质上是通过消耗更多的Token、引入更复杂的状态管理、增加工程复杂度，来换取Workflow的泛化能力。每一次循环都产生成本，每一次决策错误都可能被传递放大。状态设计、上下文管理、工具选择等都成了新的工程挑战。很可能出现的情况是：一个需要2步循环做不好的任务，即使增加到10步循环也未必能做好，因此需要大量的工程优化。

Agentic RAG

传统的RAG流程在使用中逐渐暴露出其局限性：检索 → 取前K个结果 → 填入提示词 → 生成答案。流程清晰，但一旦面对复杂、多跳的查询，就显得僵化无力。

于是，Agentic RAG的概念被提出，它将流程中的决策权交给了模型：

现在是否还需要继续检索？
应该检索正文还是附录？
是否需要更换检索关键词或切换数据源？
当前的证据是否充分，足以生成答案？

这些“判断”，在过去是隐藏在if-else逻辑或固定Workflow中的硬编码规则，依赖于开发者的经验。现在则通过ReAct等模式，将决策前移给模型，但具体执行（如检索、计算）仍由工程系统完成。这引发了一个重要的分工变化：

Agent不直接“干活”，而是负责“指挥谁、在何时、如何干活”。

许多人最初认为Agentic RAG是一种全新的RAG形态，但仔细拆解后会发现：

数据如何存储？—— 没变。
数据是否需要清洗处理？—— 依然需要。
非结构化数据（如表格）如何处理？—— 还是工程问题。
答案的引用如何确保准确？—— 仍需规则校验。
……

本质上，什么都没有变，唯一发生根本性变化的，是系统的“控制流”。 Agentic RAG是：人类定义好能力边界与可用工具 → 模型在边界内自主调度和执行流程。

这意味着什么？它有效解决了传统RAG在应对复杂、多跳查询时，因流程僵化而导致的信息割裂、证据不全等顽疾。 例如，在法律咨询、医疗诊断辅助等专业领域，Agentic RAG能够模拟专家的思维和工作流，从海量文献中精准定位、交叉验证信息，并输出具备可追溯性和可审计性的结论。

但必须注意，这种强大的灵活性是以更高的工程复杂度和推理（成本）为代价的。 它不仅没有替代数据处理等基础工作，反而对数据质量、系统架构的健壮性提出了更苛刻的要求。未来，Agentic RAG的发展方向将是框架化和组件化，通过提供更成熟的“技能”（Skills）库和调度框架来降低应用门槛，让开发者能更专注于业务逻辑而非底层实现细节。

总结

以上就是对Workflow、RAG和Agent三者关系的解析。正如大家所见，它们之间并没有严格的从属或替代关系，更像是构建智能应用时可供选择的、相辅相成的三种核心组件或设计范式。

理解它们各自的定位、优势与挑战，有助于我们在实际项目中做出更合适的技术选型与架构设计。