任务流编排设计：为什么你需要两套关系模型

在任务管理系统中，我们习惯用"父子任务"来表达拆解关系，但当你真正需要编排任务的执行顺序时，会发现一棵树远远不够。本文从图论基础出发，拆解任务编排中层级归属与执行依赖两种关系的本质差异，并给出工程实践建议。

---

从一个常见的误区说起

很多系统在设计任务模型时，会加一个 parent_task_id 字段来表达任务拆分，再配上 depth 表示层级深度。看起来很自然——大任务拆成小任务，小任务再拆成更小的任务，一棵树就搞定了。

然后有人问："前置任务怎么搞？在任务表里加个 predecessor_task_id 不就行了？"

乍一看没问题，但仔细想就会遇到一连串的反问：

• 一个任务只能有一个前置任务吗？
• 两个同级兄弟任务之间有先后顺序怎么办？
• 跨分支的任务之间有依赖怎么办？
• "A 完成后 B 才能开始"和"A 开始后 B 才能开始"是同一回事吗？

这时候你会发现，用一个字段把"归属"和"依赖"揉在一起，就像用一把尺子同时量长度和温度——维度不同，无法兼得。

---

两种关系，两种图

层级归属：树

一棵任务分解树：

提升收入
  ├── 分析经营数据
  ├── 制定提升方案
  └── 执行并跟踪

这棵树回答的是："这个任务属于谁？怎么拆的？"

每个节点只有一个父，关系是纵向的、确定性的。parent_task_id + depth 完美胜任。

执行依赖：有向无环图（DAG）

[分析数据] ──→ [制定方案] ──→ [执行跟踪]
     │                              ↑
     └──────→ [评估投入产出] ──→ [关停低效点]

这个图回答的是："这个任务要等谁完成才能开始？"

节点之间可以有任意方向的边，一个节点可以有多条入边和多条出边，但不能形成环。这就是 DAG。

为什么树不是 DAG 的子集

	树（层级归属）	DAG（执行依赖）
每个节点的父节点数	最多 1 个	无限制（多入边）
边的方向	只能纵向（父→子）	任意方向（横向 + 纵向）
兄弟节点之间	无连接	可以有连接
跨分支连接	不可能	可以
核心问题	怎么拆？	怎么跑？

树是 DAG 的特例（每个节点入度 ≤ 1 且边只纵向），但实际任务编排几乎不满足这个约束。

---

四个树结构无法覆盖的真实场景

场景一：同级任务的先后顺序

项目上线
  ├── 编写测试用例
  ├── 执行测试        ← 必须等"编写测试用例"完成
  └── 生产环境部署    ← 必须等"执行测试"通过

三个任务的 parent_task_id 完全相同，在树中它们是平等的兄弟。但业务上它们是严格串行的——这是兄弟间的时序约束，树无法表达。

场景二：跨分支依赖

数据平台建设
  ├── 数据采集模块
  │     └── 接入 CRM 数据
  └── 数据分析模块
        └── 生成经营报告   ← 依赖"接入 CRM 数据"

"生成经营报告"属于分析模块，但它要等采集模块的"接入 CRM 数据"完成——跨分支横向依赖，树的边只能纵向连接，无法跨越。

场景三：多前置任务汇聚

[接口开发] ──┐
             ├──→ [联调测试] ──→ [上线发布]
[前端开发] ──┘

联调测试要同时等接口和前端都完成。一个任务有多条入边，parent_task_id 只能指向一个父节点，无法表达"我等的不止一个"。

场景四：依赖不只是"做完再做"

依赖类型	含义	示例
Finish-to-Start (FS)	前置完成后，后置才能开始	方案评审通过后才能开发
Start-to-Start (SS)	前置开始后，后置才能开始	需求启动后才能开始技术调研
Finish-to-Finish (FF)	前置完成后，后置才能完成	验收通过后项目才算关闭

再加上滞后时间（lag）：接口开发开始 2 小时后前端才能启动——这是调度语义，不是层级语义。

---

任务流全景：从拆解到执行

把两种关系放在一起，完整的任务流模型如下：

┌─────────────────────────────────────────────────────┐
│                    目标 / 需求                         │
│                        │                              │
│                   [拆解树]                              │
│                 ╱    │    ╲                            │
│            任务A   任务B   任务C                        │
│            ╱ ╲      │       │                         │
│        A1   A2      B1      C1                        │
│                        │                              │
│                   [依赖图]                              │
│         A1 ──→ A2 ──→ B1 ──→ C1                      │
│                        │                              │
│                   [执行流]                              │
│            A1 → A2 → B1 → C1                          │
└─────────────────────────────────────────────────────┘

• 拆解阶段：目标拆成任务树（parent_task_id），决定"做什么"。
• 编排阶段：在任务之间连依赖边（TaskDependency），决定"怎么做"。
• 执行阶段：根据依赖图进行拓扑排序，决定"先做谁"。

---

依赖表的工程设计

核心表结构

task_dependency
├── predecessor_task_id   -- 前置任务（必须先完成）
├── successor_task_id     -- 后置任务（被阻塞的任务）
├── dependency_type       -- 依赖类型：FS / SS / FF
├── lag_minutes           -- 滞后时间（正=延后，负=提前）
└── UNIQUE(predecessor, successor)  -- 同一对任务间最多一条边

关键约束

1. 唯一性约束：同一对任务之间只能有一条依赖边，避免重复编排。

2. 环检测：每次新增依赖边时，必须检查是否形成环。DAG 之所以叫"无环图"，是因为环意味着"A 等B，B 等A"——死锁，谁也跑不了。

环检测的常见算法：

• DFS 染色法：新增边后从后置任务出发 DFS，看能否回到前置任务。时间复杂度 O(V+E)。
• 拓扑排序法：新增边后对全图做拓扑排序，若无法完成则存在环。

3. 自引用禁止：一个任务不能依赖自己，这是一条显然但容易遗漏的约束。

查询模式

需求	查询方式
某任务的所有前置任务	WHERE successor_task_id = ?
某任务的所有后置任务	WHERE predecessor_task_id = ?
某任务是否可以开始	查所有前置任务的状态是否都已完成
某策略下的完整依赖图	WHERE strategy_id = ?（冗余字段加速查询）
关键路径分析	在 DAG 上做最长路径计算

---

任务状态机：依赖如何驱动状态流转

依赖关系不只是"画个图好看"，它直接影响任务的状态机：

         ┌──────────┐
    ┌──→ │   todo    │ ← 新建任务
    │    └──────────┘
    │          │ 所有前置任务已完成
    │          ▼
    │    ┌──────────┐
    │    │  doing   │
    │    └──────────┘
    │          │ 执行完成
    │          ▼
    │    ┌──────────┐     ┌──────────┐
    │    │  review  │ ──→ │  done    │
    │    └──────────┘     └──────────┘
    │          │               │
    │     审批不通过          │ 触发后置任务检查
    │          │               │
    └──────────┘               ▼
                          后置任务从 todo → doing

关键规则：

1. 阻塞规则：任务有未完成的前置任务时，不能从 todo 转为 doing。
2. 释放规则：一个任务变为 done 时，检查所有后置任务——如果其全部前置任务都已完成，则自动将后置任务从 todo 推进为 doing。
3. 审批阻断：高风险任务（如资源关停、金额调整）即使前置完成，也需要人工审批后才能推进。

---

一个完整的任务流示例

假设有一个"新区域业务启动"的目标，拆解和编排如下：

拆解树（做什么）

新区域业务启动
  ├── 市场调研
  │     ├── 竞品分析
  │     └── 用户需求调研
  ├── 资源准备
  │     ├── 团队组建
  │     └── 供应链对接
  └── 业务上线
        ├── 试运营
        └── 正式发布

依赖图（怎么做）

[竞品分析] ──→ [用户需求调研] ──→ [团队组建] ──→ [试运营] ──→ [正式发布]
                                        ↑              ↑
                                 [供应链对接] ──────────┘

• 竞品分析先做，用户需求调研依赖其结论。
• 团队组建依赖需求调研结果，供应链对接可以并行启动。
• 试运营需要团队和供应链都就绪。
• 正式发布依赖试运营反馈。

执行时间线

Week 1: [竞品分析]
Week 2: [用户需求调研] | [供应链对接]  ← 并行
Week 3: [团队组建]                    ← 等需求调研完成
Week 4: [试运营]                      ← 等团队+供应链都就绪
Week 5: [正式发布]                    ← 等试运营通过

这就是"树定义结构，DAG定义节奏"——没有依赖图，你只能让所有子任务同时开始，或者靠人记着"谁该先做谁该后做"。

---

什么情况下可以不用依赖表？

如果你的任务系统满足以下全部条件，可以暂时不引入独立的依赖表：

1. 所有子任务严格按创建顺序串行执行，不存在并行。
2. 不存在跨分支的任务依赖。
3. 任务的执行顺序完全由层级决定（父完成 → 子开始）。
4. 不需要区分依赖类型，也不需要滞后时间。

这本质上是一个线性流水线场景——任务之间只有前后关系，没有分叉和汇合。

一旦出现并行、汇聚、跨分支、多前置中的任何一个，依赖表就不再是可选项，而是基础设施。

---

总结

概念	模型	存储方式	解决的问题
层级归属	树	parent_task_id + depth	怎么拆的？
执行依赖	DAG	独立依赖边表	怎么跑的？
状态流转	状态机	任务状态字段 + 依赖检查	跑到哪了？

一句话：树定义结构，DAG 定义节奏，状态机定义进度。三者各司其职，才是任务编排的完整模型。

---

如果这篇文章对你有启发，欢迎讨论交流。