工作流与 Agent 的工程选型：从“控制权归属“看 LLM 应用架构

工作流与 Agent 的工程选型：从"控制权归属"看 LLM 应用架构

本文从一道常见的 AI 工程化面试题出发------"什么时候用工作流？什么时候用 Agent？"------梳理工作流（Workflow）与智能体（Agent）的核心差异、适用边界、混合架构实践，以及工程选型时容易踩的"伪 Agent"误区。文章内容兼顾概念辨析与落地参考，适合从事 LLM 应用开发、RAG/agent 框架选型的工程师阅读。

一、问题的本质：这不是"会不会用工具"的问题

很多开发者第一次听到"什么时候用工作流、什么时候用 Agent"时，容易陷入两个误区：

要么把它当成一道"背诵题"，罗列 LangGraph、CrewAI、AutoGPT 等框架的名字；
要么把它当成一道"Prompt 题"，纠结于 System Prompt 怎么写、多智能体怎么编排。

但实际上，这道题考察的是工程选型思维 ：面对一个业务问题，你能否判断------哪些环节该交给确定性的规则，哪些环节值得交给模型动态决策。

换句话说，核心不在于"Agent 是不是更先进"，而在于"这个场景是否需要、以及能否承受 Agent 带来的不确定性"。

二、核心差异：控制权归属不同

工作流与 Agent 最根本的区别，在于执行路径的控制权归谁。

维度	工作流（Workflow）	智能体（Agent）
控制权	预设规则/代码控制执行路径	大模型根据目标与反馈动态决策
执行方式	类似流水线，步骤预先定义	类似"有经验的员工"，边看边判断
适用问题	已知路径（Known path）	未知路径（Unknown path）
典型特征	稳定、可控、可重放	灵活、自适应、需闭环
主要代价	路径固化，难以应对新分支	不确定性、排查难、成本难预估

可以用一句话概括：

工作流解决"已知路径下的稳定执行"；Agent 解决"未知路径下的动态决策"。

2.1 工作流：用规则把路径固化

工作流的路径是提前设计好的。开发者把业务拆成若干节点（Node），用有向图或状态机把节点串起来，数据按既定顺序流动。

工程上真正看重工作流的，通常不是"模型够不够聪明"，而是三点：

稳定、可控：每一步的输入输出可预期，行为可复现；
成本可预估：没有多轮推理和大量工具调用的不可控开销；
出错风险可管理：节点边界清晰，便于熔断、重试和降级。

只要这三点要求高，工作流往往就是更合适的选择。

2.2 Agent：用模型把决策留出来

Agent 的路径不是（也不能）完全预先写死。它由 LLM 充当"决策者"，根据当前状态、可用工具、工具返回结果和执行反馈，决定下一步做什么，形成一个"感知---决策---执行---反馈"的闭环。

Agent 真正有价值的能力，不是"会聊天"，而是基于当前状态进行动态决策。当任务路径无法被穷举、且业务愿意为灵活性承担一定不确定性成本时，Agent 才有用武之地。

三、什么时候更适合用工作流

工作流适合两类典型场景。

3.1 高频、重复、路径稳定的任务

例如：内容分类、数据清洗、客服意图分流、工单自动派发等。

这些任务的共同点是：规则比较清楚，路径相对稳定。把流程搭好之后可以持续复用，效率高，出问题也容易定位到具体节点。

3.2 低容错、强可控的业务场景

例如：金融审批、医疗审核、法务流程、合规检查等。

这类业务往往要求强可控性，不能让模型"临场发挥"太多------一旦出错，代价很高。工程上通常采用"工作流 + 人工兜底/审核节点"的方式，把关键决策权留在可控范围内。

四、什么时候需要 Agent

判断是否需要 Agent，关键不在于"任务难不难"，而在于路径能不能被提前穷举。当出现下面几种情况时，Agent 的价值会更明显。

4.1 需求本身模糊，目标明确但路径开放

例如用户说："帮我规划一个亲子行程，预算适中，避开高峰。"

目标是有的，但中间要"查什么、比什么、怎么调整"并不是固定流程，需要根据实时信息反复权衡。这类开放式任务天然适合让模型参与决策。

4.2 路径难以提前写死

当用户后续提问不可预测、分支繁多、且每一步不一定一次成功时，硬编码所有分支的成本会急剧上升。此时由模型根据中间结果动态选择下一步，反而更经济。

4.3 需要"先尝试、看结果、再修正"

例如复杂的代码调试、跨多源信息的调研报告撰写、需要多步工具调用的数据分析等。

这类任务往往不是一步到位，而是"尝试 → 观察结果 → 修正策略 → 再决策"的迭代过程，恰好是 Agent 动态决策闭环擅长的部分。

五、真实工程：更多是"混合架构"

在生产落地中，工作流与 Agent rarely 是二选一的关系，更常见的形态是混合架构（Hybrid Architecture）。

一个贴近实际的设计原则是：

让工作流做主干，让 Agent 做局部决策。

典型链路可以是：

复制代码

用户需求 → [工作流] 流程路由/参数校验
        → [Agent]  复杂节点动态决策（工具调用、信息整合）
        → [工作流] 审核/风控/输出格式化
        → 最终输出

其中：

前后边界、流程编排、风控规则由工作流控制；
不确定、需要灵活处理的那一小段才交给 Agent。

这种"Workflow first, Agent second"的思路，既保留了整体链路的稳定性，又在关键节点释放了模型的灵活性，是目前许多 LLM 应用落地的主流做法。

六、四个工程选型判断标准

如果在方案评审或面试中需要给出结构化判断，可以从以下四个标准出发：

路径能否提前定义？
- 能定义 → 偏向工作流；
- 不能定义 → 再考虑引入 Agent。
风险高不高？
- 风险越高，越不应把决策权随意交给模型；
- 高敏场景常用"工作流 + 人工兜底/审核"。
是否要求可审计、可留痕？
- 需要回放、复盘、合规审计的场景，工作流更易追踪每一步；
- Agent 的多步决策链路需额外设计日志记录才能满足审计要求。
成本是否会失控？
- 多轮推理 + 多工具调用下，Agent 的 token 成本、延迟和失败率都更难控制；
- 对成本敏感的场景，应优先用工作流兜底。

七、为什么不直接让 Agent "全包"

一个自然的追问是："既然 Agent 更灵活，为什么不干脆让 Agent 处理全部流程？"

原因在于 Agent 的代价同样明显：

不确定性：相同输入未必得到相同行为，难以完全复现；
链路难排查：动态决策路径不固定，问题定位成本更高；
成本/延迟难估计：多轮推理与工具调用会带来不可控的开销和尾延迟。

而工程系统优先保证的，往往是稳定性、过程可控性、结果可评估性。因此，"先工作流兜底，必要时再引入 Agent"通常是更稳健的工程表达。

八、警惕"伪 Agent"

最后一个容易加分、也容易被忽视的点：不要把"伪 Agent"当成真正的 Agent。

当前不少产品名带"Agent"，但其本质可能只是：

一个包装过的聊天框；
一个固定 Prompt；
一个单纯的 RAG 问答；
或一个单一工具调用脚本。

判断是否真正属于 Agent，关键不在名字，而在于是否具备"动态决策闭环"：能否根据当前状态、工具返回和执行反馈，自主决定下一步行动。

如果没有这个闭环，它更接近"工作流/脚本化调用"，不宜套用 Agent 的复杂度与预期。

九、总结

回到开头的问题，最稳健的回答可以归纳为三点：

工作流 解决已知路径下的稳定执行，Agent解决未知路径下的动态决策；
流程清楚时优先用工作流，路径不确定时再考虑 Agent；
生产落地中，更常见的是"工作流做主干 + Agent 做局部决策"的混合架构。

这道题目表面问的是 AI 技术选型，实际考察的是更底层的工程思维：你是否清楚------什么场景应追求灵活，什么场景应优先保证可控。而"Workflow first, Agent second"，正是一种兼顾稳定性与灵活性的务实选择。