AREX Feed Article
Workday 收购不到一年，55K 星 Flowise 宣布 8 月 31 日停运
2026 年 7 月 29 日，开源 AI Agent 构建器 Flowise 在官网发布：代码即时冻结，GitHub 仓库将于 8 月 10 日归档，8 月 31 日正式终止全部服务。此时距 Workday 将其收购，不到 12 个月。
Flowise 的 GitHub 仓库拥有超过 5.3 万颗星标。停运通知中，创始人 Henry Heng 给出的理由是："随着 AI 模型推理能力越来越强，我们注意到开发者越来越多地依赖 Claude Code、OpenClaw 等编码 agent 来处理复杂任务。僵化的低代码工作流方式很快在复杂性面前触达极限。"
就在 Flowise 发布停运通知约八周前，OpenAI 也于 6 月 3 日，将于 11 月 30 日正式关闭。两个拥有真实生产用户的 AI Agent 构建器，在同一季度内先后倒下。
"低代码画布撞上了 AI 编码 agent 的天花板"
停运消息在 上引发了 58 点、45 条评论的讨论。用户 itake 写道："两年前，prompt 调试既烦人又繁琐。上下文窗口小、工具链弱，你需要把多个复杂 prompt 串联起来才能完成任何事。现在，你可以给一个 agent 下达 50 多项任务，它会逐项完成。"他的结论：工作流引擎要解决的"可配置代码"问题，现在被 agent 直接维护代码的方式更好地解决了。
另一位用户 pdp 则更直白："因为它是一个工作流构建器。这是错误的思维模型。Agent 和工作流是完全不同的东西。"
在 OpenAI 开发者社区中，用户 Analystfirst 写道："我在这项技术上投入了大量时间，以为它是一个长期工具。构建并提供一个大约 6 个月就被弃用的工具？对我来说这不是一个稳健的商业策略。"另一位用户呼吁 OpenAI 将 Agent Builder 开源，"让那些已经用它启动项目的人可以继续前进"。
StackOne 在 8 月 5 日的中将矛头指向了更实际的问题：可视化构建器层是整个 Agent 技术栈中变动最快的部分，但企业 IT 偏偏把 OAuth 授权、权限范围和审计日志这些最不该频繁迁移的东西锁在了这一层。
作者 Guillaume Lebedel 写道，画布是"agent 技术栈中最可能易手的一层，也是最不适合存放集成的地方"。
从被收购时的高调承诺到不到 12 个月的急刹车
2025 年 8 月 14 日，Workday 通过宣布收购 Flowise。时任 Workday CTO Peter Bailis 在声明中称，"让 AI Agent 开发变得可靠和可访问是一项重大技术挑战。通过将 Flowise 引入 Workday 并投资其开源基础，我们正在赋能客户和合作伙伴。"
Flowise CEO Henry Heng 当时表示，"加入 Workday，我们可以乘势而上，加速实现让任何人无需深厚技术专长即可创建强大 AI Agent 的愿景。"当时 Flowise 拥有 42,000 多颗 GitHub 星标，被描述为"处理了数百万次聊天和工作流"。
Hacker News 用户 mkeeter 在停运讨论中翻出了 Flowise 收购后在 LinkedIn 上发的一条帖子："Flowise 不会去任何地方，我们正在加倍投入。事实上，我们才刚刚开始！"mkeeter 一并附上了专门记录"收购后即关停"现象的 "Our Incredible Journey" Tumblr 博客。
同一周，微软推出了 Power Automate 的 AI 插件，让 Claude Code 和 GitHub Copilot 可以直接从终端生成云流。David Soden 在 上评论道："两家公司读到了同一个信号，做出了相反的反应。Flowise 的结论是这个抽象层已经输了，于是关掉了项目。微软得出了类似的结论，但保留了画布继续运转。"
迁移工作流图只要一个下午，重签 OAuth 授权可能要等六周
当可视化构建器关闭时，什么可以带走，什么带不走，比多数团队预想的更不对称。
工作流图本身是可迁移的部分。节点配置、prompt、分支逻辑和重试设置，要么能以 JSON 格式导出，要么团队可以用代码重新表达。Flowise 的情况更友好：源码在 GitHub 上以 永久保留，创始人明确鼓励团队 fork 仓库并维护内部更新。
带不走的是 IT 团队真正拥有但锁在平台里的东西。每一笔应用连接都是针对旧平台 OAuth client 和 redirect URI 授权的。换到新平台，意味着新的 OAuth client、新的授权确认界面，以及在大多数企业里每个应用都要重新走一遍安全审查。
Agent 可以读薪酬数据但不能写，这条权限边界存在旧平台的权限模型里，不在任何可导出文件中。哪个 agent 在什么时候调用了哪个操作、安全团队签字确认过的审计日志，全部留在即将关闭的厂商手里。
StackOne 的分析把这种不对等总结为一个可量化的对比：迁移工作流图只要一个下午，重签所有 OAuth 授权可能要等六周。每一笔授权都是一张工单、一次审批，而且通常不归最初搭建 agent 的那个人管。
创建连接的人很少是重建连接的人，所以这份工作到达 IT 部门时不是一次有预算、有排期的迁移，而是一次计划外的打断。
88% 的 IT 团队没有集中管理，关停通知就是突击令
OutSystems 在 2026 年 4 月发布的提供了关键的背景数据。这份覆盖 1,900 名 IT 决策者的报告显示：96% 的组织已经在以某种形式使用 AI Agent；94% 担心 AI 蔓延正在增加复杂性、技术债务和安全风险；然而，只有 12% 实施了集中化的平台管理。
对于那 88% 没有集中管理的团队来说，一次构建器关停意味着每个曾自行搭建过 agent 的业务团队都要各自迁移。财务分析师在低代码画布上搭的审批 agent，不会自己去提交 OAuth 重新授权工单。
IT 部门会在 agent 停止工作后被动接手，而且通常没有当初到底授予了哪些权限范围的文档。
StackOne 的立场很明确：编排器是临时的，连接不是。连接器、每个操作的作用域范围、审计日志，这些应该放在画布之下、任何框架或模型之下。迁移到新构建器时，agent 身份、已授权的作用域和日志历史保持原位，变的只是调用方。
这不会让迁移免费：工作流图、prompt 和评估套件仍然需要在新工具中重建。但它消除了依赖其他人日历的那部分工作：安全审查、应用所有者审批、每个记录系统的重新授权。
"画布描述一个调用的形态，但这个调用是否被允许、是否有人能证明它发生过，是由持有凭据的那一层决定的，"StackOne 在此前关于 中已经阐述过这一结构性问题。当权限作用域被绑定在 Agent 调用的那一层而不是配置在构建器内部时，这条边界才能经受住平台更替。
画布会换，连接不该换
两个 Agent 构建器在同一个季度内相继关停，不是市场偶然。Flowise 创始人给出的理由——编码 agent 正在取代低代码画布——仍在加速，这意味着可视化构建器层的洗牌远未结束。对 IT 团队来说，关键的选择不是选哪个画布，而是把什么放在画布之下。OAuth 授权、权限范围和审计日志，这些是每次关停时真正的账单。