同一道审批需求：六款 .NET 工作流引擎的实现路径与适配对比

原创

驰骋工作流程

发布于 2026-10-05 10:21:08

550

同一道请假审批，不同引擎的实现路径与交付成本差异明显。本文用统一需求基线与统一口径，对比六款 .NET 工作流引擎的实现方式、场景适配与相对工作量。

0. 先说清楚：本文比什么、不比什么

0.1 本文要比的

用同一道业务题（请假）回答三件事：

实现方式：引擎侧通常怎么建模、怎么挂表单、怎么写分支、怎么把待办送到人。
场景适配：审批语义、PC、移动、企业应用、集团应用各自差在哪里。
选型建议：什么场景优先谁，什么场景属于「名字像工作流、交付却要从零造 OA」。

0.2 本文不比的

不比百万级吞吐压测（请假通常不是瓶颈）。
不把商业增值版未公开能力算进开源/社区版得分（WorkflowEngine.NET 许可单独提示）。
不比「二开机制有多炫」本身——那是另一篇文档的主题；本文只问：把这道请假题交到业务手上，要多久、还要自建多少。

0.3 定位不同，必须先认账

类型	产品	请假语境下的诚实定位
BPM / 审批向	该引擎、Slickflow、（部分）WorkflowEngine.NET	人机任务、待办、退回是主叙事
编排 / 库向	Elsa、Workflow Core	长流程/嵌入编排强；审批壳要自建
步骤 / AI 向	StepWise	不是传统 OA 审批引擎；纳入对比是为防误选

1. 需求基线：这道「简单请假」到底考什么

1.1 业务目标

解决手工纸质请假单繁琐：线上发起、逐级审批、按天数分支、人力资源备案、结果反馈申请人。

1.2 流程节点

序号	节点	角色语义
1	填写申请单	申请人（所有人可发起）
2	部门领导审批	发起人所属部门领导
3	总经理审批	条件节点：请假天数 > 5 才进入
4	人力资源备案	HR
5	反馈给申请人	通知 / 抄送 / 结束知会

需求原文节点顺序写为「部门领导 → 人力资源 → 总经理」。按转向条件「部门经理审批后：天数 > 5 走总经理，总经理后再人力资源」理解，合理主路径为： 申请 → 部门领导 →（≤5 天）人力资源备案 → 反馈； 申请 → 部门领导 →（>5 天）总经理 → 人力资源备案 → 反馈。下文均按该语义；若制度要求「先 HR 再总经理」，只改网关位置，不改变引擎对比结论。

1.3 表单与规则

项	要求
字段	请假类型、日期从/到、请假天数、请假原因、附件
类型枚举	病假、婚假、事假
发起范围	所有人
关键规则	请假天数 > 5 → 总经理审批

1.4 真正拉开差距的，不是画 5 个框

能力点	为什么重要
审批语义	待办、同意/驳回、意见、退回——请假高频
表单 + 附件	病假常要证明；无表单引擎就要自研
组织选人	「部门领导」靠组织树/上级，不是 Activity 自带的
PC 办理台	员工与领导日常入口
移动办理	领导出差批假是刚需
企业 / 集团	多组织、模板复用，决定 Demo 能否长成平台

2. 打分标准（与 Java 姊妹篇同一把尺子）

2.1 评分原则

满分 10 分；仅在 .NET 栈内部相对比较。
依据：公开能力 + 把请假跑通所需的额外自研量。
口径：强 = 产品级/配置级可交付；中 = 引擎能做但要大量自建；弱 = 基本不覆盖或模型不对题。
权重偏向「人机审批交付」，不偏向「编排炫技」。

2.2 维度与权重

编号	维度	权重	评判要点（对准请假）
S1	流程与条件分支	15%	天数分支、节点顺序、发起范围
S2	表单 / 附件 / 枚举	15%	请假单字段、附件、类型字典
S3	审批语义	20%	待办、意见、驳回/退回、知会反馈
S4	PC 应用完备性	15%	设计器、待办门户、查询、办理页
S5	移动应用	15%	移动/H5、待办推送、审批可达
S6	企业应用	10%	组织岗位、权限、消息、集成
S7	集团 / 多组织	10%	多公司、Org/租户隔离、模板分发

综合分 = Σ(维度分 × 权重)。另附「维护活跃度 / 许可」作选型参考（不进加权）。

2.3 及格线（POC 验收）

任意登录用户可发起；
表单含类型/日期/天数/原因/附件；
天数 > 5 走总经理，否则跳过；
部门领导、总经理、HR 可在待办审批并留意见；
结束后申请人能收到反馈（站内 / 邮件 / 抄送至少一种）；
PC 可办结；移动端至少可审批（原生或 H5）。

3. 六款引擎定位一览（请假语境）

产品	大致定位	请假实现主路径	更像什么
Elsa	.NET 长流程编排 + Studio	Workflow + Bookmark/人工等待 + 自建表单与待办	开发者编排平台
Workflow Core	轻量嵌入式流程库	StepBody 链 + 自建状态/UI	库级编排内核
WorkflowEngine.NET	OptimaJet 可嵌入引擎	设计器方案 + Action/Assignment + 自建或模板表单	商业组件式引擎
该引擎	流程 + 表单 + 组织一体化 BPM	设计器配节点/方向条件 + 内置表单/组织/待办	中国式审批交付平台
StepWise	代码优先步骤 / AI 编排	[Step] 方法图；无原生审批待办模型	开发/AI 任务框架
Slickflow	BPMN 风格 .NET 引擎	BPMN 任务 + Gateway + API；表单/门户视版本	标准向嵌入式 BPM

4. 同一道题：各引擎怎么实现

基于公开机制归纳路径差异；不是各厂商教程全文。

4.1 共性骨架（编排能力足够的引擎都能表达）

开始
  → 人工步骤：填写申请单
  → 人工步骤：部门领导审批
  → 条件：days > 5 ?
        ├─ 是 → 人工步骤：总经理审批 → 汇合
        └─ 否 → 直接汇合
  → 人工步骤：人力资源备案
  → 通知：反馈申请人
结束

差距在：表单从哪来、人从哪来、待办页谁提供、移动谁做、集团怎么隔离。

4.2 Elsa Workflows

步骤	典型做法
建模	Elsa Studio / 代码定义 Workflow；If 活动或流程图分支写 leaveDays > 5
人机	Bookmark / Human-in-the-loop：领导完成任务后 Resume
表单	自建 ASP.NET / Blazor / 外部表单；附件走对象存储，变量存 URL
选人	自建组织服务，把 assignee 写入业务表或自定义活动
审批壳	自建待办列表查询 Bookmark/任务；驳回=自定义信号或回退活动
反馈	HTTP/Email 活动或自定义 Activity

坦诚短板：引擎与 Studio 对开发者很友好，但请假 OA 的 80% 工作量在壳上（表单、组织、待办、移动）。V2→V3 迁移成本需单独评估。

适合：已有门户，要把请假嵌进更大编排（同步考勤、写 ERP、发消息一条龙）。

4.3 Workflow Core

步骤	典型做法
建模	C# StepBody 或 JSON/YAML 引用步骤类型
分支	决策步骤 / 条件流出 leaveDays > 5
人机	社区 Users 等扩展可做等待；完整审批要自建
表单 / 门户 / 移动	基本都无产品级能力 → 全自建

坦诚短板：嵌入成本极低，但「简单请假」一旦要求附件、部门领导、移动审批，就变成自研迷你 OA。适合：后台状态机、已有 UI 的系统内嵌流转。 不适合：实施顾问「只配不写」交付请假。

4.4 WorkflowEngine.NET（OptimaJet）

步骤	典型做法
建模	可视化设计器画方案；Condition / 分支表达天数
表单	设计器表单模板 / Vue 等可定制；完整附件中心仍常要项目补
选人	Assignment、角色、命令；部门领导规则多要接自有组织
审批	引擎命令（Approve 等）+ 自建或半成品工作台
扩展	IWorkflowActionProvider、CodeActions、Plugins

坦诚短板：

生产使用通常需商业许可（能看源码 ≠ 可免费商用）。
比 Elsa/Workflow Core 更接近「可嵌入 BPM 组件」，但仍不是开箱中国式 OA；集团组织、移动待办要自己补齐或买生态。

适合：愿意为设计器与嵌入质量付许可费、自有门户较强的团队。

4.5 该引擎

步骤	典型做法
建模	该平台流程设计器配置节点与方向条件，如请假天数 > 5
表单	内置表单设计器：枚举（病假/婚假/事假）、日期、天数、原因、附件
选人	Port_*：按部门领导、岗位、HR 角色配置
审批	待办/在途/已完成门户开箱；意见可落表单或审核框
反馈	抄送、消息、结束事件等，少写胶水
扩展	前端外挂 / 后端外挂 / 事件配置（不改发送内核）

这类请假审批单是产品的常见落地场景：表单设计器内置请假天数、请假类型等字段，主场就是审批单这类业务，而不是「纯变量桶」。

坦诚短板：国际社区与「流程即代码 / GitOps」叙事弱于 Elsa；超高并发分布式编排不是主战场；学习约定（节点号、表单 ID、外挂命名）需要时间。

适合：政企/企业要快速交付可上线的请假，以及后续一堆同类审批。

4.6 StepWise

步骤	典型做法（若硬做请假）
建模	[Step] / [DependsOn] 把「申请、审批、备案」写成方法依赖图
人机	无原生 UserTask/待办；要自建「谁点了同意再触发下一步」
表单/门户/移动/集团	均需从零；自带 WebUI 偏调试执行，不是审批工作台

坦诚结论：StepWise 很强，但强在代码步骤编排 / AI 流水线。用它做请假，等于承认你要自研半个 BPM。 纳入本文的目的：防止「看见 Workflow 字样就拿来做 OA」。

4.7 Slickflow

步骤	典型做法
建模	BPMN 风格设计器；排他网关天数 > 5
运行	WorkflowService：Start / Run / Sendback / Withdraw 等
表单	社区版常见「引擎 + 自建或轻量表单」；完整度视版本/商业线
选人	参与者配置 + 常接自有组织
扩展	IExternalService、WebApi、SQL、过程、C# 库

坦诚短板：在「标准 BPMN 嵌入」上国内口碑好；在「表单 + 组织 + 移动 + 集团开箱」上通常仍弱于该引擎。请假能较快跑通引擎侧，门户与移动仍是项目量。

适合：要 BPMN 语义、以 API 嵌入已有 .NET 业务系统。

5. 重点场景对照：审批 · PC · 移动 · 企业 · 集团

评级：强 / 中 / 弱。依据公开产品能力与常见落地形态。

5.1 审批（人机任务语义）

引擎	待办模型	驳回/退回	意见与附件进审批	一句话
Elsa	中（Bookmark 可自建）	中（自建）	中（表单外置）	能等人，不等于开箱审批
Workflow Core	弱偏中	弱	弱	库级等待，OA 语义靠你
WorkflowEngine.NET	中偏强	中	中偏强	组件强，OA 壳仍要砌
该引擎	强	强	强	请假类审批是主场
StepWise	弱	弱	弱	模型不对题
Slickflow	强	强（API 级退回等）	中（表单深度视版本）	引擎审批强，壳看项目

5.2 PC 应用

引擎	设计器	待办/办理门户	查询监控	请假 PC 交付直觉
Elsa	强（Studio）	中（偏开发/运维，业务门户自建）	中偏强	先有编排，再造 OA 皮
Workflow Core	弱	弱	弱	几乎全自建
WorkflowEngine.NET	强	中	中	设计器亮眼，门户要补
该引擎	强（中文属性）	强	中偏强	配完可给业务用
StepWise	中（执行 WebUI）	弱（非审批台）	中	调试友好，业务不友好
Slickflow	强	中	中	设计师可用，办理台多自建

5.3 移动应用

引擎	产品级移动	常见落地	领导批假体验
Elsa	弱偏中	自研 H5 + API/Webhook 恢复	取决于项目组
Workflow Core	弱	全自建	差（成本高）
WorkflowEngine.NET	中	自研或生态；接企微/钉钉	取决于项目组
该引擎	中偏强	与待办同一套流程语义	相对少造轮子
StepWise	弱	不适用审批移动	差
Slickflow	中	REST + 自研移动壳	取决于项目组

公正提醒：移动体验强依赖企微/钉钉/APP 通道。差别在于——待办语义能否直接复用，还是移动端再实现一半审批逻辑。

5.4 企业应用（组织、权限、集成、可运营）

引擎	组织岗位	权限门户	业务集成	把请假做成企业制度系统
Elsa	弱（外接）	弱偏中	强（活动/HTTP/消息）	适合已有企业中台
Workflow Core	弱	弱	中（代码集成）	仅适合深嵌现有系统
WorkflowEngine.NET	中	中	强（Action/插件）	中台 + 许可费场景
该引擎	强（Port）	强	中偏强（事件/WebApi/SQL）	适合作审批底座
StepWise	弱	弱	中（代码/AI）	不建议当 OA 底座
Slickflow	中	中	强（多种执行体）	嵌入业务系统很合适

5.5 集团应用（多组织 / 多公司）

引擎	多组织模型	流程模板分发	集团请假制度落地
Elsa	中（应用层租户自建）	中	能做，贵在治理
Workflow Core	弱	弱	基本靠自建
WorkflowEngine.NET	中	中	能做，要自建组织治理
该引擎	强（集团版 OrgNo 等运行模式）	强	主场之一
StepWise	弱	弱	不建议
Slickflow	中	中	可做，产品化弱于该引擎

6. 打分表（请假交付视角）

相对分，服务选型；正式立项仍应 POC。StepWise 按「硬做请假」诚实打低分——不是否定其在 AI/步骤编排上的价值。

维度（权重）	Elsa	Workflow Core	WorkflowEngine.NET	该引擎	StepWise	Slickflow
S1 流程与分支（15%）	8.5	7.5	8.5	8.5	5.0	8.5
S2 表单附件枚举（15%）	5.0	3.0	7.0	9.0	2.5	6.0
S3 审批语义（20%）	5.5	3.5	7.5	9.2	2.0	8.0
S4 PC 应用（15%）	6.0	2.5	7.5	9.0	3.5	6.5
S5 移动应用（15%）	4.5	2.0	5.5	8.0	2.0	5.5
S6 企业应用（10%）	6.5	4.0	7.0	8.5	3.5	7.0
S7 集团应用（10%）	5.0	2.5	5.5	8.8	2.0	5.5
加权综合	5.9	3.6	7.1	8.8	2.9	6.9

维护、许可与资料（不进加权，必须看）

产品	活跃度	中文资料	许可提示	选型态度
Elsa	高	中	宽松开源常见	编排短名单；纯请假慎选
Workflow Core	中	中	宽松开源	仅嵌入轻场景
WorkflowEngine.NET	中偏高	中偏低	生产多需商业许可	可进短名单，先算法务
该引擎	中偏高（国内交付向）	高	以官方开源说明为准	请假/OA 短名单
StepWise	中（较新）	中	以仓库为准	不要当 OA 引擎选
Slickflow	中偏高	高	社区/商业线需分清	BPMN 嵌入短名单

一句话读表

把请假当「可上线审批应用」：该引擎 综合最高——表单/组织/门户算进了产品。
把请假当「嵌入已有系统的 BPMN 流」：Slickflow 与 WorkflowEngine.NET 更贴（后者看许可）。
把请假当「更大编排里的人工节点」：Elsa 合理；别指望开箱 OA。
Workflow Core：能做流转，做不齐「简单请假」的产品面。
StepWise：请假题上故意打低——防误选，不是黑它做 AI 流水线。

7. 实现成本对照（把「简单」说透）

假设 2 名熟悉 .NET 的后端 + 1 名前端，从零到「请假可试用」：

引擎	相对工作量	工作主要花在哪
该引擎	低	设计器配流程/表单/接收人；少量测试
Slickflow	中	流程与 API 较快；表单门户移动要补
WorkflowEngine.NET	中	设计器省事；组织/移动/许可与集成
Elsa	中高	Bookmark 与活动不难；难在表单待办移动组织
Workflow Core	高	几乎从零砌审批壳
StepWise	极高（若坚持做 OA）	先造待办/退回/组织，再谈请假

公正补充：若企业已有统一表单中心、组织中台、移动待办中台，则 Elsa / Slickflow / WorkflowEngine.NET 的自建量会下降，综合分应上调——这正是它们在「中台齐全」架构里仍然合理的原因。

8. 选型建议（按场景，不捧杀）

8.1 决策树（请假及同类审批）

是否必须尽快上线「员工能直接用的请假」且缺少表单/组织/门户？
 ├─ 是 → 优先该引擎
 └─ 否，已有门户与组织中台
      ├─ 要 BPMN 嵌入现有 .NET 业务 → Slickflow
      ├─ 要商业级设计器嵌入，可接受许可费 → WorkflowEngine.NET
      ├─ 请假只是长编排中的人工节点 → Elsa
      ├─ 只要代码里嵌个状态机 → Workflow Core
      └─ AI/数据步骤流水线，不是审批 → StepWise（别拿来做请假主引擎）

8.2 分场景建议

场景	更稳妥的选择	理由（中肯版）
中小企业 / 政企 OA 请假、报销、用章	该引擎	审批+表单+组织闭环，PC/移动路径短
已有业务系统，只需嵌入标准流程引擎	Slickflow	BPMN + API 清晰，壳可复用现有 UI
要漂亮设计器、插件式 Action，预算含许可	WorkflowEngine.NET	组件质量高；先算清授权
微服务编排 + 偶发人工确认	Elsa	编排长板；审批短板用外部待办补
纯后台状态/Saga，无领导审批 UI	Workflow Core	够用就好，别过度采购
DAG / AI Agent 步骤	StepWise	对题；与请假 OA 不是同一类题
集团多公司审批平台	该引擎（集团模式）；或其它引擎 + 自建组织治理	前者产品化；后者灵活但贵在治理

8.3 与 Java 姊妹篇的对照读法（避免误读分数）

诉求	.NET 侧更贴	Java 侧更贴（姊妹篇）
开箱审批应用	该引擎	该引擎
标准引擎 + 自建壳	Slickflow / Elsa	Flowable / Camunda
千万别误选	StepWise 当 OA	OpenWFE 等停更引擎当生产

8.4 最终坦诚结论

同一道简单请假题：该引擎、Slickflow、WorkflowEngine.NET、Elsa（加自建）都能工程化做完；Workflow Core 能做「流转」但难算「交付」；StepWise 模型不对题。
分水岭仍是：你要的是 流程引擎/编排库，还是 审批应用平台。
- 前者：Elsa / Workflow Core / Slickflow / WorkflowEngine.NET（按嵌入深度与许可选）。
- 后者：该引擎。
Slickflow 是「不要该引擎那种一体化、但又要正经审批引擎」时的重要备选——分数低于该引擎，往往是因为表单/门户/集团开箱，而不是引擎不会走网关。
WorkflowEngine.NET 能力与设计器值得认真评，但许可必须进选型会议程，否则 POC 通过也可能上不了生产。
StepWise 打低分是保护项目：它很优秀，只是不该出现在「请假 OA 短名单」第一页。

9. 局限性声明

本文是公开资料 + 统一需求推演，不是厂商授权测评，也不是性能测试报告。
商业版能力未计入开源/社区版得分；WorkflowEngine.NET 尤需按合同重评。
该引擎章节结合本工作区公开示例与源码叙事；其余以公开文档与通行落地方式为准。
「集团应用」名词各异（OrgNo / 租户 / 多公司），上线前必须 POC 隔离与模板分发。
与 Java 篇分数禁止直接横比——权重相同，生态与人才池不同。

文档生成说明：基于统一请假需求，对 Elsa、Workflow Core、WorkflowEngine.NET、该引擎、StepWise、Slickflow 的公开实现路径与场景适配做相对评价。选型请以 POC、许可与安全评估为准。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

bpmn-js