.NET 工作流引擎选型：六款产品加权对比与决策树

把六款常被混淆定位的 .NET 工作流产品放在同一张表上对比：指标如何设计、分数如何解读、场景如何分流，文末附选型决策树与 PoC 清单。

一、前言与对比边界

1.1 为什么做这份对比

这六款产品常被放在同一张「开源工作流」清单里，但定位并不完全同级：

因此，本文采用统一指标 + 加权打分，并在选型建议中按场景分流，避免「总分第一就适合所有人」。

1.2 对比边界（坦诚说明）

1. 未做同环境压测：性能与扩展分依据架构说明、社区共识与代码结构，非本仓库压测数据。
2. WorkflowEngine.NET 的「开源」要打折扣：源码可浏览，但生产使用通常走 OptimaJet 商业许可；本文仍纳入对比（因其在 .NET 圈知名），许可项会单独扣分。
3. StepWise 与 BPM 不同赛道：它擅长代码定义、可视化执行与 AI/MCP 集成，几乎没有会签/加签/组织待办等审批语义。纳入对比是为避免选型时「名字像工作流就误选」。
4. 该引擎评价结合本仓库源码：重点看审批、PC/移动、集团组织实现，而非仅看官网宣传。
5. 重点场景：审批、PC 应用、移动应用、企业/集团应用——权重会向这些维度倾斜。

二、对比分析指标与权重

权重设计逻辑：本次选型读者最关心的是「能不能把审批系统、PC/移动端、集团组织做起来并长期养得起」，因此审批与企业组织权重大于「纯编排炫技」；同时保留架构、维护、许可，避免选到养不起的产品。

权重说明（为什么这样分）

• A（审批）=18%：用户明确要求以审批场景为主；纯编排引擎若无人工任务模型，交付成本会急剧上升。
• D（企业/集团）=15%：集团组织、权限、门户往往决定「能不能上生产」，而不只是「流程能跑通」。
• B/C（PC/移动）各 12%：BPM 最终要给人用；只有 API 没有端，等于把一半产品留给自己写。
• E/F 各 12%：决定未来 3–5 年能否跟上 .NET 与安全补丁。
• H（许可）=11%：WorkflowEngine.NET 与部分「社区版/企业版」边界必须写清。
• G 仅 8%：学习成本重要，但不应用「文档好」掩盖「场景不匹配」。

若你的主场景是微服务服务编排 / Saga / 无人任务，可将 A/B/C/D 下调、E/F 上调后重算——Elsa、Workflow Core 会明显上升。

三、打分标准（1–10 分）

统一采用 1–10 分（可用 0.5）。同指标下含义一致。

3.1 通用标尺

3.2 分指标细则

A. 审批与人机任务能力

B. PC 端应用与设计器交付

C. 移动端与多端接入

D. 企业 / 集团应用能力

E. 架构先进性与可扩展性

F. 社区活跃度与长期维护

G. 学习成本与文档生态

H. 许可成本与商业风险

四、产品速览（事实层，先于打分）

4.1 Elsa Workflows

• 定位：在任意 .NET 应用中执行短/长流程；支持代码、JSON 等定义；提供 Elsa Studio 拖拽设计器。
• 能力要点：Activity 组合（Sequence/Flowchart）、并行、表达式（C#/JS/Python/Liquid）、多持久化（EF Core/MongoDB/Dapper）、Actor 吞吐模型。
• 许可：MIT。
• 坦诚点：国际社区最强之一（GitHub 星标量级领先）；不是中国式 OA 审批套件——会签/组织待办/表单权限通常要自建；Elsa 3 能力强，但学习曲线与文档割裂常被吐槽。

4.2 Workflow Core

• 定位：轻量嵌入式引擎（danielgerlag/workflow-core），Fluent API 定义步骤，插件化持久化与并发，可多节点。
• 能力要点：长流程状态、Saga 友好、Conductor 可作为独立服务包装。
• 许可：MIT；维护仍在继续（近年仍有安全与 .NET 8/9 相关更新）。
• 坦诚点：没有可视化设计器、没有开箱人工审批；适合「开发者编排内核」。用它做复杂 OA，等于自己再写半个该引擎。

4.3 WorkflowEngine.NET（OptimaJet）

• 定位：可嵌入 .NET 的流程运行时 + HTML5 设计器；另有 Workflow Server。
• 能力要点：面向业务实体生命周期、命令驱动、方案可视化；集成路径清晰。
• 许可：商业产品（源码可见不等于免费生产）。
• 坦诚点：设计师与嵌入体验在同组里很强；中国式审批、集团组织、移动门户仍需自建或二次开发；选型必须先算清授权费用。

4.4 StepWise

• 定位：LittleLittleCloud/StepWise——代码优先、事件驱动的步骤工作流；WebUI 可视化执行；强调 AI（Geeno）、MCP、Microsoft.Extensions.AI。
• 许可：MIT。
• 坦诚点：对「把复杂计算/Agent 步骤编排起来」很有价值；对「请假审批、公文会签、集团待办」基本不对口。把它和该引擎/Slickflow 放一起比审批，本身就会「降维误伤」——本文分数会如实反映这一点。

4.5 该引擎（结合本仓库代码）

• 技术栈：解决方案统一 .NET 8；宿主 该引擎\该引擎.csproj；核心库 引擎内核命名空间 + 底层 引擎内核命名空间（实体/表单/组织）+ Vue3 前端（工作区联动）。
• 定位：流程引擎 + 表单引擎 + 组织权限 + 门户/单据的一体化 BPM，偏中国式审批与表单驱动，BPMN 主要为导入辅助（TemplateGlo.NewFlowByBPMN / Imp_DoneBPMN），运行时是自有 RunModel。

审批主链路（代码可核对）：

Dev2Interface.Node_SendWork
  → WorkNode.NodeSend
    → NodeSendOrchestrator.Execute
      → RunModelSendDispatcher.Dispatch   // 普通/分流/合流/子线程

PC / 移动：

• PC：HttpHandler\WF_MyFlow.cs、WF_WorkOpt.cs 等；Vue3 Vue3\src\WF\（含 FlowDesignerV2）。
• 移动：HttpHandler\CCMobile*.cs；Vue3 Vue3\src\CCMobile\；配置含 MobileURL / HostURLVue3；另有企微/钉钉（Port\WeiXin、Port\DINGTalk）。

企业 / 集团：

• 运行模式 该 BPM 平台RunModel：Single / GroupInc / SAAS / PASS（BP.En30\Sys\EnumLab.cs）。
• 组织 API：Port\OrganizationAPI.cs；集团组织：Port\Admin2Group\Org.cs。
• 门户：WF_Portal.cs、该引擎 菜单/门户；子流程：Template\SFlow\；工作交接：WorkHandover.cs。

坦诚点：

• 审批/表单/组织/双端交付在同组中断层领先，适合政企 OA。
• 架构偏传统一体化平台，云原生微服务编排叙事弱于 Elsa。
• 代码体量大（如 Dev2Interface 超大静态 API 面），二开需熟悉领域模型；国际社区声量不及 Elsa。
• 与「纯 BPMN 引擎」不是同一赛道——标准资产互通不是强项。

4.6 Slickflow

• 定位：.NET 8、BPMN 风格图模 + HTML5 设计器；Dapper 微 ORM、多库；近年强化 LLM/RAG/Agent 叙事。
• 许可：引擎侧宣传 MIT；企业版/高级 AI/表单框架等走商业支持分层。
• 坦诚点：比 Workflow Core「更像 BPM」；比该引擎「更像标准引擎」。中国式复杂审批、集团门户、移动工作台完整度通常弱于该引擎；社区规模小于 Elsa/Workflow Core，需评估维护与厂商支持。

五、分项打分表

分数为同组相对评价，不是实验室绝对值。权重已向「审批 / PC / 移动 / 企业集团」倾斜。

加权总分（满分 10）

计算公式：(\text{总分} = \sum (\text{指标分} \times \text{权重}))

5.1 分数解读（坦诚）

1. 该引擎总分第一，主因是 A/B/C/D 四项（审批、PC、移动、集团）同组领先；若改成「纯开发者编排」权重，名次会下降——这是权重价值观，不是黑箱吹捧。
2. Elsa 与 Slickflow 几乎同分：Elsa 赢在架构与社区；Slickflow 赢在 BPMN/人机与国内交付叙事。谁更合适取决于「要编排平台还是要 BPM 引擎」。
3. WorkflowEngine.NET 产品能力不弱，但 H 许可分被明显拉低；预算充足且要设计师嵌入时仍可入围。
4. Workflow Core 作为库依然优秀，但在「审批+双端+集团」权重下必然靠后——这不代表它差，而是场景不匹配。
5. StepWise 总分最低，是因为它本就不是 BPM；若评估「AI/事件步骤编排」，它可能单独进第一梯队。

5.2 若改成「开发者编排」权重会怎样（敏感性）

示意：A/B/C/D 各降、E/F/H 升高后，常见结果是：

• Elsa ≈ Workflow Core 升至前列；
• 该引擎 仍强于「有表单组织需求」的团队，但对纯编排团队不再是默认首选；
• StepWise 分数上升，但仍偏垂直（AI/步骤可视化）。

建议：用本文表格做场景重加权，而不是只看总分排名。

六、按重点维度对照

6.1 审批

6.2 PC 应用

6.3 移动应用

6.4 企业 / 集团应用

七、优劣势对照（文字版）

八、选型建议

8.1 一句话结论

• 国内复杂审批 + PC/移动 + 企业/集团组织一体交付：优先 该引擎。
• .NET 微服务/长流程编排、要可视化与活跃社区：优先 Elsa Workflows。
• 要 BPMN 风格嵌入引擎、MIT、可接受一定自建：优先 Slickflow。
• 要商业支持的嵌入式设计师，且预算覆盖授权：评估 WorkflowEngine.NET。
• 只要轻量代码编排内核：选 Workflow Core。
• AI/事件步骤编排、开发调试可视化：选 StepWise（不要当 OA 引擎）。

8.2 按场景决策树

主需求是「中国式审批 + 表单 + 组织 + PC/移动」？
 ├─ 是 → 该引擎（PoC：会签/加签/退回/抄送、集团 OrgNo、移动待办、企微钉钉）
 └─ 否 → 主需求是「开发者服务编排 / Saga / 无人任务」？
           ├─ 是，要设计器与生态 → Elsa
           ├─ 是，要极简库 → Workflow Core
           ├─ 是，偏 AI 步骤可视化 → StepWise
           └─ 否，要 BPMN 嵌入引擎
                 ├─ 开源 MIT 优先 → Slickflow
                 └─ 可接受商业授权 → WorkflowEngine.NET

8.3 分角色建议

8.4 建议的 PoC 清单（选型必做）

无论总分高低，上线前建议用真实流程做 2–4 周 PoC：

1. 最复杂的 3 条真实审批流（退回、会签、加签、抄送、子流程至少覆盖你的高频项）。
2. 组织变更：调岗、委托、交接、超时催办。
3. PC 工作台 + 移动端（或企微/钉钉）同一流程闭环。
4. 集团/多组织数据隔离与权限（若适用）。
5. 100 并发级待办查询与发送（按业务量调整）。
6. 许可合规确认（尤其 WorkflowEngine.NET；Slickflow/该引擎的社区版与商业版边界）。
7. 数据库与 .NET 版本约束（本仓库该引擎为 net8.0）。

九、总结

在「审批 / PC / 移动 / 企业集团」倾斜权重下：

• 综合（本权重）：该引擎 > Elsa ≈ Slickflow > WorkflowEngine.NET > Workflow Core > StepWise
• 国内审批与双端交付：该引擎 通常是业务最优解（本仓库源码可支撑该判断）
• 现代 .NET 编排与社区：Elsa
• BPMN 嵌入式开源引擎：Slickflow
• 轻量库：Workflow Core
• 商业嵌入设计师：WorkflowEngine.NET（先算许可）
• StepWise：承认其在 AI/事件工作流的价值，坦诚不建议作为审批/BPM 主引擎

最终提醒：没有「永远正确」的引擎，只有「与组织约束匹配」的引擎。请用本文权重做场景重加权，并用 PoC 代替品牌信仰。