简历追问：低代码工作流引擎 DAG 架构设计

关联：全栈工程师简历 > 低代码工作流引擎、15分钟：低代码平台。

对应简历描述

自主设计并实现了基于 DAG 的业务工作流执行引擎，利用 Kahn 算法实现节点拓扑排序与循环检测，支持复杂审批流与自动化业务逻辑编排。

面试官真正想确认

你是否真的做过“运行时流程引擎”，还是只是做了一个前端流程图画布。

连续追问链

1. 业务来源

• 为什么需要工作流引擎？当时哪个业务流程靠代码堆不下去了？
• 你的流程节点是审批、表单、HTTP、条件、LLM 还是别的？请举一个真实流程。
• 画布协议和运行时协议是否一致？nodes / edges JSON 里有哪些字段？

2. DAG 编译

• Kahn 算法在这里具体怎么用？入度表、邻接表、队列如何构造？
• 环检测是在保存时做、发布时做，还是运行前做？为什么需要多层校验？
• 如果将来要支持 Loop，你会继续让主图是 DAG，还是允许任意环？

3. 执行调度

• 多个入度为 0 的节点能否并行？并发限制在哪里配置？
• fan-in 节点如何等待多个上游完成？其中一个失败或被跳过怎么办？
• Condition 节点只激活一条分支时，未命中分支的下游入度如何处理？
• 节点重试、暂停、恢复、人工审批等待分别是什么状态？

4. 运行证据

• 执行状态是只存在内存，还是持久化为 execution record？
• 服务重启后流程能否恢复？怎么避免重复执行 HTTP 节点？
• 有没有针对环、跳过分支、失败重试、并发节点的单测或集成测试？

场景推演题

Start → Form → Condition → HTTP A / HTTP B → Join → Notify。条件只命中 A，B 被跳过；A 执行失败一次后重试成功。请说明每个节点状态和入度变化。

继续追：如果用户把 Join 又连回 Condition，会在哪一层被拦截？

准备证据

• 一个真实流程 JSON。
• Kahn 拓扑排序和环检测伪代码。
• execution status 枚举。
• 条件分支动态剪枝的测试用例。

容易露馅的回答

• “DAG 就是节点连线。”
• “环检测前端画布不让连就行。”
• “条件分支不命中就不执行，没别的处理。”
• “流程失败了用户重新跑一次。”