08 RAG、Workflow、Agent 与传统自动化选择
章节目标
学会根据业务任务选择 RAG、Workflow、Agent、MCP 工具调用或传统自动化，避免为了炫技堆复杂架构。
开篇案例：为什么不是所有任务都需要 Agent
一个财务团队想做“财务报表分析 Agent”。如果直接让 Agent 自由读取 Excel、判断异常、生成报告、给出经营建议，看起来很先进，但风险很高：公式可能算错，指标口径可能不一致，模型可能把正常波动说成经营风险。
更稳的做法是：用传统代码解析表格和计算指标，用 Workflow 固定分析步骤，用 RAG 引用会计政策，用模型生成报告草稿，最后由财务人员复核。这里并不需要一个“全能 Agent”，而是需要把不同架构放在合适位置。
架构选择的核心不是追求复杂，而是回答：哪一步需要语言理解，哪一步需要规则确定性，哪一步需要工具，哪一步必须人审。
架构选择原则
- 信息检索和知识问答优先考虑 RAG。
- 固定流程、固定模板和可控步骤优先考虑 Workflow。
- 多步骤动态任务、需要工具选择和异常处理时考虑 Agent。
- 跨系统任务需要 Tool Calling、MCP 或 API Gateway。
- 规则明确且模型价值不大时，优先使用普通自动化。
- 高风险动作必须设置 Human-in-the-loop。
判断流程
flowchart TD
startNode[业务任务] --> dataQuestion{主要问题是找资料吗}
dataQuestion -->|"是"| ragNode[RAG]
dataQuestion -->|"否"| stepQuestion{步骤固定吗}
stepQuestion -->|"是"| workflowNode[Workflow]
stepQuestion -->|"否"| toolQuestion{需要动态选择工具吗}
toolQuestion -->|"是"| agentNode[Agent]
toolQuestion -->|"否"| automationNode[传统自动化]
agentNode --> reviewNode[高风险动作人审]
workflowNode --> reviewNode
架构对比
| 架构 | 适合任务 | 风险 |
|---|---|---|
| RAG | 知识问答、制度检索、引用溯源 | 权限过滤和召回质量 |
| Workflow | 报告生成、审批摘要、固定处理链 | 流程变化时需要维护 |
| Agent | 风险分析、多工具任务、动态异常处理 | 状态、评估和可控性 |
| MCP / Tool Calling | 查询系统、发消息、创建工单 | 工具权限和执行风险 |
| 普通自动化 | 规则明确、步骤固定、无语言理解需求 | 容易被低估但更稳定 |
架构选择的三问
每次面对新场景，先问三个问题：
- 主要不确定性在哪里？ 如果不确定性来自知识查找，用 RAG；来自步骤变化，用 Agent；来自口径和计算，用规则或工具。
- 失败成本在哪里？ 如果失败会影响资金、法律、客户承诺，就必须加人审和回滚。
- 最小验证链路是什么？ 不要从平台化开始，先跑通一个能证明价值的闭环。
组合式架构样例
| 场景 | 推荐组合 | 为什么 |
|---|---|---|
| 制度问答 | RAG + 引用校验 | 核心是找对资料 |
| 运营日报 | 表格工具 + Workflow + RAG | 计算确定，报告生成可模板化 |
| 供应链风险 | Agent + 工具调用 + 审批 | 需要动态查询多系统 |
| 公文抽取 | OCR + 结构化输出 + 人审 | 字段准确性和责任边界重要 |
| 客服分流 | 分类模型 + RAG + Workflow | 主路径固定，高风险转人工 |
你可以把这张表当成架构评审的第一版，不要让团队一开始就陷入框架选型争论。
实操任务
对你的场景做架构选择：
- 主要任务是什么？
- 哪些步骤固定？
- 哪些步骤需要模型判断？
- 哪些工具必须调用？
- 哪些动作不能自动执行？
交付物
- 架构选择矩阵。
- 最小链路图。
- 人审节点清单。
常见误区
- 所有任务都做成 Agent。
- 用 RAG 解决需要计算和工具调用的问题。
- 忽略传统规则和普通自动化。
- 没有为 Agent 设计状态和评估。
检查清单
- 是否能解释为什么不用更复杂架构？
- 是否知道每个模型步骤如何评估？
- 是否明确工具调用权限？
- 是否有最小可验证链路？