Workflow vs Agent：什么时候用哪个

1.1 确定性 vs 自主性：两种根本不同的系统设计哲学

Workflow vs Agent 对比 — 左侧为确定性Workflow特点，右侧为自主Agent特点，以及选择决策依据

Workflow 和 Agent 的区别不是"AI 程度高低"的问题，而是两种根本不同的设计哲学，它们在面对"不确定性"时采取了完全相反的策略。

Workflow 的策略：消灭不确定性

工作流的设计出发点是：把所有可能发生的情况事先想清楚，为每种情况定义明确的处理路径。所有的分叉点（if-else）都由工程师在设计时预先编码。运行时，系统只是在执行这些预设路径，不做任何"思考"。

这种策略的代价是：遇到预设路径之外的情况，系统不知道怎么办。代价是可预见性——系统行为完全由代码决定，可测试、可审计、可解释。

Agent 的策略：拥抱不确定性

Agent 的设计出发点是：承认不可能预见所有情况，所以把决策权交给 LLM。给定目标，LLM 自己决定怎么做、用哪些工具、什么时候停止。

这种策略的代价是：行为是概率性的，同样的输入可能产生不同的输出，难以完全预测和审计。代价是灵活性——能处理预先未定义的情况，能理解模糊指令。

两者的核心区别归结为一句话：

Workflow 是"确定性机器"——所有路径都是预设的，执行是机械的，不允许偏差。Agent 是"自主智能体"——路径是动态生成的，执行是推理的，允许根据实际情况调整。

明白了这个根本区别，什么时候用哪个就变成了一个清晰的工程判断：这个任务的所有情况可以被完整枚举吗？如果是，用 Workflow；如果不是，考虑 Agent 或混合方案。

本章讨论工作流（Workflow）和 Agent 的本质区别，提供决策框架，并通过具体案例说明如何在实际项目中做出选择。

在设计 AI 自动化系统时，一个核心架构决策是：这个场景该用工作流还是 Agent？这个选择不是技术偏好问题，它直接决定了系统的复杂度、可靠性，以及出问题时能不能快速定位。选错了，要么过度设计，要么到处是漏洞。

1.2 Workflow 是什么

工作流的本质是预定义的执行路径。每一步做什么、按什么顺序做、满足什么条件走哪条分支——都是事先确定好的。

举个具体例子：公司的报销审批。

code

提交报销单
→ 金额 < 500 元？
    → 是：直接发给部门经理审批
    → 否：金额 < 5000 元？
        → 是：发给财务总监审批
        → 否：发给 CFO 审批
→ 审批通过？
    → 是：打款
    → 否：退回申请人，注明原因

这套流程清晰、固定、可重复。财务部门喜欢这种系统，因为：每一笔审批都有记录，出了问题能追溯到具体节点，合规审计一目了然。

工作流的优点就是它的确定性。系统行为完全可预测，测试覆盖容易，出错之后定位也快——能直接看到是哪个节点失败了。

但缺点也来自同一个地方：规则之外的情况处理不了。

比如用户提交报销单时附了一条备注："这笔费用很特殊，是帮领导垫付的，金额虽然超标但情况特殊。"工作流不认识这条备注，它只看金额，按规则走。如果这种"特殊情况"很多，只能不断往流程里加分支，流程越来越复杂，维护越来越难。

1.3 Agent 是什么

Agent 的本质是目标导向的自主执行。给它一个目标，它自己想怎么达成。

以出差安排为例：对一个刚入职的聪明新员工说"帮我安排下周三去上海的出差"，不需要告诉他第一步查航班、第二步比价格、第三步看是否需要提前预定酒店——他自己会想，自己会问需要补充的信息，遇到航班取消会主动找备选方案。

Agent 处理任务的方式不是按图索骥，而是在执行过程中持续感知、判断、行动：

这套循环让 Agent 能处理意外情况，能应对模糊指令，能在信息不完整时主动补充。

代价是不可预测性。同样的输入，Agent 每次可能走不同的路径，调用不同的工具，得出略微不同的结论。这在合规要求高的场景里是一个严重问题——无法向审计人员解释："这笔退款是 AI 自己决定退的，内部决策过程不透明。"

1.4 决策框架

面对一个新需求，可以用这棵决策树来判断：

几个关键判断点：

任务步骤是否完全确定？ 如果能把所有可能的情况列举出来，并且这个列表相对稳定，优先考虑 Workflow。如果发现自己在说"大概是这样，但有时候也可能……"，这个"但是"越多，越往 Agent 方向走。

合规审计要求高不高？ 金融、医疗、法务相关的场景，操作必须有迹可查，逻辑必须可解释。这种场景用 Agent 做核心决策是不合适的，除非每个 Agent 的决策都被记录和人工复核。

外部信息复杂多变吗？ 如果任务需要处理大量非结构化文本——用户写的投诉邮件、客服对话记录、产品评价——规则引擎很难覆盖，这时候 LLM 的理解能力就有价值了。

1.5 具体案例：退款处理

同一个退款需求，Workflow 和 Agent 分别怎么做？

1.5.1 方案 A：纯 Workflow

code

收到退款申请
→ 检查订单状态（已发货/未发货/已签收）
→ 检查申请时间（距购买几天内）
→ 检查退款原因（质量问题/不喜欢/描述不符）
→ 按规则矩阵判断：自动退/人工审核/拒绝
→ 执行对应操作

优点：规则透明，好维护，出问题好查。

缺点：用户写"收到的东西和图片完全不一样，我很失望"，系统不认识这段话，只能归类到"其他"走人工。用户写"快递损坏"，系统得靠关键词匹配，漏词就分类错。

1.5.2 方案 B：纯 Agent

给 Agent 一个目标："判断这个退款申请是否应该通过，执行对应操作。"它自己去读订单信息、理解用户描述、查退款政策、做判断。

优点：能理解模糊表达，灵活。

缺点：判断依据不透明，同类申请可能处理结果不一致，客服无法向用户解释为什么被拒，出了投诉不好追责。

1.5.3 方案 C：混合方案（实际推荐）

骨架用 Workflow，灵活节点用 Agent：

Agent 只负责干它擅长的事：把用户的自然语言描述转化成系统能理解的分类标签，以及在需要人工介入时生成有用的摘要。决策逻辑本身还是由 Workflow 控制，保证可审计性。

这样既利用了 LLM 的语言理解能力，又保持了流程的可控性。

1.6 选择的实质

Workflow 和 Agent 不是新旧之分，也不是高下之分。

工作流是确定性的力量——用在它该用的地方，比任何 AI 都可靠。Agent 是灵活性的力量——用在规则无法覆盖的地方，解决人工规则解决不了的问题。

一个常见的误区是：觉得 Agent 更"智能"，就想把什么都用 Agent 做。结果系统行为难以预测，测试覆盖不了，上线后问题频发，最后反而比原来的规则系统更难维护。

另一种极端是：觉得 Agent 不可控，就拒绝用，所有东西都用规则写死。结果规则越堆越多，覆盖不了的边界情况越来越多，系统越来越脆。

正确的问题不是"该不该用 Agent"，而是"哪些地方的不确定性值得用 Agent 来处理，哪些地方的确定性需要 Workflow 来保障"。

把这两个问题想清楚，架构就出来了。