为什么 Workflow 会与 Autonomous Agent 长期并存
当 Autonomous Agent 能够自己规划任务、调用工具和处理异常时，一个自然的推论是：Workflow 迟早会被取代。既然 Agent 可以临场决定下一步，为什么还要提前画好流程？
这个推论混淆了交互入口和执行机制。Agent 改变的是人如何向软件提出需求，Workflow 解决的是系统如何稳定地完成工作。前者可以越来越自由，后者仍要面对权限、顺序、失败处理和人工确认等约束。
更可能出现的形态是，Agent 站在用户面前，Workflow 留在系统内部。
用户不必先找到正确的系统，再逐项填写表单。他只需要说明目标，Agent 负责理解意图、补齐必要信息，并选择执行方式。后面运行的是预先编排的流程，还是根据任务临时生成的流程，对用户来说并不重要。
这也意味着开发者不会退出，只是工作位置向后移动。他们需要为 Agent 准备两类 Workflow。
第一类是 Fixed Workflow。Dify 中由人编排的流程就是一个例子。退款、合同审核、内容发布等业务经常重复发生，执行顺序和责任边界也相对稳定。哪个节点先运行，满足什么条件才能继续，哪里必须由人确认，都可以提前写清。模型在某个节点中的输出可能变化，但流程本身仍然可以测试和追查。
第二类是 Dynamic Workflow。大型代码迁移、全库审查和开放式研究往往无法提前拆成一条固定路径。任务范围、依赖关系和中间结果都会影响下一步，因此更适合由 Agent 根据现场情况生成编排。Anthropic 的 Dynamic Workflows 展示了这种做法：Claude 生成 JavaScript 脚本，将任务分配给多个 Subagent，并安排复核和重试。
两类 Workflow 的价值来自不同方向。Fixed Workflow 用确定的路径换取可预测性，适合高频、稳定、责任明确的工作。Dynamic Workflow 保留临场调整的空间，适合路径无法预先写死的任务。开发者提供运行环境、工具和权限边界，Agent 则根据实际进展组织工作。
它们也不必互相排斥。Agent 可以先用 Dynamic Workflow 调查问题、生成方案，再把确定下来的操作交给 Fixed Workflow 执行；也可以在固定流程遇到例外时，调用 Agent 处理局部的不确定性。
随着 Autonomous Agent 成熟，用户对流程的直接感知可能逐渐消失，Workflow 仍会留在系统内部。软件界面或许会收敛成一个对话框，系统内部却仍然需要明确的规则和执行路径。
退款、合同审核等任务可以把稳定部分交给 Fixed Workflow，把例外交给 Agent；代码迁移等开放任务则可以由 Agent 生成 Dynamic Workflow，再把确定下来的操作交给固定流程。开发者仍要为两种路径定义权限、失败处理和人工确认点。