AI Workflow 和 AI Agent 有什么区别？
很多团队做 AI 应用时，会在两个词之间摇摆：Workflow 和 Agent。
用户提一个需求，系统要查资料、调用工具、生成结果。到底应该写成固定流程，还是交给 Agent 自己规划？
这不是概念问题，是工程问题。选错了，系统要么死板，要么不可控。
先说结论：
Workflow 是把流程写清楚，让模型在固定位置发挥；Agent 是给模型目标，让它在边界内自己决定路径。
Workflow 更稳定，Agent 更灵活。
Workflow 适合确定流程，Agent 适合不确定任务。
生产落地时，很多系统最好的形态不是二选一，而是 Workflow 里嵌一点 Agent。
这句话背后其实是一个很朴素的工程原则：能确定的东西交给代码，不确定的部分才交给模型。代码便宜、稳定、可测；模型灵活，但输出有波动。把确定流程交给模型，不是智能化，而是把可控问题变成不可控问题。
所以讨论 Workflow 和 Agent 时，不要先问哪个更先进。先问这件事里有多少步骤可以写死，有多少步骤必须探索。写死的比例越高，越应该偏 Workflow；探索的比例越高，才越需要 Agent。
Workflow 是确定性流程
Workflow 的特点是步骤预先写好。
比如一个“合同审查助手”可以设计成：
- 上传合同；
- OCR 或解析文档；
- 提取关键条款；
- 对照公司模板；
- 调用模型生成风险说明；
- 人工确认；
- 生成审查报告。
这里模型不是没有参与。它可能负责提取条款、总结风险、生成报告。但整个流程是谁定义的？是程序定义的。
模型只在固定节点工作。
Workflow 的好处是稳定。每一步输入输出清楚，失败点清楚，日志也好打。出了问题，你知道是 OCR 错了、条款提取错了、模板匹配错了，还是模型总结错了。
这类系统更像传统软件，只是在某些步骤里用了大模型。
Workflow 里的模型通常是“节点能力”，不是“流程主人”。比如在合同审查里，模型可以负责抽取条款、解释风险、生成报告措辞，但它不应该随意跳过人工确认，也不应该自己决定把报告发给客户。流程主控权仍然在代码里。
这让 Workflow 更适合合规、财务、运营这类场景。业务希望模型提高效率，但不希望模型改变制度。流程越接近钱、权限、法律责任，越应该让 Workflow 占主导。
Agent 是目标驱动
Agent 的特点是路径不完全固定。
用户说：“帮我分析这份合同有没有风险。”
Agent 可能先读合同，再查公司模板，再搜索历史合同，再判断风险，再补充问题，再生成结论。它可以根据中间结果调整路径。
如果合同里有数据合规条款，它可能去查合规规则。
如果合同里有付款条款异常，它可能去查客户信用。
如果合同缺附件，它可能要求用户补充。
这些步骤不是开发者提前完全写死的，而是 Agent 根据目标和上下文动态决定。
这就是 Agent 的价值：面对开放任务时，不用把每一种路径都预先编码。
但代价也很明显：不稳定。
它可能查错资料，可能漏查资料，可能在不该停的时候停，也可能在该停的时候继续折腾。
最大区别：谁决定下一步
区分 Workflow 和 Agent，最简单的问题是：
下一步由代码决定，还是由模型决定？
如果下一步固定写在代码里，这是 Workflow。
比如：
解析文档 -> 提取字段 -> 校验规则 -> 生成报告如果下一步由模型根据当前状态选择工具和动作，这是 Agent。
比如：
目标：定位测试失败原因 模型决定先看日志、还是先搜代码、还是先跑测试当然，现实里可以混合。比如大流程由代码控制，某个“分析原因”的节点交给 Agent 循环。这是很常见也很实用的方式。
这个判断还可以再细一点：如果模型只是在某一步生成内容，它是 Workflow 里的 LLM 节点；如果模型能决定接下来调用哪个工具、是否继续查、是否停下来，它才开始变成 Agent。很多系统其实只是“Workflow + LLM”，但因为用了工具调用，就被叫成 Agent。
工具调用本身不是分界线。分界线是决策权。一个固定流程里调用十个工具，仍然是 Workflow；一个模型在边界内动态选择两三个工具，也可以是 Agent。
Workflow 的优势
第一，稳定。
流程固定，结果更可预期。尤其是企业内部系统，很多业务不是追求聪明，而是追求稳定。
第二，容易测试。
每个步骤都能写测试。输入是什么，输出应该是什么，异常怎么处理，都能定义。
第三，容易审计。
你知道系统为什么走到某一步。审计日志可以按流程节点记录。
第四，权限好控制。
每一步能做什么，提前定好。模型不能突然决定调用一个危险工具。
第五，成本可控。
调用几次模型、查几次接口、跑多久，基本能估算。
所以不要小看 Workflow。很多真正能上线的 AI 应用，本质都是 Workflow。
Agent 的优势
第一，灵活。
任务路径不固定时，Agent 可以根据情况探索。比如排查故障、分析复杂数据、阅读陌生代码。
第二，开发成本低。
如果你要把所有分支都写成流程，可能非常复杂。Agent 可以先用一个通用循环覆盖长尾情况。
第三，适合开放问题。
比如“这个项目哪里有风险”“这个客户为什么流失”“这个告警可能是什么原因”。这些问题很难提前写死步骤。
第四，能处理未知状态。
Workflow 遇到没设计过的情况，通常失败。Agent 至少可以尝试查更多信息、提出假设、请求用户补充。
但这些优势都建立在工具边界清楚、上下文可控、动作可审计的前提上。
Agent 的灵活性也有成本。它不容易做确定性测试，因为你很难提前枚举所有路径；它不容易估算成本，因为循环次数可能变化；它也不容易做权限设计，因为模型可能在不同情况下选择不同动作。没有边界的 Agent，灵活性会变成系统不稳定来源。
所以 Agent 更适合放在“可探索、低写入、可人工复核”的区域。让它负责分析、归纳、提出假设、生成草稿；让 Workflow 负责确认、提交、发布、付款、权限变更。这样能吃到灵活性，又不把核心流程交出去。
什么时候用 Workflow
流程明确时，用 Workflow。
比如：
- 发票报销；
- 简历筛选；
- 合同审查的标准流程；
- 客服工单分类；
- 报表生成；
- 内容审核；
- 数据清洗；
- 审批流。
这些任务虽然可以用模型，但步骤本身是确定的。用 Workflow 更稳。
比如发票报销，不需要 Agent 自己想流程。它就应该按规则走：识别发票、校验抬头、匹配订单、检查金额、提交审批。
模型可以帮忙识别字段和解释异常，但不该决定财务流程。
什么时候用 Agent
路径不明确时，用 Agent。
比如：
- 代码 bug 定位；
- 复杂故障排查；
- 数据异常原因分析；
- 市场调研；
- 多资料综合判断；
- 安全风险初筛；
- 长尾客服问题处理。
这些任务的共同点是：你不知道一开始该查哪里。需要根据中间结果不断调整。
比如测试失败，可能是代码逻辑错，可能是测试数据错，可能是依赖版本错，可能是环境错。固定流程很难覆盖全部路径，Agent 更适合。
但 Agent 不一定要全自动。它可以只读分析，最后把建议给人确认。等某类任务稳定后，再把常见路径固化成 Workflow。
最好的形态：Workflow 管骨架，Agent 管开放节点
生产系统里，我更推荐这个组合：
外层 Workflow，内层 Agent。
比如一个故障排查系统：
- Workflow 接收告警；
- Workflow 拉取基础指标；
- Workflow 判断告警类型；
- 对复杂类型，调用 Agent 分析可能原因；
- Agent 只能使用只读工具；
- Agent 输出假设和证据；
- Workflow 根据规则决定是否创建工单或通知人工。
这样既有稳定骨架，又有灵活分析。
再比如内容生成系统：
- Workflow 收集主题；
- Workflow 检索资料；
- Agent 负责整理角度和大纲；
- Workflow 调模型生成初稿；
- Workflow 做格式检查；
- 人工审核发布。
这种架构比“一个 Agent 从头到尾全包”更容易上线。
还有一个好处是便于演进。刚开始你可以把不确定节点交给 Agent，观察它经常走哪些路径。等某些路径足够稳定，就把它们沉淀成 Workflow。这样系统会越来越可控，而不是永远依赖模型临场发挥。
比如客服里“物流延迟三天以内”的处理路径跑多了以后，可以固定成流程；只有跨境丢件、地址异常、用户投诉升级这类长尾情况，再交给 Agent 分析。Agent 不一定是最终形态，它也可以是帮助你发现流程的过渡工具。
一个简单判断表
如果步骤清楚，选 Workflow。
如果步骤不清楚，选 Agent。
如果风险高，选 Workflow 加人工审批。
如果任务开放，选 Agent 但限制工具。
如果任务跑多了路径稳定，把 Agent 的常见路径沉淀成 Workflow。
如果 Workflow 覆盖不了长尾，把长尾交给 Agent 探索。
这比争论哪个更先进有用。
不要把 Workflow 做成假 Agent
有些系统其实是固定流程，但为了宣传叫 Agent。
比如：
用户输入 -> 检索知识库 -> 模型回答这就是 RAG 问答，不是 Agent。
再比如：
上传文件 -> 提取信息 -> 生成摘要这是 AI Workflow，也不是 Agent。
这不是贬低。Workflow 很有价值。只是叫错名字会影响设计预期。你以为自己在做 Agent，就会不必要地引入规划、工具选择和循环；明明固定流程能解决，却把系统做复杂。
也不要把 Agent 当万能 Workflow
另一种错误是：不想设计流程，直接丢给 Agent。
比如报销、审批、支付、发版、权限变更，这些都有明确规则。你让 Agent 自己决定怎么做，不是智能，是把业务规则交给一个不稳定的推理系统。
Agent 可以辅助判断，但核心流程要写在代码里。
尤其是涉及钱、权限、生产环境、合规的地方，Workflow 应该占主导。模型可以生成建议，不能绕过规则。
最后总结一下
AI Workflow 和 AI Agent 的区别，不在于有没有大模型，也不在于有没有工具，而在于下一步由谁决定。
Workflow 由代码决定流程。它稳定、可测、可审计，适合确定性业务。
Agent 由模型在边界内决定路径。它灵活、适合开放任务，但更难控制。
真正可落地的 AI 系统，通常不是纯 Workflow，也不是纯 Agent，而是把两者组合起来：Workflow 管主流程，Agent 处理不确定节点。
能写死的流程，就写死。写不死的探索，再交给 Agent。
这不是保守，是工程。
最后还有一个落地判断：如果你很难解释系统为什么做了某一步，说明 Agent 成分太重；如果你发现流程经常卡在未覆盖分支，说明 Workflow 太死。好的 AI 系统不是把一边推到极致，而是在稳定性和灵活性之间找最小可用组合。