2026 年 Java 开源工作流引擎选型：别只看版本号和社区活跃度

2026 年选择 Java 开源工作流引擎，第一步不是比较版本号、GitHub Star 或最近提交，而是确认要解决的是人工作业审批、复杂业务流程、分布式服务编排，还是应用内逻辑编排。

对中国式 OA 和低代码审批，Flowable 通常仍是更均衡的开源底座；已有 Activiti 资产应优先评估加固与渐进迁移；需要跨语言、高吞吐编排时可评估 Camunda 8、Conductor 或 Temporal；规则与流程强耦合可看 Apache KIE/jBPM；Camunda 7 存量系统可以验证 Operaton、CIB seven；LiteFlow 则更适合应用内逻辑链。

本文不评选一个适用于所有企业的“冠军”，而是回答五个问题：状态存在哪里，业务代码怎样执行，人工任务如何扩展，私有化部署要付出什么成本，未来能否平滑升级或退出。

一、先分类：Java 工作流不是同一类产品

类别	典型项目	适合解决的问题	不应期待它直接解决什么
BPMN 人工与业务流程引擎	Activiti、Flowable、jBPM、Operaton、CIB seven	OA 审批、订单履约、跨部门流程、流程中台	完整组织权限、表单、门户和中国式审批语义
完整 BPM/DPA 平台	Bonita、Camunda 商业平台	建模、表单、任务门户和应用装配	无成本替换现有低代码体系
分布式耐久执行与服务编排	Camunda 8、Conductor、Temporal	微服务编排、Saga、跨语言 Worker、可靠重试	开箱即用的会签、退回和组织选人
应用内规则与逻辑编排	LiteFlow	规则链、营销计算、风控和组件编排	持久化人工任务与跨天审批
作业与数据调度	XXL-JOB、PowerJob、DolphinScheduler	定时任务、数据管道和批处理 DAG	业务人员参与的流程生命周期

最常见的错误，是把不同类别放进同一张功能排行榜。Temporal 有成熟 Java SDK，但服务端主要使用 Go；LiteFlow 很适合拆解复杂 Java 逻辑，却不是 OA 审批引擎；Conductor 擅长 Worker、重试与失败恢复，但不以 BPMN 人工任务为中心。

图 1：先按目标负载分类，再在同一类别内比较，避免把 BPMN、耐久执行、逻辑编排和任务调度混为一谈。

二、2026 年主要候选项目概览

截至 2026 年 7 月，几个主流项目的公开状态如下：

项目	公开主线或近期版本	运行模型	选型时最应关注
Activiti	9.0.0；8.8.1 维护线	Java 嵌入式/服务化、关系型数据库	9.0.0 的 Java 25 基线；存量资产价值
Flowable	8.0.0	BPMN/CMMN/DMN、多引擎、关系型数据库	Spring 7、Boot 4、Jackson 3 的升级跨度
Camunda 8	8.9.13 稳定线	Zeebe 分区日志、Raft、外部 Worker	Self-Managed 生产许可与分布式运维
Apache KIE/jBPM	10.2.0，Apache 孵化阶段	jBPM/Kogito + Drools/DMN	流程与规则一体化；治理迁移
Bonita	2026.1-u0 / 11.0.0	引擎 + Studio + UI + Runtime	Community 与 Subscription 边界
Operaton	2.1.3	Camunda 7 血统，可嵌入或独立部署	兼容范围、治理成熟度和长期支持
CIB seven	Community 2.2.0	Camunda 7 血统，含基础 Web 应用	Community 与 Enterprise 能力区分
Conductor OSS	当前主线要求 JDK 21+	中央服务 + 持久状态 + 解耦 Worker	微服务/Agent 编排，不是 BPMN OA
LiteFlow	2.16.0	Java 组件 + EL 规则链	应用内逻辑编排，不是人工流程

版本新不等于迁移风险低。Activiti 9 的 Java 25 基线可能比企业当前平台激进；Flowable 8 同时跨越 Spring Boot 4 和 Jackson 3；Camunda 8.9 虽然稳定，却是一个需要额外基础设施与生产许可的分布式平台。

三、BPMN 与人工审批候选怎样选

1. Activiti：优先保护存量资产

Activiti 仍是轻量、可嵌入、Apache 2.0 的 Java BPMN 引擎。它适合已有大量流程定义、监听器、表结构和运维工具，且上层任务、表单和组织能力已经自研的系统。

新项目不应因为 Activiti 版本号更高就默认选择它。还要比较路线连续性、工具链、文档、人才和未来升级成本。存量系统则应先盘点内部 API、直接 SQL、序列化变量和在途实例，再决定加固、升级还是迁移。

2. Flowable：国内 OA 与低代码的优先 PoC 候选

Flowable 提供 BPMN、CMMN、DMN、事件注册、任务、历史、异步作业、实例迁移和动态状态变更。它的优势主要是：

• 嵌入式事务模型容易与 Java 业务系统结合；
• 多实例和动态状态变更为会签、退回、跳转等二次开发提供支点；
• Apache 2.0 与关系型数据库模型便于私有化；
• 国内 OA 和低代码二开经验相对丰富。

但 Flowable Engine 不是成品 OA。组织选人、表单权限、会签策略、加签闭环、撤回、审计、消息补偿和任务门户仍属于平台层。

3. Apache KIE/jBPM：规则与流程强耦合

Apache KIE 生态包含 Drools、jBPM、Kogito、DMN 和建模工具，适合保险核保、授信、合规、复杂定价等“规则决定流程，流程又触发规则”的场景。

优势是流程、规则和决策来自同一自动化生态；代价是技术栈大、概念多，传统 jBPM 与 Kogito 的运行方式也需要先划清边界。2026 年还应验证迁入 Apache 基金会后的包名、发布、治理和文档连续性。

4. Bonita：完整平台优先，而不是只取引擎

Bonita 提供 Studio、UI Designer、应用构建、连接器和运行门户，适合不希望从零建设流程设计器、页面与任务中心的组织。

对已有低代码平台而言，它的完整性也可能造成重复建设。选型时应确认社区版能力、订阅版边界、应用资产格式、流水线构建方式，以及能否只集成需要的部分。

5. Operaton 与 CIB seven：Camunda 7 存量的延续路线

Operaton 和 CIB seven 都基于 Camunda 7 血统发展，为不能立即迁到 Zeebe Worker 模式的系统提供了替代方向。它们值得验证，但不能因为“API 兼容”就跳过数据库、插件、权限、历史、外部任务和长运行实例测试。

对于这两条较新的路线，企业应特别关注治理主体、发布签名、安全修复、LTS 周期、社区版与企业版差异，以及未来能否再次迁出。

四、分布式编排候选怎样选

1. Camunda 8：跨语言与高吞吐编排

Camunda 8 的核心是 Zeebe。客户端通过 REST/gRPC 访问 Gateway，Broker 按分区处理命令并通过 Raft 复制，业务代码由外部 Job Worker 执行。它与 Java 引擎共享关系型数据库的模式不同。

它适合跨语言服务、水平扩展、可靠重试、超时、背压和故障恢复。企业也可以采用 Modeler、Operate、Tasklist、Identity 等配套产品。但自 8.6 起，Self-Managed 生产使用需要有效许可，PoC 前就应把采购和三年 TCO 放进决策。

Camunda 8 不是 Camunda 7 的 Maven 升级。流程模型、Java Delegate、事务、历史查询、运维和数据迁移都需要重新设计。

2. Conductor：Worker 驱动的服务与 Agent 编排

Conductor 通过中央服务保存耐久状态，提供重试、超时、多语言 SDK 和可插拔存储。它适合订单履约、媒体处理、跨服务 Saga 和 AI Agent 执行链。

它通常使用 JSON、代码和 Worker 表达流程，不以 BPMN 人工任务为核心。如果需求中心是会签、退回和任务门户，需要大量上层建设。

3. Temporal：代码优先的耐久执行

Temporal 让 Java 团队通过 SDK 编写 Workflow 和 Activity，使用确定性重放获得可靠重试与状态恢复。其服务端主要使用 Go，因此不符合“服务端必须是 Java 项目”的严格采购条件。

Temporal 更适合开发者控制的服务编排，而不是业务人员频繁修改的审批路线。评估时应关注代码升级兼容、确定性约束、Worker 部署、命名空间、历史增长和运维团队能力。

五、LiteFlow：适合应用内逻辑，不要承担 OA 生命周期

LiteFlow 的核心模型是“Java 组件 + EL 规则链”，支持 XML、JSON、YAML、数据库和多种配置中心，并能热刷新。它适合把定价、风控、营销或数据处理中的复杂 if/else 拆成可复用组件。

LiteFlow 通常运行在应用进程中，不提供 BPMN 人工任务、跨天等待、完整历史审计和中国式 OA 操作语义。企业可以用 Flowable 管审批生命周期，用 LiteFlow 管节点内业务规则，两者不是二选一。

六、为什么版本号、Star 和提交数不够

提交频繁可能来自依赖升级、文档、前端和自动化机器人，并不代表执行树、并发、Job Executor 等关键路径有人持续维护。Star 更接近累计知名度，也无法证明国产数据库、信创操作系统、LDAP/AD、租户隔离和等保适配已经完成。

真正值得核对的是：

• 严重安全问题是否有明确响应渠道；
• 数据库升级脚本是否覆盖目标版本跨度；
• 在途实例能否跨版本继续执行或迁移；
• 公共 API、扩展属性和历史数据是否兼容；
• 核心执行语义由多少维护者掌握；
• 商业主体退出后，仓库、商标和发布权限怎样治理。

“开源”也不等于生产永久免费。评审时要逐组件确认引擎、建模器、任务中心、运维控制台、镜像、Chart、Connector 和身份组件的许可证，并区分内部使用、SaaS 服务与交付客户三种情形。

七、中国式审批要按状态变化验收

功能	必须验证的语义	引擎支点	平台需要补齐
会签	并行/串行、比例、一票否决、动态增减人	多实例、完成条件、监听器	人员快照、并发一致性、统计审计
加签	前/后加签、返回路径、多级加签	动态任务、多实例变更、子流程	权限、闭环、人员校验、幂等
退回	上一活动、指定活动或发起人，是否重走中间节点	状态变更/实例修改 API	合法目标、变量清理、历史和消息补偿
跳转	单节点、多节点、并行分支如何合并	Migration、Modification、Change State	执行树校验、网关语义、批量授权
撤回/撤销	时间窗口、下一节点是否处理、结束后是否作废	删除、终止、移动执行、补偿事件	业务状态、外部副作用补偿、审计证据
转办/委派	责任转移还是代办后返回	Assignee、Owner、Delegation	组织权限、代理规则、通知追踪

“支持退回”不能只靠一个演示按钮证明。并行网关之后可能存在多个上一节点，多实例会签中也有多个活动实例。平台应先计算合法状态迁移计划，锁定实例并校验幂等，再调用引擎支持的状态变更 API，同时记录“谁因为什么从哪里移动到哪里”。

流程状态回退也不等于业务副作用自动回退。消息、库存、财务和外部接口必须使用 Outbox、补偿操作或人工处置。

八、私有化部署要核算隐藏成本

图 2：许可证只是私有化 TCO 的一层，运行架构、数据、运维和平台扩展往往决定长期成本。

1. 运行架构

嵌入式引擎部署简单，但要处理数据库锁、异步作业、历史增长和业务事务耦合。分布式平台增加 Gateway、Broker、分区、复制、Exporter、查询存储和控制台，扩展性更强，运维面也更大。

2. 数据库与信创

“能建表”不等于“正式支持”。至少验证数据类型、索引、分页与锁语法、乐观锁、定时器抢占、并发完成、大变量、主备切换、版本 DDL 和回滚。对国产数据库，最好维护独立兼容层和持续回归，避免直接修改引擎核心 SQL。

3. 可观测性与数据生命周期

需要把业务单号、流程实例、任务、异步作业、Worker 和下游请求串联起来，同时验证 Metrics、Tracing、结构化日志、死信处理、历史归档和数据脱敏。

4. 升级与退出

PoC 阶段就应测试 BPMN 模型可移植性、扩展属性映射、运行实例迁移、历史导出、代码适配，以及停止订阅后的生产运行和安全修复边界。

九、一套可执行的选型流程

图 3：从工作负载出发，先过硬门槛，再进入真实 PoC 和加权评分。

1. 明确主负载：人工审批优先比较 Flowable、Activiti、jBPM、Bonita、Operaton、CIB seven；跨服务编排比较 Camunda 8、Conductor、Temporal；应用内逻辑评估 LiteFlow。
2. 设置硬门槛：许可证、Java 基线、数据库、操作系统、身份集成、灾备、RPO/RTO 和安全响应必须先 Pass/Fail。
3. 用真实流程 PoC：覆盖串并行、会签、定时器、消息、补偿、迁移、退回、加签、撤回、高并发和数据库切换。
4. 对真实成本评分：业务语义、架构匹配、私有化、许可、升级、安全和团队能力都要有证据。
5. 演练升级与退出：使用真实数据副本升级，并验证流程定义、在途实例、历史、插件和业务状态。

建议评分：

维度	权重	核心证据
业务语义与扩展	25%	真实 BPMN 与中国式审批回归
架构匹配	20%	事务、吞吐、Worker 与故障模型
私有化与运维	15%	拓扑、监控、备份恢复与压测
许可与 TCO	15%	法务结论、三年成本与退出条款
升级与迁移	10%	数据副本升级、实例与接口兼容
安全与治理	10%	CVE、发布签名、维护主体
团队与生态	5%	人才、文档、案例和内部掌握

社区活跃度只应是最后一项的一部分。

十、不同企业场景的初步结论

企业场景	优先 PoC	同时比较	不建议作为默认项
新建 OA/低代码审批	Flowable	jBPM、Bonita；存量兼容再看 Activiti	Camunda 8、Conductor、LiteFlow
已有 Activiti 大量实例	当前版本加固与渐进升级	Flowable 分批迁移	一次性重写全部历史
已有 Camunda 7 CE	Operaton、CIB seven	Camunda 8 分阶段迁移	把 Camunda 8 当原地升级
保险、授信等规则密集场景	Apache KIE/jBPM	Flowable + 独立规则引擎	只凭 BPMN 画布决定
跨语言微服务编排	Camunda 8、Conductor、Temporal	按运维与许可决策	用嵌入式 OA 引擎包办
Java 应用复杂规则链	LiteFlow	Drools/DMN	用 BPMN 表达每个代码分支
快速获得完整流程应用	Bonita	商业 BPM 或成熟低代码平台	下载引擎 JAR 后期待门户自动出现

对低代码开发平台而言，流程引擎最好隐藏在稳定适配层后面。云程低代码开发平台这类产品需要长期掌握的是流程模型版本、组织选人、表单权限、中国式操作、审计、消息和业务状态之间的统一契约。这样未来升级 Flowable，或为特殊场景接入分布式引擎时，业务应用不必整体重写。

十一、最终建议

如果只记住五句话：

1. 先分工作流类型，再选项目；BPMN、耐久执行、逻辑编排和作业调度不是同一件事。
2. 对国内 OA/低代码审批，Flowable 是优先 PoC 候选，但它仍只是平台底座。
3. Camunda 8 是分布式编排平台，不是 Camunda 7 的依赖升级；生产许可与运维成本必须前置。
4. Operaton 与 CIB seven 为 Camunda 7 存量增加了选择，但兼容、治理和支持周期必须用真实数据验证。
5. 会签、加签、退回、跳转和撤销，本质是平台在引擎能力之上实现的受控状态迁移、权限与审计。

最终选型不是挑选最活跃的仓库，而是选择一种未来五年愿意承担的状态模型、扩展方式和运维责任。版本会更新，Star 会变化，真正留在企业里的，是流程数据、业务语义和升级成本。