Flowise 是一个开源的「低代码 LLM 应用编排平台」,由 FlowiseAI 团队开发并持续维护(当前主版本为 2.x)。它把 LangChain.js 生态中的组件——大语言模型、向量数据库、文档加载器、文本切分器、Agent、工具、记忆模块等——封装成可视化节点,用户通过拖拽、连线、填表单的方式即可构建完整的 LLM 工作流,而无需手写编排代码。Flowise 解决的核心痛点是:RAG 管道、Agent 调用、多轮对话等 LLM 应用链路复杂,传统手写方式调试成本高、原型验证慢。它的核心特点包括:可视化拖拽编排、内置聊天调试窗口、一键将流程发布为 REST API 并支持 API Key 鉴权、可将嵌入式聊天组件部署到任意网页、支持 Docker 与 npm 等多种部署方式、完全开源可自托管。本文按「速览 → 安装 → 上手 → 核心能力 → 生产部署 → 选型对比」的顺序展开,并在末尾提供常见误区、面试题与学习资源,读者按章节操作即可从零跑通第一个 RAG 问答应用。
掌握 Flowise 意味着你能在小时级内把 RAG/Agent 想法变成可调用的 HTTP 接口,同时保留自定义节点与自托管能力,是 AI 应用工程师与解决方案架构师验证业务场景的高效技能。
目录
速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 Flowise:从手写编排到可视化拖拽
传统方式下,用 LangChain 等框架手写 LLM 应用需要大量胶水代码:文档加载、文本切分、向量化、检索、提示词拼接、记忆管理、工具调用循环,每一步都要自己写逻辑并处理异常。链路越长,调试成本越高,一次提示词或检索策略的调整往往要改代码并重新部署。团队协作时,改一个流程就相当于走一次代码发布流程,业务人员无法参与迭代,原型验证周期常以天计。
Flowise 的解法是把 LangChain.js 的组件封装为可视化节点,节点间的连线即数据流,参数通过表单配置,免去写代码与调试的环节。每个 Chatflow 或 Agentflow 都是可独立运行的流程单元,内置聊天窗口可即时测试效果,右上角可一键生成 REST API 地址,从拖拽到可调用接口无需重写任何代码。这使得业务人员也能参与流程配置,开发者专注在节点选择与参数调优上。
与同类工具的气质差异在于:相比 Langflow,Flowise 对 LangChain.js 组件的覆盖更全、发版更频繁;相比 Dify 的平台化路线(自带用户管理、应用运营后台),Flowise 更轻量、完全自托管、可编程性更强;相比 n8n 这类通用自动化平台,Flowise 专为 LLM 语义设计,天然理解 Embedding、向量检索、上下文窗口这些概念。
安装与环境配置:Docker 或 npm 两步就绪
步骤一·安装:生产环境推荐 Docker 方式,一条命令拉起服务;开发调试可用 npm 全局安装。Docker 方式需要本机已安装 Docker;npm 方式需要 Node.js 18 及以上版本。
步骤二·配置:生产环境必须配置登录账号,通过环境变量 FLOWISE_USERNAME 与 FLOWISE_PASSWORD 开启 UI 认证,防止未授权访问你的流程并消耗模型费用。可选配置包括 PORT(默认 3000)与 DATABASE_PATH(默认数据目录 ~/.flowise,流程与配置存储在 SQLite 中)。
步骤三·验证:浏览器访问 http://localhost:3000,配置了账号则出现登录页,登录后进入主界面;Docker 方式用 docker logs flowise 查看启动日志,出现监听 3000 端口的信息即安装成功。
# Docker 方式(生产推荐)docker run -d \ --name flowise \ -p 3000:3000 \ -e PORT=3000 \ -e FLOWISE_USERNAME=admin \ -e FLOWISE_PASSWORD=change-me \ --volume ~/.flowise:/root/.flowise \ flowiseai/flowise # npm 方式(开发调试)npm install -g flowisenpx flowise start
快速上手:10 分钟跑通第一个 RAG 问答机器人
最小可用的 RAG 流程由五类节点组成:文档加载器(Document Loader)→ 文本切分器(Text Splitter)→ Embedding 模型 → 向量库(Vector Store)→ LLM 链。Flowise 以 Chatflow 承载这条链路,全部通过拖拽完成。
1. 登录后点击「Add New」→ Chatflow,输入名称(如 MyRAG),进入画布。
2. 从左侧节点面板拖入:文档加载器节点(如 Pdf 或 Text)、文本切分器节点(Recursive Character Text Splitter)、Embedding 节点(如 OpenAI Embeddings)、向量库节点(本地快速验证用 LanceDB,生产可选 Qdrant/Pinecone)。
3. 连线:文档加载器 → 文本切分器 → 向量库;Embedding 节点也连接到向量库。
4. 拖入 LLM 节点(ChatOpenAI)与提示词模板节点(Prompt Template),在节点表单中配置模型 API Key;将向量库的「检索输出」连接到提示词模板的上下文变量。
5. 点击画布右上角「Chat」按钮,在调试面板上传文档并发送问题,验证回答是否引用了文档内容。
6. 验证通过后,点击「API Endpoint」,开启 API 开关并复制生成的 POST 地址,即获得可被外部系统调用的 HTTP 接口(具体请求/响应字段以面板生成的示例为准)。
进阶技巧:为流程添加「Conversation Memory」记忆节点可实现多轮上下文;添加「Tool」工具节点(如 Web Scraper、计算器)可让 LLM 自主调用外部能力。已发布的流程可通过 REST API 调用:
curl -X POST https://your-host/api/v1/prediction/<flow-id> \ -H "Authorization: Bearer <API_KEY>" \ -H "Content-Type: application/json" \ -d '{"question":"Flowise 如何部署?","overrideConfig":{"sessionId":"user-123"}}'
核心能力详解:四大支柱
支柱一·可视化流程编排。Flowise 将 LangChain.js 组件封装为数百种可视化节点,涵盖 LLM、Agent、Chain、工具、向量库、记忆、文档加载器等类别。节点参数通过表单配置,连线即数据流,无需编写编排代码。平台支持自定义节点:通过「Custom JS Function」节点直接编写 JavaScript 执行函数,或开发外部自定义节点包,突破内置组件边界。
支柱二·RAG 管道构建。文档侧覆盖加载(PDF、Word、网页抓取、数据库查询等)与切分(递归字符切分、语义切分等);检索侧覆盖 Embedding 模型接入与向量库(本地 LanceDB/Chroma,云端 Qdrant/Pinecone/Weaviate 等)。各节点即插即用,可分别构建「文档入库索引链」与「问答检索链」两条链路,支撑知识库问答、文档摘要等场景。
支柱三·Agent 与多 Agent 编排。Agent 节点(OpenAI Function Agent、ReAct Agent 等)可绑定多工具列表,由 LLM 自主决策调用。在此基础上支持多智能体拓扑:Supervisor(主管智能体调度多个子 Agent)、Sequential Agent(按顺序依次执行)等,适合客服分流、复杂任务分解等需要多角色协作的场景。
支柱四·集成与发布层。每个流程可独立发布为 REST API(/api/v1/prediction/{flowId}),支持 API Key 鉴权;提供嵌入式聊天组件,通过一段 script 代码即可嵌入任意网页;流程以 JSON 文件导入导出,便于版本管理与团队迁移。
生产部署与监控:从上线到运维
部署方式一·Docker Compose(推荐)。容器化运行并固定镜像版本,映射端口,挂载 ~/.flowise 数据卷以持久化流程与 SQLite 数据,配置 FLOWISE_USERNAME/FLOWISE_PASSWORD 开启 UI 登录,设置 restart: unless-stopped 保证异常退出后自愈。
部署方式二·npm + 进程守护。在服务器安装 Node.js 18+,npm install -g flowise 后用 PM2 守护进程:pm2 start "npx flowise start" --name flowise,实现开机自启与崩溃重启;排障时用 npx flowise start --DEBUG=true 输出调试日志。
可观测性:外部流量建议统一经 Nginx 或云网关反向代理,负责 TLS 终结、请求限流与访问日志记录;用网关日志结合 Prometheus/Grafana 观测请求量、延迟与错误率。模型调用费用与 Token 消耗在 LLM 供应商控制台查看。流程数据落盘在 ~/.flowise 目录的 SQLite 中,需纳入备份策略,升级前先备份数据目录并导出流程 JSON。
<p class="para-label">避坑清单:</p>
<ul class="dash-list"><li>坑 1:生产环境直接暴露 3000 端口且不设登录账号,任何人可进入编辑流程并消耗模型费用——务必配置 FLOWISE_USERNAME/FLOWISE_PASSWORD 并用反向代理加 HTTPS。</li><li>坑 2:本地向量库数据不持久化,容器销毁即丢数据,多实例部署还会出现检索数据不一致——改用外部向量库或将数据卷持久化挂载。</li><li>坑 3:v1.x 导出的流程 JSON 直接导入 v2.x 可能报「节点不存在」或配置丢失——升级前在测试环境逐节点验证兼容性。</li><li>坑 4:带记忆节点的流程不传 sessionId,多轮对话会相互串扰——API 调用时在 overrideConfig 中固定传 sessionId 区分用户。</li><li>坑 5:把 API Key 写在前端 JS 中直连 Flowise 接口,密钥会被浏览器暴露——由服务端代理调用,密钥只保存在后端。</li></ul>
services: flowise: image: flowiseai/flowise:latest container_name: flowise ports: - "3000:3000" environment: - PORT=3000 - FLOWISE_USERNAME=admin - FLOWISE_PASSWORD=change-me volumes: - ~/.flowise:/root/.flowise restart: unless-stopped
| 维度 | Flowise | Langflow | Dify | n8n |
|---|---|---|---|---|
| 定位 | 低代码 LLM 应用编排(开源) | 低代码 LLM 工作流(开源) | LLM 应用平台(开源+云 SaaS) | 通用自动化工作流平台 |
| 编排范式 | 节点拖拽(LangChain.js 组件映射) | 节点拖拽(LangChain 组件映射) | 可视化编排 + 内置应用模板 | 触发器 + 节点连接(通用任务) |
| 类型约束 | 流程依赖 LangChain 组件版本 | 组件生态跟随 LangChain | 内置组件版本由平台管理 | 节点间以 JSON 数据结构传递,类型灵活 |
| 学习曲线 | 较低:可视化 + 表单配置 | 较低:可视化 + 表单配置 | 低:平台化开箱即用 | 中:需理解触发器与响应模型 |
| 生态集成 | 数百个组件,更新频繁 | 基于 LangChain 生态,社区中等 | 模型/知识库/工具集成丰富 | 数百个 SaaS 系统集成节点 |
| 生产部署 | Docker/K8s/云均可自托管 | Docker 自托管 | 自托管或使用云版 | 自托管或云版 |
| License | Apache 2.0 | MIT | Apache 2.0(社区版) | Sustainable Use License(商业用途有限制) |
| 适合谁 | 快速构建并发布 RAG/Agent 原型的开发者 | 偏好 LangChain 开源栈的小团队 | 需要产品化平台(含运营后台)的团队 | 需将 LLM 嵌入跨系统自动化流程的团队 |
选型建议:追求最短时间把 RAG/Agent 原型变成可调用 API、且要求完全自托管,选 Flowise;更偏好 LangChain 原生组件研究,可选 Langflow;需要用户管理、知识库运营、应用发布等平台级能力,选 Dify;核心诉求是把 LLM 步骤嵌入 CRM、邮件、数据库等跨系统自动化流程,n8n 更合适。
版本迭代
Flowise 由 FlowiseAI 于 2023 年开源,以「低代码拖拽构建 LangChain 应用」迅速流行;2024 年 4 月发布 1.0 正式版,重构界面与节点体系;2025 年初进入 2.x 时代,重点打磨多 Agent 编排与交互体验。项目保持高频发版节奏(截至训练数据,可能已有更新版本)。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| v1.0.0 | 2024-04 | 首个 1.0 正式版 | 全新界面与画布交互,自定义节点体系趋于稳定 |
| v2.0.0 | 2025-01 | 新一代大版本 | 多 Agent 编排能力增强(Supervisor 等节点完善),界面与交互重构 |
| v2.1.x | 2025-04 | 持续迭代 | 新模型/向量库适配,节点兼容性修复与稳定性提升 |
Flowise 的迭代重心从「覆盖更多 LangChain 组件」转向「提升编排复杂度上限与生产可用性」——1.x 解决「能用」,2.x 解决「好用」与多 Agent 协作。选型时注意版本锁定:2.x 与 1.x 的流程 JSON 不完全兼容,生产环境应固定镜像版本并规划升级窗口。Flowise 作为应用编排工具不参与模型能力榜单(如 MMLU),其质量评估以社区实际落地场景为准。
AI 应用场景
场景一:企业知识库 RAG 问答机器人
阶段:RAG 管道构建
解决的问题:传统方式需手写文档解析、切分、向量化、检索与生成全链路代码,调试周期长。Flowise 通过拖拽组装「文档加载 → 切分 → 向量化 → 向量库 → 检索 → LLM 生成」链路,非研发人员也能维护知识库内容。
具体案例:某制造企业将产品手册与质检规范 PDF 接入 Flowise,构建内部问答机器人,新员工培训与售后查询由「翻阅文档数小时」缩短为「提问即答」,回答附引用来源便于审计(实际收益取决于知识库质量,建议按自身场景验证)。
场景二:客服工单分类与自动回复 Agent
阶段:Agent 编排
解决的问题:客服工单需人工判断类别并回复高频问题,重复劳动占比高。Flowise 用 Agent 节点绑定「工单分类工具 + 知识库检索工具」,根据用户描述自动分类并生成应答草稿,运营人员仅需审核。
具体案例:某电商团队将物流、退换货、开票三类高频咨询接入 Flowise Agent 流程,重复性问答由系统自动应答,人工从重复劳动中释放并转向复杂客诉处理(团队报告的处理量级提升在数倍量级,需按自身流量实测)。
场景三:营销内容批量生成流水线
阶段:多步骤生成式工作流
解决的问题:内容团队需将同一素材改写为多平台、多语言文案,手动操作耗时。Flowise 串联「文案生成 → 多版本改写 → 关键词嵌入」节点,一次性产出多份初稿。
具体案例:某出海 SaaS 团队用 Flowise 将产品更新日志自动改写为中英双语社媒文案与邮件摘要,编辑仅需审核微调,单周内容产出量显著提升(效率收益与模板质量强相关,建议迭代提示词后再评估)。
常见误区
误区Flowise 拖几个节点做演示还行,生产环境肯定得用代码手写,可视化工具一升级就会崩。
正解Flowise 提供 UI 账号认证、API Key 鉴权、Docker/K8s 部署与数据卷持久化,可把流程作为独立服务发布并纳入网关治理,社区中已有自托管承载真实流量的案例。决定能否上生产的是运维规范——反向代理、限流、备份、版本锁定——而非工具形态本身。
为何常见:可视化工具早期 Bug 多、文档不完善,给人「玩具」印象;加上 LangChain 生态本身变动快,加剧了不信任感。
误区反正都是画流程图,Chatflow 和 Agentflow 随便选一个用就行。
正解Chatflow 是固定管线,节点沿既定路径执行,适合 RAG 问答、内容生成等确定性流程;Agentflow 由 LLM 自主决策调用哪些工具、跳转到哪些节点,适合开放任务如客服分流与多步工具调用。选错类型会导致流程行为不可控或无法发挥 Agent 能力。
为何常见:两者在 UI 上从同一入口创建、操作方式高度相似,初学者极易忽略其执行语义的根本差异。
误区我把流程 JSON 导出来,升级到新版本再导入不就行了?文件没坏就没问题。
正解Flowise 高度依赖 LangChain 组件版本,v1.x 导出的流程导入 v2.x 时,组件名与参数结构可能不兼容,出现「节点不存在」或配置丢失。跨大版本升级前应在测试环境导入验证,逐节点修正,并固定镜像版本后再规划生产升级窗口。
为何常见:JSON 是通用数据格式,给人「数据可移植」的错觉,忽略了节点定义本身与组件版本的耦合关系。
误区拖拽连线就能做出 AI 应用,那我不需要理解 token、embedding、向量检索这些概念。
正解可视化屏蔽的是工程代码,不是算法决策。不理解 embedding 与向量检索的差异,就无法定位「换了检索方式效果变差」的原因;不理解上下文窗口与提示词结构,就调不好 RAG 的回答质量。Flowise 降低的是实现成本,方案选型与效果调优的决策责任仍在人。
为何常见:低代码宣传强调「零门槛」,容易让人误以为思维模型层面的能力也能被可视化替代。
误区网页聊天组件把 Flowise 接口地址和 API Key 写进前端 JS 里,能用就行。
正解API Key 在请求头明文传递,一旦被浏览器暴露,任何人都能免费调用接口并消耗模型费用。正确做法是「前端 → 自建后端 → Flowise 接口」的代理链路,密钥只保存在服务端,并配合网关限流与访问日志审计。
为何常见:Flowise 官方示例直接给出带 Bearer 头部的 curl 命令,容易让人误以为前端可以直连接口。
面试题
Q1. Flowise 的核心定位是什么?
- A.LLM 模型训练与微调平台
- B.低代码可视化 LLM 应用编排工具← 正确答案
- C.向量数据库管理系统
- D.模型推理性能测试工具
答案:B。Flowise 是低代码 LLM 应用编排平台,核心是可视化拖拽构建 RAG/Agent 工作流。它不负责模型训练(排除 A)、不提供向量存储服务(排除 C)、也不做推理性能测试(排除 D),而是把 LangChain.js 组件封装为节点。
Q2. Flowise 默认通过哪个端口提供 Web 界面?
- A.3000← 正确答案
- B.8000
- C.5000
- D.8080
答案:A。Flowise 默认监听 3000 端口,启动后访问 http://localhost:3000 进入界面。8000 常见于 Django、5000 常见于 Flask、8080 是常见备选端口,均与 Flowise 默认配置无关。
Q3. 关于 Flowise,下列哪些说法正确?
- A.完全开源且支持自托管部署← 正确答案
- B.仅支持 OpenAI 一家模型
- C.流程可一键发布为 REST API← 正确答案
- D.必须使用官方云端服务
答案:AC。Flowise 采用 Apache 2.0 协议开源,可通过 Docker/npm 自托管(A 正确);支持 OpenAI、Anthropic、本地 Ollama 等多家模型(B 错误);每个流程可发布为 REST API 并支持 API Key 鉴权(C 正确);官方云服务只是可选项,不是必须(D 错误)。
Q4. Chatflow 与 Agentflow 的核心区别是?
- A.Chatflow 支持多轮对话,Agentflow 只支持单轮
- B.Chatflow 沿固定管线执行,Agentflow 允许 LLM 自主决策← 正确答案
- C.Agentflow 的响应速度更快
- D.Chatflow 不支持调用向量库
答案:B。Chatflow 按预定节点顺序执行,流程确定性强;Agentflow 由 LLM 决策调用哪些工具、跳转哪些节点,适合开放任务。两者都支持多轮对话与 RAG/向量库能力(排除 A、D),速度取决于模型而非流程类型(排除 C)。
Q5. 通过 REST API 调用已发布的 Flowise 流程时,正确的鉴权方式是?
- A.请求头携带 Authorization: Bearer← 正确答案
- B.URL 查询参数携带 api_key
- C.请求头发送明文账号密码
- D.流程发布后无需任何鉴权
答案:A。Flowise 预测接口 /api/v1/prediction/{flowId} 通过请求头 Authorization: Bearer <API_KEY> 鉴权,API Key 在界面密钥管理中创建。URL 参数会泄露密钥,明文密码用于 UI 登录而非接口鉴权,发布后的流程默认要求带密钥调用。
Q6. 以下哪些是官方支持的 Flowise 部署方式?
- A.Docker 容器运行← 正确答案
- B.npm 全局安装启动← 正确答案
- C.从 GitHub 源码构建← 正确答案
- D.仅限官方云服务
答案:ABC。Flowise 官方文档明确支持 Docker、npm 全局安装(npx flowise start)以及从 GitHub 克隆源码构建三种自托管方式。官方云服务(Flowise Cloud)是托管选项之一,并非唯一部署途径(D 错误)。
Q7. 标准 RAG 问答管道中,节点的正确连接顺序是?
- A.文档加载 → 文本切分 → Embedding → 向量库 → 检索 → LLM 生成← 正确答案
- B.Embedding → 文档加载 → 向量库 → LLM 生成
- C.LLM 生成 → 文档加载 → 向量库 → 检索
- D.向量库 → 文本切分 → Embedding → LLM 生成
答案:A。RAG 入库链路必须先加载文档,再切分为小块,然后经 Embedding 向量化写入向量库;问答时从向量库检索相关内容,最后交给 LLM 结合上下文生成回答。其余顺序在数据流上不成立——未切分的文档无法有效向量化,LLM 生成也不可能作为管道起点。
Q8. 关于 Flowise 生产部署,下列说法正确的有?
- A.应配置 UI 登录账号密码← 正确答案
- B.建议配置反向代理和限流← 正确答案
- C.本地向量库无需持久化
- D.API Key 可写在网页前端
答案:AB。生产环境必须通过 FLOWISE_USERNAME/FLOWISE_PASSWORD 开启 UI 认证(A 正确);外部流量应经反向代理提供 HTTPS 并限流(B 正确)。本地向量库数据不持久化会随容器销毁丢失(C 错误);API Key 暴露在前端会被任意调用者盗用(D 错误)。
Q9. 通过 API 调用带对话记忆(Memory)节点的 Chatflow 时,如何区分不同用户的会话?
- A.在 overrideConfig 中传 sessionId← 正确答案
- B.每次更换新的 API Key
- C.修改 URL 中的 flowId
- D.在 URL 后追加用户 ID
答案:A。Flowise 的预测接口支持在请求体 overrideConfig 中传 sessionId 来区分会话,同一 sessionId 的多次请求共享记忆,不同 sessionId 互不干扰。API Key 只负责鉴权不区分会话,flowId 对应不同流程,URL 参数不是官方支持的会话标识方式。
Q10. 多实例部署 Flowise 时,为保证文档检索数据一致,最可靠的做法是?
- A.挂载共享持久化卷或改用外部向量库← 正确答案
- B.为每个实例配置独立 API Key
- C.增加容器内存配置
- D.所有实例共用同一管理密码
答案:A。多实例部署时,若各实例使用本地向量库且无共享存储,各自写入的向量数据不一致,检索结果会漂移。可靠方案是共享持久化数据卷或直接使用外部向量数据库(Qdrant/Pinecone 等)。API Key、内存、密码都与数据一致性无关。
参考来源
- webpageFlowise 官网产品介绍、云服务入口与官方博客