扣子产品下线公告观点讨论与反思
扣子企业版下线，本质是字节 AI 办公战略收拢的选择。虽然扣子在智能体搭建赛道取得了不错的开发者市场份额，但企业版业务存在几个核心问题：一是与豆包工作场景重叠，内部资源分散、销售 GTM 冲突；二是商业模式以售卖搭建工具为主，使用者局限在少数开发人员，缺少全员高频使用场景，续费和扩单能力弱；三是企业侧的账号、审计、办公生态集成投入成本巨大，品牌心智停留在 “创作者工具”，很难转型成企业办公底座。
本次下线不是否定智能体低代码方向，而是把已经验证的工作流、Bot 编排能力整合进集团主线产品。这件事给我们的启示：面向企业的 AI 产品，要提前对齐集团主线边界，区分开发者工具和全员生产力底座两种定位；企业 SaaS 的核心壁垒是深度融入现有工作流与合规体系，而不只是编辑器能力。
某前员工评价是
1. workflow 不是被 AI 淘汰的，是被「模型自己会规划」淘汰的
2. 当年我们拼命做的拖拽节点，其实是在替模型的笨买单，实际上这玩意就是一种低代码平台延续出来的过渡模式，是一个中间产物
3. 业务KnowHow大于一切，当年人们学的如何搭建工作流的技能已经被Agent内化，一文不值
观点一：Workflow 不是被 AI 淘汰的，是被「模型自己会规划」淘汰的
评价：部分正确，但把“执行控制权的转移”误判成了“工作流技术的消亡”。
这句话最有价值的地方，是指出了 AI 应用开发中的一个重要变化。
过去，开发者需要把一个复杂任务拆解成明确的步骤：
用户输入
↓
意图识别
↓
查询知识库
↓
调用业务 API
↓
结果校验
↓
输出结果
因为早期模型的规划、推理和工具调用能力有限，开发者不得不通过拖拽节点、设置条件、编写提示词等方式，把执行路径提前定义好。
随着 Agent 能力提升，一些原本需要人工设计的流程，可以改由模型在运行时动态决定：
用户目标
↓
Agent 分析任务
↓
自主选择工具与执行步骤
↓
根据执行结果调整计划
↓
验证目标是否达成
这一变化是真实的。微软的 Durable Task 文档也明确区分了两类模式：由代码定义控制流的确定性工作流，以及由模型决定工具调用顺序和执行路径的 Agent 工作流。两者解决的是不同类型的问题。
问题在于，模型会规划，不代表所有任务都适合让模型规划。
例如，一个客服 Agent 可以自主判断应该先查询订单还是先检索知识库；但退款金额是否超过授权额度、退款是否需要人工审批，不能只由模型根据上下文自行决定。
所以更准确的说法是：
被替代的是一部分由人手工编排的、低价值的控制逻辑，而不是 Workflow 本身。
未来的工作流可能越来越少地表现为开发者手工绘制的节点图，越来越多地表现为代码、策略、工具接口、状态机和执行约束。
这甚至不一定意味着工作流引擎消失。相反，Agent 越有自主性，底层系统越需要可靠的执行机制。
观点二：当年我们拼命做的拖拽节点，其实是在替模型的笨买单，是低代码平台延续出来的过渡模式
评价：对技术历史的解释有道理，但低估了可视化编排的独立价值。
这句话实际上包含两个判断，需要分开看。
第一，拖拽节点在一定程度上是对模型能力不足的补偿。
这一点是成立的。
在早期大模型应用开发中，开发者经常需要通过人工编排弥补模型的不足：
- 模型不知道下一步应该调用哪个工具，就增加条件分支。
- 模型容易偏离任务目标，就固定执行顺序。
- 模型输出不稳定，就增加格式转换和校验节点。
- 模型难以处理复杂业务，就把业务拆成多个独立步骤。
- 模型无法可靠地管理长任务，就借助外部状态和流程引擎。
从这个角度看，很多节点确实承担了原本可以交给更强模型完成的任务规划工作。
第二，拖拽节点是低代码时代的过渡产物。
这就不完全正确了。
可视化编排除了帮助模型补足能力之外，还有三个独立价值：
独立价值 | 为什么仍然重要 |
可观察性 | 可以检查每个步骤的输入、输出和失败位置 |
可控性 | 可以明确哪些步骤允许执行，哪些条件必须满足 |
可维护性 | 可以让非专业开发者理解、修改和协作维护业务流程 |
这些价值并不会随着模型推理能力增强而自动消失。
实际上，越是需要多人协作、持续运行、合规审计的系统，越需要一种能够理解和控制执行过程的表达方式。
微软的 Agentic Application Patterns 文档仍然将确定性工作流与 Agent 自主执行作为互补模式，并指出确定性工作流适用于已知步骤、明确的错误处理和需要可审计控制流的场景。
我们更倾向于把工作流的演进理解为三个阶段：
这里要注意：第三阶段并不是第二阶段的完全替代。
更合理的技术方向是，把原本固化在流程图里的低价值步骤交给模型，把必须确定执行的业务规则留在可控的系统里。
因此，我认为拖拽节点可能会逐渐失去作为 AI 应用开发核心交互方式的地位，但可视化流程本身未必会消失。它也可能从“编排工具”演变成“运行过程的观察、调试与治理界面”。
观点三：业务 Know-How 大于一切，搭建工作流的技能已经被 Agent 内化，一文不值
评价：前半句基本正确，后半句明显夸大。
这句话最值得关注的，是它指出了 AI 应用开发中价值分布的变化：技术工具的使用技巧越来越容易被自动化，而对业务目标、规则和结果的理解可能变得更加重要。
但它犯了一个常见错误：把某项技能的价值下降，推导成这项技能的全部价值归零。
1. 哪些工作流技能确实在贬值？
以下能力的差异化价值正在下降：
熟练使用某个平台的拖拽界面。
熟记各种节点的配置方式。
手工拼接常见的提示词链。
通过大量条件分支弥补模型的规划不足。
重复搭建标准化的知识库问答流程。
依靠平台特有的操作技巧完成简单自动化。
如果一个人的核心竞争力只是“我比别人更熟悉某个 AI 工作流平台”，那么确实存在较高的技能贬值风险。
因为这些能力往往具有三个特征：容易描述、容易标准化、容易被模型学习并自动生成。
2. 哪些技能不会因为 Agent 出现而变得一文不值？
真正有长期价值的能力，往往不是如何拖拽节点，而是如何确保业务目标被正确实现。
能力 | 价值判断 | 原因 |
平台操作技巧 | 下降较快 | 易被自然语言生成和自动化替代 |
通用工作流搭建 | 下降较快 | 标准化流程容易被模型生成 |
业务流程分析 | 仍然重要 | 需要识别真实需求、例外和隐性规则 |
业务规则建模 | 仍然重要 | 需要定义权限、状态、约束和边界 |
系统集成能力 | 仍然重要 | 涉及 API、数据、身份认证与遗留系统 |
Agent 评估与测试 | 重要性上升 | 需要验证正确性、稳定性和边界行为 |
安全、审计与治理 | 重要性上升 | 自主执行增加了权限滥用和不可预测行为的风险 |
业务结果负责能力 | 核心价值 | 最终要对成本、质量、效率和业务结果负责 |
举一个 ERP 的例子。
假设需要构建一个采购审批 Agent。它可以自主完成需求理解、供应商信息检索、价格比较、合同条款摘要，甚至生成采购建议。
但以下问题仍然需要明确的业务定义：
哪些采购行为需要审批？
不同金额、品类和部门对应什么审批权限？
供应商资质如何验证？
什么情况下必须拒绝执行？
如何避免重复下单？
发生错误后如何追溯、撤销或补偿？
模型可以协助发现和实现这些规则，但不能替组织决定规则应该是什么，更不能天然保证执行正确。
因此，真正的竞争力不只是业务 Know-How，也不是单纯的技术能力，而是：
业务理解 × 系统设计 × AI 能力 × 结果验证。
其中任何一个环节薄弱，都可能导致 Agent 无法在真实业务中可靠落地。
二、从 Coze 的产品变化，能否推导出这三个观点？
这里需要特别谨慎：产品下线、功能调整和技术范式被淘汰，是三件不同的事情。截至目前能查到的官方资料，不能直接支持“Coze 整个产品已经下线”这一前提。
扣子官方文档显示，2026 年 7 月 1 日下线的是低代码智能体发布到豆包渠道的入口，已发布的智能体不受影响；官方 FAQ 也明确表示，扣子编程仍然作为独立产品提供服务。所以，如果这里所说的“下线”是某项功能、某个入口或者某一产品形态的调整，那么不能直接把它当成整个 Workflow 范式失败的证据。
即便一个工作流平台最终停止运营，也可能有很多原因：
产品定位发生变化，资源转向更大的产品形态。
用户愿意为结果付费，却不愿意为复杂的编排过程付费。
产品获客、留存、商业化或运营成本不符合预期。
模型能力进步，使原有的产品交互方式失去竞争力。
平台之间的竞争加剧，基础模型厂商或 AI 编程平台提供了更完整的解决方案。
这些因素可能同时存在。仅凭产品下线，无法判断究竟是哪一个因素起了决定性作用。
更重要的是，产品的商业成败不能直接证明其底层技术范式已经过时。
例如，某个可视化工作流平台不再流行，并不意味着工作流引擎、任务编排、状态机、重试机制和执行审计就不再有价值。这些能力甚至可能被集成到用户看不见的底层基础设施中。
三、真正值得关注的是：AI 应用开发的价值链正在发生什么变化？
如果把这三个观点放到一起，我认为它们真正指向的是一个更重要的问题：
AI 应用开发的竞争壁垒，正在从“如何构建流程”向“如何让 AI 在真实业务中可靠地完成任务”迁移。
这一变化也带来了一个值得重视的反直觉结论：
Agent 越强，应用层开发者可能越不需要亲手编排每一个步骤；但企业对底层执行可靠性、业务约束和结果验证的要求，不一定随之降低。
自主规划解决的是“下一步应该做什么”，并不自动解决“是否有权做、是否做对了、失败后怎么办”。
四、如果今天重新学习 AI 应用开发，应该把时间花在哪里？
我建议把技能分成三个层次。
第一层：理解业务与问题建模--优先级最高
学习业务流程分析、领域建模、业务规则提取、异常场景识别、需求拆解和验收标准设计。
目标是知道什么任务值得自动化、哪些决策可以交给 Agent、哪些规则必须固定。
第二层：掌握 Agent 系统工程--重点投入
学习工具调用、任务规划、上下文管理、状态持久化、确定性工作流、异常恢复、幂等性、可观测性和评估体系。
不必执着于某个平台的拖拽操作，但必须理解工作流与 Agent 各自的适用边界。
第三层：企业级交付能力--形成差异化
学习权限管理、数据安全、审计、成本控制、人工审批、线上监控、故障处理和业务效果评估。
目标是让一个原型从“能够演示”走向“能够持续运行”。
这三层能力的组合，比单独掌握某一种 Agent 框架或工作流平台更有迁移价值。
五、最终结论：这三个观点究竟有多客观？
原观点 | 我的判断 | 更准确的理解 |
Workflow 被模型自主规划淘汰 | 部分正确 | 人工编排的部分控制逻辑正在被替代，工作流机制仍有独立价值 |
拖拽节点是低代码时代的过渡产物 | 部分正确 | 拖拽式编排可能不再是主流开发入口，但可视化、确定性执行和治理仍然有价值 |
工作流技能已经一文不值 | 夸大其词 | 平台操作技巧在贬值，业务建模、系统集成、验证和治理能力仍然重要 |
如果要把这三句话改写得更客观、更符合技术发展规律，我会这样表达：
- AI 正在把部分流程设计权从开发者转移给模型，但确定性执行、状态管理和业务约束不会因此消失。
- 可视化工作流是早期 AI 应用的重要开发抽象。随着模型规划能力增强，人工逐节点编排的必要性会下降，但可观察性、可控性和可维护性仍然是系统工程的核心需求。
- 标准化的工作流搭建技巧正在贬值，真正的价值正在向业务建模、Agent 系统工程、可靠性治理和业务结果交付迁移。
我最认同第三个观点的方向，但不认同“一文不值”的结论。
因为一个人如果只会搭建工作流，确实可能被 Agent 替代；而一个人如果理解业务、知道如何设计可靠的系统，并且能够判断 AI 的输出是否真正满足业务要求，那么 Agent 更可能成为他的生产力工具，而不是他的直接替代者。
真正需要淘汰的，不是 Workflow，而是把“熟练使用某个 AI 平台”误认为长期核心竞争力的思维方式。
浙公网安备 33010602011771号