开源流程引擎距离中国式工作流平台还差多少功能？

一句话回答：开源流程引擎通常已经完成了最难替代的执行内核，但距离可直接交付的中国式工作流平台，仍有组织人员、审批操作、表单权限、统一待办、移动消息、审计运维等约三分之二的产品化工作。

这里的“三分之二”不是厂商跑分，也不是说引擎只完成三分之一的技术难度。它是一种工程估算：如果把企业工作流拆成约 50 个常见能力项，引擎直接提供或稍加封装即可使用的通常不足一半；剩余能力需要流程扩展层、低代码平台和行业应用共同完成。

一、先给结论：引擎是内核，不是开箱即用的 OA

Flowable 的公开 API 提供 RepositoryService、RuntimeService、TaskService、HistoryService 等服务；Camunda 8 提供 Zeebe 执行、Tasklist、Forms、Identity、Operate 等组件；Activiti 也将自己定位为轻量级 BPMN 2 流程平台。它们解决的是流程定义如何部署、Token 怎样执行、任务怎样创建、事件和定时器怎样触发、历史数据怎样保存。

但业务人员提出的问题通常是：

• 审批人怎样按部门主管、连续多级主管、岗位或表单字段动态计算；
• 会签达到 60% 是否通过，一人否决怎样立即终止其他任务；
• 已办节点怎样退回，发起人怎样撤回，管理员怎样跳转；
• 每个节点能看哪些表单字段、能点哪些按钮、能查看哪些业务数据；
• 待办如何进入门户、手机、钉钉、企业微信或统一消息中心；
• 操作怎样审计，流程异常怎样监控，运行中实例怎样迁移。

这些能力并非 BPMN 引擎都“不支持”。更准确地说，引擎给出了任务、多实例、事件、变量和状态变更等原语，但没有替企业定义完整的产品语义。

二、能力边界：开源引擎已经解决什么

1. 一张图看清三层能力边界

企业工作流可以分成三层：

1. 执行内核：BPMN、CMMN、DMN、任务、事件、作业、变量、历史和事务；
2. 流程平台：中国式审批操作、组织解析、表单权限、规则、统一待办、消息、审计和运维；
3. 业务产品：门户、移动端、合同、人事、采购、费用、项目等行业应用。

图 1：引擎提供稳定内核，平台补齐审批与治理能力，业务产品负责用户场景。三层相互依赖，但不能混为一个采购或研发对象。

开源引擎最有价值的部分，是状态机、并发、事务、持久化、异步作业和 BPMN 语义。这些能力自己从零实现风险很高。中国式平台最耗产品打磨的部分，则是操作语义、组织权限、表单体验和跨系统协同。

因此，选型时不能拿 Flowable Engine 与一套完整 OA 的界面逐项比较，也不能拿 Camunda 商业产品的全部组件来证明“开源引擎已经什么都有”。应先明确比较的是引擎、开源应用、商业套件还是企业自己的平台。

2. 开源引擎已经提供了哪些基础

Flowable、Activiti 和 Camunda 的具体架构不同，但成熟流程引擎通常已经提供以下基础：

能力域	引擎通常提供的基础	平台仍需完成的工作
模型	BPMN 解析、部署、版本	模型目录、权限、评审、差异和发布审批
执行	Token、网关、事件、子流程	企业级异常策略和业务补偿
人工任务	创建、查询、签收、完成、委派	中国式操作、统一待办和权限校验
多人任务	串行/并行多实例、完成条件	会签票数、意见、动态增减人和审计
自动任务	Java Delegate、Worker、Connector 等	集成资产、凭据、幂等、监控和复用
时间能力	Timer、Job、重试	催办升级、工作日历和 SLA 产品规则
数据	变量、历史、查询 API	业务数据模型、脱敏、数据权限和报表
接口	Java/REST/gRPC 等	统一鉴权、限流、租户隔离和业务 API

Flowable 官方文档明确支持 User Task、候选用户与候选组、多实例和 completionCondition；REST API 支持 complete、claim、delegate、resolve 等动作。Camunda 8 的 User Task 支持人员分配、时间计划、变量映射、表单与任务监听器，Tasklist 提供基础任务队列、筛选和办理界面。

这些能力足以搭建流程应用，却不等于中国企业可以把引擎 JAR 包部署后，第二天就给全公司使用。

三、组织与任务语义：从审批人到动态操作

1. 组织和审批人不是 userId 与 groupId

BPMN 标准主要表达 assignee、candidateUsers、candidateGroups。中国企业的审批人规则远比这复杂：

• 发起人的直属主管、连续多级主管或指定层级主管；
• 部门负责人、分管领导、岗位、职级、矩阵组织和项目角色；
• 表单中的人员、部门、区域、成本中心或法人主体；
• 发起人自选、上一节点选择、运行时加签；
• 同一人重复出现时跳过、合并或仍需重复审批；
• 审批人为空时自动通过、转管理员、报错或走兜底人员；
• 代理、请假委托、轮班、兼岗和跨组织协同；
• 组织变更后，历史实例仍能解释当时为什么选中某人。

Flowable 官方文档说明其 IDM 可管理 User、Group 和 Membership，但也说明 IDM 不是流程引擎核心，嵌入业务应用时经常不使用；User Task 文档还指出，人员标识允许与外部身份系统集成。这个设计非常合理，却意味着企业必须建设组织适配层。

一个可审计的人员解析服务至少要输出：规则版本、输入上下文、候选计算过程、最终人员快照、空结果策略和去重策略。只在 BPMN 表达式里写一个 findLeader()，短期简单，长期很难测试、审计和跨引擎迁移。

2. 会签能运行，不代表会签产品已经完成

多实例 User Task 是实现会签的良好基础。Flowable 支持串行与并行多实例，也可以用 completionCondition 在满足条件后提前结束剩余实例。但中国式会签还包含一整套产品规则：

会签问题	引擎原语	平台产品语义
并行还是依次	isSequential	设计器名称、办理顺序和展示方式
多少人通过	completionCondition	同意票、否决票、弃权和分母口径
一票否决	提前完成多实例	剩余任务关闭原因与通知
动态加人	修改运行时任务或执行结构	加签类型、权限、范围和审计
人员重复	集合中可出现重复值	跳过、合并还是重复办理
审批意见	变量或 Comment	意见模板、附件、签名和时间线
撤销一票	状态变化与变量修正	是否允许、重新计算和审计

完成条件中的 nrOfCompletedInstances 只表示完成了多少实例，不天然等于多少人同意。平台必须保存结构化审批结果，计算 approvedCount、rejectedCount、abstainedCount，并明确提前结束时未办理任务的状态。

会签人员还可能在运行过程中变化。增加一名审批人时，分母是否变化？已经达到 60% 后还能否加签？串行会签应插在当前人之前还是之后？这些都不是 BPMN 标准替企业做出的决定。

退回、跳转、加签和撤回最容易被低估。

很多项目把中国式操作理解为“调用一个 changeState API”。真正困难的不是移动执行位置，而是保证操作后流程仍然一致。

3. 退回

退回到上一节点需要确定“上一节点”是模型上的前驱，还是本实例实际经过的节点。并行分支、多实例、子流程和循环存在时，两者可能完全不同。平台还要决定：

• 当前并行分支是单独退回还是全部退回；
• 已完成的其他分支是否保留；
• 退回后重新办理还是直接恢复旧任务；
• 局部变量、审批意见、附件和业务状态怎样处理；
• 重新向前时是否再次发送消息和调用外部系统。

4. 加签

前加签、后加签、并行加签、串行加签不是同一个动作。它们对任务所有者、多实例计数、后续路径和审计记录的影响不同。单纯创建一条独立 Task，可能无法阻塞原流程，也无法被历史查询正确解释。

5. 跳转

管理员跳转适合应急处置，但目标节点必须在合法作用域内。跨子流程、跨并行汇合或跳过补偿边界，可能留下未关闭执行、定时器、订阅和作业。平台应先生成影响预览，再执行受控状态变更。

6. 撤回与撤销

提交后尚无人办理的“撤回”，与下游已经办理甚至调用外部系统后的“撤销”不是一件事。前者可以是受限状态回退；后者往往需要补偿流程、业务冲正和人工确认。

因此，这类操作需要统一的 Workflow Operation Service，负责权限判断、目标计算、执行树调整、多实例同步、变量策略、副作用补偿和审计，而不是散落在各业务系统中的临时代码。

四、表单与门户：从 formKey 到统一工作入口

1. 表单不只是一个 formKey

流程引擎通常能保存表单引用、任务变量或简单表单数据。中国式低代码工作流需要的是“表单全生命周期”：

• 拖拽式表单设计、组件协议和数据模型；
• 表单版本与流程版本绑定；
• 发起、审批、抄送、查看等场景的字段可见、可编辑、必填规则；
• 节点按钮权限和操作原因校验；
• 主子表、附件、图片、电子签名、打印模板；
• 字段级脱敏、行级数据权限和跨租户隔离；
• 业务校验、联动计算、字典和远程数据源；
• 草稿、暂存、自动保存和移动端适配。

Camunda Forms 能设计表单并与 User Task 或 Start Event 关联，Tasklist 可以渲染办理；Flowable 也提供 FormService 和表单相关能力。这些是很好的起点，但企业常用的字段权限、数据权限、复杂组件、打印和业务对象绑定，仍然是低代码平台的职责。

表单与流程不能只靠 processVariable 粘合。建议建立独立的 Business Data ID，流程保存稳定引用和必要快照；大对象、附件和高频业务数据留在业务库或内容服务中。

2. 任务列表不等于统一工作门户

开源或商业组件中的基础 Tasklist 已经能展示候选任务、个人任务、优先级、到期时间和表单。企业用户期待的却是统一工作入口：

• 我的待办、已办、发起、抄送、草稿和委托；
• 来自多个流程引擎、业务系统和租户的统一任务；
• 按组织、业务类型、紧急程度、SLA 和标签筛选；
• 批量审批、快捷意见、转办、催办和关注；
• 流程图、时间线、意见、附件和业务表单在同一页面；
• PC、H5、uniAPP、小程序和原生 App 一致办理；
• 钉钉、企业微信、短信、邮件和站内信通知；
• 单点登录、深链接、消息回执和已读状态。

图 2：统一待办、表单、组织权限和消息不是引擎内部模块，而是围绕引擎建设的平台服务。

如果每个业务系统直接查询引擎任务表并各做一套待办页，几年后会出现字段不一致、权限分散、消息重复、查询缓慢和升级困难。更稳妥的做法是通过任务事件或标准 API 建立统一任务中心，由门户消费平台任务模型，而不是绑定某个引擎的内部表结构。

五、消息与治理：决定平台能否长期运行

1. 消息、催办与 SLA 是独立产品

Timer Event 能在指定时间触发，并不自动形成企业可用的催办系统。完整 SLA 至少需要：

• 自然日、工作日、节假日和不同地区日历；
• 首次提醒、重复提醒、升级提醒和超时动作；
• 节点 SLA、流程 SLA 和业务优先级；
• 暂停、挂起、转办后是否重新计时；
• 消息渠道、模板、语言、频控和失败重试；
• 通知去重、已读回执和送达状态；
• 负责人、主管和管理员的升级链路；
• 超时统计、排行榜和过程改进报表。

建议引擎 Timer 负责可靠时间触发，平台 SLA Service 负责业务时间计算和策略，Notification Service 负责渠道、模板、重试和回执。把所有逻辑写进 TaskListener，会让模型难以阅读，消息也难以统一治理。

2. 审计、版本和运维决定能否长期运行

流程跑通只是上线起点。企业平台还要处理：

治理领域	需要的平台能力
模型治理	目录、权限、草稿、评审、发布、回滚、差异比较
实例治理	挂起、恢复、终止、迁移、异常修复、批量操作
作业运维	失败作业、重试、死信、告警、吞吐和积压
审计	谁在何时以什么理由执行了什么操作
数据治理	历史保留、归档、脱敏、删除和合规导出
版本治理	表单、规则、组织快照、集成配置与流程版本绑定
多租户	模型、实例、任务、数据、消息和运维权限隔离
可观测性	指标、日志、追踪、业务耗时和瓶颈分析

Flowable、Camunda 等已经提供历史、管理和部分迁移或运维基础，但平台仍要将技术 API 变成安全、可解释的管理产品。尤其是运行中实例迁移，必须评估活动映射、变量、事件订阅、作业和子流程，而不是把所有实例直接指向新版本。

六、到底还差多少：一份 50 项能力清单

可以用下面的工程口径做初步盘点：

能力域	常见能力项数量	引擎直接或薄封装	主要平台建设内容
模型与执行	8	6	发布治理、静态检查
任务与人员	8	3	组织解析、代理、空人策略
会签与审批操作	10	3	退回、加签、撤回、跳转
表单与数据权限	8	2	设计器、字段权限、数据范围
门户与移动协同	6	1	统一待办、移动端、IM
消息与 SLA	4	1	日历、模板、升级、回执
治理与运维	6	2	审计、迁移、监控、归档
合计	50	18	约 32 项需要平台化建设

这张表不是对某个版本的绝对评分。Camunda 8 完整产品、Flowable 商业平台或成熟国产平台可能已经提供其中大量能力；纯开源引擎或只嵌入一个 JAR 包的项目，差距则会更大。

更重要的是，能力项数量与研发难度不成正比。引擎已经解决了最复杂的执行一致性；平台剩余功能看似都是“页面和接口”，但涉及权限、审计、复杂状态和长期产品维护，同样不能低估。

七、哪些功能应该二开，哪些应该独立建设

建议按稳定边界拆分：

1. 适合做引擎适配或扩展

• 统一部署、启动、查询、任务完成与变量 API；
• 多实例会签策略与审批结果聚合；
• 受控状态变更和运行时操作适配；
• 任务、实例、作业和历史事件发布；
• 引擎异常到平台错误码的映射；
• 目标引擎特有的监听器、Worker 和扩展属性。

2. 适合做独立平台服务

• 组织与审批人解析；
• 表单、字段权限、按钮权限和数据权限；
• 统一任务中心和门户；
• 通知、催办、工作日历与 SLA；
• 审计、评论、附件和电子签名；
• 模型资产、版本治理、发布审批；
• 监控、报表、归档和多租户治理。

独立服务不应直接更新 ACT_RU_、FLW_ 或其他引擎内部表。引擎升级时，内部结构可能变化；通过公开 API、扩展点和事件同步，才能保留替换引擎和演进架构的可能。

八、一条现实的建设路线

图 3：先做可控审批闭环，再统一平台服务，最后建设治理与规模化能力。时间取决于团队、存量系统和行业要求。

1. 第一阶段：可控审批闭环

目标是让典型串行、条件、会签流程安全上线。完成 BPMN 设计、组织解析、表单绑定、待办已办、同意拒绝、基础退回、消息和审计。暂时限制自由跳转、复杂并行回退和动态子流程。

2. 第二阶段：平台化复用

建设统一任务中心、审批操作服务、表单权限、SLA、消息渠道、移动端和流程事件中心。形成引擎适配 SPI，使业务应用不直接依赖 Flowable 或 Camunda 数据结构。

3. 第三阶段：治理与规模化

补齐模型发布审批、差异、迁移、批量运维、多租户、归档、可观测性和流程分析。把线上异常沉淀为模型检查规则和自动化测试。

成熟团队可以并行推进，但不要在第一阶段就承诺“任意节点自由回退、任意并行结构都可撤销”。先定义受支持的模型子集，远比做一个行为不可预测的万能按钮可靠。

九、低代码平台应该怎样定位

云程低代码开发平台可以把开源引擎作为可替换的执行内核，把真正可复用的价值放在上层：

• 用 BPMN.js 和仿钉钉设计器服务不同建模人群；
• 用统一 Approval Policy 表达会签、退回、加签和空审批人策略；
• 用组织解析服务连接部门、岗位、角色和项目组织；
• 用表单引擎统一字段、按钮与数据权限；
• 用任务中心向门户、uniAPP、钉钉和企业微信提供一致待办；
• 用审计与运维中心管理版本、实例、作业和异常。

这样既能继承 Flowable 等开源项目的执行可靠性，又避免把平台核心能力锁死在某个引擎的内部 API 和数据库表中。

十、结语与参考资料

1. 如果只记住七件事

1. 开源流程引擎解决的是执行内核，不是完整 OA；
2. assignee 和 group 只是组织审批规则的起点；
3. 多实例能实现会签骨架，但票数、意见和动态人员属于平台语义；
4. 退回、加签、跳转、撤回必须同时处理执行树、变量、作业和副作用；
5. formKey 与 Tasklist 不能替代企业表单和统一门户；
6. 消息、SLA、审计、迁移和运维应建设为独立平台能力；
7. 最合理的路线是保留成熟引擎内核，在上层形成稳定的中国式工作流产品。