前言

一个框架的生命里，总会有那么一两个版本，它的意义不在于修了多少 bug、加了多少特性，而在于把框架自身的边界，狠狠地往外推了一把。

对 LiteFlow 来说，2.16.0 就是这样一个版本。

过去五年，LiteFlow 始终在回答同一个问题：当业务逻辑越来越庞杂，我们该如何把它组织得清晰、可控、可复用？我们给出的答案是"编排"——把一个个独立的逻辑单元，用一套简洁的表达式自由地串联、并联、嵌套起来。

而这一两年，整个软件世界正在被同一股力量重新塑造：AI 正在从一个可选项，变成业务系统里一个绕不开的角色。于是一个新的问题摆到了我们面前：当 AI 也成为业务逻辑的一部分，它能不能、又该不该，被纳入我们一直坚持的这套"编排"里来？

2.16.0，就是我们交出的答卷。

从这个版本起，LiteFlow 有了自己的 AI Agent 模块。而比"有了"更重要的是：这个 Agent 不再是悬挂在系统之外的一个独立服务，而是一个能被你直接编排进规则、与现有业务节点平起平坐的一等公民。

这是 LiteFlow 这两年里，我们自己心里分量最重的一个版本。

主角：AI Agent 第一次能被"编排"了

这一两年，AI 这个词已经被说烂了。但凡一个框架、一个产品，不挂上点 AI 都不好意思发版。

所以请允许我们先把丑话讲在前头：这次 2.16.0 带来的，并不是一个"大模型组件"。

这个区别，比你想象的要重要。

其实在 2.16.0 之前，就已经有不少公司用 LiteFlow 在跑 AI 业务了——他们在自己的组件里直接调用大模型，LiteFlow 则在背后充当后端编排引擎，把一次次模型调用串成完整的业务链路。这条路一直走得通，我们也无意去抢它：今天调一次大模型实在太容易了，new 一个 client、发个请求，我们再官方包一个"大模型组件"出来，纯属画蛇添足。

我们这次想做的，是另一件本质上完全不同的事——把 Re-Act Agent 做成 LiteFlow 的组件。

一个 Agent，和"调一次大模型"，根本不是一个量级的东西。至于差在哪，下一节细说。但在那之前，得先把另一件事讲明白。

你有没有发现，现在市面上的 Agent，绝大多数都是一座孤岛？

它自己是自己，有自己的运行逻辑、自己的上下文、自己的工具。你想让它和现有业务系统配合，往往就是在外面再写一层胶水代码把它裹起来。Agent 归 Agent，业务归业务，两边各玩各的。

而 LiteFlow 这框架，从第一天起干的就是一件事：编排。把一堆逻辑节点，用一行表达式串起来、并起来、绕起来。

那问题就来了。如果一个 AI Agent 本身，就是其中一个节点呢？

这就是 liteflow-react-agent 这个模块的全部出发点。

先说清楚，什么是 Re-Act

Re-Act 不是我们造的词，它是 Reasoning（推理）+ Acting（行动）的合称，是让大模型从"只会聊天"变成"能干活"的一种经典套路。

你直接调大模型 API，它只能根据你给的提示词回你一句话。查不了数据库、调不了接口、读不了文件，它没有手。

Re-Act 给了它一双手。它的工作方式是一个循环：先推理（我现在该干嘛），再行动（调一个工具），然后观察（工具返回了啥），接着再推理，一直转到它觉得活干完了为止。

举个你可能天天在用的例子，Claude Code。

你让它改个 bug，它不是凭空给你写一段代码。它会先去搜你的项目结构，看看现有代码怎么写，然后改文件，跑测试，测试挂了再回头改……这一整套"想一下、动一下、看一眼结果、再想一下"的过程，就是 Re-Act。

理解了这个，你也就理解了这个模块的内核。liteflow-react-agent 把 ReActAgent 封装成了一个标准的 LiteFlow 组件。

而"组件"这两个字，正是这次的精髓所在。它意味着，从对接各大模型平台、到多轮会话记忆、再到 Skill 技能体系，一个 Agent 该有的能力，模块都替你包揽好了。你真正要做的，只是声明一个组件、实现那么几个简单的方法——一个组件，就是一个 Agent。 你可以只声明一个，也可以声明一大堆，让多个 Agent 各管一摊、彼此协同。而它们，全都是标准的 LiteFlow 组件。

至于这些 Agent 声明出来之后能玩出什么——好戏，才刚刚开始。

然后，神奇的事情发生了

一旦 Agent 变成了 LiteFlow 的组件，它就自动继承了 LiteFlow 的全套编排能力。

你原来怎么写规则，现在还怎么写，只不过里面某个节点，是个会思考的 AI。

串一下？

THEN(prepare, deepseekAgent, recordReply);

prepare 是你的普通 Java 节点，负责准备数据。deepseekAgent 是个 AI。recordReply 又是普通 Java 节点，负责落库。AI 就这么自然地夹在业务流程中间，前后都是你熟悉的代码。

想让两个不同的大模型同时上？

WHEN(deepseekAgent, qwenAgent);

让 DeepSeek 和通义千问同时分析同一个问题，并行跑，互不打架。

想根据情况走不同的 AI？

IF(isMath, mathAgent, deepseekAgent);

是数学题就走数学 Agent，否则走通用 Agent。而这个 isMath，就是个普普通通的布尔组件，和你平时写的一模一样。

再复杂一点：

THEN(
    prepare,
    WHEN(analyzerAgent, riskAgent),
    summaryAgent,
    notify
);

准备数据，两个 Agent 并行做分析和风控，第三个 Agent 汇总它俩的结论做决策，最后通知出去。一条规则，三个 AI，各司其职，还和你的业务节点穿插在一起。

停下来想一秒：上面这些关键字，THEN、WHEN、IF、SWITCH、FOR，没有一个是为 AI 新造的，全是 LiteFlow 用了好几年的老东西。你不需要学任何新的编排语法。你会编排 LiteFlow，你就会编排 AI。

想象空间有多大

我们写到这块的时候，是真有点兴奋的。

因为这意味着，AI 不再是你系统外面挂着的一个独立服务，而是可以长在你业务流程的任意一个环节里。

• 风控链路里塞一个 Agent 节点，让它结合实时上下文做一次智能研判；
• 内容审核流程里塞一个 Agent，让它去干那些规则写不出来、"说不清但你懂"的判断；
• 一条数据处理链路，前面用普通组件清洗，中间交给 Agent 分析，后面再用组件落地；
• 甚至多个 Agent 协作。借助 Skills 技能系统，给不同的 Agent 注入不同的长指令和专属工具，一个负责查、一个负责写、一个负责审，在同一条规则里接力。

而且它不挑模型。OpenAI、Claude、Gemini、DeepSeek、通义千问、Kimi、GLM 都能接，想混着用就混着用，换模型基本就是换一行 model() 的事。

我们一直觉得，一个好能力的标志，是它能激发使用者的想象力，而不是把人框死在我们预设好的那几个场景里。AI Agent 接进 LiteFlow 之后能玩出什么花样，老实讲，我们自己都猜不全。这部分，我们更期待社区。

最后补一句：上面我们一行使用细节都没展开。model()、systemPrompt() 怎么写，工具怎么注册，流式输出怎么接，文档里都有完整章节。这篇文章，我们只想让你感受到一件事：这个口子，现在开了。

适配了 Springboot 4

Springboot 4 前阵子正式发布了，底层依赖和 API 改了不少。

LiteFlow 这次第一时间跟上，单独提供了一个 liteflow-spring-boot4-starter。如果你已经升到了 Springboot 4，把 starter 换成这个就行（注意 Springboot 4 本身要求 JDK17 起步）。

还在用 Springboot 2.x、3.x 的同学完全不用动，原来的 liteflow-spring-boot-starter 接着用。

没什么花哨的，但生态在往前走，框架就得跟上，这是本分。

graaljs 脚本插件，终于支持 JDK25 了

先澄清一点，免得引起误会：LiteFlow 从 2.15.0 起就已经全面支持 JDK8 ~ JDK25 了，这早就不是问题。

真正补上的，是一个藏在角落里的短板。liteflow-script-graaljs 这个 JS 脚本插件，底层用的是 GraalVM 的 JS 引擎，而 GraalVM 的版本一直比 JDK 慢半拍。所以过去一段时间，你在 JDK25 上用这个插件会有点尴尬。

这次我们把底层引擎升了上去，graaljs 终于能在 JDK25 上正常跑了。如果你之前就因为它卡在老 JDK 上没敢升，现在可以放心了。

最后

AI 会不会取代程序员？一定会。但它取代不了你想亲手做点东西出来的那股劲儿。而当"做出来"越来越便宜，你的想法只会越来越多。

五年多了，我们做的一直是同一件事：把"想到"和"做到"之间那段路，铺得短一点。

如今 AI 来了，这段路从未这样短过。