这几天不少自部署 Flowise 的朋友都在等一个准信，现在官方靴子落地了。先说结论：Flowise 要停运了，不是停更观望，是 GitHub 仓库已经切成“归档”状态、官网挂出《The Future of Flowise》告别页的那种停运。今天是 8 月 26 日，离官方时间表上的最后一站——8 月 31 日核心团队退出 Discord 和 GitHub——还剩 5 天。Flowise官网
这篇把官方公告原文、GitHub 上能查到的实时数据和社区这两周的讨论都翻了一遍，帮你判断：手里的 Flowise 要不要继续跑、要不要迁、往哪迁。
先对齐事实：官方时间表长什么样
官网的告别页写得很体面，关键信息是这张时间表：
2026 年 7 月 29 日：公告 + 代码冻结。功能开发立即停止，不再审阅和接收新 PR。
2026 年 8 月 10 日：仓库归档。代码永久可见，但 Issues 和 PR 全部锁定，npm 包和 Docker 镜像标记为 deprecated。
2026 年 8 月 31 日：生命周期结束（EOL）。核心团队退出 Discord 和 GitHub 的官方存在，社区管理能移交的移交。
我在 8 月 26 日通过 GitHub API 实测了一下仓库状态：55391 颗星、24949 次 fork，仓库状态 archived: true，最后一次代码推送停在 8 月 13 日——就是创始人 Henry Heng 把 README 改成“Flowise has been archived”的那次提交。GitHub顺手查了下周边生态：聊天嵌入组件 FlowiseChatEmbed 5 月就已归档，文档仓库 FlowiseDocs 6 月也归档了。也就是说，这不是某个模块停摆，是整个官方盘子在收。
代码本身不会消失：Apache 2.0 协议，官方明确鼓励 fork 继续维护。但“代码还在”和“项目还活着”是两码事，后面说这对不同用户意味着什么。
官方给的理由，比想象中坦诚
小红书上记录这次关停的观察帖也注意到了这份反常：大家原本以为官方会解释运营成本或商业压力，结果团队重点谈的，却是开发者正在改变构建 AI 应用的方式。小红书一般项目停运，官方话术都是“运营成本”“战略调整”。Flowise 这段告别词里真正有意思的是这句——官方点名说，AI 模型推理能力越来越强，开发者正越来越多地依赖 Claude Code、OpenClaw 这类新一代编程智能体（coding agent）来处理复杂任务，而低代码那种“固定流程画布”的玩法，一碰到复杂需求就很快触到天花板。Flowise官网翻译成人话：我们不是被竞品打死的，是被“AI 直接写代码”这条路线绕过去的。
社区这两周的讨论也基本在印证这个说法。小红书上一篇 77 赞的停运观察帖下面，有条高赞评论很直白：“当代码编写和理解不再是门槛，低代码平台也就没那么有必要了。我退休了的父母没有编程基础，现在 Claude Code 已经用得很溜了”。小红书知乎上这两天也有帖子在讨论“AI 写代码这么强了，低代码平台还有未来吗”。知乎圈子里的情绪不是惋惜居多，更多是“果然如此”。
再补两个公开背景，帮你把这件事看全：
第一，商业层面，据 HR 科技行业观察方向的账号在 2025 年 9 月的报道，Workday 完成了对 Flowise 的收购（当时描述就是“低代码 AI Agent 构建平台”）。小红书之后翻 Flowise 的提交记录，从今年 3 月起出现了多位 workday 邮箱后缀的贡献者，主要在修安全问题。
第二，安全层面，这个项目今年压力相当大：4 月曝出 CVSS 满分 10.0 的 RCE 漏洞（CVE-2025-59528），6 月 360 漏洞挖掘智能体一口气发现 13 个 0day，7 月更是出现过一天挂出约 30 条安全公告的场面。知乎微博回头看，最后一个正式版 3.1.4 发布于 7 月 29 日——正好是官宣代码冻结那天，更新日志几乎全是安全修复。可以说最后这个版本，就是给所有自部署用户的“告别补丁”。仓库的安全说明页也写得明白：项目正式进入停运流程，将很快停止积极维护与支持，不再接收新的安全漏洞报告。GitHub
关键问题：你属于哪种用户，决定完全不一样
停运这件事，对不同人的杀伤力差别很大，分开说。
第一种：还没部署、只是收藏过教程的。 结论最干脆：别入坑了。npm 包和 Docker 镜像已经标记废弃，8 月 31 日之后连官方答疑渠道都没有，一个 5.5 万星、历史上有过满分 RCE 且被在野利用过的工具，没人维护之后暴露在公网上是什么后果，不用多想。新需求直接看下一节的迁移方向。
第二种：部署在个人电脑、内网或 NAS 上玩 demo 的。 可以继续跑，但做个自查：这个实例有没有暴露在公网？里面存的模型 API Key、第三方服务凭证有多少？如果纯内网、不存敏感凭证，当个本地玩具没问题，反正代码是 Apache 2.0，想留多久留多久；如果挂了公网端口，建议要么关掉公网访问，要么趁早迁移。
第三种：跑在生产环境、嵌在公司网站或业务里的。 这是最需要认真对待的一批，三条路摆出来：
原地加固继续跑：适合流程简单、暂时没人力迁移的团队。前提是确认版本停在 3.1.4（已知漏洞修复最全的版本），关掉不必要的外部访问，把里面存的凭证全部换一轮。注意这只是买时间，不是解决方案。
fork 自维护：官方明确鼓励这条路，但要想清楚成本——这个仓库是 server/ui/components 的 monorepo，上游生态（LangChain 等）还在快速动，长期靠一两个人跟安全补丁，负担不轻。适合有前端 + Node 开发能力、且把 Flowise 当内部基础设施的团队。另外社区里已经有人提醒：社区主体代码是 Apache 2.0，但 enterprise 目录是商业许可，fork 前先看清楚边界。小红书
迁移到其他平台：大多数人的现实选项，往下看。
迁移方向怎么选：三张地图
结合最近知乎、小红书上几篇对比讨论和官方定位，给你一张简化版路标：
做知识库问答、客服机器人、单 Agent 的 → Dify。 和 Flowise 定位最接近，可视化 + 开源 + 可自部署，RAG 和 Agent 应用类型划分清楚，中文社区教程现在也最活跃。迁移时重点核对三样：模型凭证配置、知识库文档重新灌入、以及对外接口的调用方式（Flowise 的 API/embed 组件要换成 Dify 的对应形态）。
主要做跨系统自动化、触发器式流程的 → n8n。 如果你的 Flowise 流程本质是“收到表单→调模型→写回表格→发通知”这类自动化，n8n 的节点生态和错误重试机制更顺手，社区里“跨系统自动化选 n8n”基本是共识。小红书
流程复杂、团队里有会写代码的 → 直接用编程智能体重写。 这正是 Flowise 官方告别词里指的方向：用 Claude Code 这类工具，把原来画布上拖出来的逻辑直接写成代码，灵活度和可调试性都更高，代价是得有基本的工程能力，且要注意代码要自己管好——没有了平台的护栏，权限和密钥管理全靠自己。
提个醒：有今年 5 月的对比帖给新手的排序就是 Dify 优先、Flowise 次之，现在这个排序变成了既定事实。知乎另外别把宝押在“再等等看有没有社区 fork 接盘”上——截至发稿，还没看到有影响力的社区 fork 冒出来，2.4 万次 fork 里绝大多数只是收藏性质。
最后聊两句行业信号
Flowise 的离场值得多看一眼，因为它是很少见的、把“被 coding agent 淘汰”写进官方告别词的 5 万星级开源项目。画布式低代码的核心卖点是“不用写代码”，而当 AI 把写代码的门槛直接铲平，这个卖点就悬空了。
但也不急着给低代码整体判死刑，留两个反方证据。一是 coding agent 赛道本身迭代极快，前段时间社区还在围观某个当红编程智能体项目从爆火到热度速冻，工具选型的波动风险并不比低代码小。小红书二是可视化画布的价值不只是“不会写代码的人能用”，还在于业务、开发、运营能围着一张图一起改 Agent，这个协作场景短期内没有替代品。
接下来值得持续盯的信号：有没有社区 fork 真正立起来接盘维护、Dify 或 n8n 会不会顺势推出 Flowise 流程导入工具、以及 8 月 31 日之后官方 Discord 的实际状态。有进展再来同步。
如果你手里正跑着 Flowise，评论区聊聊你的处置方案，给同在坑里的朋友一个参考。
