为何Netflix Conductor不支持异步运行SIMPLE任务与subworkflow

1. 核心引擎的设计底层就决定了能力边界 #

Conductor的任务模型从最早设计开始，就把**「轮询驱动」作为普通任务的默认交互契约**：

• 对于SIMPLE类任务，引擎的核心逻辑就是把任务分发到对应队列，等待独立的执行Worker主动拉取、处理后回传状态，整个状态流转是完全基于Worker的主动上报驱动的。
• 目前内置支持异步的HTTP、EVENT、KAFKA任务，本质上是因为这几类任务的交互模式天生不需要Worker轮询：HTTP任务由引擎自身发起请求、等待外部回调或超时；EVENT、KAFKA任务本身就是引擎和外部系统的事件双向交互，不存在独立的轮询执行角色，异步是这类任务的固有属性，不是额外叠加的能力。
  如果强行在引擎层给SIMPLE任务加通用异步支持，会直接打乱原本的任务交互契约：引擎没办法判断一个挂起的SIMPLE任务是「没有Worker拉取」还是「Worker已经处理、在等外部异步回调」，也没有统一的入口来接收所有异步SIMPLE任务的完成信号。一旦用户配置了异步模式但忘了注册对应的回调监听，就会出现任务永久悬挂、状态机卡死的问题，反而会大幅提升引擎的运维复杂度。

2. 异步Subworkflow没有内置支持的核心权衡 #

Conductor里的Subworkflow任务从设计之初，就是作为一类特殊的可插拔内置任务存在的：引擎不会直接在主流程的节点层面托管子工作流的全生命周期，而是把Subworkflow节点当成普通任务扔到队列里，由内置的Subworkflow Worker拉取后触发子流程运行，等子流程完全结束后再回传主流程节点的状态。
不做原生异步Subworkflow的核心原因有两个：

• 如果把Subworkflow的异步生命周期托管收回到核心引擎层，会直接打破原来的解耦设计：原来引擎核心只负责状态机流转，所有任务的具体执行逻辑都是可插拔的Worker实现。如果在核心层重新写一套异步Subworkflow的状态管理、异常处理、超时重试逻辑，会和现有Worker实现的同步Subworkflow逻辑形成两套并行维护的路径，很容易出现逻辑不一致的问题。
• 异步Subworkflow的需求场景本身没有统一语义：有的用户需要主流程触发子流程后立刻往下走、后续按需追子流程结果；有的用户需要主流程和子流程完全解耦，触发后就彻底不管子流程的运行状态；还有的用户需要在子流程触发后、中途做状态同步。引擎层很难做一个通用的抽象覆盖所有场景，硬做出来的通用能力往往会变成四不像，满足不了实际的业务需求。

3. 现有变通方案其实是契合设计哲学的最优解 #

你提到的「通过发事件触发子工作流运行」的适配方案，本质上就是Conductor设计思路下的标准实现：

• 整个链路完全基于现有能力组合，不需要侵入核心引擎逻辑，所有的状态流转都是完全透明、可自定义的
• 解耦后的两个工作流没有强制的状态依赖，不会出现主流程因为子流程状态异常永久挂起的问题
• 如果需要建立两个流程的状态关联，只需要在子工作流结束时再发一个关联事件回传主流程即可，整个链路的控制权完全在用户手里

补充说明：其实并不是完全无法实现异步SIMPLE、异步Subworkflow，只是Conductor把这类自定义异步逻辑的实现权限开放给了用户通过公开API组合，而不是把它做成开箱即用的通用内置能力。比如要做异步SIMPLE，你完全可以在Worker拉取任务后先上报"处理中"状态，等异步业务流程跑完后再调用Conductor的任务更新接口标记完成，整个过程不需要引擎层做任何特殊改动。

内容的提问来源于stack exchange，提问作者nikolayandr