10月29日Coze企业版宣布全面下线，社群和朋友圈都炸了。今年5月专业版停服、30款模型分批下架，这个节奏早有预兆：拖拽节点在替模型的笨买单，工作流只是过渡形态。

10.29 号，Coze 官方宣布企业版本即将全面下线。

这条消息出来以后，我的社群和朋友圈都快炸了。大家都很感叹，作为字节之前的明星产品，在 AI 这波浪潮下，来得快，去得也快。

又一次印证了一个观点：在 AI 时代，只要你学得慢，你就不用学了。

不过这次扣子下线的是企业版，并不是整个扣子下线。

其实，Coze企业版本下线我们早有预兆，今年5月，Coze 专业版停服、后面分批次下架了接近30款模型、海外版又批量下线了多项核心功能，这明显不是一个正常的节奏。

之前我们课程体系中还会讲解如何用 Coze 搭建工作流 AI。在今年 4 月份，我们就已经放弃了 Coze 平台作为工作流 AI 的载体，并全面转向了 AI Coding 的方式。

正如前面那哥们说的，我们之前拼命做的拖拽节点，其实是在为模型的笨买单。Coze 这类低代码工作流平台，本身就是 AI 发展过程中的一种过渡形态。

随着大模型越来越强大，自己会规划任务、决定下一步做什么的时候，之前需要人手动编排的很多工作，现在 Agent 自己就可以完成了。

但这并不是说工作流技术就过时了。

Coze 企业版为什么会下线？

这次 Coze 企业版下线，我认为核心原因，还是字节内部的战略调整和资源分配问题。

第一，字节内部的 AI 战略开始收拢，资源需要向核心业务集中。

如果关注过字节今年在 AI 领域的动作，就知道字节正在不断调整内部的 AI 产品线，把资源往豆包集中，响应粗主干的战略。

今年7、8 月，飞书、TRAE 和 Coze 团队被整合进豆包体系，接着字节推出了独立的 AI 办公产品「豆包工作」。

而Coze 企业版在做 AI 办公、企业工作流和智能体开发，豆包工作也在做 AI 办公，飞书本身又有成熟的企业协作生态，而火山引擎负责企业级 AI 基础设施和交付。

对于字节来说，内部有多条产品线做相似的事情，就意味着重复投入研发资源、运营资源和企业交付成本。

与其同质化竞争，不如把相关能力整合进核心产品，让资源更加集中。

第二，Coze 在 ToB 这条路上，本身也没有竞争优势。

Coze 最初能够火起来，很大程度上就是因为门槛低，主打一个C端小白。不用懂编程，拖几个节点、配置下模型，就能搭建一个 Chat Bot 或者工作流。

这对于个人开发者、小团队以及想快速验证 AI 场景的业务人员来说，确实非常有吸引力。

但是，ToB 和 ToC 完全是两回事，在toB这块，Coze 并没有竞争优势。

像腾讯有企业微信，阿里有钉钉，这些产品本身就连接着大量企业的组织架构、员工、文档以及业务流程。

企业想引入 AI，可以直接在现有的办公生态上扩展，不需要再引入一套完全独立的平台。

而字节自己也有飞书和火山引擎，在企业办公和 AI 基础设施方面，更有优势。

这样一对比，Coze 企业版的定位就非常尴尬了。

所以，字节选择放弃独立的 Coze 企业版，把资源集中到更有优势的业务上，我觉得并不意外。

当然，这次下线 Coze 企业版套餐，并不能说明工作流平台就没有价值了。

事实上，Coze 这类工作流平台能够在过去几年迅速流行起来，并且被大量使用，说明它解决了很多实际问题。

那为什么现在却越来越倾向于使用 Agent 和 AI Coding 呢？

要回答这个问题，我们不妨先回顾一下，工作流平台当初为什么能够流行起来。

工作流平台为什么流行？

Coze 这类工作流平台，在过去两年多的时间里非常流行，我认为主要有几个原因：

第一，极大地降低了 AI 能力接入门槛。

在这之前，想调用大模型、做知识库检索、串联多个 AI 动作，通常需要工程团队花费一定时间去开发。

而这类平台把这些能力直接封装成可视化的节点，让产品和业务同学像搭建积木一样去实现自己的业务流程，几个小时内就可以跑通一个可用的 MVP。

这对于想要快速验证 AI 价值的企业来说，这样的效率提升是无法拒绝的。

对于个人用户而言，也可以拿它快速搭建工作流。在 Agent 还没普及之前，这确实是门槛最低、当前最优的一种解决方案。

第二，提供了开箱即用的工具链。

它还内置了知识库、数据库、版本控制、运行日志追踪等一套应用开发能力，用户不需要自己从零去搭建这些基础配套设施，拿来就能用，这极大降低了启动成本。

第三，具备开源和私有化部署能力。

开源版本的存在，让企业可以基于底层代码做定制化改造，嵌入内部身份认证系统、对接私有数据源、适配业务特有的流程规范、添加自定义组件节点。

正是这些优势叠加在一起，Coze 这类平台在过去几年里被大量企业、个人用户使用。

从我们接触的案例来看，有很多公司在这一块使用得非常深入，他们基于开源版本做二次封装，叠加自己的定制化需求，来搭建企业内部的 AI 应用开发平台。

见过最多的是，内部有几百个工作流都是在 Coze 平台上搭建的，覆盖客服问答、内容生成以及内部数据处理等各类场景。

所以我们不能因为 Coze 企业版下线，就否定这类平台曾经创造的价值。

只不过，随着 Agent 能力越来越强，过去这种以人工编排为核心的开发方式，也开始暴露出越来越多的问题。

工作流平台遇到的瓶颈

工作流的整个搭建过程，是人把复杂任务拆成一个个节点，明确每个节点的输入和输出，再用连线确定执行顺序，模型只需要在指定的节点完成非常明确的任务。

这里的分工逻辑是：人负责规划，模型负责执行。

这种方式在业务逻辑简单、流程固定的情况下，确实很好用。但随着业务越来越复杂，问题也开始暴露出来了。

第一个问题，就是工作流太死板，维护成本太高。

工作流最大的特点是确定性，我们提前把各种可能出现的情况考虑进去，再通过条件判断、循环、分支等节点控制执行过程。

当业务逻辑变得复杂以后，节点可能从最初的几个增加到几十个，甚至上百个，整个画布跟蜘蛛网一样，让人眼花缭乱。

更麻烦的是后期维护。一旦有需求变动，你要从几百个节点中去找到目标节点就非常困难，并且极有可能，你改动其中一个节点，会导致很多节点都要跟着修改，迭代维护成本就上来了，甚至根本维护不动。

业务越复杂，这个问题就越明显。

随着模型的理解、推理、编程和工具使用能力不断提升，分工逻辑开始发生变化。

以前，我们需要告诉它：先执行第一步，再执行第二步；如果遇到某种情况，就进入某个分支。

现在，Agent 已经可以自己根据任务目标拆解步骤，选择对应的工具，并根据执行结果规划下一步了。

所以之前我们也说过，像 Coze、Dify 这种纯手动拖拉拽的工作流编排方式，很可能只是 AI 发展过程中的一种阶段性产物。

站在现在的视角来看，与强调自主规划和动态执行的 Agent 范式相比，这种需要手动编排大量节点的方式，确实显得没那么先进，也没有吸引力了。

就好比现在大家都 AI Coding 了，谁还愿意去古法编程呢？

当然，这只是从开发方式的角度来说，并不意味着所有业务都应该交给 Agent 自主执行。

第二个问题，就是低代码平台始终无法解决的两难处境。

Coze 工作流平台本质上就是低代码开发范式，类似这种工具早在 AI 出现以前就有了，甚至还有无代码平台，只不过是扣子这类平台又把这个范式带到了 AI 时代。

它们一直想解决一个问题：让不懂编程的人，也能通过拖拉拽的方式开发应用。

想法很好，但现实往往没那么简单。

对于程序员来说，不会太喜欢。拖拉拽不一定比直接写代码效率高，特别是遇到复杂逻辑的时候，写代码反而更灵活，也更容易管理和维护。

而对于非技术同学来说，搭建起来又挺吃力的。

虽然整体门槛是降低了，但遇到代码、循环、数据结构组装、HTTP 请求等节点的时候，还是会把他们难住，并且这里还是需要有一定的编程思维才行。

所以就出现了一个很尴尬的局面：简单的工作流，业务同学自己就能搭建，但解决的问题有限；复杂的工作流，业务同学搞不定，最终还是得找程序员帮忙。

平台想要做得足够灵活，就必须提供更多节点和配置能力，这样上手门槛就越来越高。

反过来，如果为了降低门槛，把功能做得非常简单，又无法满足复杂业务的场景。

两边都很难兼顾，这其实也是很多低代码平台长期面临的问题。

只不过 Coze 更偏向低门槛和个人开发者生态，Dify 则更多面向企业级应用开发，给研发团队提供 AI 应用开发和运行的平台。

而 AI Coding 的出现，恰恰正在改变这个局面。

过去我们选择低代码平台，是因为写代码的门槛太高。

但现在，很多原本需要通过拖拉拽配置的功能，我们直接通过自然语言告诉 Agent，它就能帮我们生成对应的代码。

既不需要自己手动搭建几十上百个节点，也不用被平台预先提供的节点能力限制住。

当然，AI 生成的代码同样需要测试、维护和管理，但至少在开发方式上，我们多了一种更加灵活的选择。

所以我认为，真正受到冲击的，并不是 Workflow 这种技术范式，而是依赖人工拖拉拽来构建复杂 AI 应用的开发方式。

工作流平台的价值仍然会存在

虽然我也不太喜欢这种拖拉拽的工作流平台，但不得不承认，它们在企业生产环境中的价值是真实存在的，因为确实解决了很多实际的业务问题。

甚至在我看来，企业中大量流程相对固定的业务场景，使用 Workflow 就已经足够了，根本没必要引入复杂的 Agent 架构。

为什么这么说？

因为企业生产环境和个人使用场景不一样。

个人使用 Agent，可以接受它偶尔犯错，大不了多尝试几次。但企业不一样，容错率是很低的，企业场景会更关注确定性、稳定性和成本。

比如一个固定的业务流程，输入什么、经过哪些处理环节、最终输出什么，都需要尽可能可控。一旦出现问题，还能通过运行日志快速定位到具体的执行节点，方便排查和追溯。

而这恰恰是 Workflow 的优势。

相比之下，Agent 虽然更加灵活，能够自主规划任务、动态选择工具，但也意味着执行路径更加不可预测，调试难度和运行成本往往也更高。

这里并不是说 Agent 不好，而是没必要为了追求技术上的先进，把原本简单的问题复杂化。

所以，前面说 Coze 这类平台是阶段性产物，并不是说 Workflow 这种范式要被淘汰，而是指纯粹依赖人工拖拉拽节点来开发复杂 AI 应用的方式，正在失去原有的优势。

这其实是两个不同的概念。

Workflow 是一种任务编排范式，而 Coze、Dify 只是实现这种范式的工具。

即便我们都通过 AI Coding 来开发应用，编写 Skills，背后依然会使用 Workflow，只不过不再需要人手动去编排复杂杂的流程节点了。

因此，Workflow 不会因为 Agent 的发展而消失，两者也不是非此即彼的关系。

在实际业务中，完全可以用 Workflow 控制整体流程，在需要自主判断和动态决策的环节引入 Agent。现在很多低代码开发平台也支持这种模式，比如 Dify就可以把 Agent 当成一个节点在 Workflow 中使用。

技术最终还是要回归业务本身，能以更低的成本、更稳定的方式解决问题，才是最重要的。

总结

回到 Coze 企业版下线这件事。

核心原因是大厂内部的战略取舍，其次也反映了企业级 AI 市场竞争越来越激烈，这并不是宣告工作流平台、Workflow范式已经过时。