Flowise 的多 Agent 协作：Supervisor/Worker 与 Sequential Agents

学习目标

理解 Flowise Supervisor/Worker 模式的 LangGraph 实现机制
掌握 Sequential Agents 各节点类型的功能与组合方式
学会根据任务特性选择合适的多 Agent 模式

前置知识

本章涉及多 Agent 路由与隔离的通用原理，建议先阅读：

多 Agent 路由与隔离

下文假设你已理解 Supervisor 模式、Handoff 机制等通用概念，直接聚焦 Flowise 的具体实现。

项目实践

Supervisor/Worker 模式

Flowise 的 Supervisor/Worker 基于 LangGraph StateGraph 编译，核心流程：

Supervisor 节点核心配置：

supervisorName：Supervisor 的名称（自动转为小写下划线）
supervisorPrompt：必须包含 {team_members} 占位符
model：支持 tool calling 的 LLM（ChatOpenAI、ChatAnthropic、ChatMistralAI 等）
recursionLimit：最大递归步数，默认 100
summarization：是否将最终输出摘要为对话总结
agentMemory：可选的 LangGraph CheckpointSaver，用于状态持久化

路由决策的结构化输出：

Supervisor 使用 RouteTool 进行结构化输出，schema 定义为：

z.object({
    reasoning: z.string(),        // 选择该 Worker 的原因
    next: z.enum(['FINISH', ...members]),  // 下一个执行的 Worker
    instructions: z.string()      // 给下一个 Worker 的具体指令
})

Worker 节点：

每个 Worker 是一个独立的 Agent（可配置自己的 LLM、工具、提示词）
Worker 执行后返回结果给 Supervisor
Supervisor 根据结果决定下一个 Worker 或返回 FINISH

Sequential Agents 模式

Sequential Agents 是线性状态机，节点按预设顺序执行。Flowise 提供 12 种 Sequential Agent 节点：

节点	功能	关键配置
Start	流程入口	`agentMemory`、`webhookDefaultInput`
Agent	LLM Agent + 工具	`model`、`tools`、`systemPrompt`
Condition	文本匹配条件分支	条件规则（输入值 → 目标节点）
ConditionAgent	LLM 语义判断分支	`model`、分类条件
ToolNode	纯工具执行	`tools`
Loop	循环控制	`maxIterations`
Iteration	迭代执行	迭代逻辑
LLMNode	纯 LLM 调用	`model`、`prompt`
CustomFunction	自定义 JS 函数	`javascriptFunction`
ExecuteFlow	嵌套执行另一个 Flow	`chatflowId`
End	流程终止	无
State	状态读写	`stateKey`、`operation`

状态传递机制：

节点间通过 $state 变量传递数据：

{{ output.result }}     → 引用上游节点的 output
{{ state.myKey }}       → 引用状态中的 myKey
$state.myKey            → 在 CustomFunction 中访问状态

Webhook 引用解析：

Start 节点支持从 Webhook 请求中提取数据：

{{ $webhook.body.name }}    → 提取请求体中的 name 字段
{{ $webhook.headers.auth }} → 提取请求头中的 auth 字段

安全设计：使用 lodash.get 解析路径，但阻断了 __proto__、constructor、prototype 路径，防止原型链污染。

问题与规避

Supervisor 无限路由循环

问题：Supervisor 可能陷入 A → B → A → B 的无限循环。

对策：

设置合理的 recursionLimit（默认 100）
在 Worker 提示词中明确要求 Worker 返回完整结果
启用 summarization 选项，在达到限制时输出摘要

Sequential Agent 状态丢失

问题：在条件分支中，不同分支的节点可能访问到不一致的状态。

对策：

使用 State 节点显式管理关键状态
避免在不同分支中修改同一个状态键
使用 CustomFunction 节点进行状态转换时，确保返回值格式一致

Worker 工具冲突

问题：多个 Worker 配置了相同的工具名，Supervisor 路由时可能混淆。

对策：

每个 Worker 使用唯一的名称
Supervisor 的 {team_members} 占位符应包含所有 Worker 的唯一标识

设计取舍

Supervisor/Worker vs Sequential Agents

维度	Supervisor/Worker	Sequential Agents
决策方式	LLM 动态路由	预定义流程
适用场景	任务类型不确定	步骤明确
调试难度	高（路径不可预测）	低（路径固定）
LLM 开销	每次路由额外一次调用	无路由开销
灵活性	高（自动适应不同任务）	中（需要手动调整流程）

Flowise 的设计哲学：同时提供两种模式，让用户根据场景选择。对于需要智能分配任务的场景（如”用户提问 → 判断意图 → 选择专业 Agent”），使用 Supervisor/Worker。对于步骤明确的流水线（如”搜索 → 总结 → 翻译 → 输出”），使用 Sequential Agents。

LangGraph vs 自研执行引擎

Flowise 在 Multi Agents 场景下选择 LangGraph StateGraph，而在 Chatflow 场景下使用自研 BFS 引擎：

维度	LangGraph StateGraph	自研 BFS
状态管理	内置 CheckpointSaver	手动管理
条件边	原生支持	需手动实现
可视化	不直接支持	React Flow 原生支持
依赖	增加 LangChain 依赖	零额外依赖

Flowise 的选择是务实的：LangGraph 在多 Agent 状态管理方面已足够成熟，无需重新发明；而简单 Chatflow 不需要复杂状态管理，自研 BFS 更轻量。

参考来源

版本信息

📅 2026-05-27 🏷️ bc22bf8 🔀 bc22bf8