很多团队一开始做 Agent，真正卡住的不是模型，而是分类错误。
他们把本来适合做 workflow 的任务做成了 agent，于是系统变慢、变贵、变难测。 也有人把本来需要 agent 的任务硬塞进 workflow，于是流程图越画越大，分支越写越多，最后仍然经常卡死。
所以，区分 Agent 和 Workflow，不是术语洁癖，而是系统设计里的第一道分流。
如果只保留一句最有用的话，那就是：
Agent 和 Workflow 的本质区别，不在于有没有模型，
而在于“下一步由谁决定”。如果下一步由代码、图结构、规则引擎或显式节点关系事先定义好，那么它更接近 Workflow。 如果下一步需要系统根据当前上下文、环境反馈和目标状态在运行时判断，那么它更接近 Agent。
这句话看起来简单，但它几乎解释了后面所有差异。
Workflow 的核心是预定义控制流。 Agent 的核心是运行时决策权。
Anthropic 在公开工程文章里把这件事说得非常直接：
- workflow 是通过预定义代码路径编排 LLM 和工具
- agent 是由 LLM 动态决定过程与工具使用
LangGraph 的官方文档也给出几乎同样的区分：
- workflows 有预定代码路径，并按既定顺序运行
- agents 更动态，会自己定义过程与工具使用方式
OpenAI 在 Agents SDK 的 orchestration 文档里则换了一种说法，但本质一致：
orchestrating via codeallowing the LLM to make decisions
Google ADK 甚至把两类对象直接并列出来：
LLM Agents负责 flexible、dynamic decisionsWorkflow Agents负责 predefined、deterministic execution patterns
Microsoft Agent Framework 进一步把两者的系统边界讲清楚：
- agent 是由 LLM 驱动、可调用工具、步骤动态生成的执行单元
- workflow 是显式定义执行路径、可纳入 agent、人类、外部系统的业务过程
AWS 的 prescriptive guidance 也从架构模式上给出了类似判断：
- workflow agents 更接近 centralized coordinator 和 procedural orchestration
- 更自治的 agent collaboration 则意味着更高的灵活性和更高的协调成本
这些公开资料合在一起，其实已经形成了一个非常稳的判断标准：
Workflow 主要在设计期决定路径，
Agent 主要在运行期决定路径。这不是绝对二分，而是一条控制权光谱。
在光谱的一端，是完全确定的流程。 输入是什么，走哪条支路，调用哪个系统，什么时候结束，几乎都能在代码里提前写好。
在光谱的另一端，是高度开放的任务。 系统只知道目标，不知道中间要走多少步、查哪些信息、换哪些策略、是否需要交给别的 Agent 或人类。
大多数现实系统，其实都落在中间。 也就是说，真正成熟的架构往往不是“只做 Agent”或者“只做 Workflow”，而是：
在该确定的地方确定，
在必须灵活的地方放开。理解这一点以后，我们就不该再问“哪个更高级”，而应该问“该把自由度放在哪一层”。
为了把这个问题看得更清楚，我们可以从五个维度区分 Agent 和 Workflow。
第一，是控制流来源。 Workflow 的控制流来自程序员预先写好的图、节点、边、条件和顺序。 Agent 的控制流更多来自模型基于上下文做出的临场判断。
第二，是任务分解方式。 Workflow 先分解，再执行。 Agent 经常是一边观察，一边决定要不要继续分解、是否换工具、是否调整路线。
第三，是异常处理方式。 Workflow 通常提前定义失败分支和回退分支。 Agent 则更像运行时自适应系统，它可能根据失败原因重试、改写查询、切换工具、请求澄清，甚至改变整个策略。
第四，是可预测性。 Workflow 更容易估算路径长度、成本、时延和覆盖面。 Agent 的表现更依赖输入复杂度、环境反馈和模型当场决策，因此天然更难完全预测。
第五，是责任边界。 Workflow 更适合承载强合规、强审批、强责任链路的业务步骤。 Agent 更适合承载那些目标明确、但路径无法完整写死的任务推进环节。
如果把这五个维度压缩成一句话，就是：
Workflow 追求确定的可控性，
Agent 追求不确定条件下的可适应性。这里有一个特别容易被忽视的误区：
很多人以为 workflow 是“死板”，agent 是“聪明”。 这其实是错误的。
workflow 不是低级形态，而是把“复杂问题中已经确定的部分”固定下来。 agent 也不是高级形态，而是把“复杂问题中暂时无法预写的部分”留给运行时决策。
所以二者不是上下级关系，而是两种不同的控制策略。
这也是为什么 Anthropic 反复强调：
先从最简单的方案开始，
只有当固定路径不够时，再引入 agentic complexity。Google 和 AWS 这些平台资料都在提醒同一件事： 控制越往代码与流程图侧收，系统越可预测； 控制越往运行时模型决策侧放，系统越灵活，但也越难测、越难控。
微软把这个问题说得更彻底：workflow 本身可以包含 agent，agent 也可以运行在 workflow 之中。 这意味着两者不是互斥关系，而是可以相互嵌套的两种抽象层。
这一点非常关键。 因为现实世界里的系统，最常见的正确答案其实是混合架构。
最典型的三种混合方式是：
第一种，workflow 外壳，agent 内核。 整体流程由代码控制，例如先鉴权、再拉取数据、再进入审批、最后写回系统； 但其中某一步，比如“如何综合多源证据生成建议”，交给 agent 动态处理。
第二种，agent 外壳，workflow 子步骤。 系统先由 agent 判断任务类型，再选择不同的固定子流程。 例如客服 agent 先判断是退款、物流还是账户异常，再进入对应 workflow。
第三种，多层混合。 外层 workflow 负责责任链、权限、日志、审批和回滚； 中层 agent 负责任务分解和策略调整； 底层再接若干确定性的工具流程。
理解这三种混合方式，比空谈“到底用哪个”更重要。
因为很多业务问题并不是“开放式探索”或“固定式执行”二选一，而是同时包含两部分。
举个客服系统的例子。
如果任务是：
- 识别订单号
- 查询物流
- 按固定规则生成标准答复
那这显然更像 workflow。 即使中间用了模型做分类、抽取或文案润色，控制流仍然是预定义的。
但如果任务变成：
- 用户一次提出退款、补偿、发票、改地址多个诉求
- 不同系统里信息冲突
- 某些规则在新老订单、会员等级、履约状态下并不一致
- 系统需要动态判断先查什么、查到什么程度、何时升级人工
那么问题就从“执行既定流程”变成了“在任务过程中实时决定流程”。 这时 Agent 的价值才会真正出现。
再看内容生产或研究任务，差异也很明显。
如果任务只是“把既有素材整理成固定结构报告”，通常 workflow 就够了：
- 收集材料
- 清洗数据
- 填充模板
- 做格式检查
- 导出结果
但如果任务变成“面对不完整材料，决定应该补查什么、先问谁、是否需要改写问题、何时停止搜索并开始成文”，那它已经不再是静态模板流水线，而是动态探索过程。
研究论文里对这件事也有非常清楚的映射。
Plan-and-Solve 更接近“先规划后执行”的确定性路线，它适合把复杂任务先压成一个较稳定的中间计划。
ReWOO 把推理与观察解耦，也是在试图降低多轮环境依赖带来的成本与不稳定性，本质上是在把一部分 agent 式自由度重新收束成更可控的执行结构。
AutoGen 的价值，则在于把 computation 和 control flow 显式拆开，让开发者能更清楚地决定哪些部分交给对话驱动，哪些部分由程序控制。
这些研究没有否定 Agent，反而是在不断说明：
一旦任务规模上去，纯自由式 agent 很难直接落地，
系统通常需要不同程度的 workflow 化约束。这也是为什么工业界越来越重视状态图、typed edges、checkpoint、human-in-the-loop、trace、evaluation。 这些东西听起来像“工程配套”，其实它们恰恰是在补 Agent 天生不稳定的那一面。
因此，判断一个任务该做 Agent 还是 Workflow，可以先问六个问题。
第一，这个任务的主路径能不能提前写出来。 如果能，大概率先做 workflow。
第二，异常分支是否相对有限。 如果异常分支有限且可枚举，workflow 仍然占优。
第三，系统是否必须依据实时环境反馈持续改变策略。 如果必须，agent 的必要性会上升。
第四，步骤数量和顺序是否经常变化。 如果变化大，固定流程会迅速膨胀。
第五，结果是否需要强责任链和强审计。 如果需要，至少外层必须 workflow 化。
第六，失败成本能不能接受“模型当场判断失误”。 如果不能，就不该把关键控制权全放给 agent。
把这六个问题问完，很多争论会自动消失。
最后，本章希望留下的不是“Workflow 像铁路，Agent 像司机”这种类比本身，而是一条更可执行的系统原则：
Workflow 处理的是可预定义的控制流，
Agent 处理的是不可完全预定义的控制流。
真正成熟的系统，不是盲目追求更强的 Agent，
而是精确决定：哪些地方必须固定，哪些地方值得放权。下一章要继续拆开另一个常见误解：
为什么“会调用工具”这件事，仍然不足以定义一个 Agent。