Spring AI赋能Flowable：自然语言驱动的流程引擎智能改造

让我们先用一张图在脑子里立住BPMN流程图上的每个节点本质上是系统能理解的确定性规则而大模型擅长的恰恰是人类用一段话描述的模糊意图。把这两者接到一起让自然语言直接驱动流程引擎运转这就是我最近在做面向flowable的Spring AI这件事的核心目标。这篇文章不是讲怎么把大模型包成一个聊天机器人塞进系统里而是讲一条更务实的路把Spring AI作为模型能力适配层嵌入flowable流程引擎的模型部署、任务流转、条件判断、监听器、历史审计这几个关键环节让流程既能保留BPMN原有的确定性又具备理解模糊指令并转成流程行为的能力。如果你是做Java后端、正在搞工作流平台或者被业务方那句能不能让审批流智能一点逼到墙角这篇内容应该能给你一套能直接照着落地的方案。1. 为什么说这是一次给老引擎插上新传感器的改造先把调子定下来flowable和Spring AI不是同层的东西两者也不存在替代关系。flowable是流程引擎负责把BPMN定义变成可执行的过程实例、任务列表、审批路由Spring AI是模型接入框架负责把国内外的各种大模型封装成统一的接口、管理对话记忆、做RAG和工具调用。它们的关系更像是生产流水线和加装在产线上的智能质检仪——流水线不会因为加了质检仪就变成另一条流水线但整条线的产出质量、异常感知能力和换型速度都会上一个台阶。1.1 flowable到底在解决什么问题接触过flowable的人应该都知道它的核心资产是BPMN 2.0模型。一个流程定义文件里包含开始事件、用户任务、服务任务、排他网关、条件表达式、边界事件等元素引擎启动进程实例后任务按照定义好的顺序和条件不断流转。这套机制的好处是严谨每个节点的状态明确、审批人明确、跳转条件明确出问题可以追溯审计合规有据可查。但它也有很明显的短板业务方需要一次新流程往往得先整理需求文档、画流程图、定义表单、配置审批人、写网关条件这一串动作下来周期以周计。更麻烦的是流程跑起来之后条件判断写在XML里业务方想调整审批额度阈值必须改流程定义重新部署。这是flowable从诞生起就存在的重模型、轻交互问题不是它不好而是设计定位决定了的——它假定使用者已经拥有了结构化的需求。1.2 Spring AI在java生态里到底挑了什么担子Spring AI这个项目经历了好几个阶段早期大家关注的是它能把OpenAI、通义、Ollama、Azure OpenAI等模型统一成一套ChatClient接口后来随着Spring AI Alibaba的加入出现了更多本土化的组件比如通义模型接入、NL2SQL和Agent能力Spring AI 2.0里更是把ChatClient的API打磨得非常好用。它解决的问题很具体不用每个模型写一套SDK适配、不用自己维护对话上下文、能统一处理流式输出、能嵌入RAG管道。放到面向flowable的Spring AI这个场景里Spring AI的角色是模型的抽象层和任务编排层。flowable只管自己的流程流转至于把用户一句话转换成流程参数分析当前待办应该推给谁根据历史审批数据给决策建议这些逻辑可以不写在flowable内部而是由Spring AI的Advisor、ChatClient、RAG管道来实现。这种松耦合保留了流程引擎的纯正性。1.3 两者结合的价值不是自动审批而是意图到规则的翻译我评估一个AI流程功能值不值得做真正的标准其实是这个需求是不是把人的模糊意图翻译成流程能执行的规则。比如业务方说超标的单子不要直接转给总经理了先走个风险评估这句话要翻译成网关条件、服务任务、审批人策略的组合——用大模型去理解门控条件并把它们映射到流程变量上这就是对应的传感器。而自动审批这类直接让AI替代人工决策的功能风险大、责任不清晰很难落地我之前尝试过不少最终都退回到AI给建议、人工做决定的模式。2. 对接Spring AI之前先把flowable的扩展点盘清楚很多人在做这个方向时踏进了一个坑一上来就纠结该在哪个环节调用大模型然后对着流程定义无从下手。我的习惯是反着来先从flowable本身出发把引擎提供的所有能插入外部逻辑的孔位列成清单再看哪个孔位适合接AI。2.1 流程模型部署期改写BPMN能力部署流程定义时flowable的BpmnXMLConverter和自定义命令拦截器可以在部署前对XML做处理。比如解析出每个节点后自动补充描述文本、生成可读的中文节点名、帮用户修正缺失的默认事件定义。接入Spring AI后可以让模型读取一段用户描述直接生成一份合法BPMN XML草稿。我们做过实验模型生成的XML大多数情况下可以解析但Gateway条件表达式、SequenceFlow的id引用经常出错因此需要一个校验器加人工确认环节不能直接把模型输出当成品部署。2.2 任务流转期RuntimeService与TaskService是关键切入点流程实例启动、任务完成、任务认领这些动作都会经过RuntimeService和TaskService。比如在启动流程实例前拦截用户输入的自然语言描述由AI提取流程Key、业务参数、发起人、期望审批人再调用runtimeService.startProcessInstanceByKey。这里涉及一个关键的API设计AI提取结果必须稳定输出成JSON结构如果你用Spring AI可以让ChatClient的实体输出能力直接映射成一个StartProcessRequest记录再用ObjectProvider做二次校验。2.3 任务监听器和执行监听器流里的挂钩点flowable监听器是接入AI非常自然的位置。ExecutionListener可以挂在流程开始、结束、流向节点等处TaskListener可以挂在任务创建、分配、完成等处。我们实际用的比较多的是TaskListener中的create事件任务创建后调用Spring AI给任务生成一个预审摘要包括这个任务是什么、关联的流程背景、可能的处理倾向以及Assignee变更前的判定提示。这里要注意监听器是同步阻塞的大模型调用如果太慢会卡住事务我们实际项目中在监听器里只发一个异步指令让AI结果稍后通过回调落库。2.4 条件表达式与脚本任务该不该让AI参与判断flowable的排他网关和条件事件依赖表达式引擎常见的是Spring EL和UEL。如果让AI直接参与条件判断比如根据用户输入动态决定走哪条分支有两个实现思路一是AI先提取流程变量再由表达式引擎判断这是安全的二是AI直接输出分支编号这条风险很大因为不可解释。我推荐只做变量提取不做最终判断。这个边界不守住排查流程Bug会非常痛苦。2.5 历史数据层从审计表到知识库flowable自带history表里面存了流程实例、任务节点、耗时、操作人、审批意见等。这部分数据是天然的业务过程语料做RAG时喂给模型可以回答类似这个订单为什么走了那么久哪个环节阻塞最多这样的问题。Spring AI Alibaba有NL2SQL能力可以让自然语言变成SQL去查这些表。不过流程表结构复杂多租户还要拼租户ID需要把SQL生成限制在预设的视图范围里不能放开让它直连底表。3. 四个实测能落地的AI流程玩法有了扩展点接下来是功能层面的设计。我挑四个自己实际做过、且稳定性被验证过的玩法展开每个都包含实现方案和部分核心代码方便直接参考。3.1 自然语言发起流程从一句话到已启动业务痛点很常见发起人不想在几十个流程模板里翻找也不想研究表单字段。我们的做法是做一个一句话发起入口用户直接输入我要申请一台MacBook Pro价格两万三用于前端开发后端接住这个请求后走三步调用Spring AI的ChatClient用少量示例告诉模型流程列表里有资产采购申请流程-ASSET_BUY和普通报销流程-EXPENSE并规定输出JSON包含processKey和paramMap。用Spring AI的实体映射能力直接转成StartProcessParam再做一次数值校验。调用runtimeService.startProcessInstanceByKey并把用户原句存到流程变量里供后续节点查。核心代码类似这样String statement 我要申请一台MacBook Pro价格两万三用于前端开发; ProcessStartRequest req chatClient.prompt() .system(systemPrompt()) // 包含流程列表与JSON格式约定 .user(statement) .call() .entity(ProcessStartRequest.class); if (req.processKey() null || !valid(req)) { throw new BizException(AI未能明确识别流程类型请补充金额或用途关键词); } runtimeService.createProcessInstanceBuilder() .processDefinitionKey(req.processKey()) .variable(originStatement, statement) .variables(req.params()) .start();这里的工程经验一定要给模型一个无法识别时可抛出的兜底渠道否则模型会在流程Key里瞎编一个值。我们最后的兜底是启用一个人工建单流程AI不确定时转人工填写而不是直接报错。实测情况是业务方其实更接受AI拿不准就转人工这个行为毕竟可靠性在内部系统里很重要。3.2 AI辅助流程建模从口述需求到BPMN草图这个玩法我投入的精力最大。我们自己团队在做流程编排时经常要接收业务方几百字的流程描述包含技术评审不过就打回重新填写财务二审超过三天的要抄送部门总监这类嵌套规则。人工画图漏规则是常事所以让AI先生成草稿再让实施人员在校验器里修正是减负比较明显的路径。实现上我们分两个阶段解析描述抽取要素。让AI把过程转成JSON树包含任务节点、网关、条件、事件。渲染成BPMN XML。在这个阶段用thymeleaf之类模板引擎把JSON树渲染成标准BPMN XML再交给flowable解析。要注意的是现阶段的模型对BPMN语法的记忆有偏差尤其容易漏掉sequenceFlow的sourceRef和targetRef导致生成的XML语义有残缺。我们的做法是自定义了一个BpmnModelValidator遍历所有节点检查是否有悬浮线对错误类型给出可读提示并且在部署前用flowable自带的BpmnXMLConverter做一次往返转换如果解析失败就返回给用户需求描述中缺少环节的流转方向让用户补充而不是默默修。3.3 待办智能摘要与审批建议不说废话的AI助手一个待办任务审批人点开之后看到的经常是表格里的字段值他要知道为什么这件事需要我批、有没有风险点得自己去翻审批历史。我们的方案是任务创建时异步调AI生成一个待办摘要存在扩展字段里。这个摘要包含流程背景、此前审批人意见、当前环节可能的审批要点。关键之处是这里用到Spring AI的Advisor能力比如用MessageChatMemoryAdvisor把当前流程实例下的历史审批意见拼接成上下文让模型生成的摘要具备连贯性。在审批人查看页面时除了摘要我们还提供一个相似历史单子的参考——用向量检索历史流程的表单数据找出提交过类似内容的单子让审批人看当时怎么批的。这个功能的工程难度不算高但业务方好评度确实非常高。3.4 监听器里的动态超时与跟进提醒flowable的边界事件配合定时器能做超时处理但超时时间如果写死在BPMN里业务方改规则就得重新部署。我们把超时时长设计为外部策略流程节点进入等待状态时触发监听器监听器把当前节点信息发送给AI服务AI根据流程类型、当前步骤、历史平均耗时等变量计算建议超时时间并更新到定时器上。这个方案在离线流程里跑得很稳。不过要提醒一点不要把AI计算超时时间的逻辑做成同步调用最好用消息队列异步化。定时器重置本身是引擎事务的一部分如果因为外部服务超时导致定时器更新失败整个流程节点状态就会异常。我们实际线上遇到过一次因HTTP调用超时导致的任务卡死之后统一改成了先落库、后回调的异步模式。4. 把历史流程变成可查询的过程经验库做AIflowable的第二个大方向不是管流程如何流转而是让流程跑完后的数据可以被AI反刍。这一节结合了Spring AI Alibaba的NL2SQL和RAG能力也是热搜里出现比较多的两个关键词说明大家的关注点都集中在让AI去理解已有数据这条线上。4.1 为什么直接依赖NL2SQL要克制很多人看到NL2SQL第一反应是让AI直接回答上个月报销单平均审批时长是多少。这个想法没问题但实现上有一层几乎必然踩的地雷流程数据结构复杂act_hi_procinst、act_hi_taskinst、act_hi_varinst跨表join关系多多租户隔离还要求每条SQL都拼租户条件。让模型直接生成SQL连库一个幻觉就会把全租户的单子查出来。我们的处理是拆三步预先定义一个白名单视图比如fin_flow_daily_summary里面已经把关键指标和租户ID字段都准备好了。让AI在给定的视图白名单内生成SQL而不是连底表。AI生成的SQL必须经过一层PostProcessor校验检查SQL里有没有跨视图、有没有重命名敏感字段再交给JdbcTemplate执行。public ListMapString, Object queryByNl(String userQuestion, String tenantId, String flowFolder) { String sql chatClient.prompt() .system(nl2sqlSystemPrompt(userViews, tenantId)) .user(userQuestion) .call() .entity(NlQueryResult.class) .sql(); SqlValidator.validate(sql, allowedViews, tenantId); return jdbcTemplate.queryForList(sql); }我们在实际使用中发现模型生成SQL的准确率大约在八成左右剩余两成的错误多半出在时间范围描述上例如最近一个月到底是对应create_time还是end_time。对应策略是尽可能把公历时间换算交给代码而非模型在传给模型之前就把用户问题里的相对时间补全成绝对时间范围。4.2 用RAG回答这个流程为什么慢NL2SQL适合回答数值类问题但业务方更常问的是为什么慢卡在哪个环节。这类问题只有数值查询是不够的因为回答平均耗时15.2天并不解决为什么。我们搭了一个简版RAG管道把每个流程实例的节点流转日志、审批意见、耗时分布生成一段自然语言摘要向量化之后存到向量库。查询时就检索出相似历史单子的摘要作为上下文让LLM用类比的方式回答新流程可能会卡在哪。这部分的工程重点是分块策略。不要把一个整流程实例的日志拆成互相没有关系的碎片我使用的是按流程实例为单位切块每块含节点链信息、审批意见、耗时区间这样检索出来的上下文才有逻辑完整性。实测中给模型这个上下文之后再回答有没有风险质量明显高于只给节点耗时数字。4.3 打通审计合规与智能问答的边界最后提一个和合规相关的点AI基于历史数据做出来的分析结论只允许作为参考不能直接写进审计表。我们项目里凡是AI生成的分析都明确标记来源为AI建议审计记录仍是flowable自带的原始信息。这块如果做反了后期合规审核会有很大的麻烦。5. Spring AI还是LangGraph4j我最终选型的原因热搜词里有一条是现在到底用spring ai 还是langgraph4j我之前在两个方向间反复横跳过这里把考量写出来供选型的人参考。5.1 先想清楚Agent到底要在此承担什么这两个技术栈的选择本质上是要不要把流程引擎换成Agent。LangGraph4j是借鉴LangGraph思路在Java生态落地的状态图框架它把节点、边、状态、条件路由做成了一套图执行引擎从能力上看和BPMN有非常多重叠。你大可以用LangGraph4j做完一套流程定义和路由但它并没有补齐flowable在审批人分配、会签、或签、历史审计、定时提醒、子流程、多租户这些业务机制上的积累。而flowable缺的是对自然语言复杂指令的理解能力——正好是Spring AI的领域。我的结论是如果我还是在一套BPMN需求明确、需要严格审批流和审计的系统中主线仍然会使用flowable同时让Spring AI充当理解层、推荐层和查询层。只有当项目本身就是纯AI编排、无固定审批链路、状态图会动态生成的实验性项目时LangGraph4j才有明显优势。面向成熟业务系统的多数场景选Spring AI给flowable增强是效率最高的路径。5.2 Spring AI 2.0带来的实际体验变化Spring AI 1.0时代最有冲击力的入口是ChatClient但API刚刚成型时也有不少别扭的地方比如工具调用要写一堆配置。2.0版本的明显变化是模型配置更收敛、工具定义更简单、结构化输出更稳定实体映射的泛型能力强了很多这对让AI返回流程参数对象的玩法是直接的利好。Spring AI Alibaba这条线也值得推进。它的NL2SQL组件、通义模型在中文流程描述上的理解能力都比较稳特别是当你的目标用户是中文业务人员通义千问这类模型对打回重新写抄送领导这类口语表达解析得比英文模型好很多。如果你有私有化部署需求Ollama加中文embedding模型也能在Spring AI体系内平滑接入扩展性比想象中好。5.3 团队基因和代码维护成本还有一个不太常被提但很重要的考虑因素团队基因。Java团队对BPMN流程、事务、数据库资源天然熟悉让他们去学LangGraph4j状态图结构反而增加心智负担。Spring AI做的是模型管道的抽象Java后端可以直接沿用Spring Boot日常的开发习惯。在当前偏保守的选型氛围下走flowable加Spring AI增强路线代码的可维护性、后期交接成本都比搞纯状态图引擎要低。这个平衡我觉得在中小团队尤其是自研平台团队里非常重要。6. 工程落地最容易被忽略的六个坑最后把这几个月踩过的坑集中做一份排查记录。老规矩不在需求层面争论AI能不能做到只说工程上怎么让AI可靠地跑在生产流程里。6.1 大模型调用延迟和流程事务的冲突flowable核心API大多在Spring事务里执行监听器、执行器内同步调用大模型会让HTTP连接占用住数据库事务延迟高一点就直接拖垮整个流程。我们最后的方案是所有模型调用都放到Spring事件监听器里异步处理引擎只负责更新流程变量AI结果通过回调写入关联表。在异步调用处还是要加一层内存队列限流以免多个流程并发启动时把模型服务打爆。6.2 JSON输出的全凭运气要靠三重重试与Schema校验解决哪怕提示词里强调了一百遍只输出JSON模型仍然可能输出带markdown代码块、缺字段、超量列举的JSON。在我们的实现中使用了Spring AI结构化输出同时又在结果上包了一层validator一旦解析失败会带着原输入和错误信息重试一次最多三次。这里有价值的一个技巧是第二次重试时的提示词里附加上次输出了什么导致失败模型看错误后会自动修正准确率明显提升。6.3 监听器里不要写AI的最终决定只写建议工程项目里AI可以调用工具链但不要在流程引擎的监听器里直接做事实性判断比如这个流程能不能通过。我们设计了一个外部决策表服务AI建议和规则引擎判断并存当规则引擎给出明确结论时优先走规则引擎只有在规则引擎没有覆盖的领域才把AI建议作为权重参考。这条边界守好了能让合规和审计都松了一口气。6.4 多租户数据隔离会让AI的思维串门流程平台通常都有多租户逻辑而AI调用在代码层面没有租户边界概念。如果提示词里没有注入当前租户信息模型可能参考到别家的历史流程模式。处理方式是所有发给模型的系统提示词里动态拼入租户ID并在NL2SQL场景把租户ID当成强制条件拼入SQL。我在code review里见过因为漏拼租户ID导致串数据的事故这条务必写进团队代码规范。6.5 流程版本变化之后的AI模型同步维护flowable允许流程定义一键切换版本但RAG向量库里存的旧流程摘要不会自动更新。如果业务方在V2版本里把审批链路改了AI还会拿着V1的旧知识回答这个流程怎么走。这个问题要设计成在流程版本发布时自动触发一次向量重灌并按版本号做隔离查询。虽然前期开发量会多一点但能避免后期很多弱智错误。6.6 观测性比模型调优更容易被忽视模型输出没有确定性调试时的第一件事永远是看输入。我们通过Spring AI的观察接口把每次模型请求的system、user、assistant输出都记录到了日志表页面端也做了可视化。这样一旦业务方报告AI给了一次错误建议我们能马上回放当时的上下文知道是提示词问题还是数据检索问题。没有这套记录AI抽风会变成一个无法排查的黑盒。最后说一点个人体会我接手这个方向的初期一直纠结于让AI多做一些事觉得模型能够生成流程、能判断条件、能审批那一刻看起来好像很有成效。但实际运行一段时间就会发现把AI嵌进flowable最大的价值不是它的自主判断能力而是它能把人类自然语言表达出来的复杂流程意图翻译成流程引擎能理解、能执行、能审计的规则。翻译的边界越清楚系统越稳定。如果你团队也在推进flowableSpring AI这个方向我的建议是先从自然语言发单、流程条目标注、历史问问这样低风险功能开始做把模型调用的稳定性、异步链路、观测日志完全跑通后再考虑Agent化。贪大求全会让你一次性承担太多未知变量失败的几率远大于一步一个脚印地推进。先把传感器装好再谈自动化改造。