LLM节点执行器：PaiFlow核心设计，支持多模型流式输出

在 PaiFlow 里，LLM 节点是最核心的节点之一，它要做提示词拼装、多轮对话、流式输出、异常兜底。所以我们在实现上，力求：

第一，不管是 DeepSeek、讯飞星火、智谱，还是后面可能接入的其他模型，节点层都不应该感知这些差异。第二，它要理解“上下文”。提示词模板、变量替换、多轮对话历史，都要能兼顾。第三，支持实时反馈，流式输出几乎是刚需。

1.LLM节点执行器的整体设计

LLMNodeExecutor 是 PaiFlow 工作流引擎中专门负责与大语言模型（LLM）进行交互的节点执行器。它的核心目标是：将工作流中的业务数据（如用户输入、上下文历史）转换为标准的 LLM 请求，然后处理 LLM 返回的响应（包括流式和非流式），并将输出格式化为工作流可以继续处理的结果。

作为 AbstractNodeExecutor 的子类，它天然继承了超时、重试、输入解析、输出存储、事件回调（ onNodeStart / onNodeEnd ）等通用能力。

LLMNodeExecutor 的核心是实现 executeNode(...) 方法，在这个方法中注入 LLM 独有的业务逻辑。

它通过经典的设计模式（模板方法模式+工厂模式），将通用流程控制、具体业务实现和底层服务依赖三者完美解耦。对上，遵守 AbstractNodeExecutor 定义的模板，无缝融入工作流的生命周期管理；对下，通过工厂和接口，灵活适配多种 LLM 服务。另外，还能通过 Callback 将引擎的 SSE 事件推送机制连接起来。

2.LLM节点执行器的具体实现

2.1 LLM节点的配置示例

LLM ...

15 条评论

QiQ 2026年03月26日 19:23

引用原文：LLM 节点要支持多轮对话

对于开始-LLM节点-结束这样的工作流，发送一句话，执行一次工作流，得到一个回答，发送另一句又会执行工作流，怎么实现LLM节点多轮对话？@派聪明

回复1 取消回复

派聪明 2026年03月26日 19:25

在PaiFlow中，LLM节点通过对话历史池实现多轮对话，具体机制如下： 1. **对话历史存储**：系统使用Guava的LoadingCache创建对话历史池，以`chatId+nodeId`为键存储各会话历史记录。每条历史包含用户输入、LLM思考过程和回复内容。 2. **历史记录管理**： - 每次对话添加新记录时，队列自动限制长度(MAX_HISTORY_LENGTH=10)，超出则移除最早记录 - 缓存设置上限(10000会话)和30分钟过期策略，防止内存溢出 3. **提示词构建**：执行时将历史对话纳入提示词： ```java // 系统提示词 → 历史对话(用户输入+模型回复) → 当前用户输入 if (!CollectionUtils.isEmpty(req.getHistory())) { for (ChatItem item : req.getHistory()) { // 添加历史用户输入 msgList.add(new UserMessage(message.content())); // 添加历史模型回复 msgList.add(new AssistantMessage(response.content())); } } ``` 4. **工作流执行流程**： - 首次发送消息：创建新历史记录，执行工作流 - 后续发送消息：通过相同chatId获取历史记录，构建包含上下文的新提示词 - 每次执行后：将新问答追加到历史记录池 5. **配置控制**：通过`enableChatHistoryV2`开关控制多轮功能，可设置保留轮数(如rounds=3) 这样用户每次发送新消息时，系统都能自动关联历史对话，实现连贯的多轮交互体验。

云宿 2026年03月24日 09:51

引用原文：MAX_HISTORY_LENGTH 设成 10

@派聪明你最高就缓存了10条，但是你前端又没有限制用户可以保存的最大轮数，那假如用户设置为60，他不还是缓存10条，有什么用呢

昏睡的吐司 2026年03月23日 21:07

引用原文：expireAfterWrite 设成 30 分钟，意味着这段时间里没再写入这个会话，它就会自动过期回收。

@派聪明如果30分钟从缓存中删除，那什么时候同步存入数据库呢

小时月 2026年03月19日 22:37

引用原文：是新特性

@派聪明解释一下record新用法，什么版本jdk引入的

派聪明 2026年03月19日 22:39

参考资料中提到的 **`record` 是 Java 14 引入的新特性**（作为预览功能），在 **Java 16 中正式成为标准特性**。它的核心作用是**简化不可变数据类的编写**，减少样板代码。 --- ### **`record` 的核心特点：** 1. **自动生成不可变类** - 所有字段隐式声明为 `final`。 - 自动生成构造函数、`getter` 方法、`equals()`、`hashCode()` 和 `toString()`。 2. **语法简洁** - 传统类需要手动编写大量代码，而 `record` 仅需一行声明： ```java public record LlmResVo(Usage usage, String content, String thinkContent) {} ``` 等效于传统类： ```java public final class LlmResVo { private final Usage usage; private final String content; private final String thinkContent; public LlmResVo(Usage usage, String content, String thinkContent) { ... } public Usage usage() { ... } public String content() { ... } public String thinkContent() { ... } @Override public boolean equals() { ... } @Override public int hashCode() { ... } @Override public String toString() { ... } } ``` 3. **适用场景** - 适合**纯数据载体**（如 DTO、API 响应对象），如参考资料中的 `LlmResVo`，用于封装模型 API 的返回数据。 --- ### **参考资料中的应用：** 在 `LLMNodeExecutor` 中，`LlmResVo` 被定义为 `record`： ```java public record LlmResVo(Usage usage, String content, String thinkContent) { } ``` - **作用**：封装从模型 API 接收的响应数据（`usage` 统计信息、`content` 回答内容、`thinkContent` 推理过程）。 - **优势**：无需手动编写 `getter`/`equals` 等方法，代码更简洁，且保证数据不可变性。 --- ### **总结：** - **引入版本**：Java 14（预览）→ Java 16（正式）。 - **核心价值**：用极简语法实现不可变数据类，减少重复代码。 - **参考资料场景**：`LlmResVo` 作为模型 API 的响应载体，完美契合 `record` 的设计目标。

Je 2026年03月18日 00:10

引用原文：maximumSize 设成 10000，意思是最多缓存一万个会话的队列，再多就让 Guava 做淘汰

@派聪明这个maximumSize 和上面的MAX_HISTORY_LENGTH有什么区别

派聪明 2026年03月18日 00:10

根据参考资料中的描述，`maximumSize` 和 `MAX_HISTORY_LENGTH` 是两个不同层级的限制参数，作用如下： ### 1. **`MAX_HISTORY_LENGTH`（单个会话队列长度限制）** - **作用**：控制**单个会话**中保存的历史对话条数上限。 - **实现位置**：在 `ConcurrentLinkedQueue` 的自定义实现中（通过重写 `add` 方法）。 - **逻辑**： - 每个会话（由 `chatId + nodeId` 唯一标识）维护一个独立的队列。 - 当队列长度达到 `MAX_HISTORY_LENGTH`（如 10）时，**自动移除最旧的一条记录**，确保单个会话的历史记录不会无限增长。 - **代码示例**： ```java private static final int MAX_HISTORY_LENGTH = 10; // 单个会话最多保存10条历史 private static ConcurrentLinkedQueue createChatHistoryQueue() { return new ConcurrentLinkedQueue() { @Override public boolean add(ChatItem item) { if (size() >= MAX_HISTORY_LENGTH) { poll(); // 移除最旧记录 } return super.add(item); } }; } ``` ### 2. **`maximumSize`（全局会话数量限制）** - **作用**：控制**整个缓存**中保存的不同会话队列的总数量上限。 - **实现位置**：在 `LoadingCache` 的配置中（通过 `CacheBuilder.newBuilder().maximumSize()`）。 - **逻辑**： - 缓存存储所有会话的队列（key 为 `chatId + nodeId`）。 - 当会话数量达到 `maximumSize`（如 10000）时，**根据 LRU 策略淘汰最久未使用的会话队列**，防止内存溢出。 - **代码示例**： ```java private static final LoadingCache> chatHistoryCache = CacheBuilder.newBuilder() .maximumSize(10000) // 全局最多缓存10000个会话队列 .expireAfterWrite(30, TimeUnit.MINUTES) .build(CacheLoader.from(LlmChatHistory::createChatHistoryQueue)); ``` --- ### **核心区别总结** | **参数** | **作用范围** | **限制目标** | **淘汰机制** | |------------------------|------------------|--------------------------|--------------------------| | `MAX_HISTORY_LENGTH` | 单个会话内部 | 单个会话的历史记录条数 | 移除最旧的一条记录（队列内） | | `maximumSize` | 全局缓存层面 | 不同会话队列的总数量 | LRU 策略淘汰整个会话队列 | ### **设计意图** - **`MAX_HISTORY_LENGTH`**：防止单个会话的历史记录无限膨胀（如长时间对话占用过多内存）。 - **`maximumSize`**：避免系统因会话数量过多（如高并发场景）导致内存耗尽。两者结合，既保证了单个会话的历史记录可控，又限制了全局内存占用，形成双重保护机制。

满意的身影 2026年03月17日 18:12

引用原文：record 用法

解释一下

berlin 2026年03月01日 16:51

为什么用guava而不用redis？guava与redis相比优势是什么呢？

liuyongyuan 2026年03月04日 14:58

轻量，就一个小需求需要缓存没必要引入redis

1.LLM节点执行器的整体设计

2.LLM节点执行器的具体实现

2.1 LLM节点的配置示例

热门评论

15 条评论

目录

划线评论