概念/概念定义

应用背景：业务步骤有顺序，每一步还有生命周期

薪酬任务要先创建薪资组，再关联员工，然后计算、审批和提交。“审批”依赖计算结果；审批节点自身又会经历待执行、进行中、等待人工、完成或失败等状态。

只在提示词里写“请按顺序执行”，无法支持并行节点、中断恢复和局部重试。依赖关系与节点状态需要成为程序可读的一等数据。

概念定义

任务 DAG 用有向无环图表示步骤依赖，节点状态机记录每个任务的运行状态。二者共同把流程顺序从自然语言说明转换为可调度数据。

节点通常包含 ID、目标、依赖、状态、验收条件和结果引用。下游节点只有在所有依赖节点完成、前置条件通过后才能进入 ready。

工程机制

规划执行由五类组件组成：

• Planner 生成或局部修订任务图；
• Scheduler 计算可运行节点；
• Executor 执行当前节点；
• Validator 核对业务回执和验收条件；
• Workspace 持久化图、状态迁移和 Checkpoint。

常见状态包括 pending、ready、in_progress、awaiting_approval、completed、failed 和 blocked。每次状态转换都应记录触发事件和计划版本。

ReAct 用于任务结构尚不明确的阶段。依赖关系形成后，Orchestrator 把控制权交给规划执行。失败时可以替换受影响子图，保留已经验收的节点。

案例用法

薪资组快速搭建要求先创建快照，再导入模板，导入失败时回滚。早期实现把顺序写入 Skill 并交给 ReAct，测试中出现跨步和漏步。任务 DAG 上线后，依赖边限制了可调度顺序，模型不再逐轮决定先后。

同一状态机也支持 HITL。敏感节点进入 awaiting_approval，审批通过后回到 ready，拒绝后进入 blocked 或触发替代计划。

适用条件

当流程包含严格先后关系、并行分支、失败恢复或人工审批时，应使用任务 DAG 与状态机。调度状态与其他状态的边界见会话统一状态，审批恢复见HITL 阻塞与恢复。