最近技术圈里流传着一个让人心里一紧的标题“Flowise is shutting down”。如果你正用 Flowise 搭过 Agent、做过 RAG 知识库或者只是把它列入技术选型清单看到这句话第一反应多半是我手上的工作流怎么办是不是要立刻迁移这里先给一个偏冷静的判断“shutting down”不一定等于“开源项目彻底死亡”。在 LLM 工具快速迭代的这几年很多“关停消息”最后被证实是托管服务下线、某个子项目调整甚至只是某个匿名用户的个人实例关闭。真正值得关心的不是一条标题而是三件事第一Flowise 当前到底处于什么状态第二如果你的 LLM 应用真的建在 Flowise 上备份和迁移路径是否完整第三下一次再遇到类似消息你用什么方法快速验证真伪。这篇文章会从 Flowise 的核心概念讲起带你完成一次完整的本地自托管部署再用 Flowise 搭一个最小可用的 LLM 问答工作流最后给出“如果项目真的停止维护你该怎么迁移、怎么选替代方案”的工程级建议。读完你至少能回答一个问题离开 Flowise你的 Agent 会不会一夜之间跑不起来1. 技术圈的“关停消息”为什么总让人焦虑先不谈 Flowise 本身聊一个更普遍的规律越是被社区大量使用的开源工具越容易出现“关停谣言”。原因很简单这类工具用户基数大只要 GitHub 仓库几天不更新、官方发布一条调整公告、或者有人在社交媒体上说“我准备迁移出去”整个传播链就会自动补全剩余的恐慌部分。但技术决策不能建立在标题情绪上。一个开源项目停止维护和一家 SaaS 公司关闭服务器性质完全不同。前者你手里有源码最坏情况下还能 fork 后继续维护后者如果数据没导出才叫真正的“一夜归零”。所以正确做法是把“Flowise is shutting down”拆成几个可以验证的问题官方 GitHub 仓库是否还显示 Active 状态最近一次 commit 和 release 是什么时候官方文档和 release 页面是否有“停止维护”“存档”“云服务下线”的说明npm 包或 Docker 镜像是否还在正常更新社区 issue 里是否有官方维护者回应如果在这些渠道上看到的都是“正常更新”那这条标题大概率对应的是自托管实例或某个特定托管服务的下线而不是 Flowise 项目主体关闭。更本质的一点是LLM 应用开发工具正处在“基础设施还没定型”的阶段。今天火的编排工具三个月后可能被新框架取代今天很顺手的可视化平台明天可能被大模型厂商内置能力覆盖。这不是 Flowise 独有Dify、Langflow、n8n 都面临同样的不确定性。因此与其把全部安全感寄托在“某个平台永远活着”上不如把技能重点放在理解节点、导出流程、备份数据、会迁移。这些能力在任何框架下都能复用。2. Flowise 的核心概念与适用场景Flowise 是一个开源的可视化 LLM 应用编排工具如果你用过 Node-RED 或 n8n上手会非常快。它把 LLM 应用拆成一个个节点例如LLM 节点配置模型提供商和模型名例如 OpenAI、Azure OpenAI、本地 Ollama。Prompt 节点编写系统提示词和用户提示词模板。Memory 节点保存对话历史支持 Buffer Memory、Window Buffer Memory 等。Vector Store 节点对接向量数据库例如 Pinecone、Chroma、Qdrant用于 RAG 场景。Tools 节点给 Agent 挂载搜索、计算、API 调用等工具。Chain 节点把前面所有节点串成一条完整调用链。从架构上看Flowise 底层大量借鉴了 LangChain 的链式架构思想。你拖拽出来的流程图本质上是在生成一段“模型调用 外部工具 记忆管理”的编排逻辑。它最大的价值是让不熟悉 LangChain 工程细节的人也能快速搭出一个有记忆、有工具、有知识库的 Agent 原型。2.1 Flowise 适合什么场景快速验证 LLM 应用原型团队想验证“给客服做一个基于内部文档的问答机器人”是否可行Flowise 可以在几小时内跑通从上传文档到问答案例的闭环。非后端团队参与 AI 应用设计产品经理、运营人员也能通过拖拽理解 Agent 的数据流减少“需求翻译”的损耗。小规模业务机器人在流量不大、对部署要求不高的内部工具或 demo 中Flowise 可以直接承担运行时职责。RAG 知识库快速搭建Flowise 对常见的文档加载、切分、向量化、检索流程做了封装比手写 LlamaIndex 或 LangChain 代码快很多。2.2 Flowise 不适合什么场景高并发大规模生产系统Flowise 的节点编排在性能上有一定运行时开销相比直接用代码调用模型不适合极端性能要求的场景。复杂权限和审计需求如果需要精细到接口级的权限管控、严格的审计日志原生 Flowise 不能满足需要二次开发。深度定制模型调用逻辑部分特殊模型、特殊采样参数、自定义 Agent 决策逻辑用节点很难表达清楚不如直接写代码灵活。前端界面深度定制Flowise 自带聊天界面主要用于 demo若需要复杂客服工单、多轮流程表单还是要自研前端。因此Flowise 更准确的定位是**“从想法到可运行原型之间的加速器”**而不一定是最终生产系统的全部底座。理解这一点再去看“是否停止维护”的恐慌就更容易理性取舍你可以把它当成开发工具而不是不可替代的生产依赖。3. 环境准备与前置条件为了不受“官方云服务状态”影响最稳妥的方式是自托管部署 Flowise。自托管以后只要 Docker 镜像还能拉取、Node.js 依赖还能安装你的本地环境就不会因为外界消息而立刻失效。3.1 环境要求Flowise 官方支持两种主要部署方式Docker 和 Node.js 源码运行。版本号会持续变化以下配置以官方仓库当前推荐为准如果后续版本有调整以你实际拉取到的镜像和官方 README 为准。环境推荐配置操作系统LinuxUbuntu/Debian 更推荐、macOS、WindowsDocker DesktopDockerDocker Engine 20.10docker-compose 或 Docker Compose v2Node.js源码方式Node.js 18 或更高版本npm 或 yarn内存至少 2GB 可用内存RAG 场景建议 4GB模型 APIOpenAI API Key 或兼容接口本地模型可配合 Ollama这里有一个容易被忽略的点Flowise 默认端口是 3000。如果你本机已经运行了其他 Web 服务占用 3000 端口需要提前改端口。3.2 Docker 部署 FlowiseDocker 部署是最省心的方式适合大多数场景。执行命令前先确保 Docker 已启动。# 创建数据目录便于备份持久化数据 mkdir -p /data/flowise cd /data/flowise # 运行 Flowise 容器 docker run -d \ --name flowise \ -p 3000:3000 \ -v $(pwd)/flowise-data:/root/.flowise \ flowiseai/flowise:latest参数说明-d后台运行。--name flowise指定容器名称方便后续查看日志和启停。-p 3000:3000映射宿主机的 3000 端口。-v $(pwd)/flowise-data:/root/.flowise把 Flowise 的配置和数据库目录持久化到宿主机这是备份的关键一步建议必须加。flowiseai/flowise:latest官方镜像。生产环境不建议直接用latest可以锁定一个具体的 release 版本号。启动后访问http://localhost:3000能看到 Flowise 的向导页面。3.3 使用 docker-compose 管理项目稍微复杂度提升后我更推荐用docker-compose.yml管理方便修改环境变量和映射端口。# 文件路径docker-compose.yml version: 3.8 services: flowise: image: flowiseai/flowise:latest container_name: flowise restart: unless-stopped ports: - 3000:3000 environment: - PORT3000 - FLOWISE_USERNAMEadmin - FLOWISE_PASSWORDyour-strong-password # 如果你的模型服务走的是本地地址可以配置为宿主机可达地址 # 例如 Ollama 在宿主机时容器内访问需要指向 host.docker.internal # - OLLAMA_BASE_URLhttp://host.docker.internal:11434 volumes: - ./flowise-data:/root/.flowise启动命令docker compose up -d设置FLOWISE_USERNAME和FLOWISE_PASSWORD后访问 Flowise 会要求登录。注意这两个环境变量只是基础访问保护Flowise 内置的登录并不是企业级身份认证系统生产环境建议再加一层反向代理和更严格的安全策略。3.4 源码方式运行可选如果你需要研究 Flowise 内部实现或者要给 Flowise 做二次开发可以使用源码方式。# 拉取代码 git clone https://github.com/FlowiseAI/Flowise.git cd Flowise # 安装依赖 npm install -g pnpm pnpm install # 构建并启动 pnpm build pnpm start源码方式对 Node.js 版本和依赖安装速度有一定要求如果只是使用功能建议优先 Docker。4. 使用 Flowise 搭建一个最小 LLM 问答工作流环境跑起来后我们来做一个最小可用的 LLM 问答工作流。目标很直接用户在聊天窗口输入问题模型返回回答并且能记住多轮对话上下文。4.1 创建 Flowise 流程打开http://localhost:3000登录后点击“Add New”创建流程。画面中的画布就是你的工作区左侧有节点面板可以搜索基础节点。一个最小对话流程需要以下节点Chat Model选择模型提供商例如 OpenAI Chat Model填入 API Key 和模型名。Prompt Template编写提示词模板。Chat Memory使用 Buffer Memory 作为对话记忆。LLM Chain把模型、提示词、记忆组装起来。拖拽完成后节点连接方式大致是Chat Model → LLM Chain → 输出 Prompt Template → LLM Chain Chat Memory → LLM Chain4.2 配置 Chat Model 节点在 Chat Model 节点中Connect Credential新建一个 OpenAI API 凭证输入你的 API Key。Model Name例如gpt-4o-mini或gpt-3.5-turbo。具体以你账号可用的模型为准。Temperature先保持默认后续按效果调整。如果使用的是 OpenAI 兼容接口例如本地 vLLM、OneAPI 或国内云厂商的兼容网关需要看官方节点是否支持配置Base URL。有些第三方节点支持配置自定义 endpoint没有的话就选择原生 OpenAI。4.3 配置 Prompt 模板在 Prompt Template 节点中写入提示词模板你是一个乐于助人的技术助手。请用简洁、专业的中文回答用户问题。 上下文记忆 {chat_history} 用户问题 {question}{chat_history}和{question}是聊天记忆和用户输入注入到提示词模板中的占位符。不同版本的 Flowise 对变量名要求可能不同如果节点没有自动解析可以在 LLM Chain 节点的配置里查看输入变量。4.4 测试对话流程点击画布右上角的“Chat”按钮会打开聊天预览窗口。输入你好请用一句话介绍你自己。再输入请记住我叫张三。 我问题我叫什么名字如果配置正确第二次回答应该能结合历史记忆回答“张三”。这说明 Chat Memory 已经生效。4.5 导出流程文件Flowise 的流程可以通过右上角菜单导出为 JSON 文件建议在完成每个重要版本后都导出一份。流程界面右上角 → 菜单 → Export Flow导出文件是一个包含节点、连线、配置的 JSON。它不包含你的 API Key但包含模型名称、提示词等配置可以用于版本管理和迁移到其他实例。5. 通过 API 调用 Flowise 工作流Flowise 画布里的流程最终要成为可调用的接口。核心思路是把流程导出为可嵌入的 widget或者通过 Flowise API 触发。不同版本 API 路径略有差异下面演示最常见的方式。5.1 获取 Chatflow ID保存流程后在流程列表页可以看到每个流程都有一个chatflowId通常也可以从流程 URL 中提取。API 调用时需要这个 ID。5.2 使用 curl 调用curl http://localhost:3000/api/v1/prediction/{chatflowId} \ -X POST \ -H Content-Type: application/json \ -d { question: 请用一句话介绍你自己 }参数说明{chatflowId}替换成你的流程 ID。question是用户输入。如果流程开启了历史会话请求中可能需要携带sessionId。具体字段以当前版本的 API 文档为准。5.3 使用 Python 调用import requests BASE_URL http://localhost:3000 CHATFLOW_ID your-chatflow-id resp requests.post( f{BASE_URL}/api/v1/prediction/{CHATFLOW_ID}, json{question: 请用一句话介绍你自己} ) print(resp.status_code) print(resp.json())运行之前需要先安装requests库pip install requests5.4 如何验证 API 调用成功成功返回时响应 JSON 中通常包含text字段或output字段里面是模型回答内容。如果返回 401说明需要配置 API 凭证如果返回 404说明chatflowId不对如果返回 429说明请求太频繁或流量限制。Flowise API 不是 OpenAPI 强约束标准每次版本升级都可能调整返回结构。生产环境建议在代码层面对响应做容错处理不要依赖固定字段名。6. 如果 Flowise 停止维护如何降级风险与迁移回到开头的标题。即使 Flowise 真的停止维护你也并非无路可走。开源生态的特点是项目会死代码不会消失数据还在你手里。6.1 从使用层到数据层确认“你手里有什么”自托管 Flowise 时真正重要的数据只有两类Flowise 配置数据库默认是 SQLite位于/root/.flowise目录下。里面保存了用户、凭证信息、流程定义等。你主动导出的 JSON 流程文件包含节点图和配置。你的向量数据库数据如果你用了 Chroma 等本地向量库需要单独备份向量库目录。因此最稳妥的自保动作是# 进入 Flowise 数据目录 cd /data/flowise # 停止容器避免备份过程中数据写入 docker stop flowise # 备份整个数据目录 tar -czvf flowise-backup-$(date %Y%m%d).tar.gz flowise-data # 重新启动容器 docker start flowise这个备份包可以让你在另一台机器上恢复 Flowise 实例。前提是版本尽量一致数据库跨大版本可能存在兼容问题。6.2 导出流程定义并迁移到其他平台即使你决定放弃 Flowise也不要先删数据再找替代方案推荐按以下顺序迁移导出所有 Flowise 流程 JSON。梳理流程中用到的模型、向量库、外部 API列出依赖清单。在替代平台里重建流程。做业务验证使用原有测试集对比回答质量。切换流量修改上游调用方把请求从 Flowise API 切换到新平台 API。观察期后再下线 Flowise。如果你会用 LangChain 写代码Flowise 导出的配置可以作为“设计文档”来参考你完全可以把节点连线翻译成 LangChain 代码。因为 Flowise 本身就是 LangChain 思想的图形化实现翻译成本并不高。6.3 替代方案对比平台类型特点适合人群Flowise开源可视化 LLM 编排拖拽灵活贴近 LangChain 架构快速原型、中小型应用Dify开源 LLMOps 平台内置 RAG、Agent、工作流、监控和数据集管理需要完整 LLM 应用运营闭环的团队Langflow开源可视化数据流和 LangChain 强绑定节点式编程熟悉 LangChain 的开发者n8n开源自动化平台不只是 AI还覆盖业务流程自动化已经用 n8n 做自动化顺便接 AI 的团队Code (LangChain/LlamaIndex)编程框架完全可控无平台绑定对性能和定制要求高的生产项目从管理成本看Dify 在“可视化 观测 团队协作”上比 Flowise 更完整n8n 在业务流程集成上更强Langflow 对 LangChain 开发者更友好。没有绝对最优只有和你业务形态最匹配。7. Flowise 常见问题与排查方法问题现象可能原因排查方式解决方案容器启动后访问 3000 端口无响应端口被占用或容器启动失败执行docker ps -a查看容器状态执行docker logs flowise查看日志修改宿主机映射端口例如-p 3001:3000聊天测试时提示 API Key 无效凭证配置错误或 Key 过期在 Flowise 凭证管理里重新保存 Key确认模型服务商的 API 控制台可用重新配置凭证确认可用后在模型节点更新提示词中的{chat_history}不生效版本变量名不同或未正确连接 Memory 节点查看 LLM Chain 节点的输入变量提示根据当前版本调整占位符名称重新连接 Chat Memory调用 API 返回 401访问未授权或未配置 API Key查看服务端日志确认是否启用了应用保护配置FLOWISE_USERNAME/FLOWISE_PASSWORD或添加 API Key 请求头导出 JSON 后导入其他实例失败目标实例版本过低或过高对比源实例与目标实例版本升级目标实例到相同版本或手工调整 JSON 中的节点类型Docker 容器频繁被系统杀掉内存不足执行docker stats查看内存增加宿主机内存或限制模型并发请求排查时最有效的动作永远是先看日志而不是猜配置。docker logs -f flowise日志中如果出现EADDRINUSE说明端口被占用如果出现MODEL_NOT_FOUND说明模型名配置错误如果出现UNAUTHORIZED说明凭证问题。先把错误关键词定位到再搜解决方案效率会高很多。8. 工程建议与风险控制8.1 不要把“可视化编排”当成生产系统的全部Flowise 这类工具最理想的使用姿势是用它做原型验证和中小型业务而不是把所有生产业务都押在一个节点的拖拽配置上。如果项目已经进入高并发、强监管、多团队协作阶段底层建议替换为代码编写 版本管理用 Flowise 做配置预览和调试而不是运行时依赖。8.2 配置和密钥管理不要把 API Key 直接写在流程配置里尤其是团队多人共用一个 Flowise 实例时。Flowise 支持凭证管理功能尽量在凭证中心集中配置。同时不要在导出的 JSON 中泄露 Key。如果怀疑 Key 已泄露立刻去模型服务商控制台吊销并更换。8.3 数据备份一定要自动化手动备份容易遗忘可以用系统定时任务配合 docker 命令完成。# 每天凌晨 2 点执行备份 0 2 * * * cd /data/flowise docker stop flowise tar -czvf flowise-backup-$(date \%Y\%m\%d).tar.gz flowise-data docker start flowise find /data/flowise -name flowise-backup-* -mtime 7 -delete这段命令的意思是停止容器、压缩数据目录、启动容器、删除 7 天前的备份文件。实际使用前先在测试环境验证一遍不要直接在生产环境执行。8.4 锁定依赖版本使用 Docker 镜像时不要在生产环境用latest标签。例如image: flowiseai/flowise:1.8.2这样可以避免官方发布新版本后你的生产环境因为依赖变化而“悄悄升级”。每次升级前先在测试环境确认兼容性再迁移生产数据。8.5 关注社区动态但不要被舆论绑架判断一个开源项目是否值得依赖看三个信号提交频率是否有持续维护。Issue 响应维护者是否回应用户问题。关键节点变更底层框架如 LangChain大规模变更时项目是否跟上。但即使各项信号都很好也要为自己留后路。技术生态里唯一的不变就是变化。9. 总结与后续学习方向回到最初的标题。“Flowise is shutting down”不一定是一个已经发生的事实但把它当作一次“末日演练”非常有价值。通过这次演练我们应该确认自己做到了四件事Flowise 是否已经用 Docker 自托管数据目录是否做了持久化。重要流程是否导出了 JSON 文件并纳入版本管理。是否清楚自己的 Flowise 实例使用了哪些模型、向量库和第三方服务。是否了解至少一个替代平台的迁移路径。完成了这四步Flowise 是否关停对你来说就不再是一个“生死攸关”的问题而只是一个“要不要换工具”的技术决策。这也是所有依赖快速迭代开源工具团队的生存法则工具可以换数据必须在自己手里核心逻辑必须能翻译成代码。下一步建议你挑选一个自己最常用的 Flowise 流程亲自完成“导出 JSON → 用 LangChain 代码重建 → API 输出一致”这一条链路。这个过程会逼你理解 Prompt、Memory、Model 在数据流中到底如何协作也会让你从“拖节点的人”变成真正理解 LLM 应用编排的人。建议先把这篇文章收藏备用特别是 3.2 节的 docker-compose 配置和 6.1 节的备份命令等真的需要迁移时你会感谢当时的这个备份动作。