背景：审批需求永远在变
FDP 中台的业务复杂度高，审批和表单几乎每个季度都在变：会签、加签、驳回、转办、按金额分支、跨部门审批。早期用状态机硬编码，每改一次就要发版，测试成本越来越高。
引擎化不是把审批画成一张图，而是把“定义”和“执行”分开：定义可以配置、可以版本化；执行必须稳定、幂等、可审计。
核心难点
- 已发布流程不能变，运行中的实例必须绑定启动时的版本。
- 会签、或签、加签、驳回、撤回等动作要能组合，且状态迁移合法。
- 表单 Schema 与流程定义解耦，字段权限与数据权限分离。
- 跨服务动作要可补偿，重复点击和重复消息不能推进两次流程。
方案：元数据、执行、权限三层
1. 元数据
流程定义、表单 Schema、权限模型、运行时实例、历史审计五类对象分开建模。流程定义发布后不可变，按版本号管理；实例记录启动时的定义版本和表单版本，老实例继续走老版本。
2. 执行引擎
采用任务 + 令牌模型：节点生成待办任务，任务完成推进令牌，网关按条件选分支。任务完成用 taskId + version 做乐观锁，消息消费记录去重键，跨服务动作通过 outbox 或本地消息表保证可重试。
3. 权限与规则
功能权限、数据权限、字段权限三层分离。审批人解析器支持角色、组织、上级和表单变量组合，解析结果可解释。规则表达式运行在沙箱里，限制函数白名单、执行超时和外部 IO。
4. 嵌入与复用
引擎以 SDK 和服务两种形态嵌入 FDP 及其他业务系统：简单场景直接引用组件，复杂场景走独立服务。统一网关负责鉴权、日志和限流，避免每个接入方重复实现。
结果
6 年演进从独立引擎到中台能力
多业务复用表单与流程嵌入不同系统
版本化定义发布后不可变，实例绑定版本
完成了独立版本的审批流引擎与表单设计器，并嵌入 FDP 底层服务；多个业务系统复用同一套流程能力，常规审批变化从“改代码发版”变成“改配置发布”。引擎的版本、权限和幂等边界也在真实业务里被反复验证。
复盘
流程引擎的价值不在于节点类型多，而在于边界清楚：定义与实例分离、表单与流程解耦、版本不可变、动作可幂等、权限可解释。把这五件事做对，配置化才是资产。