这是一个在项目启动会上经常被问到的问题我们要做 AI是用 Workflow 还是 Agent不过这里先要澄清一个概念Workflow 是执行模式工作台是产品形态。本文讨论的不是界面长什么样而是数字员工背后的执行方式是否以 Agent 为中心。换句话说真正需要比较的是预编排的 Workflow和以 Agent 为核心的动态执行环境。问题本身没有问题但回答这个问题需要先放弃一个隐含的假设两者之间存在优劣之分选对了就比选错了好。实际上两者解决的是不同结构的问题用错了场景再好的技术也会表现糟糕。把选型框架搭清楚比记住结论更有用。两者的本质差异AI Workflow 的核心特征是预编排。开发者在设计阶段把任务的执行路径写清楚先做 A再做 B根据 B 的结果走 C1 或 C2最后汇总输出。LLM 在这个流程里是一个特殊的处理节点它的输入由上游节点提供输出交给下游节点处理。整个流程的主控制权在预先写好的逻辑里不在 LLM 手里。AI Agent 的核心特征是动态推理。任务接收之后Agent 可以根据上下文决定执行步骤、调用顺序、中间结果的处理方式。开发者提供的不只是界面而是环境和约束——本体、工具、记忆机制、权限边界、校验规则、人工确认点Agent 在这个环境里运行。控制权更多地交给 Agent但不是完全放任开发者仍然需要定义目标、边界和兜底机制。这个差异决定了两者各自擅长什么。六个维度的选型框架为此我们列出了六个判断维度每个维度有明确的倾向判断。把它们展开来说。1、任务结构任务的执行步骤是否可以在设计阶段确定举例来讲。规章制度问答的步骤是固定的接收问题、检索文档、生成回答。不管用户问什么流程都是这三步。这类任务适合 Workflow。采购补货方案的步骤取决于用户的具体要求要不要排除某些品类、要不要结合历史数据做趋势分析、输出格式是 Excel 还是直接在页面展示。不同的要求会走完全不同的执行路径没有办法在设计阶段把所有路径都写出来。这类任务适合 Agent。判断标准可以先抓主线如果主要执行路径能在设计阶段定义清楚而且例外分支也有限优先用 Workflow如果任务在运行时经常需要补充信息、改写计划、临时选工具优先用 Agent。2、交互模式任务需要几轮对话才能完成Workflow 适合单轮或少轮触发。用户提交一个问题系统返回一个答案交互结束。即便有多轮每轮的交互内容也是预先定义好的。Agent 适合需要多轮确认或动态补充信息的场景。Agent 在执行过程中可能发现需要追问用户用户的回答会改变后续的执行方向。这种交互无法预先脚本化需要 Agent 在运行时动态判断。3、业务价值这个任务产生的业务价值是高是低这个维度主要影响的是愿意为推理成本支付多少。Agent 通常需要更多轮模型调用、更长上下文和更多工具交互成本与延迟往往高于固定流程。如果任务的业务价值很高比如 AI 辅助生产异常根因分析单次推理节省的人工成本远超推理费用工作台的成本结构就是合理的。如果任务业务价值不高比如自动生成周报摘要用 Workflow 固定流程生成已经够用不需要为动态推理支付额外成本。4、容错要求这个任务能不能接受错误如果有错误能不能被发现和纠正容错要求高的场景不适合让 Agent 无约束地闭环执行。生产线上的质检结果直接影响产品放行结果出错的代价极高而且错误可能在很晚才被发现。这类场景需要每一步的结果都可以被验证Workflow 的固定流程更容易插入验证节点。即便使用 Agent也通常只适合放在分析、建议、解释这些辅助手环节而不适合直接做最终放行。Agent 适合可以试错的场景通常有人类兜底。AI 生成的补货方案采购主管审核之后才会执行错误在人工审核阶段被拦截代价可接受。AI Coding 生成的代码开发者跑测试并做 Review 之后再合并很多错误能在这个阶段被发现代价也相对可接受。5、执行闭环任务执行主要靠 Agent 在运行时闭环还是靠多个确定性组件协同完成规章制度问答里文档检索依赖 Embedding 模型和向量数据库召回、过滤、权限控制、答案生成往往由多个组件协同完成。这里的重点不是 LLM 能不能独立完成而是整个闭环天然更适合被拆成若干可验证节点用 Workflow 把各组件编排起来是自然的选择。AI Coding 里从理解需求到生成代码到解释设计再到调用测试、读取日志、继续修复往往需要 Agent 在运行时反复规划和调整。执行闭环更多由 Agent 主导所以Agent 是更合理的容器。6、工具依赖任务执行需要的工具集是固定的还是动态变化的Workflow 的工具集在设计阶段就确定了流程里的每个节点知道自己要用什么工具。如果任务需要的工具是固定的几个Workflow 对工具的管理更精确。Agent 则会根据任务动态选择工具。一个查询任务可能用 TableBinding一个创建任务可能用服务端命令一个分析任务可能同时用多个工具然后汇总。工具集是开放的调用顺序由 Agent 在运行时决定。决策原则六个维度不需要全部指向同一侧才能做决策但也不适合简单按票数相加。更稳妥的原则是分层判断。先看容错要求和任务结构再看交互模式、工具依赖和执行闭环最后看业务价值与成本。容错要求是第一主裁维度因为它影响的是风险而不只是效率。一个任务对错误零容忍即便其他维度都指向 Agent也应该优先考虑 Workflow或者采用Agent 负责分析Workflow 或人工负责最终执行的混合架构。任务结构是第二主裁维度因为它最直接地影响实现的可行性。步骤不确定的任务强行用 Workflow 实现意味着要把大量可能路径都写出来代码复杂度会迅速上升维护成本极高而且仍然无法覆盖所有边界情况。三个案例的实际判断AI Coding。任务结构不确定需求理解、方案设计、代码生成、测试修复每一步依赖上一步的结果动态调整交互多轮需要开发者审查代码、确认设计方向业务价值高替代或加速工程师的核心工作容错要求可接受代码可以通过运行测试验证错误通过多轮 Review 发现执行闭环偏向 Agent需要在运行时读代码、调工具、看日志、改计划工具依赖具有动态性不同任务会调用不同的仓库、命令和环境能力多数关键维度都指向 Agent结论清晰。规章制度问答。任务结构确定接收问题、检索文档、生成回答步骤固定交互单轮为主用户提问系统返回答案业务价值中低辅助查询不是核心业务流程。容错要求较高答案偏差会影响员工对规章的理解执行闭环偏向确定性编排检索、过滤、权限控制、生成各自职责清晰工具依赖相对固定主要就是文档库、检索和生成链路多数维度指向 Workflow结论清晰。生产质检异常处理。这是最复杂的一个案例因为它在不同维度上指向不同侧。合格/不合格的一次判定步骤固定容错要求极高适合 Workflow。异常根因分析步骤不确定设备问题原料问题工艺漂移需要结合历史工单、设备日志、原料批次动态推理适合 Agent。这两个子任务在同一个业务场景里但性质完全不同。混合架构是这里的自然答案Workflow 负责实时判定输出合格或不合格触发异常后启动 Agent 的子流程做根因分析人工最终确认。两条链路职责清晰互不干扰。这个案例说明了一件事选型的边界不在系统层面而在任务层面。同一个系统里可以同时运行 Workflow 和 Agent分别处理它们各自擅长的部分。没有必要为了技术一致性而把所有任务都强行纳入同一种范式。一个容易犯的错误在实际项目里有一个偏差方向值得单独提出来过度依赖 Agent。众所周知Agent 在演示时效果通常比 Workflow 更惊艳因为它能处理用户随口说出的复杂任务而 Workflow 的演示更像在展示一个固定功能。这让很多团队产生了Agent 更先进的印象倾向于把所有任务都放进 Agent。代价在生产环境里才会显现推理成本和响应时延高于预期某些关键任务的准确率与稳定性波动更大Workflow 本来可以提供的一致性在 Agent 里变成了需要额外治理的问题。Agent 的动态推理能力是为不确定性设计的。把结构确定的任务放进 Agent不是在利用这个能力而是在为用不上的能力付出成本。Workflow 处理确定性任务的成本更低、结果更稳定这不是局限是它在这类场景下的优势。本文是企业AI落地系列的第17篇。下一篇用生产质检这个混合案例做更细致的拆解一个场景怎么被拆分成两条链路两条链路怎么协作知识库应该放在哪一层。
Workflow vs Agent：没有优劣之分，只有场景之别
这是一个在项目启动会上经常被问到的问题我们要做 AI是用 Workflow 还是 Agent不过这里先要澄清一个概念Workflow 是执行模式工作台是产品形态。本文讨论的不是界面长什么样而是数字员工背后的执行方式是否以 Agent 为中心。换句话说真正需要比较的是预编排的 Workflow和以 Agent 为核心的动态执行环境。问题本身没有问题但回答这个问题需要先放弃一个隐含的假设两者之间存在优劣之分选对了就比选错了好。实际上两者解决的是不同结构的问题用错了场景再好的技术也会表现糟糕。把选型框架搭清楚比记住结论更有用。两者的本质差异AI Workflow 的核心特征是预编排。开发者在设计阶段把任务的执行路径写清楚先做 A再做 B根据 B 的结果走 C1 或 C2最后汇总输出。LLM 在这个流程里是一个特殊的处理节点它的输入由上游节点提供输出交给下游节点处理。整个流程的主控制权在预先写好的逻辑里不在 LLM 手里。AI Agent 的核心特征是动态推理。任务接收之后Agent 可以根据上下文决定执行步骤、调用顺序、中间结果的处理方式。开发者提供的不只是界面而是环境和约束——本体、工具、记忆机制、权限边界、校验规则、人工确认点Agent 在这个环境里运行。控制权更多地交给 Agent但不是完全放任开发者仍然需要定义目标、边界和兜底机制。这个差异决定了两者各自擅长什么。六个维度的选型框架为此我们列出了六个判断维度每个维度有明确的倾向判断。把它们展开来说。1、任务结构任务的执行步骤是否可以在设计阶段确定举例来讲。规章制度问答的步骤是固定的接收问题、检索文档、生成回答。不管用户问什么流程都是这三步。这类任务适合 Workflow。采购补货方案的步骤取决于用户的具体要求要不要排除某些品类、要不要结合历史数据做趋势分析、输出格式是 Excel 还是直接在页面展示。不同的要求会走完全不同的执行路径没有办法在设计阶段把所有路径都写出来。这类任务适合 Agent。判断标准可以先抓主线如果主要执行路径能在设计阶段定义清楚而且例外分支也有限优先用 Workflow如果任务在运行时经常需要补充信息、改写计划、临时选工具优先用 Agent。2、交互模式任务需要几轮对话才能完成Workflow 适合单轮或少轮触发。用户提交一个问题系统返回一个答案交互结束。即便有多轮每轮的交互内容也是预先定义好的。Agent 适合需要多轮确认或动态补充信息的场景。Agent 在执行过程中可能发现需要追问用户用户的回答会改变后续的执行方向。这种交互无法预先脚本化需要 Agent 在运行时动态判断。3、业务价值这个任务产生的业务价值是高是低这个维度主要影响的是愿意为推理成本支付多少。Agent 通常需要更多轮模型调用、更长上下文和更多工具交互成本与延迟往往高于固定流程。如果任务的业务价值很高比如 AI 辅助生产异常根因分析单次推理节省的人工成本远超推理费用工作台的成本结构就是合理的。如果任务业务价值不高比如自动生成周报摘要用 Workflow 固定流程生成已经够用不需要为动态推理支付额外成本。4、容错要求这个任务能不能接受错误如果有错误能不能被发现和纠正容错要求高的场景不适合让 Agent 无约束地闭环执行。生产线上的质检结果直接影响产品放行结果出错的代价极高而且错误可能在很晚才被发现。这类场景需要每一步的结果都可以被验证Workflow 的固定流程更容易插入验证节点。即便使用 Agent也通常只适合放在分析、建议、解释这些辅助手环节而不适合直接做最终放行。Agent 适合可以试错的场景通常有人类兜底。AI 生成的补货方案采购主管审核之后才会执行错误在人工审核阶段被拦截代价可接受。AI Coding 生成的代码开发者跑测试并做 Review 之后再合并很多错误能在这个阶段被发现代价也相对可接受。5、执行闭环任务执行主要靠 Agent 在运行时闭环还是靠多个确定性组件协同完成规章制度问答里文档检索依赖 Embedding 模型和向量数据库召回、过滤、权限控制、答案生成往往由多个组件协同完成。这里的重点不是 LLM 能不能独立完成而是整个闭环天然更适合被拆成若干可验证节点用 Workflow 把各组件编排起来是自然的选择。AI Coding 里从理解需求到生成代码到解释设计再到调用测试、读取日志、继续修复往往需要 Agent 在运行时反复规划和调整。执行闭环更多由 Agent 主导所以Agent 是更合理的容器。6、工具依赖任务执行需要的工具集是固定的还是动态变化的Workflow 的工具集在设计阶段就确定了流程里的每个节点知道自己要用什么工具。如果任务需要的工具是固定的几个Workflow 对工具的管理更精确。Agent 则会根据任务动态选择工具。一个查询任务可能用 TableBinding一个创建任务可能用服务端命令一个分析任务可能同时用多个工具然后汇总。工具集是开放的调用顺序由 Agent 在运行时决定。决策原则六个维度不需要全部指向同一侧才能做决策但也不适合简单按票数相加。更稳妥的原则是分层判断。先看容错要求和任务结构再看交互模式、工具依赖和执行闭环最后看业务价值与成本。容错要求是第一主裁维度因为它影响的是风险而不只是效率。一个任务对错误零容忍即便其他维度都指向 Agent也应该优先考虑 Workflow或者采用Agent 负责分析Workflow 或人工负责最终执行的混合架构。任务结构是第二主裁维度因为它最直接地影响实现的可行性。步骤不确定的任务强行用 Workflow 实现意味着要把大量可能路径都写出来代码复杂度会迅速上升维护成本极高而且仍然无法覆盖所有边界情况。三个案例的实际判断AI Coding。任务结构不确定需求理解、方案设计、代码生成、测试修复每一步依赖上一步的结果动态调整交互多轮需要开发者审查代码、确认设计方向业务价值高替代或加速工程师的核心工作容错要求可接受代码可以通过运行测试验证错误通过多轮 Review 发现执行闭环偏向 Agent需要在运行时读代码、调工具、看日志、改计划工具依赖具有动态性不同任务会调用不同的仓库、命令和环境能力多数关键维度都指向 Agent结论清晰。规章制度问答。任务结构确定接收问题、检索文档、生成回答步骤固定交互单轮为主用户提问系统返回答案业务价值中低辅助查询不是核心业务流程。容错要求较高答案偏差会影响员工对规章的理解执行闭环偏向确定性编排检索、过滤、权限控制、生成各自职责清晰工具依赖相对固定主要就是文档库、检索和生成链路多数维度指向 Workflow结论清晰。生产质检异常处理。这是最复杂的一个案例因为它在不同维度上指向不同侧。合格/不合格的一次判定步骤固定容错要求极高适合 Workflow。异常根因分析步骤不确定设备问题原料问题工艺漂移需要结合历史工单、设备日志、原料批次动态推理适合 Agent。这两个子任务在同一个业务场景里但性质完全不同。混合架构是这里的自然答案Workflow 负责实时判定输出合格或不合格触发异常后启动 Agent 的子流程做根因分析人工最终确认。两条链路职责清晰互不干扰。这个案例说明了一件事选型的边界不在系统层面而在任务层面。同一个系统里可以同时运行 Workflow 和 Agent分别处理它们各自擅长的部分。没有必要为了技术一致性而把所有任务都强行纳入同一种范式。一个容易犯的错误在实际项目里有一个偏差方向值得单独提出来过度依赖 Agent。众所周知Agent 在演示时效果通常比 Workflow 更惊艳因为它能处理用户随口说出的复杂任务而 Workflow 的演示更像在展示一个固定功能。这让很多团队产生了Agent 更先进的印象倾向于把所有任务都放进 Agent。代价在生产环境里才会显现推理成本和响应时延高于预期某些关键任务的准确率与稳定性波动更大Workflow 本来可以提供的一致性在 Agent 里变成了需要额外治理的问题。Agent 的动态推理能力是为不确定性设计的。把结构确定的任务放进 Agent不是在利用这个能力而是在为用不上的能力付出成本。Workflow 处理确定性任务的成本更低、结果更稳定这不是局限是它在这类场景下的优势。本文是企业AI落地系列的第17篇。下一篇用生产质检这个混合案例做更细致的拆解一个场景怎么被拆分成两条链路两条链路怎么协作知识库应该放在哪一层。
