Flowable 和 Camunda 谁更适合中国式 OA 审批？

如果目标是建设传统中国式 OA 审批平台，并要求私有化部署、Java 深度二开、关系型数据库和可控的引擎扩展，Flowable 通常是更合适的 PoC 起点。它并不直接提供完整的会签、加签、退回和撤回产品，但部署形态与国内 Java 技术栈更贴近，状态变更 API 也较容易被封装成受控的审批操作服务。

Camunda 必须拆成 Camunda 7 和 Camunda 8。Camunda 7 技术形态同样适合传统人工作流，但社区版生命周期使其不再适合作为新项目默认底座；Camunda 8 面向分布式流程编排，适合跨服务、跨语言 Worker 和高可用场景，却通常不是传统 OA 的最短实现路径。

真正决定项目成败的不是引擎能否移动 Token，而是平台能否把引擎原语变成安全、可解释、可审计的业务动作。

一、先给结论：三种路线适合不同问题

选型问题	Flowable	Camunda 7	Camunda 8
传统 OA 新项目	优先进入 PoC	不建议作为新底座	仅在同时需要分布式编排时评估
Java 与本地事务	可嵌入，RDBMS 路线	可嵌入，RDBMS 路线	客户端连接集群，业务逻辑在 Worker
会签、退回、跳转	原语较贴近平台封装	技术可行，但生命周期不利	可实现，平台适配更重
私有化与许可	开源引擎边界较清晰	社区版已 EOL	需逐项核对组件和生产许可
最适场景	OA、BPM、低代码审批	既有系统治理	分布式流程编排、端到端自动化

图 1　中国式 OA 是从执行内核到审批操作、组织权限、表单、门户和运营的一整套能力。

对多数请假、报销、采购、用印、合同和人事审批，Flowable 的优势是工程匹配度，而不是绝对功能更多。若人工审批只是跨系统旅程中的一环，且企业已经具备分布式平台运维能力，Camunda 8 才可能体现架构价值。

二、为什么必须把 Camunda 7 和 8 分开

Flowable 与 Camunda 7 都属于 Java 加关系型数据库的传统流程引擎路线，可嵌入 Spring 应用，通过引擎服务 API 操作流程，并把运行时与历史数据保存到关系型数据库。这种形态便于：

• 将审批动作与业务表更新放在明确的事务边界中；
• 复用 Java、Spring、连接池、数据库备份和监控体系；
• 按传统信息系统方式查询待办、已办、意见和流程轨迹。

Camunda 8 的核心是分布式编排集群。客户端通过 Gateway 发送命令，Broker 保存流程状态并分配 Job，业务逻辑由外部 Worker 执行，查询和运营依赖相应平台组件。

因此：

• Flowable 与 Camunda 7 比较的是相近的嵌入式引擎；
• Flowable 与 Camunda 8 比较的是两种系统架构；
• Camunda 7 技术可用不等于生命周期适合新项目；
• Camunda 8 能做人工审批，不等于更适合传统 OA。

供应商如果只说“基于 Camunda”，却说不清版本、组件、许可和部署拓扑，选型信息仍然不完整。

三、中国式 OA 审批的难点不在画流程

标准 BPMN 可以表达用户任务、网关、事件、子流程、多实例和条件流转，但企业真正要求的是组织制度的数字化：

• 按部门、岗位、职级、汇报线、区域和项目动态找人；
• 顺序会签、并行会签、比例通过、一票否决和动态增减人员；
• 前加签、后加签、加签后返回或继续；
• 退回发起人、上一步或指定节点，并决定后续是否重审；
• 转办、委托、代理、协办、抄送、传阅、催办和超时升级；
• 发起人撤回、管理员撤销、流程作废和重新提交；
• PC、移动端、门户、消息、电子签名和附件权限；
• 流程版本、表单版本、组织快照、审批意见和操作审计。

其中普通审批、条件流和会签结构可以用 BPMN 建模；运行中加签、退回、跳转和撤回则必须由平台定义操作语义、权限、拓扑变化、幂等与审计。

四、BPMN 原生能力与平台能力怎样分工

OA 需求	可使用的 BPMN/引擎原语	平台必须补齐
普通审批	User Task、候选人、条件流	组织找人、权限、表单、意见
顺序/并行会签	Multi-instance User Task	通过策略、动态加人、统计展示
或签	候选用户/组、领取与完成	抢占、释放、代理和审计
超时催办	Timer、Boundary Event	消息渠道、频率和升级对象
条件审批	Gateway、表达式、DMN	规则治理、版本和可解释性
回退/跳转	状态变更或实例修改 API	合法路径、并发清理和历史语义
撤销补偿	Cancel/Compensation 等事件	外部副作用补偿和业务状态

多实例只是会签的执行结构。平台仍要回答通过率分母如何计算、动态加人是否计票、转办和弃权如何处理、一票否决后剩余任务是否取消，以及运行中组织变化采用实时关系还是启动快照。

五、Flowable 为什么更贴近传统 OA

Flowable 可嵌入 Java 应用，也可服务化部署，状态保存在关系型数据库中。对于现有 Java 团队，这意味着部署、日志、监控、数据库容灾和本地事务方案更熟悉。

更关键的是，Flowable 的状态变更能力较适合作为退回和跳转的底层原语。例如可以把当前活动移动到其他活动、将多个活动汇聚到单个活动、将单个活动拆分到多个活动，并处理部分父子流程状态变化。

但这些 API 不是可直接暴露给前端的 OA 功能。平台必须先计算：

• 哪些执行实例和并行任务应终止；
• 目标节点是否位于当前作用域或子流程；
• 并行网关是否会留下孤立 Token；
• 目标处理人按历史快照还是最新组织解析；
• 原任务、意见、附件和表单权限如何记录；
• 定时器、消息订阅和异步作业如何处理。

Flowable 还同时提供 BPMN、CMMN 和 DMN 能力。固定路径适合 BPMN，案件式流程可以评估 CMMN，金额、职级和风险规则可用 DMN 管理。对于传统 OA，这些能力提供了更大的平台封装空间。

六、Camunda 7 与 Camunda 8 的适用边界

Camunda 7 的多实例和 Process Instance Modification 同样可以支撑会签、回退和实例干预，存量系统可以继续治理。但新项目必须把社区版生命周期、安全维护和未来迁移成本纳入决策，不能只看功能可行性。

Camunda 8 的优势是：

• 分区与复制的流程状态存储；
• 跨语言 Job Worker；
• 跨微服务的长事务编排；
• 高吞吐、水平扩展和集群高可用；
• 更适合端到端自动化平台。

它也支持 User Task 和实例修改，但传统 OA 需要的平台能力并不会因此消失。组织找人、表单权限、审批意见、统一待办、消息触达和中国式操作仍需建设，而且私有化时还要评估集群运维、数据链路和组件许可。

图 2　Flowable 与 Camunda 7 更接近嵌入式审批内核，Camunda 8 更接近分布式编排基础设施。

七、会签、加签与动态人员怎样实现

会签应优先使用多实例建模，而不是运行中无规则地创建一批任务。平台在实例启动前解析人员集合，并保存组织快照、通过策略和人员版本。

动态加签则需要区分：

• 前加签：加签人先处理，完成后回到原审批人；
• 后加签：原审批人完成后，加签人继续处理；
• 并行加签：原审批人与新增人员共同参与；
• 加签并完成：当前人提交意见后立即转入新增任务。

每种模式都要明确原任务是否保留、审批责任归属、完成条件如何变化、意见如何展示以及撤销加签的权限。引擎只负责创建、终止或迁移执行状态，平台负责把这些动作组织为稳定业务语义。

八、退回、跳转、撤回为什么风险最高

图 3　审批动作应先经过权限、策略和拓扑计划，再由引擎适配器执行。

任何引擎都不应向前端暴露通用的 jump(source, target)。正确链路是：

1. 接收业务动作与幂等键；
2. 校验操作者、任务状态和业务状态；
3. 分析作用域、并行分支、子流程、定时器和目标节点；
4. 生成任务取消、Token 移动、变量恢复和重新找人计划；
5. 调用 Flowable、Camunda 7 或 Camunda 8 的适配器；
6. 更新业务单、审批意见、操作日志、待办和消息；
7. 对超时或失败进行对账、补偿和告警。

撤回、撤销和作废也必须区分。撤回通常表示下游尚未实质处理时退回草稿；撤销表示终止运行中的申请；作废表示业务单不再有效。终止流程不会自动撤销 ERP 写入、预算冻结、合同编号或外部消息，因此高风险流程必须设计补偿或人工异常处理。

九、转办、委托、代理与抄送不能混用

• 转办：任务责任永久转移给另一人；
• 委托：受托人处理后可能返回委托人；
• 代理：按时间和流程范围自动代办；
• 协办：新增参与者提供意见，不一定拥有最终提交权；
• 抄送/传阅：通常不改变流程 Token；
• 催办：不改变处理人，只触发消息和升级策略。

Assignee、Owner、Candidate 和 Delegation 等引擎字段只能承载部分语义。平台还要管理代理有效期、冲突优先级、敏感字段、责任链、消息和审计。

当前项目已经提供加签、退回、跳转、委托、转办、催办、撤销、个人待办、待阅、移动审批等平台接口。这正说明最终交付的是审批中心，而不是裸引擎 API。云程低代码开发平台继续组合表单、组织、门户、移动端和流程分析，也是为了让引擎可升级，而业务动作模型和用户入口保持稳定。

十、私有化部署还要比较哪些成本

只比较 API 会漏掉一半成本。

1. 数据与事务

检查审批状态与业务单据如何保持一致，任务、意见、表单、附件和消息能否追溯，历史数据如何归档，以及数据库恢复后如何与消息和外部副作用对账。

2. 身份与权限

检查 AD、LDAP、OIDC、企业微信或钉钉对接，人员、部门、岗位、职级和汇报线同步，以及管理员代办、敏感流程双人复核、附件和字段级权限。

3. 运维与可观测

必须能从业务单号定位流程实例、任务和异常，查看作业、定时器、失败重试和积压，并对管理员跳转、迁移和人工修复保留操作日志。

4. 许可与退出成本

不要只看引擎仓库。应分别核对设计器、任务列表、运营台、身份、分析、生产、灾备和非生产环境的许可，同时验证模型、运行数据和历史数据能否导出。

十一、推荐的场景决策

图 4　先判断主要矛盾是审批产品化还是分布式编排，再考虑存量、许可和运维能力。

• 80% 以上是传统行政、人事、财务和合同审批，Java 团队维护且需要深度二开：Flowable 优先 PoC；
• 已经稳定运行 Camunda 7：先治理依赖、建立回归和退出方案，不要因 EOL 仓促重写；
• 主要是跨微服务、跨语言的端到端编排，人工任务只是一环：评估 Camunda 8；
• 两类需求都强：建设独立审批中心，通过适配器连接一个或多个流程运行时。

无论选择哪种引擎，移动端和业务系统都不应直接依赖引擎任务表或内部状态变更命令。