梳理AI应用三大支柱：Workflow、RAG、Agent

本文来自微信公众号： 叶小钗 ，作者：叶小钗

上周我们强调了Workflow的重要性，私下又有很多粉丝找过来，一定让我聊聊Workflow、RAG与Agent之间的关系，这一下就把我难住了，一个是这东西有撒好解释的？另一方面他们之间貌似没什么绝对的关系...

但是细细一想就会发现问题，也体现了一个AI现状：

我们这些经常接触AI项目的，认为很简单的东西，其实多余数人是不清楚的，这个信息差比想象的大了很多！

比如，我天天发AI文章，我老婆一定是视而不见、甚至觉得有点烦的，所以我们觉得理所当然的知识，其他人可能真的不清楚，所以我们这里有必要再次好好解释一番：

unsetunset三支柱unsetunset

不严格来说Workflow、RAG、Agent属于AI项目的三大支柱，他们分别对应不同的业务场景，比如：

大家应该就看出来了，他们其实是三种技术路径，并且彼此之间并不是互斥的，比如RAG系统里面大概率有Workflow；Agent很可能既包含Workflow、又包含RAG。

按照我之前的定义，他们依次对应着算法、数据与泛化能力，说人话的话是：

接下来我们做详细展开：

unsetunsetWorkflow→SOPunsetunset

Workflow又称为工作流，解决的是

怎么一步步把这件事做完

SOP这个词

的问题，然后大家普遍认为Workflow是简单流程，难以表达业务的复杂性，所以大家用得更多的其实是，然后老板们从感受上也会觉得高级不少：

SOP对应我们常说的行业KnowHow，是我们要将这件事做好，应该具有什么样的流程，他是一套可以被设计的策略，

将我们日常的动作翻译为技术语言，也就是我们常说的算法实现或者业务系统化

。

Workflow的核心是整理

，其背后对应着各种管理问题，包括沟通、设计等，这个是非常耗能力的。但如果只是Workflow+LLM的具体用法的话，最常见的是两种变形：

一、关键词提取

还是上最经典的案例：

请问北京明天的天气情况如何？

工作流程序会执行两个操作：关键信息提取+流程执行。

对应这里的操作很简单，拿到明天到底是什么日期，拿到北京这个地点，时间地点提取成功后就调用天气查询接口。

这也是我们最初使用模型最最常用的功能，也是提升AI产品稳定性的核心，专业名称是：实体提取或槽位填充，我自己更喜欢用关键词提取这个词。

除了关键词提取外，第二个就是意图识别了：

二、意图识别

依旧是请问北京明天的天气情况如何？这个案例，为什么我们是要调用天气接口，而不是调用其他接口，这里的背后就是LLM最主要的能力，自然语言理解，其背后对应着意图识别。

大家可以看到，其实Agent的基石，Function Calling Tools调用的准确性也是在此。

什么时候要调天气接口、什么时候要调旅游规划接口、什么时候要...

这是我们提前规划好的，提前设计清晰的，如果是模型识别不准那么我们就针对性处理即可，可以是微调、也可以是提示词注入，从这里大家也一定意识到了：

我们常说的模型的可观测性，其实更多的就在这里

为什么Workflow还不够

到这里问题也就出来了，按理说Workflow这种模式很稳定，各个企业应该很喜欢啊，毕竟现阶段大模型最让人诟病的就是不稳定。

这里的答案是：

对的，各个企业确实都喜欢Workflow，并且实际跑在生产环境的80%都是Workflow

，真正不喜欢Workflow的是两种人：

那么为什么研发人员不喜欢Workflow呢？答案是

太复杂了，维护起来全是泪，这是一个工程问题

，比如下图是维护了3年的Workflow：

Workflow的挑战不在技术难度而是维护难度，需要面对的是：

也就是有限的Workflow需要面对无穷的用户意图（与表达），最终结果就是维护成本爆炸，到一定时间后谁改谁错。

至此，相信大家对什么是Workflow，包括Workflow有什么优缺点是比较清楚的了，我们接下来再说RAG：

unsetunsetRAGunsetunset

模型本身的知识是训练进去的语料，这东西肯定是不满足当前的信息流速的，为了获取

更新、更专业、更隐私

的知识，RAG技术应运而生。

RAG常用的数据源是本地结构化知识库与网络信息，但更多形式的也支持，包括PDF、Word、Excel、图片......

RAG难的核心表面上看是如何每次把用户需要的知识搜索出来，但背后真正难的是如何进行数据结构设计、如何清洗数据、如何处理用户问题......

到这里大家应该就看明白了：

RAG是一定离不开Workflow的

，因为数据如何清洗、如何存储、用户问题又如何重写、最终检索的内容如何排序等全部都是一个个小Workflow。

并且，整体RAG框架看起来简单，用起来非常难，很多同学掌握Workflow很快，到让他做个简单AI客服，一下就懵逼了，这里我们也描述下简单RAG项目怎么做，这里只说策略不举例，一次完整的RAG流程是：

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

很多同学这里最大的问题是：检索返回的都是不相关的垃圾信息。于是整个流程就宣告失败；如果返回了想要的内容，但是其中垃圾信息较多，也不能算成功。

搜索成功的核心有二：

改写用户查询，会慢及最烦躁的数据入库处理：

一、查询改写

这块也不只是RAG需要面临的问题，对于Agent的Tools调用，也会遭遇相同的问题：用户语言太模糊，他具有多意图，泛化能力要求极高，这东西只有模型能够解决。

还是那句话：用户无限的意图需要被有限的工具所收敛、对应着用户的无限问题需要被知识库做边界。

比如用户一句话可能有多个问题，但我们需要处理的只能是知识库里面有的问题，如果没有那么就无需处理。

综上，重写查询，相当于在检索前做一轮语义收束，会大大提升检索精确度，当前常见的策略是查询分解，偶尔会用到HyDE：

查询分解的核心思维是分而治之，将复杂或多意图查询拆分为独立的原子子问题；

HyDE(假设文档嵌入)属于先脑补，后检索，让LLM基于问题生成一份“假设答案”，用其丰富语义去检索；

这里具体如何做查询分解和HyDE我们就不展开了...

二、查询效果评估

查询改写后就开始真正的查询，问题就变成了

如何评价每次查询的质量

，这个是非常经典的面试题，常见的评估指标有：

也有通俗一点的说法：

但是每次我以为说清楚了，都还是有同学没明白，所以这里还需要进一步说细点：

首先，评估查询质量要细化到每个链条，这里依次是：

然后接下来就是具体的标准，这东西还不能一蹴而就，是个逐渐加强的过程，具体细节这里也不展开，给个简单案例表，大家体验下就行：

错误类型

常见现象

修复

RAG问题太过复杂，我们这里稍微点一下就好，应该足够清晰描述他与Workflow的关系了，最后就是Agent了：

unsetunsetAgentunsetunset

前面我们说了

用户无穷的意图难以被有限的Workflow、知识表述

，否则无论Workflow还是RAG（Data）的维护成本都会奇高，最终AI项目就会夭折。

在这个基础下Agent应运而生，虽然这东西从描述上似乎“牛逼轰轰”的：

具有自主规划并具有执行能力，能最终交互结果的系统

；

但其实很简单：

就是为了解决Workflow泛化能力不足的问题，其本质是用循环增加Token消耗，去换取生成的Workflow更合理的架构，最终解决的Workflow工程维护问题

；

对应着的Agentic RAG是一样的，常规的RAG其实也是写死了的Workflow，因为Workflow固定也因为数据格式的固定，所以这里稍微有点需求变化就要上硬代码，但Agent也同步解决了这个问题

。

只不过，暂时Agent解决Workflow的效果还不错，但是Agentic RAG做得一般

还是之前最常见的问题：请问明天成都天气怎么样，我明天飞机到成都，要去旅游。

这里用户的意图是很多的：

这就是Agent了：开放、模糊、需求不确定、步骤不确定。然后Agent的ReAct架构就会使用大模型的能力

自己生成Workflow

：

对于初学者，可以粗暴的认为ReAct框架就是Agent：

ReAct

从模型演进角度看，LLM长期存在一个硬伤：只能想、只能说，不能做。

Function Calling/Tool Calling的出现，本质是把“外部能力”挂到模型上，但在真实场景中很快就暴露问题：工具一多、问题一模糊，模型就开始乱调、错调，整体稳定性很差。

这里一方面是模型理解能力不足，另一方面是生成的Workflow不好，于是乎ReAct架构就来了，他的价值不是让模型更聪明，而是通过一个固定循环，把“思考”和“行动”强行绑在一起：

推理（Thought）→行动（Action）→观察（Observation）→再推理

模型是一次性生成答案，Agent是边想边做、看结果再决定下一步。复杂问题被拆成多个可验证的小步骤，每一步都有明确的输入、输出和反馈。

例如“2018年世界杯冠军国家的总统是谁”，Agent会先确认冠军国家，再查询该国总统信息，两轮“思考→行动→观察”后得到最终答案。

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

但需要清醒地认识到：

ReAct并不是银弹。

它本质上是用更多Token、更多状态管理、更多工程复杂度，去换取Workflow的泛化能力。每一轮循环都是成本，每一次决策错误都会被放大，状态设计、上下文管理、工具选择，都会成为新的工程难点。

很有可能的情况是：

2次循环做不好的，10次也做不好，所以需要做很多工程优化

。我们最后说下Agent与RAG的关系：

Agentic RAG

传统的RAG在使用过程中，大家慢慢发现一些问题：

流程非常清楚，但问题也很明显：

一旦问题变复杂，流程就不够用了。

与之前Workflow一样，Agentic RAG出现了，他把这件事交给模型：

这些“判断”，过去都藏在if-else/Workflow里，靠经验硬编码；现在是通过ReAct，把决策权前移给模型，但执行权仍然在工程侧。所以你会发现一个非常重要的分工变化：

Agent不“干活”，Agent负责“指挥谁干活”。

很多人开始以为Agentic RAG是一种“新的RAG形态”，但你仔细拆就会发现：

所以，什么都没有变，

唯一变化的，是控制流。

Agentic RAG是：人设计能力边界→模型在边界内调度流程。

这意味着什么？

它有效解决了传统RAG在应对复杂、多跳查询时，因流程僵化而导致的信息割裂、证据不全等顽疾。

例如在法律、医疗等专业领域，Agentic RAG能模拟专家的工作流，从海量文档中精准定位并交叉验证信息，输出可追溯、可审计的结论。

但要注意，

这种强大的灵活性以更高的工程复杂度和推理成本为代价。它并非替代了数据处理等基础工作，而是对数据质量和系统架构提出了更高要求。

未来，Agentic RAG的发展方向将是框架化、组件化，通过提供更成熟的“技能”（Skills）库和调度框架，降低其应用门槛，让开发者能更聚焦于业务逻辑而非底层实现。

unsetunset结语unsetunset

以上就是Workflow、RAG、Agent之间的关系，如大家看到的，他们直接其实没什么必然的关系...