工作流不是流程图传统工作流是确定性的：每个节点是一段代码，分支条件是布尔表达式，失败是预定义的异常类型。相同输入给相同输出，跑一百次和跑一次结果一样。Agent Workflow 打破了这个假设：传统 Workflow（Airflow / n8n）： 节点 = Python 函数 / API 调用（确定性） 分支条件 = x 0（布尔表达式） 失败处理 = try/except（预定义异常类型） Agent Workflow： 节点 = LLM + 工具（输出不确定） 分支条件 = 置信度 ≥ 95%（语义判断） 失败处理 = 重试 + 人工升级 + 语义降级Agent Workflow 是三种本质不同的执行模型之一，而不是流程图的升级。三种执行模型DAG（有向无环图）控制流在执行前完全确定，节点之间只能向前，不能回头。代表：Airflow、n8n、GitHub Actions 用途：数据管道、ETL、定时任务 特点： → 结构可视化，执行顺序透明 → 不支持循环（Agent 的重试逻辑需要变通处理） → 适合确定性数据处理，不适合需要动态分支的 AI 任务状态机系统有有限个"状态"，事件触发状态转移。当前状态 + 事件 → 下一个状态。代表：LangGraph、自研 Workflow（基于 JSON 状态文件） 用途：有分支、有重试、有人工确认门的业务流程 特点： → 任意时刻系统状态可序列化（支持中断续接） → 支持循环（重试就是状态回退） → workflow_state.json 就是状态文件，确认门就是等待事件以 Bug 修复工作流为例，状态机的结构是：状态：analyzing / fixing / reviewing / waiting_human / done / failed 事件：analyze_done / fix_passed / human_approved / timeout 转移：analyzing + analyze_done → fixing fixing + fix_passed → reviewing reviewing + human_approved → done reviewing + timeout → waiting_human（升级）事件驱动节点之间通过消息解耦，每个节点订阅消息、处理后发布新消息，天然支持异步和长时间运行。代表：Temporal、AWS Step Functions、Apache Kafka Streams 用途：长时间运行（ 1 小时）的业务流程、企业级事务 特点： → 节点之间松耦合，可以独立部署和扩展 → 内置持久化和 Durable Execution 保证 → 复杂度高，不适合快速迭代选型判断任务是数据管道，节点确定性 → DAG 任务有分支/重试/人工确认门 → 状态机 任务运行时间超长，需要强一致 → 事件驱动大多数 AI Agent Workflow 用状态机：支持循环重试、状态可序列化、中断可续接。Anthropic 5 种基本模式任何 Agent Workflow 都可以用这 5 种模式来描述。掌握这套语言，就能和任何人说清楚你的系统架构。模式 1：Prompt Chaining（顺序链）A → B → C 上一步的输出是下一步的输入适用：任务可以分解成有序步骤，每步的质量对后续步骤有直接影响。示例：Bug 修复工作流的主链路 Phase 1（获取信息）→ Phase 2（日志分析）→ Phase 3（根因分析） → Phase 4（代码修复）→ Phase 5（提交）→ Phase 7（通知）关键约束：任何一步失败，整条链中断。需要为每步定义 on_failure 行为。