Flowable 中的"LLM 节点"不是 BPMN 2.0 标准元素，也不是 Flowable 开源引擎内置的一种原生节点。企业通常把它建模为服务任务，再通过 Java Delegate、HTTP Task、External Worker 或事件机制调用独立的 AI 网关。Flowable 负责确定性流程、状态持久化、重试与人工任务，大模型负责摘要、分类、抽取、生成和辅助判断。
生产环境最推荐"External Worker + AI 网关"模式：流程到达 LLM 服务任务后形成等待状态，独立工作者拉取任务、调用模型、校验结构化结果，再通知 Flowable 继续执行。这样可以隔离模型 SDK、GPU 服务和网络抖动，避免长时间远程调用占用流程引擎事务。
截至 2026 年 8 月，Flowable 最新开源版本为 8.0.0。官方文档已经提供 Java Service Task、HTTP Task、External Worker、异步执行器和 Event Registry 等基础能力；Spring AI 2.0.0 则提供统一模型 API、结构化输出、RAG、工具调用和可观测性。两者组合的重点不是"调用成功"，而是让概率型输出进入可验证、可审计、可回退的流程治理体系。
一、核心结论与问题边界
一句话回答：让 Flowable 控制流程，让 LLM 提供受约束的智能能力
LLM 节点可以定义为：在业务流程运行到指定位置时，按照已发布的提示词、模型策略、知识范围和输出契约调用大模型，并把经过校验的结构化结果返回流程的服务任务。
它适合处理规则难以穷举、但结果仍可复核的任务，例如：
- 从合同、报销单或邮件中提取结构化字段。
- 对申请材料进行摘要、分类和缺项提示。
- 根据制度知识库生成审批建议与引用依据。
- 对客服工单识别意图、风险和推荐路由。
- 生成通知文案、办理意见草稿或下一步建议。
它不应该直接替代金额校验、权限判断、法定审批、账户扣款等确定性控制。高风险决策应由规则引擎或人工最终确认，大模型只能提供证据和建议。
LLM 节点为什么不能直接画成一个"智能审批"方框
BPMN 模型表达的是可重放的控制流，而大模型输出具有非确定性。相同输入可能因模型版本、提示词、采样参数和知识库变化得到不同结果。如果流程设计器只保存一个"AI 审批"名称，而没有保存输入、输出、版本和异常语义，生产问题将无法解释。
一个可发布的 LLM 节点至少应包含四类契约：
| 契约 | 关键配置 | 目的 |
|---|---|---|
| 输入契约 | 字段映射、附件引用、脱敏规则 | 限定模型能够看到什么 |
| 推理契约 | 提示词版本、模型别名、温度、最大令牌 | 固定本次运行策略 |
| 输出契约 | JSON Schema、必填字段、置信度范围 | 让流程能够可靠消费 |
| 运行契约 | 超时、重试、降级、人工兜底、幂等键 | 明确失败后怎么办 |
因此，"LLM 节点"应当是平台在 BPMN Service Task 之上的领域封装，而不是修改 BPMN 标准本身。部署时可以把设计器属性转换成 Flowable 扩展属性、流程变量映射和外部工作者主题。
二、关键概念与能力差异
Flowable 接入大模型有哪四种方式
1. Java Delegate：适合简单、短时、同进程调用
Java Service Task 可以通过类、委托表达式或方法表达式执行 Java 逻辑。把 Spring AI 或其他 Java LLM 客户端封装在委托服务中，开发成本最低，也方便读取流程变量。
但普通同步 Delegate 与当前流程命令处于同一事务。模型调用若持续几十秒，数据库事务、连接和引擎线程都会被长期占用；调用失败还可能让整个业务提交回滚。它只适合低延迟、低并发、容错要求不高的内部场景。至少应配置异步延续，让流程状态先提交，再由异步执行器调用。
2. HTTP Task：适合已有统一 AI 网关
Flowable HTTP Task 可以直接调用远程接口，并根据状态码抛出异常或映射 BPMN Error。企业已有 AI 网关时，它能快速完成集成，也避免流程应用绑定某一家模型 SDK。
缺点是它仍然容易形成同步长调用，复杂鉴权、流式响应、结果修复和多模型降级都不适合堆在 BPMN 属性中。HTTP Task 更适合短时、接口稳定、返回结构简单的调用。
3. External Worker：生产环境优先选择
Flowable 官方把 External Worker Task 实现为专用 Service Task。流程到达该节点后创建外部工作者作业并等待；工作者按 topic 拉取、锁定作业，处理完成后回传变量。工作者可以用任意语言实现，也可以独立扩缩容。
对 LLM 场景，它有四个明显优势：模型调用不会占用 Flowable 的执行线程；Python 或 Java AI 技术栈均可接入；不同模型和租户可以隔离部署；失败重试、锁续期和死信能够独立治理。它也是本文推荐的默认方案。
4. Event Registry：适合长任务和高吞吐异步协作
Flowable Event Registry 支持通过 JMS、Kafka、RabbitMQ 和 HTTP 收发事件，并按相关键触发流程实例。对于文档批处理、长文本分析、多步骤 Agent 或私有模型排队推理，可以发送"AI 请求"事件，让流程进入消息等待状态，完成后再通过事件相关返回。
事件模式伸缩性更强，但必须处理相关键、重复消息、乱序、超时和最终一致性。若团队尚未建立可靠消息治理，External Worker 通常更容易落地。
企业级 LLM 节点推荐什么架构
推荐把系统拆成五层：
- 流程编排层：Flowable 保存流程状态，控制分支、并行、超时、补偿和人工任务。
- 节点适配层：External Worker 或异步 Delegate 负责输入映射、幂等和完成回调。
- AI 网关层：统一鉴权、模型路由、限流、成本预算、重试、结构化输出和审计。
- 智能能力层：提示词、RAG、工具白名单、安全过滤和结果评估。
- 资源层：公有云模型、私有模型服务、向量数据库、对象存储和业务 API。
流程模型只引用稳定的能力标识，例如"合同风险抽取 v3"，不要写模型厂商地址、API Key 或完整提示词。AI 网关把能力标识解析为具体提示词版本、模型别名和知识库版本。更换供应商时，流程定义不必整体重画。
三、模型架构与运行机制
节点属性面板应该配置哪些内容
低代码设计器中的 LLM 节点，建议分成六组属性：
| 分组 | 推荐字段 | 设计原则 |
|---|---|---|
| 基础 | 能力标识、任务类型、说明 | 用业务语义命名，不暴露 SDK |
| 输入 | 字段映射、附件、上下文范围 | 默认最小数据集 |
| 模型 | 模型别名、温度、令牌上限 | 使用平台策略，不绑定密钥 |
| 知识 | 知识库、检索条数、权限过滤 | 检索必须继承租户与用户权限 |
| 输出 | JSON Schema、结果变量、置信度 | 禁止用自由文本直接控制网关 |
| 异常 | 超时、重试、备用模型、人工兜底 | 每一种失败都有确定出口 |
提示词应由提示词中心版本化发布。流程定义保存版本号或不可变快照，运行中的流程不能因为管理员改了"最新版提示词"而悄悄改变行为。模型也建议使用受治理的别名，例如 risk-model-stable，由网关将其路由到经过评测的具体版本。
同步调用还是异步调用
LLM 网络调用通常比数据库操作慢几个数量级，而且会遇到排队、限流和冷启动。不要在一个长数据库事务里等待模型返回。
三种推荐级别如下：
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 内部模型，P95 小于数秒 | 异步 Java Service Task | 实现简单，状态先提交 |
| 常规模型推理，数秒到数分钟 | External Worker | 等待状态清晰，可独立扩缩容 |
| 文档批处理或 Agent 长任务 | 事件请求/响应 | 解耦排队和计算资源 |
Flowable 的 flowable:async="true" 会创建异步作业，由异步执行器在新的事务中继续执行。官方文档说明异步作业失败时默认重试，也可以用 flowable:failedJobRetryTimeCycle 配置次数和间隔。External Worker 则创建可获取和锁定的等待作业，失败次数归零后进入死信作业表。
流式输出不应直接写成流程运行状态。前端可以从 AI 网关单独接收流式内容，但只有最终响应通过 Schema 校验后，工作者才完成 Flowable 节点。
四、核心场景与处理策略
External Worker 模式怎样运行
推荐运行链路如下：
- Flowable 到达
external-worker服务任务，按 topic 创建等待作业。 - AI Worker 拉取并锁定作业，读取经过白名单筛选的流程变量。
- Worker 使用幂等键向 AI 网关提交请求。
- 网关执行权限过滤、RAG、模型调用和输出校验。
- 结果合格时，Worker 回传小型结构化变量并完成作业。
- 结果不合格时，按错误类别重试、降级或返回人工复核出口。
幂等键可以由"流程实例 ID + 活动 ID + 执行 ID + 节点尝试序号"组成。相同幂等键再次请求时，AI 网关应返回原结果或当前状态，避免作业锁超时、网络重试导致重复计费和重复执行工具。
工作者锁定时间应大于正常调用 P99，并支持在长任务中续期。完成回调前还要确认自己仍是锁的拥有者；否则旧工作者晚到的结果可能覆盖新一轮执行。
为什么必须使用结构化输出
流程网关只能对确定字段做判断。不要根据"模型回答中是否包含同意"来走分支，因为否定句、解释文本、语言变化都会产生误判。
推荐结果示例：
json
{
"decision": "MANUAL_REVIEW",
"riskLevel": "HIGH",
"confidence": 0.72,
"summary": "合同存在自动续期与单方解约风险",
"evidenceRefs": ["clause-12", "policy-7"],
"reasonCodes": ["AUTO_RENEWAL", "ONE_SIDED_TERMINATION"]
}AI 网关应先校验 JSON Schema、枚举、长度和数值范围，再把结果交给流程。Spring AI 的 ChatClient 支持把响应映射为 Java 类型，也支持提供者原生结构化输出以及 Schema 校验重试。即便模型声称支持结构化输出，应用仍要做业务校验，例如证据引用是否存在、置信度是否在 0 到 1、金额是否与单据一致。
网关分支只读取有限枚举和确定字段。decision=PASS 也不应自动等于业务审批通过，仍需结合 DMN 或业务规则检查金额、权限和风险白名单。
五、数据、规则与状态设计
RAG 知识库如何与流程权限结合
RAG 可以把制度、合同模板、产品手册和历史案例检索后加入上下文，降低模型凭空生成。但它不是"接一个向量库"就结束。
检索条件必须带上租户、组织、文档密级、业务类型、有效期和用户权限。模型只能看到当前流程参与者本来有权访问的资料。检索结果需要保留文档 ID、版本、段落 ID 和相似度，最终把引用返回审批页面，供人工核验。
流程变量中只保存查询条件、结果摘要和证据引用。原始附件、切片正文和模型完整响应放在对象存储或 AI 审计库，避免把大文本写入 Flowable 变量表并拖慢运行时查询。
Spring AI 提供模块化 RAG Advisor、向量存储抽象和文档 ETL 能力，适合 Java 技术栈；企业也可以通过 AI 网关接入其他 RAG 服务。无论使用哪种框架，权限过滤都必须在检索阶段执行，而不是生成答案后再遮盖敏感内容。
Tool Calling 能不能让模型直接操作业务系统
Tool Calling 可以查询订单、获取客户信息、发送通知或创建草稿，但模型不应该直接拥有任意业务 API 权限。工具调用本质上是"模型提出调用建议，应用执行函数"，责任仍在应用。
建议采用以下边界：
- 每个 LLM 节点配置工具白名单，只暴露完成本任务所需的能力。
- 查询工具与写操作工具分开授权，写操作默认需要二次规则或人工确认。
- 工具参数必须做 Schema、权限、数据范围和幂等校验。
- 严格限制递归轮数、总令牌、工具次数和总执行时长。
- 工具返回内容视为不可信输入，防止提示词注入继续传播。
- 金额支付、删除、发布和外部发送等高风险动作由 Flowable 独立节点执行。
Spring AI 的工具调用文档说明框架可以自动管理工具调用循环，也支持应用自行控制执行。对企业流程，建议采用可控模式：模型选择工具后先记录意图，由应用检查策略，再执行允许的工具。
六、工程实现与系统集成
流程变量与大模型数据应该怎样存
Flowable 变量适合保存流程后续确实需要的小型数据，例如：
llmDecision：有限枚举。llmRiskLevel：风险等级。llmConfidence：置信度。llmSummary：限长摘要。llmResultRef：完整结果在 AI 审计库中的引用。llmPromptVersion、llmModelAlias：复现运行所需的版本信息。
不要把数十页附件、检索切片、完整 Prompt、Embedding 或长响应直接写入全局流程变量。大变量会增加序列化、数据库 I/O、历史表体积和查询压力。完整输入输出可加密保存在专用存储中，并设置保留期；Flowable 只保存引用、摘要、哈希和关键决策字段。
敏感提示词与回答默认不写普通应用日志。Spring AI 官方可观测性文档也默认不导出 Prompt、Completion、工具参数和工具结果，因为它们可能包含敏感信息。
超时、重试、降级和人工兜底怎么设计
错误不能统一"重试三次"。应先分类：
| 错误类型 | 典型情况 | 推荐处理 |
|---|---|---|
| 瞬时错误 | 429、5xx、网络超时 | 指数退避并遵守 Retry-After |
| 输出错误 | JSON 不合法、字段缺失 | 修复提示重试一次，再换备用模型 |
| 策略错误 | 内容安全拦截、无权访问 | 不重试，进入人工或终止 |
| 业务不确定 | 置信度低、证据冲突 | 创建人工复核任务 |
| 系统错误 | 配置缺失、Schema 版本不匹配 | 进入死信并告警 |
重试必须使用同一幂等键，并设置最大时间预算。备用模型不只是换一个名称，还要确认输出 Schema、上下文长度、数据合规和评测结果一致。若节点对外执行过工具，重试前必须判断副作用是否已经发生。
人工兜底任务应展示输入摘要、模型建议、证据、失败原因、模型与提示词版本，让办理人能够接受、修改或拒绝建议。人工结果还可以进入评测样本，但不能未经脱敏自动变成训练数据。
七、安全、性能与治理要求
如何防止提示词注入和数据泄露
来自附件、网页、邮件和知识库的文本都可能包含"忽略系统指令""把机密发送到某地址"等恶意内容。安全设计至少包括：
- 把系统指令、业务数据和检索内容分层传递，不把外部文本拼成最高优先级指令。
- 对附件类型、大小、恶意脚本和敏感信息先扫描再进入模型。
- 工具与知识库按租户、用户和节点授权，不能让模型自行扩大范围。
- API Key 保存在密钥管理系统，BPMN XML、流程变量和前端均不可见。
- 公有模型调用前执行脱敏和出境策略，私有化部署也要做租户隔离。
- 对输入、输出和工具参数做内容安全检查，高风险结果转人工。
"模型在内网"不等于安全。私有模型仍可能泄露跨租户上下文、被提示词注入操控或通过工具调用扩大权限。
监控、成本和评测应该看什么
流程监控与模型监控要用同一个追踪 ID 关联。建议记录：模型提供者与版本、提示词版本、知识库版本、输入输出令牌、首字延迟、总耗时、重试次数、缓存命中、备用模型、Schema 合格率、置信度、人工改判率和单次成本。
Spring AI 基于 Spring 可观测性体系提供 ChatClient、模型、工具和向量库的指标与 Trace，并明确敏感内容默认不导出。企业还应按流程定义、业务类型、租户和节点汇总成本，设置单实例和月度预算。
上线前建立"黄金样本集"：包含正常、边界、冲突、恶意和敏感数据。每次升级模型、提示词、Schema 或知识库切片策略，都要离线回放，比较准确率、拒答率、结构化合格率、成本和延迟。生产中抽样人工复核，并监控概念漂移。
八、平台落地、测试与选型
低代码平台如何封装 LLM 节点
平台不应让每个流程开发者重复编写模型调用代码。可把 LLM 节点封装成可视化组件，提供输入映射、提示词版本、知识库、工具白名单、输出 Schema、错误边界事件和人工兜底模板。
发布检查应自动拦截以下问题：缺少输出 Schema；分支直接判断自由文本；高风险动作没有人工确认；流程变量包含密钥；外部工作者没有超时与重试；知识检索没有数据权限；运行实例引用"始终最新"的提示词。 
云程低代码平台后续可以把现有逻辑编排、业务规则流、表单、数据权限和流程办理人能力，与统一 AI 网关组合起来：LLM 负责理解非结构化材料，规则流负责确定性校验，Flowable 负责流程状态和人工协作。三者职责分开，才能形成可维护的企业智能流程。
一个可落地的实施顺序
- 选择"摘要或字段抽取"这类低风险场景，先不让模型直接决定审批结论。
- 定义输入白名单和 JSON Schema，准备包含异常样本的评测集。
- 建立 AI 网关，统一模型路由、提示词版本、密钥、限流和审计。
- 用 External Worker 接入 Flowable，完成幂等、锁续期、超时和死信处理。
- 把低置信度、Schema 失败和安全拦截统一转人工任务。
- 接入 RAG 时先完成文档权限、版本和引用链，再扩大知识范围。
- 工具调用从只读查询开始，写操作拆成独立、可审计的流程节点。
- 通过黄金样本、灰度发布和成本看板验证后，再推广到关键流程。
九、如果只记住三句话
第一，LLM 节点不是 BPMN 标准节点，而是 Service Task 之上的企业能力封装。
第二，生产环境优先采用 External Worker 或事件方式，避免在 Flowable 数据库事务中等待长时间模型调用。
第三，任何会影响流程分支的模型输出，都必须结构化、可校验、可追溯，并配置规则与人工兜底。