扣子企业版下线：被替代的不是 Coze，是"搭 Bot"这件事

一、先把事实说准：下线的到底是什么

按火山引擎文档中心的官方公告，时间线是这样的：

三个必须澄清的点，免得误读：

1. 下线的只是"企业版套餐"，不是扣子整个产品关停。个人用户和开发者仍可继续使用扣子相关功能。
2. 官方没有披露具体原因，公告口径是"因产品整合安排"，并称"正在规划后续可供企业客户选择的产品和套餐方案"。已有客户在合同有效期内可继续使用并获得客服支持。
3. 现有对话、记忆、文件、编程项目、低代码工作流等资源的导出与备份安排，官方说将在后续公告中明确。

另外，这不是孤例。同一段时间里，腾讯元器宣布 11 月 9 日停服、QClaw 宣布 12 月 24 日停止运营、百度秒哒团队并入百度搭子。一个多月内，多家大厂的 AI 应用开发平台集中调整——这更像一次行业性的路线收敛，而不是某款产品的偶然失手。

二、Coze 其实赢了，只是赢的那个市场不大

先给 Coze 应得的尊重。

它 2024 年 2 月在国内上线，把"零代码搭一个 Bot、一键发到飞书/微信/抖音"这件事做到了极致。不写代码、拖拖拽拽、配好知识库和插件就能跑，它真正完成了 Agent 的"民主化"，也教育了整整一代开发者什么叫工作流、什么叫工具调用。据媒体报道，2.0 升级时官方提到已服务超 1000 万真实开发场景；IDC《中国智能体开发平台市场份额，2025》中，扣子以 19.3% 的份额位居中国智能体开发平台公有云市场第一。

但同一份测算里还有个刺眼的数字：2025 年这个公有云市场全年规模约 2.5 亿元，据此推算扣子的平台产品收入约 0.48 亿元。

需要说清楚：这是基于市场规模的估算，不含模型调用与云资源，并非字节官方财务数据。

市占率第一、全年盘子不到三亿——这说明的不是"扣子做得不好"，而是"帮人搭一个 Agent"这件事本身，卖不出企业级的价格。企业愿意付钱的从来不是搭建工具，是搭完之后那个能长期跑在业务里、出事能追责的系统。

三、为什么会被替代：三层原因

1. 模型把"搭建"这件事吃掉了

低代码 Agent 平台诞生于一个特定前提：那时候模型还不够强。

所以平台必须替模型把活拆开——画布上摆节点、连箭头、定义每一步的输入输出和执行条件，人把"该怎么干"预先写死，模型只负责在格子里填空。扣子把 AI 应用拆成模型、知识库、插件、记忆这些组件，就是那个年代的产物。

如今长上下文、自主规划、工具调用、多步执行已经成了模型的基础能力。用户一句话，Agent 自己拆任务、找工具、调系统、写回结果。当初需要人拖拽出来的那张流程图，现在模型自己就能生成。

最硬的证据来自扣子自己：据界面新闻体验报道，其拖拽式模块化画布已不再是主推路线，产品重心全面转向"扣子编程"，优先走自然语言生成 + 代码优先的范式；2025 年底扣子开发平台就已升级为扣子编程。平台方比谁都清楚，画布不是终局。

一个工具被替代，往往不是被对手打败，而是它要解决的那个问题，被上游能力顺手消掉了。

2. 企业买的不是"能搭出来"，是"能长期稳定跑下去"

企业侧的需求，从一开始就不在同一个坐标系里。

企业要的是深度嵌进业务流、数据不出门、可观测、可追责的"数字员工"；不是"能随便拼几个插件跑个 demo"。界面新闻援引一位大厂 AI 办公产品从业者的判断很到位：对有复杂业务流程、私有化部署和深度系统集成需求的大型企业，开放开发平台依然有价值，但竞争重点不再是提供多少可拖拽的组件，而是谁能更好地连接模型、数据和企业系统，解决 Agent 在真实业务中的稳定运行问题。

第三方技术观察说得更直白：未来 Agent 基础设施的竞争，不再是"可视化界面"的竞争，而是 "Agent 治理（Governance）" 的竞争。

这恰好是低代码平台的结构性短板。以 2025 年 7 月开源的 Coze Studio（Apache 2.0，Go 后端 + React/TS 前端，Docker 部署）为例，它确实让企业能自建一套可视化编排环境，但公开的项目评估普遍标注 "生产就绪度未验证"，其 README 也明确提示公网部署存在账号注册暴露、SSRF、Python 代码执行、接口水平越权等风险；企业级权限管理、插件市场与模型推理闭环仍与原有商业生态深度绑定。

"能搭"和"敢让它改生产数据"，中间隔着一整套治理。

3. 产品受制于组织，底座才受制于客户

还有一层最容易被忽略、却最致命：企业系统要跑五年、十年，而一个 SaaS 产品线的存续，取决于它所属公司的战略。

2026 年 8 月，扣子团队整体并入豆包体系；企业级办公 Agent 的能力收归"豆包工作"，底层算力与企业级交付收归火山引擎。夹在中间的独立企业 SaaS 套餐，就失去了独立存在的组织土壤。多家媒体分析都指向同一个逻辑：在"粗主干、集中兵力"的阶段，与主干业务重叠、又没跑出独立商业闭环的产品线，随时可能被整合。

对企业 CIO 来说，这是一道很朴素的算术题：如果承载核心链路的平台可能停售，那我的系统凭什么算"可持续交付"？

可持续交付不是"功能多、更新快"，而是三件更笨的事：

• 明天它还在，不因为供应商的组织调整而消失；
• 三年后要加能力，是在既有架构上叠，而不是推倒重来；
• 数据、配置、流程都在自己手里，出问题时能查、能改、能迁走。

这一层，通用搭建平台给不了；它属于开源、可私有化、有架构治理约束的底座。

四、Coze 与 g2rain：不是同类，差在"流程怎么定义"

先认识 g2rain：一个面向企业的开源智能体平台

g2rain（谷雨）的定位，官网写得很直白：面向企业的开源智能体平台，连接模型、知识与业务工具，让智能体在明确的身份和权限边界内执行任务，并支持执行过程追踪。

注意，它不是一个"更好用的画布"，也不是给现有系统加个聊天框。它从一开始就把 AI 当成一种新的、受控的调用方，接进企业已有的组织、岗位、应用授权和数据规则里。用户从一句话发起任务，平台要把这件事拆成可查、可授权、可回溯的执行过程。

截至 2026 年 11 月，官网按 7 个方向收录了 33 个开源项目（Apache 2.0、可私有部署），v1.0.0 已联合发布。其中六个 Agent 核心组件均已开源：Chat Shell（对话与执行时间线）、Agent Runtime（任务图、模型与工具调用、检查点与恢复）、Agent Studio（Agent 画像、Skill 手册与执行契约）、Agent App（配置、模型与 MCP 工具管理、执行追踪）、Model Nexus（统一模型访问网关）、MCP Registry（MCP 工具发现与调用代理）。

最大的区别：流程是"画"出来的，还是"描述"出来的

这才是两者真正的分野，不在功能多少，而在流程是怎么定义出来的。

Coze 那一路，流程是画出来的：人先把任务拆成节点、连好线、定义每一步的输入输出和跳转条件。画布画完，能走的路径基本就定死了；客户流程一变，就得改节点、加分支。

g2rain 这一路，流程是描述出来的。它先用 DDD 把业务能力拆成边界清晰、职责单一的最小颗粒度接口，注册成可被发现和调用的 MCP 工具；再用 Skill 描述"这件事该怎么做"——用自然语言把任务方法写清楚：哪些信息由用户提供、哪些通过工具获取、什么结果代表完成、缺信息或出异常怎么反馈，再配上围绕输入、参数、产出和完成判定的执行契约。用户同样只需用自然语言说出目标，模型负责理解目标、在多个可用能力里选择合适的执行路径、处理那些有弹性的编排，真正落地的动作由 Runtime 按契约调用受控工具完成。

一句话概括：画布预设的是"步骤"，Skill 描述的是"目标和方法"。 步骤写死了，泛化空间就有限；目标和方法说清楚了，模型就能在同一个受控能力集里，把没被事先枚举出来的流程变体也跑通——这就是模型能力带来的流程泛化。

官网那个例子很直观：同样是"准备并发布一篇企业内容"，不同客户的素材来源、审核角色、发布规则各不相同。传统做法要在 CMS 里不断加分支或写定制代码；而在 g2rain 的思路里，不同客户只要调整 Agent 或 Skill 的组织方式，就不必改写 CMS 的核心领域逻辑，围绕自己的制度、组织结构和审批习惯定义执行路径即可。

所以"泛化"值不值钱，不看模型回答得多聪明，而看三个更笨的指标：一个新流程需要新增多少定制代码、已有能力在不同租户流程里能复用多少、从提需求到流程上线要多久。当新增需求不再等价于新增一轮定制开发，企业流程的适配成本才真的降下来。官网的结语说得更干脆：

"AI 原生 SaaS 的终点，不是让每个页面都出现聊天框，而是让企业已经沉淀的能力可以通过自然语言被发现、组合和执行。"

泛化不等于放任：模型管"怎么走"，平台管"能不能走"

让模型去泛化流程，最容易被质疑的一句是"那不就失控了"。g2rain 把边界划得很清楚：

• 交给模型：理解自然语言目标和非结构化资料、在多个可用能力中选择执行路径、生成草稿与处理方案、处理存在一定弹性的流程编排。
• 仍由确定性系统执行：身份认证、权限判断与租户隔离，金额库存计量等关键业务规则，数据一致性、事务与幂等，最终状态变更、审计留痕与合规约束。

而且 Skill 绑定的工具范围，与用户实际业务权限是分别管理的——Agent-Skill、Skill-Tool 绑定只表达"可用能力"，不自动替代岗位授权或租户应用开通，实际调用仍要核对身份、租户上下文、接口权限和数据归属。高风险写操作还要过人工确认、审批、额度限制或回滚。

落到运行细节上，Runtime 维护任务图、节点和工具调用状态，通过 SSE 推送进度与结果；它还会留检查点与恢复记录，并明确提醒：某次提交已在下游成功、但返回结果时中断，应先核实业务结果再决定后续动作，不能把任意失败都当成可以直接重放。

模型负责"怎么走得通"，平台负责"能不能走、走了谁负责"——正因为后者是硬的，前者才敢放开。这也是"泛化"和"治理"必须长在同一个底座上的原因。

对比表

也补一句边界：六个组件虽已开源，官网仍明确说明——各项目分别维护实现、配置与发布记录，不提供统一版本的整套安装包；部署时要固定所选项目版本、核对接口与配置兼容性，再验证模型调用、工具访问和会话执行。交易、订阅、计量计费等云端商业化能力仍在规划中。把话说到这个份上，比一句"全部可用"更可信，也更像"可持续交付"该有的样子：不把规划中的能力说成已交付。

五、那"替代"到底指什么

说清楚，免得变成踩一捧一：

不是 g2rain 取代 Coze，也不是 Coze 消失了。 个人场景、内容创作、快速原型、轻量自动化，Coze 依然是最顺手的工具之一，这点没变。

真正的替代发生在企业核心系统这一层，是三件事同时发生：

1. 通用低代码搭建平台不再作为系统主承载体——它要么下沉为原型与编排层，要么被 AI 办公入口直接吸收；
2. 承接核心链路的，变成能私有化、能治理执行、能长期迭代的底座；
3. 评判标准换了轨：从"多快能搭出一个 Agent"，变成"Agent 能不能被长期、可控、可追责地交付"。

有意思的是，Coze 自己也在往这个判断上收敛——重心从拖拽画布转向代码优先的扣子编程，企业级交付收归主干与私有化底座。两条路线看似背向，其实在回答同一个问题：当 Agent 不再只是聊天，而是真的会改数据、会跑流程，工程该怎么组织。

区别只在于：一个把重心放在"让人更快搭出来"，另一个把重心放在"让流程能被描述、被模型泛化、被平台治理，并且能交到客户自己手里"。前者优化的是搭建体验，后者优化的是流程适配成本——而后者，恰恰是企业愿意长期付钱的地方。

六、给准备上 Agent 的企业：先问三个问题

选型会上少问"有多少插件""能不能拖拽"，多问这三句：

1. 它会改数据吗？改错了谁负责？ —— 要能说清权限边界、参数来源、是否有高风险人工确认、有没有审计留痕。
2. 这个平台明天停售，我的系统还在吗？ —— 要能私有化、开源可接管、数据可导出、流程可迁移。这次公告里"资源导出与备份安排另行公布"这一句，值得每个采购方认真读一遍。
3. 三年后加新流程，是改配置还是重写？ —— 要看流程是被预设在画布里、客户一变就得加分支，还是能用 Skill 描述目标与方法、让模型在受控能力集里泛化；也要看有没有架构治理约束、模块边界是否清晰、多仓库能否长期保持一致。

三个问题都答得上来，才谈得上"可持续交付"。答不上来，搭得再快也只是一次性交付。

写在最后

扣子企业版下线，最值得记住的不是某个产品的退场，而是它替行业把一句话摆到了台面上：

AI Agent 的竞争，正在从"谁能让它跑起来"，转向"谁能让它在企业里一直、稳稳地跑下去"。

前者靠画布把步骤预设好，后者靠 Skill 把目标与方法描述清楚、再让底座把身份、权限、审计和恢复托住。这不是谁比谁先进，是重心迁移了。

关于 Agent 执行治理的细节——执行追踪、任务图与检查点、高风险确认、中断后怎么判断能否恢复——我们后续再展开讲。