很多人想知道：Workflow、RAG 和 Agent 到底是什么关系？这个问题看似简单，却让我一时语塞——一方面，这些概念在实际项目中高度交织，并无绝对界限；另一方面，它也暴露了当前 AI 领域的典型现象：我们这些深度从业者觉得“理所当然”的知识，对大多数人来说其实仍有不小的信息差。
不严格的“三大支柱”：场景与定位
Workflow、RAG 和 Agent 可以视为现代 AI 项目的三大核心技术路径，它们分别对应不同业务复杂度，并非互斥，而是高度互补：
| 支柱 | 核心能力 | 典型场景 | 对应本质 |
|---|---|---|---|
| Workflow | 任务可控、步骤执行 | HR 提效（简历筛选、身份证录入） | 算法 / 流程设计 |
| RAG | 数据获取与注入 | AI 客服、知识问答 | 数据 / 外部知识补充 |
| Agent | 自主规划与泛化 | 复杂任务（自动搜索并生成 PPT、报告） | 泛化能力 / 动态决策 |
现实中，它们常常组合使用：RAG 系统内部通常包含 Workflow；Agent 则很可能同时集成 Workflow 和 RAG。
用更直白的话总结：
- Workflow：解决“怎么一步步把事做完”，强调可控性。
- RAG：解决“模型怎么拿到最新/专业/私有数据”。
- Agent：解决“系统怎么应对开放、模糊、复杂需求”，通过动态组装 Workflow 和数据源，实现部分自主能力。
下面我们逐一展开。
Workflow：从 SOP 到生产主力
Workflow（工作流）本质上是将业务流程翻译成可执行的技术语言，常被称为 SOP（标准作业程序）。它代表行业 Know-How，核心在于“整理”与“设计”，将日常操作系统化。
在 LLM 时代，Workflow 的两大经典变形是：
- 关键词提取（实体/槽位填充） 示例：“北京明天的天气如何？” 系统先提取“北京”（地点）和“明天”（日期），再调用天气接口。这是最早期、最稳定的 LLM 应用方式。
- 意图识别 系统判断用户想查天气而非旅游规划，从而路由到正确接口。Function Calling 的准确性也依赖于此。
为什么 Workflow 还不够？
Workflow 稳定性极高，企业最爱——据观察，生产环境中约 80% 的 AI 系统仍以 Workflow 为主。但它有两个天然敌人：
- 融资/卖课的 Agent 玩家：Workflow 不够“性感”。
- 研发人员：维护成本爆炸。
核心痛点是工程维护，而非技术难度：
- 新增意图层出不穷；
- 业务策略频繁迭代；
- 用户表达千变万化。
有限的 Workflow 难以覆盖无穷的用户意图，最终导致维护崩盘。一套运行 3 年的 Workflow 图，往往密密麻麻、改谁谁哭。
RAG：知识补充的必备方案
大模型的预训练知识无法跟上信息更新速度，也缺乏企业私有/专业数据，RAG（Retrieval-Augmented Generation）应运而生。它通过外部知识库（文档、数据库、网络等）为模型注入实时信息。
RAG 表面难点是“检索准确”，实际难点在于全链路数据工程：清洗、切分、索引、查询改写、排序等——这些本质上都是小 Workflow。因此，RAG 离不开 Workflow。
一个完整 RAG 流程看似简单：
用户提问 → 查询改写 → 检索 → 重排 → 生成答案
但失败率极高，常见问题是“检索不到”或“检索到垃圾”。成功关键在于两点：
- 查询改写：收束用户模糊/多意图表达
- 查询分解：将复杂问题拆成原子子问题
- HyDE：先生成“假设答案”再检索，提升语义匹配
- 数据质量与评估：确保“该有的内容一定能被搜到”
RAG 质量评估经典维度（也是常见面试题）：
| 错误类型 | 常见现象 | 修复方向 |
|---|---|---|
| 路由错 | 问题被分到错误模块 | 完善意图体系、补难例、增加兜底检索 |
| 搜不到 | Top-k 无相关证据 | 优化 chunk 策略、混合检索、同义词表 |
| 搜到但没排上 | 正确证据被埋没 | 重排模型、去重聚合、版本优先级 |
| 证据对但答错 | 生成失真、遗漏、冲突未说明 | 严格证据约束、逐条引用、冲突模板 |
| 边界处理错 | 不该答强答 / 该答却拒绝 | 明确范围外策略、缺槽追问、转人工条件 |
这些环节环环相扣，缺一不可。
Agent：用循环换取泛化能力
Workflow 和传统 RAG 的核心问题是“固定流程难以应对开放需求”。用户意图无穷，硬编码成本爆炸——Agent 正是为此而生。
Agent 本质是用更多 Token 和循环，换取动态生成的 Workflow，从而解决维护难题。Agentic RAG 同理：将传统 RAG 的僵化控制流交给模型决策。
最经典的 Agent 框架是 ReAct（Reasoning + Acting）：
- 问题：LLM 只能“想”和“说”，不能“做”。
- Function Calling 出现后，工具多了但调用乱了。
- ReAct 解决方案：强行绑定“思考 → 行动 → 观察”循环。
示例：“2018 年世界杯冠军国家的总统是谁？” Agent 会分步：先查冠军（法国）→ 再查总统（马克龙），每步可验证，显著降低幻觉。
但 ReAct 不是银弹：
- 成本更高（多轮 Token、状态管理）；
- 工程复杂度上升（工具选择、上下文管理）；
- 某些问题 2 轮做不好，10 轮也未必好。
Agent 与 RAG 的融合：Agentic RAG
传统 RAG 的固定流程（先查 → Top-k → 生成）在复杂、多跳查询中容易失效。Agentic RAG 将决策前移：
- 该不该继续查？
- 查哪个数据源？
- 证据够不够？
核心变化：控制流从硬编码变为模型调度，执行仍由工程侧完成。
这意味着：
- 数据清洗、存储、表格处理等基础工作一点没少；
- 唯一改变的是“谁来决定下一步”。
Agentic RAG 特别适合法律、医疗等需要交叉验证的专业场景，能输出可追溯结论。但代价是更高工程复杂度和推理成本。未来方向是框架化、技能（Skills）库化，降低门槛。
结语
Workflow、RAG 与 Agent 之间并无绝对界限，而是层层递进、互为补充的关系：
- Workflow 是基础，提供稳定可控的执行框架；
- RAG 是数据层扩展，让模型“知晓”外部世界；
- Agent 是泛化层突破，用动态规划应对开放复杂需求。
大多数生产系统仍以 Workflow + RAG 为主，Agent 更多用于探索性或高价值复杂场景。理解三者关系，能帮助我们更理性地选择技术栈，避免盲目追逐“Agent 热”而忽略基础工程。
希望这次拆解能彻底澄清大家的疑惑。如果还有具体场景想讨论，欢迎继续交流！