维护过审批系统的人应该都有同感流程引擎这东西用顺了就像个靠谱的管家什么任务该找谁、什么条件下往哪走你交代一遍它就照着执行。可问题是这位管家只会听人话之外的条件表达式。业务方突然跟你说你看这段申请理由这么写是不是该走加急通道你就得重新去改BPMN、加判断逻辑、甚至为一种新情况单独配一个网关分支。我最近半年一直在折腾一件事把AI接到Flowable的决策节点上让流程引擎继续管状态让大模型来管这句话到底什么意思这个单子该不该加急。这篇文章就把这套思路从设计到落地完整拆一遍适合正在用Flowable做审批、工单、合同类系统又想引入AI能力的开发者也适合刚入门工作流的同学理解这个方向到底在往哪走。1. 先搞清楚Flowable到底解决了什么问题1.1 从一张BPMN图看Flowable的决策模型Flowable是基于BPMN 2.0规范的开源工作流引擎核心能力是把业务流程画出来、跑起来、盯得住。你可以在流程设计器里画好一张图里面包含开始事件、用户任务、服务任务、网关、结束事件然后用Flowable引擎去解析、实例化、推进这些节点。传统流程决策主要依靠三种手段条件流表达式在排他网关Exclusive Gateway上写表达式比如${amount 5000}根据流程变量的值决定走向。决策表Flowable集成DMN规范可以用Decision Table维护规则适合多条件组合判断。事件监听器和JavaDelegate在节点进入、离开时执行自定义逻辑用代码做判断。这套体系最大的价值是确定性。规则写死了任何一笔流程在相同条件下都会走到相同的分支审计时能说清楚为什么这么走。但确定性也带来了僵化。1.2 传统流程决策的四个痛点第一个痛点是规则写死之后不好改。一个排他网关的条件表达式就是一小段EL表达式看起来简单。但真实业务里判断这个工单是否紧急可能需要结合申请描述、客户等级、历史处理时长、当前资源负载。这些逻辑没法在表达式里写完只能堆Java代码改一次就要重新发版。第二个痛点是引擎无法理解非结构化信息。审批单里有一大段申请理由传统的流程引擎只会把它当一个字符串变量。它不会判断因为客户明天要签约所以必须今天审批完这句话里的紧急含义也不会从合同文本里抽出付款方式。过去这些只能靠人看、靠人判断。第三个痛点是缺乏自我进化能力。流程跑了一年后历史数据里其实藏着大量规律什么样的工单更可能超时、什么样的申请更容易被驳回、哪类驳回其实可以自动处理。但传统引擎不会学习这些规律只能靠运营同事手工统计后再去改流程规则。第四个痛点是异常场景处理成本高。流程卡住、审批人长期未处理、条件分支没有任何一个满足这些情况一旦出现基本就是人工介入而且介入后怎么处理也没有一个标准推荐完全依赖管理员经验。这些痛点在流程量小的时候不显眼一旦流程成为核心系统的主动脉每天几千几万个实例在跑问题就会放大成运维事故和业务投诉。这也是我把AI引进来最初的原因。2. AI不是在替换流程引擎而是给引擎装了一个决策大脑2.1 接入AI的四种主流模式把AI接进工作流业界现在还没有一个标准答案但实际落地大概可以分成四种模式。模式A是AI当规则计算器。流程的结构不变还是排他网关加条件流只是网关前的AI服务节点负责把非结构化输入转成结构化判断。比如工单描述是一段长文本AI节点读取这段文本理解语义后输出一个JSON{priority:high, category:network}然后把它写入流程变量。网关再根据这些变量分流。这种模式改造量最小是我个人最推荐起步的方式。模式B是AI Agent动态规划流程路径。流程结构不提前画死让Agent根据目标自己决定要执行哪些步骤。比如一个售前方案评审流程传统做法是固定写死需求确认→方案编制→技术评审→商务评审→签批。但AI Agent可以读当前需求复杂度简单需求直接跳过技术评审复杂需求额外增加一次架构评审。这种模式听起来炫但对案例管理和审计要求很高落地时要非常谨慎。模式C是AI作为流程辅助者。AI不直接决定流程走向而是在每个节点帮人更高效地干活。比如自动填充表单、根据历史审批意见生成草拟意见、把合同附件里的关键条款抽取出来给审批人做摘要。这类应用不涉及决策权的转移阻力最小人也愿意用。模式D是AI作为流程优化器。离线分析流程日志识别瓶颈节点、预测超时风险、建议流程改造点。比如发现某个节点平均处理时间是72小时AI分析发现其中90%的等待是因为缺少一个附件于是建议把附件上传提前到提交节点。这种模式需要流程数据仓库和建模能力见效周期更长。2.2 引擎管状态模型管判断这里要特别强调一个观点AI接入流程不等于把BPMN引擎扔掉。很多人一听智能流程决策就以为未来流程图不用画了大模型全包了。这个理解很危险。流程引擎真正的价值是管理状态一个流程实例现在在哪个节点、下一步该由谁处理、已经等了多少天、所有操作有没有留痕、出问题能不能回滚。这些能力是AI模型给不了的。大模型没有事务的概念也没有强制状态机的保证你不可能让它维护一百万个流程实例的一致性。所以合理的方式是分工Flowable管理确定性、状态、权限、审计、超时、重试AI管理非确定性、语义理解、推荐、预测、异常提取。用一句话概括就是引擎管状态模型管判断。这个边界划清楚之后系统设计就简单了流程图还是画的网关还是排他网关只是在关键节点上多挂了一个AI服务它像一个参谋把我的判断是输出来流程引擎再决定那就往这走。3. 实战Spring Boot里搭一个Flowable AI决策链路3.1 工程依赖和初始化先搭一个Spring Boot工程版本选2.7或3.x都行但注意Flowable和Spring Boot版本要匹配。我用的是Spring Boot 3.2和Flowable 7.0。核心依赖如下dependency groupIdorg.flowable/groupId artifactIdflowable-spring-boot-starter-process/artifactId version7.0.0/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-alibaba-starter/artifactId version1.0.0-M6.1/version /dependencyFlowable的starter会自动建好它需要的表默认前缀是ACT_包括流程定义、运行实例、历史数据、定时任务等。如果不想和业务表混在一起可以在配置里指定表前缀和数据库隔离spring: datasource: url: jdbc:mysql://localhost:3306/flowable_ai?useSSLfalseserverTimezoneAsia/Shanghai username: root password: root flowable: database-schema-update: true async-executor-activate: true history-level: full这里三个配置要重点说database-schema-update填true方便开发阶段自动建表生产环境建议改成false后手动执行升级脚本async-executor-activate打开异步执行器后面AI调用和异步消息都用得到history-level除非性能扛不住否则建议用full因为AI优化流程日志时需要完整历史数据。3.2 设计一个带AI决策节点的BPMN流程我用一个售前方案审批流程做例子。业务逻辑是销售提交方案申请系统自动判断加急还是普通加急走快速审批通道普通走标准审批通道。传统写法是在网关里写条件由提交人手动选择或靠一堆字段拼接。现在我改成AI判断。流程节点如下开始事件销售提交方案申请表单包含客户名称、方案描述、预算金额。服务任务AI决策节点读取方案描述和预算调用大模型输出紧急程度、方案分类、风险提示。排他网关根据aiDecision.urgent的值分流。加急审批任务由部门总监处理。普通审批任务由部门经理处理。结束事件。BPMN XML关键片段如下注意AI判断节点是一个serviceTask委托类指向自定义的AiDecisionDelegateprocess idsolutionApproval name售前方案审批流程 isExecutabletrue startEvent idstartEvent/ serviceTask idaiDecisionTask nameAI决策节点 activiti:delegateExpression${aiDecisionDelegate}/ exclusiveGateway idurgencyGateway/ userTask idurgentApprovalTask name加急审批 activiti:assigneedirector/ userTask idnormalApprovalTask name普通审批 activiti:assigneemanager/ endEvent idendEvent/ sequenceFlow idflow1 sourceRefstartEvent targetRefaiDecisionTask/ sequenceFlow idflow2 sourceRefaiDecisionTask targetRefurgencyGateway/ sequenceFlow idflow3 sourceRefurgencyGateway targetRefurgentApprovalTask conditionExpression xsi:typetFormalExpression ![CDATA[${aiDecision.urgent true}]] /conditionExpression /sequenceFlow sequenceFlow idflow4 sourceRefurgencyGateway targetRefnormalApprovalTask conditionExpression xsi:typetFormalExpression ![CDATA[${aiDecision.urgent false}]] /conditionExpression /sequenceFlow /process担心aiDecision变量没有值导致网关报错的可以在流程图里给网关加默认流。排他网关最好总有一条兜底路径杜绝条件都不满足、流程卡死的情况。这个习惯救了我好几次。3.3 实现调用AI的JavaDelegate接下来写AiDecisionDelegate。它要做的事情有三个取出流程变量、组装Prompt、调用大模型、解析返回结果、写回流程变量。Component(aiDecisionDelegate) public class AiDecisionDelegate implements JavaDelegate { private static final ObjectMapper MAPPER new ObjectMapper(); Resource private ChatClient chatClient; Override public void execute(DelegateExecution execution) { String proposalDesc (String) execution.getVariable(proposalDesc); BigDecimal budget (BigDecimal) execution.getVariable(budget); String prompt 你是一个流程决策助手。请根据以下售前方案信息判断该方案是否紧急。 紧急标准客户明确表达时间紧迫、存在签约风险、金额超过100万或在重要行业有战略意义。 方案描述%s 预算金额%s 只输出JSON格式{urgent: 布尔值, reason: 判断理由, confidence: 0到1的数值} .formatted(proposalDesc, budget); String modelResponse chatClient.call(prompt); JsonNode decision; try { decision MAPPER.readTree(modelResponse); } catch (JsonProcessingException e) { throw new BpmnError(AI_RESPONSE_PARSE_ERROR, AI返回无法解析转到人工处理); } boolean urgent decision.path(urgent).asBoolean(false); double confidence decision.path(confidence).asDouble(0.0); execution.setVariable(aiDecision, Map.of( urgent, urgent, reason, decision.path(reason).asText(), confidence, confidence, rawResponse, modelResponse )); if (confidence 0.6) { // 置信度不够不直接用AI结果转人工定夺 execution.setVariable(aiDecision.urgent, false); execution.setVariable(aiDecision.needManualReview, true); } } }这里有一个非常关键的细节我只把urgent、reason、confidence这种结构化小字段写进流程变量没有把大模型的完整返回文本塞进变量。后面5.3会专门说为什么这里先记住流程变量要瘦身。chatClient这里用的是Spring AI Alibaba的接口实际会走HTTP调用本地或云端模型服务。如果你不想依赖Spring AI直接注入一个RestTemplate调OpenAI兼容接口也行逻辑是一样的。区别只是Spring AI帮你封装了Prompt模板、输出解析、工具调用省事很多。3.4 通过CommandExecutor做AI调用的统一埋点与拦截Flowable内部所有命令都经过CommandExecutor它的职责是执行命令并支持拦截器链。这个机制非常适合做统一埋点。比如我想统计每次AI决策节点消耗了多少时间、模型返回是否超时、网关决断结果是什么我不需要改业务代码只要加一个CommandInterceptor。Component public class AiTracingInterceptor extends AbstractCommandInterceptor { private static final Logger log LoggerFactory.getLogger(AiTracingInterceptor.class); Override public T T execute(CommandConfig config, CommandT command) { long start System.currentTimeMillis(); try { return next.execute(config, command); } finally { long cost System.currentTimeMillis() - start; if (command instanceof ExecuteActivityCmd || command instanceof TriggerableActivityBehaviorCmd) { log.info(flowable command [{}] cost [{}]ms, command.getClass().getSimpleName(), cost); } } } }然后在配置里把它挂到CommandExecutor上。这样每次执行活动节点、推动流程时我都能看到AI服务任务在整个命令链条里占用了多少时间。这个数据对排查性能问题极其有用。3.5 事件监听与人工兜底AI不是神总有判断不靠谱的时候。设计里我留了双保险置信度低于0.6的决策不进自动分支直接给人工生成一个复核任务。实现方式有两种。一种是在JavaDelegate里用RuntimeService动态创建用户任务另一种是提前在BPMN图里画好一个人工复核节点用条件流把低置信度的情况引过去。我倾向第二种因为流程模型里看得见业务方也更容易理解。同时可以注册GlobalEventListener监听任务创建事件把AI判断的理由和历史审批人处理时长一起推给当前审批人帮助人快速决策。这块本质上就是AI辅助人审落地阻力小。4. 哪些流程决策可以交给AI哪些必须留给人4.1 适合AI的决策点信息理解、推荐、文本生成AI真正的强项是语义理解、知识综合和模式识别。具体到流程场景最适合AI介入的是以下几类工单自动分类与定级。一段故障描述进来AI判断影响范围、紧急程度、对应处理团队。这个场景几乎是标配落地快、价值明显。审批意见摘要与会签推荐。一个合同审批节点积压了几十条历史意见AI把意见按技术可行、商务风险、法务关注分类摘要再给出会签人员推荐。自然语言申请理由的风险识别。比如报销单里写了与客户聚餐AI可以结合票据描述判断是否触及合规红线提醒审批人重点核实但不直接拒绝。方案文档摘要生成。把几十页技术方案压缩成审批人需要的三大段做什么、怎么落地、风险有哪些。这属于文本生成类能显著降低审批人的阅读负担。流程日志的瓶颈分析。离线跑不是在线决策用AI聚类分析历史数据发现哪个环节最拖时间。这些场景有一个共同点判断标准不唯一、信息里含有大量非结构化内容、结果不需要100%正确、人做最终兜底。4.2 不适合AI的决策点强规则、合规、权限、金额上限反过来有些决策是绝对不能交给大模型的。比如权限判断。一个用户能不能看到某个流程的数据这必须基于RBAC/ABAC的确定性规则不能用AI猜这个用户应该能看猜错就是数据泄露。硬性金额阈值。超过50万必须走集中采购这一条是铁的。哪怕AI判断这笔采购有战略价值、建议豁免流程也不能自动豁免。模型输出只能作为参考不能覆盖制度底线。合规与审计强相关判断。哪些单据必须留存、哪些环节必须签字这些要严格按制度走不允许模型发挥。需要追责的决策。出了安全事故、资金损失审计要问谁、在什么时候、基于什么规则做了这个决定这种情况下模型的概率式决策会变成追责黑洞。我见过一个反面案例某团队把是否通过预算审批交给大模型判断理由是模型能理解业务上下文。结果有一次模型输出了一段流畅但完全虚构的审批通过理由要不是有金额上限规则兜底就会造成一笔大额支出。这个案例之后团队立了个规矩AI只可建议不可直接做资金和权限类决策。4.3 设计置信度 人工复查的双通道机制既然AI不能完全独立决策那就需要一个机制来平衡效率和风险。我的做法是给AI决策加一个置信度通道。if (confidence 0.9) { // 自动决策直接按AI判断走分支 } else if (confidence 0.6) { // 半自动按AI判断走但通知业务负责人可干预 } else { // 转人工复核暂停自动流转生成人工复核任务 }阈值怎么定建议先在历史数据上回放把过去一年已完成的流程拿出来让AI重新判断一遍对比原结果。看AI在哪个阈值区间准确率最高、误判率可接受。不要拍脑袋设0.6不同业务差别很大。双通道机制里还要考虑超时降级AI服务调用超过3秒直接切换成规则引擎的旧逻辑或者转人工。降级方案在流程序列化设计里必须提前预留不能等线上出问题再补。5. 常见问题与排查技巧实录5.1 AI调用超时把整个流程事务拖垮这是接入AI后最容易踩的坑。Flowable的流程推进默认在同一个事务里如果JavaDelegate里同步调用大模型接口而模型响应要15秒这个事务就锁着流程序实例15秒。并发一高数据库连接池就满了整个工作流引擎都跟着卡死。解决思路是把AI调用改异步。有几种做法用Flowable的异步执行器把服务任务配置为asynctrue让引擎把任务丢给异步线程池处理或者自己用Async把AI调用扔出事务线程再或者把AI调用前置到流程发起阶段在网关判断前就把结果算好存到扩展表里。我个人用的方案是Flowable异步执行器加消息队列双保险。关键业务场景下AI决策节点异步跑跑完回调推进流程。这样对主链路的影响最小。5.2 大模型返回的JSON不稳定大模型返回结构不稳定是常态尤其模型版本更新后。一个看起来人畜无害的只输出JSON模型有时候会给你多带一段解释或者把布尔值输出成字符串true。处理策略有两个层面。第一层是生成侧约束用Spring AI的withResponseSchema或者模型的response_format: json_object把返回格式固定死。第二层是消费侧容错解析JSON前先做清洗去掉json标记、截取第一个{到最后一个}的子串、布尔值字符串归一化。我甚至见过模型把confidence返回成0到100之间的整数解析时要做归一化处理否则置信度判断直接失效。5.3 流程变量塞大对象导致历史表膨胀刚开始做这个项目时我把AI返回的完整JSON、甚至把合同全文都塞进了流程变量运行一个月后ACT_HI_VARINST表膨胀到几十GB查询历史流程越来越慢。后来总结出三条规矩流程变量只放结构化判断结果和必要业务主键大文本存业务表或对象存储流程里只存文件ID。AI产生的rawResponse最多截断保存而且放在单独的日志表不进流程变量。历史数据定期归档ACT_HI_*表按时间分区超过半年的数据迁移到历史库。5.4 低代码平台集成Flowable时的依赖冲突有人在Jeecg这类低代码平台里集成Flowable会碰到mybatis版本冲突、jackson版本冲突甚至spring-security配置互相覆盖。我的建议是尽量让Flowable独立部署成一个流程服务通过接口对外提供能力不要和业务单体强耦合。如果一定要集成在同一个JVM里就注意Flowable自带持久层尽量排除掉自己业务里的MyBatis包避免类加载冲突。5.5 模型服务挂了如何优雅降级最后说降级。模型服务不可能100%可用企业私有化部署尤其容易因为显卡驱动、模型显存溢出而挂掉。在JavaDelegate里AI调用必须包上熔断逻辑。我的做法是try { decision callAiModel(prompt); } catch (Exception e) { // 降级到规则引擎 decision ruleBasedDecision(proposalDesc, budget); execution.setVariable(aiDecision.fallback, true); execution.setVariable(aiDecision.fallbackReason, e.getMessage()); }降级逻辑会写一个标记审批人在任务页能看到当前决策由规则引擎生成AI服务不可用这样即使判断比AI粗糙一些人也有知情权。生产环境我还会加一个健康检查任务模型服务恢复后自动把降级标记关闭。6. 结合最近的实践再说几句如果你准备在项目里引入这套Flowable AI的组合我的建议是先别追求Agent式的动态流程编排那一步的复杂度和风险太高。先从AI判断一个条件、网关根据判断走分支开始把调用链路、超时降级、置信度通道、审计日志跑成熟再逐步扩展到AI生成摘要、AI推荐审批人、AI分析流程瓶颈。踩了这些坑之后我最大的体会是AI和流程引擎之间的关系不是替代而是互补。流程引擎给了AI一个可以信任的执行框架AI给了流程引擎一双能看懂真实世界的眼睛。只有把确定性和非确定性放在一个可控的系统里智能决策才能真正从Demo走到生产环境给业务带来实际价值。