过去，我们把 AI 接进工作流；现在，我们开始让 AI 自己寻找工作路径。
那么，曾经让无数人第一次做出 AI 应用的低代码平台，是否正在失去存在的理由？
这几天，看到字节跳动旗下扣子（Coze）企业版宣布分阶段下线，我脑海里冒出的第一个问题，并不是“扣子以后还能不能用”，而是：如果连这样一款具有行业知名度、曾经把 AI 工作流带进大众视野的产品，都在调整企业版，工作流式 AI 低代码平台是否已经到了必须重新证明自己的时候？
这种不安并不难理解。回想早期搭建 AI 应用的过程，我们需要费力配置提示词、知识库、接口请求、判断条件和输出格式。在可视化画布里放下几个节点，拉出几条连线，点击运行，看着信息逐步流动——那种“我也能做出一个 AI 产品”的满足感，确实改变过很多人的开发体验。
但今天，一切显得不同了。你可以向编程智能体描述一个需求，让它自己修改项目、运行测试、提交代码；可以要求一个通用 AI 助手搜索资料、操作工具、整理文件、形成结果；甚至可以不打开任何画布，就完成过去需要十多个节点才能串起来的任务。
当“告诉 AI 你想做什么”越来越接近“让 AI 帮你做出来”，人工拖拽节点，究竟还是降低门槛的捷径，还是开始成为新的操作负担？
这是本文想讨论的问题。我不会把某个产品的退出简单解读为整个技术路线的死亡，也不打算用“Agent 将取代一切”这样响亮却不够严谨的口号结束讨论。相反，越往企业应用的真实现场看，就越会发现一个略显矛盾的事实：低代码画布作为卖点正在贬值，而可靠的工作流执行能力，可能比任何时候都重要。
这篇文章会从一个产品公告讲起，依次聊聊第一代 AI 工作流的成功、AI 编程带来的冲击、Agent 与 Workflow 的真实边界、企业落地难题、平台商业模式，最后给出我对未来几年的判断。尽量少一些堆砌名词，多一些可验证的事实、真实的工程问题与可操作的建议。
阅读提示： 文中有关扣子服务时间的描述以 2026 年 10 月 29 日官方公告为依据；有关行业趋势、商业动机和未来走向的部分属于分析判断，不等同于相关企业的官方表态。文中应用案例为便于讨论而构造的典型场景，并非宣称某企业已发生的真实案例。
01｜先别急着宣判：扣子企业版，到底发生了什么？
2026 年 10 月 29 日，扣子发布《扣子企业版下线公告》。官方给出的原因表述是“推进企业级服务的产品整合升级”，现售企业版先暂停新售，随后按计划分阶段下线。[1]
把关键日期列出来，事实会清楚很多：
| 时间 | 官方安排 | 对用户的直接影响 |
|---|---|---|
| 2026 年 10 月 29 日 | 发布企业版下线公告 | 公布产品整合、停售与下线安排 |
| 2026 年 11 月 30 日 | 企业标准版、企业旗舰版暂停接受新客户购买 | 新客户采购路径发生变化，存量合同仍需按具体约定处理 |
| 2026 年 12 月 31 日 | 火山引擎购买的旧个人进阶版、旧企业版、旧团队版下线 | 旧版套餐到期退出，超出该日期的未使用部分按公告退款 |
| 2027 年 12 月 31 日 | 新版企业标准版、企业旗舰版全面下线 | 企业套餐在该时间点前完成退出 |
公告同时写明，存量客户可以在合同约定的有效期和对应套餐下线日期前继续使用相关功能，并获得约定支持。关于对话、记忆、文件、编程项目、低代码工作流等资源如何导出与备份，官方表示将在后续公告中说明。[1]
这几句话里，有三层信息值得分开看。
第一，关停的是明确列出的企业版套餐，不是宣布所有扣子产品立即停止运行。 把“企业套餐将下线”直接写成“扣子彻底关停”，既会误导读者，也会干扰现有用户的迁移判断。
第二，产品整合是已确认的官方说法，商业化失败并不是已被证实的原因。 外界可以讨论模型能力进步、产品线重叠、企业付费转化、组织战略变化等可能因素，但在缺乏经营数据和内部决策信息时，这些都只能是解释假设，不能当成已经坐实的结论。
第三，也是我认为最值得企业用户注意的一点：下线日期是明确的，资源迁移的完整路径却仍有待官方进一步说明。 对一个只是体验过几个模板的个人用户来说，这可能不算大事；但对一个已把知识库、API、审批规则和业务数据接进平台的企业来说，平台退出意味着一场真正的系统迁移。
有趣的地方在于：一个面向“快速构建应用”的平台，最终却让行业重新讨论“应用究竟属于谁、迁移成本有多高、业务能否脱离原平台运行”这些非常传统的软件工程问题。
也许，这恰恰是整件事最有价值的启示。
不是“低代码已死”，而是“平台依赖风险”再一次被看见
设想一家团队已经用某个低代码平台构建了几十个内部应用。页面不是最宝贵的资产，节点也不是。真正珍贵的是藏在节点背后的东西：供应商系统接口、审批规则、字段映射、知识库结构、用户权限、错误处理、测试样例，以及不断积累的运行经验。
如果这些能力只能在一款产品的专有运行时里执行，那么团队拥有的可能不是完整的业务软件，而是一份依赖特定平台才能解释和运行的业务配置。
当平台持续运营时，这种依赖容易被忽略；当套餐调整、价格变化、功能停止维护或者服务区域改变时，它才会成为一笔看得见的成本。
所以，扣子企业版事件引发的真正问题不应只有“AI 低代码是否会被淘汰”，还应包括：在 AI 时代，我们到底应该把什么能力交给平台，又应该把什么资产保留在自己手里？
02｜被低估的功劳：AI 工作流曾经解决过一件很难的事
讨论一种工具会不会过时之前，先承认它曾经创造过什么价值。
在大模型刚开始大范围进入应用开发的阶段，模型本身更像一个擅长语言理解与生成的“引擎”，而不是完整的软件系统。它能回答问题，但不会天然知道如何访问你公司的资料；它能生成一段 JSON，却未必总能保证字段一致；它能总结文档，但不知道总结完成后应当通知谁、写入哪个表格、如何触发下一个环节。
为了把一次“模型调用”变成一个“可以使用的应用”，开发者需要自己搭建大量胶水代码：接口鉴权、数据清洗、检索增强、分支判断、外部工具、状态保存、日志与异常处理。这些工作单独看未必复杂，拼到一起却足以耗掉一个小团队大量时间。
工作流式 AI 低代码平台，恰好填上了这个缺口。
它把散落在代码和配置中的逻辑，抽象为人人都能理解的节点：用户输入、知识检索、调用模型、判断条件、执行工具、输出结果。复杂度并没有消失，但复杂度被重新组织，并以更容易理解的方式呈现出来。
这是一种很重要的产品创新：让原本需要工程师才能完成的“系统编排”，第一次在一定程度上变成了业务人员可以参与的“流程设计”。
第一份价值：它把“从想法到验证”的距离缩短了
想象一位市场人员要制作一个竞品资讯助手。过去需要申请开发资源，整理需求，等待排期；有了可视化 AI 工作流后，他也许可以在一天内完成一个初版：抓取公开信息、提取要点、调用模型整理成报告，再发送到指定渠道。
这未必是一套可靠的生产系统，但足以验证“这个需求值不值得做”。把试错成本降下来，本身就是价值。
一个团队需要尝试十个方案，最后只有两个值得投入工程化建设。如果前期每个方案都必须开发完整后端，那么很多想法会在预算和排期阶段就被放弃。低代码平台的意义，是允许更多假设以更低成本进入真实验证。
第二份价值：它让业务逻辑第一次变得“可见”
流程图并不只是为了漂亮。对于需要产品经理、业务专家、研发和运维共同讨论的系统，一张清晰的流程图有时比三千行代码更容易达成共识。
“为什么没有进入人工审核？”“这一类客户信息会写入哪里？”“模型回答失败后会不会再次执行？”这样的问题，在流程画布中至少有了一个可讨论的入口。
当然，可见不等于可管理。等到流程越来越大，几十个节点交织、多个子流程相互调用，画布本身也可能成为新的复杂性来源。但在早期，它确实极大改善了跨角色沟通。
第三份价值：它帮助 AI 从“聊天”走向“干活”
很长一段时间里，大众对 AI 的感知停留在输入一个问题、得到一段回答。工作流平台让更多人看到了另一种可能：AI 的输出可以成为下一步动作的输入。
当模型整理出的数据可以被程序校验、写入表格、提交系统、触发消息，AI 才开始进入业务链条，而不只是停留在浏览器里的对话框。
从这个角度看，今天很多 Agent 产品所宣称的“调用工具、完成任务”，并不是凭空出现的全新需求。只不过过去这些步骤大多由人预先连起来，现在越来越多由模型根据任务进行动态选择。
但一种工具的历史功劳，不等于它能永久维持溢价
问题就出在这里：当流程编排从创新能力变成常见能力，用户不再愿意为“有一个画布”支付高溢价。他们开始要求平台解决更棘手的问题：运行是否稳定、数据是否安全、能否对接现有系统、组织是否方便协作、出现错误能否恢复、迁移成本是否可控。
第一代 AI 低代码的成功，是把应用做出来；下一代平台必须证明，自己能让应用活下去。
03｜那些漂亮的演示，为什么到了生产环境就没那么轻松？
在产品发布会上，最容易打动人的演示往往是这样的：选择一个模板，拖入几个节点，连接知识库，配置模型，点击运行。几秒钟后，一份结构完整的报告出现了。观众看到的是流程顺滑、配置简单、结果直接。
真实企业里的问题，不会这么配合演示。
比如，一个客户服务系统要自动处理退货申请。第一天，它识别用户意图、查询订单、生成回复，一切正常。第二天，订单系统接口超时；第三天，客户上传了一张无法识别的图片；第四天，用户订单里出现两个相同商品；第五天，人工客服修改了审核结论；第六天，供应商改了接口字段；第七天，数据库权限被安全部门收紧。
七天之后，原来那条简洁的流程已经长出了大量“如果……那么……”：超时重试、重复请求去重、图片识别失败、人工接管、补偿操作、规则版本变更、权限不足告警……
这不是低代码工具设计得不好，而是现实业务本来就复杂。一种工具可以降低表达复杂度的门槛，但不能取消复杂性本身。
1. 画布越大，不一定越容易维护
在简单场景里，节点让逻辑一目了然；到了跨部门、跨系统、跨版本的大型流程，一张画布可能容纳几十甚至上百个节点，变量在不同节点间传递，循环与分支交织，测试只能靠反复点击运行。
最终，“看得见”可能滑向“看不清”。工程师为了定位一个错误，需要不断缩放画布、查看中间输出、确认每个节点的参数版本。原来为了避免写代码而搭建的东西，慢慢表现出一套程序应有的全部复杂度，却不一定具备成熟代码工程里的差异对比、模块测试、静态分析和版本管理能力。
所以我并不认为节点越多的平台一定越强。当流程已经足够复杂时，好的抽象应当减少人需要理解的部分，而不是把所有细节同时展示在屏幕上。
2. 一次成功，不代表可以重复成功
生成式模型存在输出波动，外部系统存在网络抖动，知识库会持续更新。原型里成功运行一次，并不等于在不同输入、不同用户、不同时间段都能保持预期效果。
真正需要衡量的，是持续运行的成功率、人工返工率、错误恢复时间、每个有效结果的成本，以及关键操作是否可追溯。这些指标也比“画布上有多少种节点”更接近真实价值。
3. 平台解决“连接”，不等于解决“责任”
当一个 AI 代理错误修改客户资料时，是模型理解有误、接口参数有误、权限放得太宽、审批没有介入，还是业务规则本身定义不清？这不能只凭一条“调用成功”的日志来判断。
一个成熟系统要回答：谁发起了请求？谁授权了工具？模型依据什么数据做出判断？真实执行的参数是什么？哪个版本的规则在生效？能否回滚？影响了哪些记录？
这些问题听上去不如“自动生成 30 个工作流”炫酷，却决定了企业敢不敢把核心业务交出去。
4. 隐藏的成本往往出现在“持续运行”之后
别只计算搭建第一版花了几个小时，还要计算后续的人员维护、模型调用、失败重试、知识更新、接口变更、审计要求和人工兜底。一个平台如果让搭建成本降低 80%，但让每次修改都必须手工检查整个流程，它的长期成本优势就可能大幅缩水。
这也是为什么我越来越警惕一种宣传方式：只展示“从零搭建一个 Agent 多么快”，却不展示“半年后这个 Agent 变得复杂时，应该如何维护”。
04｜真正改变游戏规则的，不只是 Agent，而是 AI 编程
如果说工作流平台最初的卖点是“无需编程也能做 AI 应用”，那么 AI 编程正在触碰它最核心的价值叙事。
过去，产品经理说：“我想做一个自动整理会议纪要并发送待办的工具。”开发者会把这句话拆成后端接口、数据库、前端页面和定时任务；低代码平台则把它变成几个可以手动配置的节点。
现在，编程型智能体可以直接理解需求、阅读代码库、生成和修改程序、运行测试，并在人审核后形成可合并的代码变更。GitHub 官方文档就将研究代码库、规划任务、修改文件、测试和提交可审查的 PR 列为 Copilot 智能体的能力范围，同时提醒开发者谨慎处理高风险、上下文复杂的任务。[9]
这意味着，过去需要“先学习一种低代码平台的表达方式，再把业务想法翻译成节点”的用户，现在多了一条路：直接描述结果，让 AI 生成实现。
拖拽节点的两个优势，正在被重新定价
第一是开发速度。 如果一个流程只需要调用模型、处理 JSON、访问几个接口，那么直接让 AI 生成代码可能比拖入节点、查找参数、逐个接线更快。尤其是流程变化频繁时，自然语言修改代码的体验可能更顺畅。
第二是知识门槛。 低代码曾经通过“不写代码”吸引非技术人员。如今，越来越多非技术人员可以在 AI 的帮助下完成基础开发。是否需要懂代码仍然重要，但“必须亲自写完每一行代码”已经不再是进入软件开发的唯一途径。
不过，结论不能走到另一个极端：AI 会写代码，不代表每家企业都应该放弃低代码。 代码本身不是完成交付的证明。谁来运行、更新、授权、监控、测试、处理安全漏洞？如果 AI 一次生成了一个 Python 服务，而团队没人理解依赖、数据库和部署环境，那么所谓“零门槛”也只是把门槛延迟到了上线那一天。
因此，未来可能并不是“画布消失、人人直接写代码”，而是用户入口从“人工拖节点”转向“描述需求”，由平台在底层选择生成流程、编排已有组件、创建代码、调用现有服务，或者组合多种方式。
低代码真正该怕的，是自己只剩下一张画布
如果一个平台的独特性只在于“提供很多节点”和“有一套漂亮的拖拽界面”，那确实容易被 AI 编程工具、模型厂商的原生应用能力和其他集成平台分流。
但如果它提供完整的业务连接器、统一权限、团队协作、生产运行时、审计、版本控制与评测，那它与代码生成智能体竞争的就不是同一个层次的能力。前者解决的是组织如何持续生产和运营 AI 应用，后者更多解决一次具体任务如何被构建和完成。
这也解释了为什么我认为，“低代码会不会被 AI 编程替代”不是一个只能回答是或否的问题。不同复杂度、不同组织成熟度、不同责任要求的场景，会做出不同选择。
05｜Agent 并不是 Workflow 的下一代替身
人们喜欢把技术发展想象成一条线：规则自动化 → 工作流 → Agent → 多 Agent → 全自动企业。但现实系统的发展很少这么整齐。
在我看来，Workflow 与 Agent 的关系，更像铁路与越野车：前者适合已经明确的路径，后者适合探索尚不确定的路线。 谁更先进，不取决于名字，而取决于你要去哪里、途中会遭遇什么、允许承受多大代价。
Anthropic 在《Building effective agents》里对两者作出过很清晰的区分：Workflow 让模型和工具沿预定义路径运行；Agent 则由模型动态决定步骤与工具调用。该文同时提醒，构建 AI 系统时应当从尽可能简单的方案开始，在确有需要时再增加 Agent 的复杂性；更灵活的自主性往往伴随更高的延迟和成本。
LangGraph 的文档同样强调可以在同一系统中混合确定性步骤与模型驱动步骤，并使用持久状态、人工介入和恢复能力进行控制。
一件事：整理日报，适合固定流程
每天晚上六点，从业务系统读取当天销售数据、检查缺失值、生成摘要、发送给负责人。这种任务的输入和输出比较明确，处理步骤基本稳定。我们当然可以让一个 Agent 每天重新思考“今天应该先做什么”，但这不仅可能增加费用，还可能让它偶尔改变不应改变的路径。
此时，一个小而清晰的 Workflow 往往更合适：数据获取由固定接口完成，指标计算交给程序，语言总结使用模型，发送动作遵循已有权限和通知规则。
这里的“可预测”，不是落后的代名词，而是业务要求。
另一件事：调查系统异常，适合探索式 Agent
假设一套软件突然出现性能下降。需要查看日志、定位异常时间段、比较最近变更、分析调用链、推测瓶颈，必要时请求补充信息。我们很难提前画出每一种故障的全部分支。
这时候 Agent 有优势：它可以提出假设、调用不同诊断工具、根据结果修正方向，再形成带证据的建议。但“让 Agent 分析”并不意味着可以“让 Agent 随意重启服务或修改生产配置”。一旦涉及真实操作，仍应把风险较高的行为交给明确的授权机制和审计体系。
真正有价值的是中间地带
大部分复杂企业应用其实既不是一条死板的流水线，也不是一个可以无限自主行动的智能体。一个合同审查应用可以让 Agent 查阅条款、识别风险、检索政策；但风险分级的口径、最终审批人、签署权限与归档步骤，应由业务规则和治理体系决定。
可以让 AI 负责提出可行路径，但不能把组织责任全部托付给它。
这时最合理的组合往往是：确定性的外部边界 + 可探索的内部任务 + 必须留下痕迹的关键动作。
| 场景 | 更适合的主导方式 | 原因 |
|---|---|---|
| 每日数据同步、固定报表 | Workflow | 路径稳定、容易验证，追求低波动 |
| 多文档探索式研究 | Agent | 信息来源不确定，需要迭代搜索和整理 |
| 合同审查与审批 | Workflow + Agent | AI 做理解与建议，规则管审批与责任 |
| 跨系统订单处理 | Workflow 为主、Agent 辅助 | 外部动作需要事务性与可追溯性 |
| 复杂代码排障 | Agent 为主、测试和人工审核兜底 | 探索空间大，但上线操作必须受控 |
| 一次性文案润色 | 单次模型调用 | 不必为了“Agent”增加系统复杂度 |
这里最值得记住的不是表格里的分类，而是选择方法：先判断任务的不确定性，再判断动作的风险；两者越高，就越需要把自主性和控制机制分开设计。
06｜AI 越能自主行动，企业越需要“确定性的刹车”
我们对 AI 的期待，已经从“回答我的问题”变成了“替我完成工作”。这当然是进步。但有一个常被宣传忽略的现实：回答错了与执行错了，代价完全不同。
如果一个聊天助手把某个市场趋势解释错了，人可以重新提问、查看资料、纠正答案；如果一个获得企业系统权限的 Agent 因为理解错误而修改了一批客户信息、错误删除记录或者向外部发送了敏感文件，损失往往不会因为“模型下次答对”而自动消失。
因此，AI 应用一旦具备真实的操作能力，治理要求就会迅速提高。这里并不是要求一切都由人审批，那会重新把自动化变回手工流程。关键是分清哪些操作可以安全自动化、哪些操作需要约束、哪些操作必须由人承担决策责任。
把一次真实业务动作拆开看
以“自动处理采购申请”为例。模型可以阅读申请内容、识别采购品类、比对合同、查询历史价格、生成审查建议。这些属于对信息的解释和整理，虽然也需要质量检查，但多数不直接改变业务事实。
接下来，如果系统要创建正式采购单、冻结预算、发起付款、变更供应商账户，行为性质就不同了。这些操作具有真实的业务副作用，必须考虑授权、额度、审批与回滚。
一个合理的设计是：
AI 负责读懂输入、提取信息、提出处理方案；
规则引擎核验预算、供应商、权限、流程状态；
对需要审批的动作暂停执行，等待具有相应角色的人员确认；
获批后由确定性服务调用业务接口；
把输入、建议、批准人、调用参数和结果写入审计日志；
执行失败时按幂等、重试、补偿等规则恢复，而不是让模型随意猜测如何补救。
请注意，这里真正使系统可靠的并不是一个“更聪明”的模型，而是一套把模型自主性放在正确位置上的执行机制。
OWASP 在有关 LLM 应用的安全风险中专门讨论了 Excessive Agency（过度代理权限/自主性），指出过宽的功能、权限和自主范围可能放大模型错误或提示词注入造成的影响；其建议包括最小权限、减少不必要工具和对敏感动作进行人工确认。[8]
这给平台厂商一个直接的产品启示：未来企业付费的理由可能越来越少是“我能创建几个 Agent”，越来越多是“我能不能限制每个 Agent 只能做被允许的事，并且出问题后能找到完整证据”。
为什么这反而是 Workflow 的机会？
因为审计、审批、状态流转、权限校验和异常恢复，本质上都需要一定程度的确定性。AI 可以参与判断，但不能自己决定是否跳过所有约束。Agent 越强，越需要一套不会因为 Agent 的临时判断而被随意改变的控制体系。
这里的工作流，不一定表现为传统的拖拽画布。它可以是代码定义的状态机、事件驱动流程、业务规则引擎、持久化任务队列，或者由视觉编辑器配置的执行图。但只要存在真实的业务责任，就不可能彻底绕开控制流。
同样，这也解释了为什么 n8n 支持在 AI Agent 调用指定工具前加入人工审核，允许用户批准或拒绝执行；Dify 的生产级 Workflow 页面也把人工介入和运行追踪作为重要能力。[5][10]
所以，Agent 崛起带来的一个可能结果不是工作流消失，而是工作流从前台舞台退到了后台。用户不一定看见它，但系统越来越依赖它。
07｜企业真正买单的，从来不是“智能”，而是可交付的结果
谈 AI 产品商业模式时，我们总爱比较模型参数、节点数量、插件规模、响应速度。但对于真正需要采购并维护系统的企业，一套 AI 应用至少要通过四道非常现实的考题。
第一关：它能否接入我已经存在的业务世界？
企业不是一张白纸。ERP、CRM、OA、文档系统、数据库、身份认证、文件共享、审批平台和内部 API，早就存在不同的建设年代、不同的安全边界、不同的维护团队。AI 应用无法独立于这些系统产生价值。
一个在演示环境里会检索网页的 Agent，不代表它能进入企业内网；一个会生成表格的工作流，也不代表它有权读取财务数据库。真正难的是跨系统身份认证、访问控制、接口稳定性、数据血缘和组织边界。
平台连接器的数量当然重要，但连接器背后的可靠性、权限模型、支持范围和持续维护更重要。一个成熟的 SAP、Oracle、国产数据库或内部自研系统适配，往往比再增加十个演示插件更有实际价值。
第二关：它能否在组织规模下运行，而不只是给一个人用？
个人工具只要满足使用者就可以；企业工具必须面对组织。谁能创建应用？谁能发布？谁能编辑提示词？谁有权连接生产数据库？模型费用计入哪个部门？哪些日志对审计员可见？员工离职后个人创建的流程怎么办？
这些问题听起来与“大模型能力”没什么关系，却是企业长期使用时绕不过去的事实。对于企业来说，“有人会用”不是“组织能管”。
当部署范围从 5 人扩大到 500 人时，权限、资源配额、账单分摊、模板复用、资产归属和版本治理就从附加功能变成了基础要求。
第三关：它能否经受长期变化？
模型会升级、价格会调整、业务系统会更换、组织会改组、API 会废弃。真正成熟的 AI 应用必须容忍这些变化，而不是每发生一次变化，就安排人员逐张画布手动排查。
例如，原来的模型可以稳定返回某个结构，新版本出现了额外字段；供应商改变了限流策略；某个工具被停用。这时平台需要知道哪些应用会受到影响、如何进行回归测试、是否可以回滚到上一个版本。
换句话说，持续交付能力才是使用成本的决定因素之一。一个建立在固定平台上的 AI 应用，如果不能方便地进行变更、测试和审计，就可能在业务增长后拖累团队。
第四关：它到底省了多少成本，或者创造了多少价值？
“自动完成了 1000 次任务”不是收益指标。如果其中 300 次需要人工返工，100 次因为接口错误重复执行，每次调用又消耗了较高费用，那么“自动化次数”只是一项漂亮的展示数据。
对企业更有意义的是每个有效结果的总成本，可以粗略理解为：
单位有效任务成本 =（模型调用 + 工具运行 + 平台费用 + 人工审核 + 返工修复 + 运维投入）÷ 最终成功完成的任务数。
这个式子不是某家平台的定价公式，而是一种比较不同技术路线的方法。它提醒我们：不要只看 Token 单价，不要只算搭建耗时，更不要把大量失败后的人工补救当成免费的资源。
一个由小模型加固定规则完成的稳定流程，可能比多 Agent 自主协同更便宜；反过来，一项高度复杂的分析任务如果由 Agent 提高了成功率，哪怕单次模型费用更高，也可能明显节省人工时间。
最便宜的技术，不一定是每次调用最便宜，而是获得可信业务结果的总成本最低。
08｜为什么热闹的 AI 低代码行业，商业上仍可能很难做？
这部分必须谨慎：目前没有足够的公开证据，能够把扣子企业版下线直接归因为“企业客户不愿付费”或“平台经营亏损”。但把个案与行业的一般性压力区分开来，并不妨碍我们分析这一类产品普遍面临的商业挑战。
其一，构建工具很容易被免费体验重新定义价格
低代码应用搭建工具具有天然的“先玩起来”属性。用户会愿意尝试、分享模板、制作 Demo，甚至很愿意在社区展示成果。但“我愿意试用”和“我愿意让公司每年为它付一笔长期预算”，是两种不同的行为。
企业采购关注安全、稳定、集成和支持；个人创作者往往关注上手难度、模板数量和免费额度。一个同时面向大众创作与企业生产的平台，可能需要运营两套差异很大的产品和服务体系。
前者需要便宜、简单、流畅；后者需要合规、私有化、治理、SLA、变更管理和长期支持。这两种期待并不矛盾，但要用同一套定价与运营策略服务它们，并不容易。
其二，平台容易被两侧同时挤压
从上游看，基础模型提供商不断把检索、工具调用、文件处理、代码执行、代理运行等能力向自身产品内部整合。很多过去需要平台单独封装的功能，会逐渐成为模型 API 或智能体 SDK 的常用能力。
从下游看，办公软件、CRM、客服系统、数据库产品以及各类 SaaS 本身也在加入 AI。用户可能不再需要打开一个“AI 应用搭建平台”，而是直接在已经工作的业务系统中触发智能功能。
这就形成了典型的双向挤压：上游提供能力，下游拥有场景，中间层如果只做薄封装，议价能力就可能减弱。
但不要由此得出“中间层必然消失”的结论。中间层仍然可以提供巨大的价值：跨模型适配、跨系统集成、独立治理、统一运行时和企业特定能力。关键在于，它必须拥有自己的不可替代性。
其三，节点与模型逐渐同质化，价格竞争会更直接
模型节点、HTTP 节点、知识检索节点、循环、判断、格式转换和常用触发器，迟早会变成用户默认要求的“标配”。如果产品差异只在节点图标和配色，采购者自然倾向于选择价格更低、与现有系统更兼容、锁定成本更小的工具。
这种竞争不是低代码行业独有的问题。任何建立在标准化基础能力上的中间产品，都必须持续向上移动价值：深入业务规则、提供行业知识、强化安全治理、降低维护成本，或者形成拥有高切换成本的生态。
其四，真正昂贵的部分恰好不是市场上最容易展示的部分
做一个漂亮的 AI 画布很容易被看见；构建高可靠执行引擎、企业身份体系、权限审计、跨版本兼容、离线部署、容量规划和故障恢复，却很难在 30 秒的演示里被看见。
这会造成产品经营上的一个错位：获得用户关注的功能与支撑长期付费的功能，并不总是同一批功能。 如果团队把绝大部分资源投入了“更吸睛的搭建体验”，却没有把生产运行能力做深，进入企业市场时就会遇到阻力。
同样，如果平台一开始就追求沉重的企业治理，它可能又会失去原本低代码“快速上手”的吸引力。产品定位越模糊，这种资源拉扯越明显。
我更愿意把扣子企业版事件看成一个提醒：流量、使用量、生态热度和企业软件收入，是不同的指标。 我们可以为产品创新喝彩，但仍然必须追问，它创造的价值究竟由谁付费、如何持续兑现。
09｜真正的危机不是 Workflow 消失，而是它不再拥有“独占入口”
如果站在 2026 年回头看，AI 应用的“创建入口”至少已经出现了几条不同路线。
第一条路线，是过去大家熟悉的可视化 AI 低代码平台：用画布拖节点、配置模型和知识库，快速发布应用。
第二条路线，是AI 编程工具与代码智能体：用户描述需求、智能体修改工程文件，再通过代码审查、测试和部署完成交付。
第三条路线，是通用任务型智能体：直接围绕用户目标执行检索、整理、操作工具等任务，用户可能根本不需要先创建一个传统意义上的“应用”。
第四条路线，是业务软件内部的原生 AI：用户仍待在自己的办公系统、设计工具、客户管理系统里，只是工作过程中加入了智能能力。
这四条路线正在争夺同一个预算，却不必然拥有相同的用户。低代码平台面临的挑战，不是别人“也支持拖拽”，而是别人让一部分用户发现，自己根本没有必要再拖拽。
原来要打开平台，现在可能只需要说一句话
考虑一个日常任务：将本周的项目周报整合为管理层简报。过去，用户需要登录工作流平台，寻找触发器、文档读取、摘要生成、模板输出和发送节点，然后调试参数。
今天，用户有可能直接在协作平台里问：“汇总本周相关项目的关键进展、风险和延期原因，生成一页简报，先给我审阅。”如果系统已经接入组织里的文件和权限，原来那张流程图就不必再暴露给用户。
在这种情形下，工作流并没有消失。文档读取、权限检查、资料提取、任务生成和审阅环节仍然存在，只是用户看到的入口从流程配置器变成了自然语言对话。
这对平台行业的冲击很大：过去你要教育用户“来这里搭应用”；未来用户可能反问“为什么不在我原来的工作工具里直接完成？”
原来的产品中心，也可能变成新的基础设施
我认为，未来优秀的工作流平台会分成两种路径。
一种继续坚持“创作工具”的身份，把简单易用、模板生态和无代码创作做到极致。这不是没有价值，尤其对个人、教育、轻量团队、营销创作和试验场景来说，仍然有充分需求。
另一种则向企业级运行基础设施演进：即使用户不打开画布，平台仍负责执行调度、状态持久化、统一工具管理、权限审批、审计追踪和运行指标。它不再依赖“被看见”证明价值，而是像数据库、消息队列和 API 网关一样，融入业务系统的内部。
真正危险的，是既没有把创作体验做到明显领先，又没有把运行治理做到足够深的平台。 这类产品夹在中间，既容易在前台被通用智能体替代，也容易在后台被专业工程框架取代。
10｜如果让我重新设计一套 AI 应用平台，我会怎样划分边界？
我不会从“画一张尽可能完整的节点图”开始，而会先问五件事：用户到底要完成什么结果？哪些步骤存在不确定性？哪些动作具有不可逆后果？哪里需要长期状态？出了问题谁来负责？
在这些问题明确之后，我才会选择模型、流程、工具和部署形态。对真正长期运行的系统，我倾向把它理解成五种能力的协作，而不是一种产品形态包打天下。
第一层：自然语言入口——让人表达目标
用户可以像委托同事一样描述任务：“帮我整理供应商材料，识别合同风险，形成评审建议。”这个入口要尽量低门槛，不要求用户先学会所谓的 Agent 框架和节点类型。
但入口不能只会聊天。它还应该帮助用户澄清目标、确定输入材料、选择输出标准、理解授权范围。例如，当涉及“删除过期记录”时，系统应要求用户明确“过期”的定义，而不是默认拥有删除所有历史文件的权限。
第二层：任务理解与智能规划——让 AI 处理不确定部分
这是 Agent 应该发挥优势的地方：理解目标、选择合适工具、根据外部信息更新计划、发现缺失内容，并在必要时把问题交还给用户。
但它的权力应当被限制为“在允许的范围内规划和执行”。可以探索不同查询路径，不代表可以临时扩大数据库访问范围；可以推荐新的模型，不代表可以绕过组织的敏感数据处理规则。
第三层：确定性执行与状态管理——让流程可靠地继续
当 Agent 决定“需要查询合同”“需要发送审批”“需要等待用户反馈”之后，真正执行这些动作的部分应当具备明确输入输出、超时、重试、幂等、暂停与恢复机制。
对于可能运行几小时甚至几天的任务，系统不能只依赖一次进程和一段聊天上下文。一旦发生重启，必须知道前面哪些动作已经完成，哪些动作不能重复执行，下一步应在哪里恢复。
Temporal 关于 Durable Execution 的文档就特别强调：有的 AI 任务会跨越进程崩溃、网络超时或多日等待人工审批，持久执行的价值是恢复此前已作出的决定，而不是重新猜一遍后续步骤。[7]
第四层：企业级治理——让自主行为有边界
这一层往往在产品宣传中被一笔带过，却是企业采购时最难绕开的部分。它至少涉及身份、租户、角色权限、API 密钥、敏感数据保护、人工审批、行为审计、调用预算、风控策略和变更管理。
我尤其看重权限的“最小授予”。一个用于检索内部知识的 Agent，就不应顺手拿到删除全部文件的权限；一个用于起草回复的 Agent，不应天然拥有直接向外发送邮件的能力；一个用于代码分析的 Agent，原则上也不该默认具有生产环境的最高权限。
从安全工程的角度看，“模型很聪明”不是授权依据，任何跨系统动作都应按普通业务系统的标准进行控制。
第五层：持续交付与可观察性——让应用越用越好
AI 应用发布后仍需要持续评估：是否仍能完成任务？模型升级后有没有质量回退？错误集中出现在哪些输入？同一个任务的成本是否上涨？是否出现越权调用？
如果每次优化都只能凭用户主观感觉决定“这次比上次好一点”，那产品很难进入成熟的软件管理流程。需要稳定的数据集、评测规则、版本对比、追踪日志以及人工抽检，把“结果好不好”转化成能够持续验证的指标。
OpenAI Agents SDK 的文档将运行循环、工具调用、守护规则、人工审核和追踪视为重要组成部分，也反映出 Agent 产品的能力重点已经从单纯调用模型向完整工程运行转移。[6]
这五层不一定由同一个厂商提供，也不一定都要求自己建设。但对于一个认真做企业 AI 的团队来说，必须能够说清楚：谁负责每一层、责任边界在哪里、未来能不能替换。
11｜一个更有意思的趋势：画布可能不会消失，却会越来越少由人手工绘制
这个判断听起来有点反直觉。既然 AI 能自己规划步骤，为什么还需要画布？
因为画布不仅可以用来创建流程，还可以用来理解和审核流程。
过去，画布是用户的主要输入方式：自己拖节点、选参数、连线。未来，它很可能成为 AI 生成方案后的可视化审阅界面。人告诉系统：“我要一个能够处理供应商材料、核对风险并生成审查意见的应用。”系统先生成执行计划、权限范围和流程结构，再展示给人确认。用户不必亲手拼出所有节点，但仍能查看关键步骤、替换某个工具、插入审批环节、调整成本限制。
换句话说，画布可能从“手工编程界面”演变成“人机共同协商的业务蓝图”。
这会显著改变低代码产品的设计重点。以前产品竞赛的是节点多不多、线条拉得顺不顺、变量配置有没有快捷方式；未来更值得比拼的是：
能否根据自然语言需求自动构造可理解、可编辑的流程；
能否指出流程中的安全风险、无效步骤和高成本节点；
能否把运行日志还原为业务人员看得懂的执行路径；
能否在修改一个节点时判断影响范围，并生成必要的回归测试；
能否让同一份流程定义既可在平台中执行，也能导出为可审查的代码或开放格式。
尤其是最后一点，我认为会逐渐成为重要的竞争条件。用户不只是要获得“使用平台的能力”，还应尽可能拥有“带走自己构建的成果”的能力。
这里不必期待所有平台都把核心源代码完全开放。合理的商业软件可以拥有专有技术，但它至少应该让用户明确知道：数据能导出到什么程度？工作流定义是否有通用格式？知识库如何迁出？外部接口配置如何重建？日志和版本能否留存？
一个平台越自信，就越应该在留住用户的价值上竞争，而不是把用户锁在迁移成本里。
12｜真正决定技术选型的，是业务场景，而不是技术流行程度
在讨论行业趋势时，人们容易停留在概念层面：Agent 多么灵活、Workflow 多么稳定、低代码多么方便。但企业真正做项目时，问的往往不是“我们要不要上 Agent”，而是“这件事到底怎么做才可靠”。
不妨看三个典型的任务。它们都有 AI 参与，却需要完全不同的系统设计。
场景 A：自动生成投标方案——让 Agent 研究，让 Workflow 守住交付标准
一家技术服务企业需要根据客户招标文件生成技术响应方案。看似只是“上传文件，生成 Word”，实际任务却十分复杂：需要识别技术指标、区分强制与建议要求、理解客户现有环境、匹配产品能力、形成技术章节、检查漏项和一致性，最后输出符合格式要求的文档。
如果把全过程写成固定工作流，会很快碰到问题。不同招标文件的结构各不相同，技术指标的表达方式也不一样，某些条款需要检索产品资料，另一些需要跨章节对照，复杂的业务约束很难全部预先枚举。
这类任务适合引入 Agent：它可以根据文件结构决定需要深入分析哪些章节、提出信息缺口、检索资料、拆分写作任务并对结果进行反复校核。
但如果让 Agent 独立决定所有输出，又很容易出现另外一些问题：擅自补写产品不具备的性能指标、遗漏强制格式、引用不存在的证明材料，或者把不同版本的产品参数混在一起。
所以我更倾向于一种混合方式：
输入层固定做文件解析、原文定位、版本识别和材料校验；智能分析层由 Agent 负责条款理解、技术匹配、内容生成及交叉检查；质量控制层用可复算的规则检查指标覆盖、证据引用、禁用措辞和文档格式；交付层则通过模板和程序生成标准化成果，最后交由人员审核确认。
在这个案例里，Agent 的价值是减少复杂分析和组织文字的工作量，Workflow 的价值是让结果满足明确的交付标准。两者缺一不可。
它也说明了一个问题：对企业而言，AI 应用不是“模型回答得好不好”，而是“整个交付物是否可以使用、可以追溯、可以负责”。
场景 B：客户信息归档与审批——不是越自主越好
再看一个表面更简单的任务：销售人员把客户邮件转给系统，系统识别商机信息、补全 CRM 字段、生成下一步跟进计划，并在需要时发起报价审批。
这里 AI 的理解能力很有价值。它可以从非结构化邮件里提取客户姓名、预算、时间要求和产品兴趣；也可以把长篇沟通记录总结成简洁的商机备注。
但 CRM 字段落库、报价权限、折扣审批、客户隐私保护却属于另一类约束。即使模型判断“这个客户一定能成交”，它也不应该绕过销售政策，直接给予某个大额折扣。
所以，这类系统最值得投入的不是“多加几个反思型 Agent”，而是做好：字段校验、数据去重、角色权限、历史记录、人工确认、失败补偿和审计追踪。模型是其中重要的一环，却不是流程的主人。
如果用一句话概括：需要模型做判断时，让它判断；需要组织承担责任时，把控制权交回组织。
场景 C：弱网或离线的边缘系统——平台价值来自可生存性
还有一种经常被互联网产品忽略的场景：边缘设备、机动终端或网络不稳定的业务环境。中心服务可能暂时不可达，设备资源有限，业务又不能完全中断。
在这种环境里，AI 应用的目标不一定是“最聪明的回答”，而是“在可用资源条件下持续提供必要能力”。模型可能需要采用轻量版本，流程需要本地自治执行，外部工具需要有断连后的降级策略，任务状态必须可保存，网络恢复后再进行必要的同步与冲突处理。
一个全程依赖在线编排平台的复杂 Agent，即使单次能力很强，也可能因为链路中断而丧失可用性。反过来，一套资源开销可控、允许离线运行、具备确定性恢复机制的 Workflow，可能更符合这类业务的最低保障要求。
当然，它也可以搭配本地 Agent，在允许的资源范围内完成知识检索、故障分析和辅助决策。这种场景下，平台需要同时考虑模型能力、部署拓扑、运行资源、网络容错和数据一致性。
技术越进入现实世界，越会发现“可用”比“炫酷”更重要。
三个案例背后的同一个原则
前面三个例子分别强调开放式分析、业务审批和离线可靠性。它们从不同方向说明了一件事：不存在一种平台因为名字叫 Agent 就自动适合所有项目，也不存在一种流程因为是低代码就注定过时。
合适的技术，应当匹配任务的不确定性、操作风险、集成复杂度、运行环境和交付责任。任何脱离场景讨论“谁取代谁”的结论，都很容易变成技术宣传而不是工程判断。
13｜那么，Dify、n8n、LangGraph 和 Agent SDK 们，正在走向哪里？
分析一个品类的未来，不能只看一款产品的关停，也要观察仍在建设的产品把资源投向哪里。这里不做排行榜，也不假装存在一套对所有用户适用的“最佳平台”。更有意义的是观察不同路线分别在解决什么问题。
Dify：强调从视觉编排走向生产级 AI 应用
Dify 的 Workflow Studio 把模型调用、知识检索、工具、条件逻辑、触发器、人工审核、版本与运行追踪放在统一画布中。它当前公开的产品表达很有代表性：模型只是一个节点，能否可靠交付取决于围绕模型搭建的工程体系。[5]
我认为这是一条相对清晰的演进路径：保留低代码的易用性，但逐步把竞争重点移向团队协作、运行可控和生产交付。它不要求用户放弃画布，而是试图证明画布仍然可以承载复杂业务。
但对实际选型的人来说，不能因为产品强调“生产级”就默认所有企业要求都已满足。仍需验证版本能力、权限边界、容灾方式、插件安全、运行容量及私有化维护成本。
n8n：从业务自动化向 AI 增强演化
n8n 的出发点与 AI 原生平台并不完全一样。它长期面向跨系统自动化和集成任务，AI 是其不断扩展的一类能力。官方文档将其描述为结合 AI 与业务流程自动化的工具，并支持在工作流中引入 AI Agent、外部集成和人工审批。[10]
这一路线的强项在于业务系统连接和自动化思维。它提醒我们：很多企业买的不是“有多少智能体”，而是“能不能让多个系统真的联动起来”。
同样，工作流运行数量、任务吞吐、连接器维护和数据安全仍是实际部署时需要验证的部分，不是产品名称可以替代的事实。
LangGraph：把状态和控制权交还给工程团队
LangGraph 更接近工程框架与运行时。它允许开发者用状态、节点和边组织应用，将确定性步骤与 Agent 行为组合，并强调持久执行、人工介入和状态恢复。[4]
这与低代码平台并不构成简单的高低关系。工程团队愿意承担代码建设和维护成本，换取更细粒度的控制能力；业务团队可能更看重统一画布和可视化协作。
对于需要复杂状态、多轮工具调用、细致恢复语义的项目，代码级编排通常有更大的设计自由度；但团队必须自己处理更多工程细节，并建立相应的运维能力。
OpenAI Agents SDK：Agent 本身需要完整工程支撑
Agents SDK 的官方资料覆盖了智能体循环、工具调用、交接、守护规则、人工审批和追踪，强调 Agent 不只是“模型加 Prompt”，而是一个具有运行状态和约束边界的系统。[6]
这说明即使从 Agent 原生路线出发，最终也会面对熟悉的软件工程问题。越是允许模型动态选择行为，越要清楚地设计工具权限、执行边界和结果评估。
MCP：可能让工具连接成为更加标准化的底层能力
Model Context Protocol（MCP）试图为 AI 应用连接数据和工具提供开放协议。标准化的价值在于降低重复开发与集成成本，减少每种 Agent、每种模型与每套业务系统之间的专有连接工作。[11]
但协议标准化不会自动解决访问权限、业务语义、数据质量、审批责任和运行可靠性。MCP 更像是改善“如何连接”，而不是保证“连接后一定可以安全完成所有工作”。
如果连接工具逐渐成为普遍能力，那么平台真正的壁垒更可能转移到如何选择工具、如何授权、如何约束、如何记录、如何评估工具使用的结果。
不要把这些产品放在同一张“功能越多越好”的榜单里
| 路线 | 常见代表 | 适合关注的核心问题 | 主要需要自行验证的风险 |
|---|---|---|---|
| 视觉 AI 应用编排 | Dify 等 | 原型效率、业务协作、部署与治理 | 复杂流程维护、权限粒度、可迁移性 |
| 业务流程集成自动化 | n8n 等 | 外部系统连接、事件触发、流程自动化 | 连接器稳定性、运行规模、版本管理 |
| 代码级 Agent / Workflow 框架 | LangGraph 等 | 状态控制、复杂编排、持久执行 | 开发维护成本、团队工程能力 |
| Agent 原生 SDK | OpenAI Agents SDK 等 | 工具调用、动态决策、追踪与守护 | 应用层权限、生产运维与业务集成 |
| 业务软件内嵌 AI | 各类 OA、CRM、ERP 厂商 | 原系统场景与数据权限 | 跨系统能力、模型选择与产品锁定 |
这不是产品评分表，而是一张“问题地图”。具体产品能力变化很快，应以采购或部署时的官方文档、试用版本和真实验证为准。
14｜要不要把现有 Workflow 迁移出去？先问清楚这六件事
对于已经在扣子企业版或其他云端 AI 低代码平台上运行重要业务的团队，行业争论可以以后再谈，系统连续性必须先处理。
尤其需要注意：扣子官方当前披露了企业套餐的下线安排，但明确把部分资源的导出与备份细节留给后续公告。[1] 因此，不能假设任何资源都已经具备完整的一键迁移能力，更不能以网上流传的个别迁移经验代替本组织自己的验证。
第一件事：把“用了多少个平台功能”变成一份资产清单
不要只统计创建了多少个工作流。应当区分真正承载生产任务的应用、已经废弃的测试流程、模型配置、知识库、文件、长期记忆、对话与运行日志、外部连接器、API 密钥和访问权限。
一个简单的盘点办法是，把每个应用写成一行：业务负责人、用途、输入输出、调用频率、依赖系统、数据敏感级别、最后一次运行时间和中断后果。
这样的清单不仅服务于迁移，也可以帮助企业看清哪些应用真正创造价值，哪些只是一次性试验留下的资产。
第二件事：识别哪些能力属于平台专有运行时
同样叫“工作流”的东西，迁移难度可能截然不同。简单的 HTTP 调用和 Prompt 节点容易重建；专有的变量表达式、沙盒运行方式、知识库索引、插件协议、对话记忆机制和特殊触发器，则可能需要重新设计。
我建议把依赖分为三类：能够直接导出的标准数据、能够通过接口重新搭建的业务逻辑，以及只能依赖原平台解释的专有状态。迁移风险最大的通常是第三类。
第三件事：不要只迁移流程定义，还要迁移行为语义
两张画布看起来一模一样，不代表迁移后执行结果一致。不同平台对空值、超时、循环、并行执行、重试、变量生命周期、知识库召回和工具错误的处理，可能存在差异。
迁移验证不能只检查“节点都在”，还应当用相同的输入集合比较输出、外部动作和异常处理过程。对于敏感业务，更应保留人工复核和安全降级方案。
第四件事：建立一组真正有代表性的回归样本
在旧平台还能运行时，尽可能保留经过授权的测试输入、预期结果和关键运行痕迹。样本不仅包括成功案例，也包括空白文档、缺失字段、权限不足、接口超时、重复提交和高风险请求等异常情况。
如果没有这些基准，迁移完成后的“看上去能跑”缺少说服力。真正应该验证的是：新旧系统在相同业务条件下是否满足相同的验收标准。
第五件事：分批迁移，并保留回退能力
最危险的方案，是到最后一天把所有工作流切换到新平台。更稳妥的策略是先选低风险、依赖少、容易验证的应用进行试迁移，再处理跨系统和高风险任务。
条件允许时，应让旧版与新版系统并行验证一段时间，观察结果差异、成本变化和异常数量，然后再逐步切换正式流量。关键业务需要明确回退策略，不应把“已迁移”理解为“已可停旧系统”。
第六件事：把退出能力写进下一份采购要求
经历过一次迁移之后，最不应该做的，就是重新选择另一个更漂亮但更封闭的平台。下一份平台采购或架构设计中，应主动关注资产可导出、接口公开程度、运行时替代方案、数据归属、合同退出条款、日志留存和迁移支持。
这并不意味着必须完全自建或者排斥商业云服务。企业可以理性使用平台能力，但需要明确“可以购买服务”与“必须把核心资产永久绑定在供应商”之间的区别。
从长期来看，最好的平台未必是让你永远离不开它的那个，而是即使你有能力离开，仍然愿意留下。
15｜如果今天要选型，我只会认真看八项能力
行业里常见的选型材料很容易堆成几十页：支持多少模型、多少类型节点、多少插件、多少模板、几种部署方式。它们当然有用，但很难直接回答一个更重要的问题：这个平台能不能承载我们接下来三年的 AI 应用？
如果让我为企业做第一轮筛选，我更愿意用八个维度来建立判断框架。
| 维度 | 真正要问的问题 | 建议采用的验证方式 |
|---|---|---|
| 任务能力 | 是只适合固定流程，还是能合理处理开放任务？ | 同时测试确定性任务和探索性任务 |
| 可控执行 | 发生超时、重试、人工暂停和恢复时是否可靠？ | 注入异常，检查状态、重复动作和恢复结果 |
| 业务集成 | 能否对接现有身份、数据库、OA/CRM 和内部 API？ | 选一条真实跨系统流程试运行 |
| 数据与权限 | 模型和工具能访问什么？谁能审批与审计？ | 最小权限与越权测试 |
| 可观察性 | 能否解释一次失败发生在哪里、为什么？ | 故障定位与日志追溯演练 |
| 可持续维护 | 模型、插件或流程更新后如何验证影响？ | 版本差异、回归测试与回滚验证 |
| 部署适应性 | 云端、内网、弱网或本地部署要求能否满足？ | 目标环境压力测试与断连测试 |
| 退出与迁移 | 数据、应用逻辑和日志能否迁出？ | 实际做一次小规模迁出、重建、比对 |
这张表里，最容易被忽略的是最后三项。很多团队把选型重心放在“谁更好上手”，却没有真正验证应用在半年后的维护复杂度，也没有问清楚服务退出时能带走什么。
“好用”应当从主观体验变成可复算的结果
比较两个平台时，不妨拿同一个任务、同一组输入、同样的风险要求做试验。记录从需求到上线需要的时间、人工修复次数、任务成功率、单位有效结果成本，以及故障定位与恢复所需时间。
举例说，平台 A 用两小时搭建完成，但运行一周产生了大量人工返工；平台 B 用一天搭建完成，却在连续运行、异常处理和版本管理上表现更好。到底选谁，不应被“第一次搭建时谁更快”一项指标决定。
我越来越倾向于将 AI 平台的采购评价，从“创建效率”扩展为“生命周期效率”。这个词听起来没有“智能体工厂”那么有冲击力，却更接近企业软件的真实竞争。
还要问一个常被忽略的问题：团队现在到底具备什么能力？
同一套工具在不同团队中的表现可能差异很大。一个有强工程能力、成熟 CI/CD、安全审计体系的团队，也许更愿意采用 Agent SDK 和代码级框架；一个业务需求变化快、工程资源有限的团队，可能更适合可视化平台与标准化连接器；组织本来就深度使用某套办公或业务软件时，优先使用原系统的 AI 能力可能反而成本最低。
这意味着产品选型不只是技术比较，也是组织能力匹配。
不存在放之四海而皆准的最佳 Agent 平台，只有更符合当前业务、风险和团队能力的技术组合。
16｜下一代 AI 平台，可能不再像一个平台
如果把时间往后推三年，我最感兴趣的不是画布是否还会流行，而是 AI 应用本身会变成什么样。
今天我们习惯说“搭建一个 Agent”“发布一个工作流”“创建一个 AI 应用”，这些词背后都默认了一件事：先有一个明确边界的软件对象，再把用户带进去使用。
但未来可能出现更多“按任务即时组织能力”的形态。用户在日常工作中提出目标，系统从已有技能、工具、企业数据和可执行流程中自动挑选组件，必要时生成少量代码，形成一次可审计的执行。完成后，系统保留必要状态和记录，而不一定要求人给这项任务创建一个永久存在的可视化应用。
这种变化会让传统平台的“前台感”越来越弱，却让后台治理的价值越来越高。
趋势一：固定画布不再是唯一的创作入口
我预计自然语言、示例文件、现有代码、产品文档和操作录制，会越来越多地成为创建 AI 应用的起点。平台自动生成初步流程，用户再进行调整。视觉编辑不会失去价值，但它的角色会从“必须的入口”变成“可供检查和修改的表达方式”。
如果未来几年，复杂业务仍主要依赖人工从头拖节点才能创建，那就说明智能生成可靠流程的能力并没有想象中成熟。这是一个可以被事实检验的判断。
趋势二：单 Agent 与多 Agent 的标签会逐渐失去营销魔力
现在很多产品喜欢用“多智能体协作”展示先进程度。然而，对多数企业来说，Agent 数量本身并不是业务指标。一个 Agent 能稳定完成的任务，拆成五个 Agent 后未必会更好，反而可能增加调度复杂性、调用成本和故障定位难度。
我预计未来用户会更关注任务完成质量、成本、审计和运行可控性，少一些对“用了几个 Agent”的迷恋。多 Agent 会在确实需要专业分工、并行研究或复杂任务规划的场景发挥价值，但不应成为所有应用的标配。
趋势三：AI 平台会更像可组合的软件基础设施
模型、知识、工具、流程、执行环境、身份权限、观察与评测会逐渐形成更清楚的模块边界。企业可以选择购买一套一体化产品，也可以选用不同组件，但底层连接方式会越来越重视标准化与可替换性。
像 MCP 这样的协议可能改善工具连接，代码级 Agent 框架可能改善复杂任务编排，而传统工作流技术可能继续承担持久运行和确定性控制。它们未必归属于同一个厂商，却可能在同一个业务系统里协同工作。
趋势四：可靠性会成为比“智能程度”更有议价权的卖点
模型能力持续提升后，简单任务的回答质量差距可能收窄。到那时，采购方会更加关注：谁能安全连接企业系统，谁能减少返工，谁能在故障后恢复，谁能提供可审计的执行证据。
未来的平台评测，也许会从“可以搭建多少个 Demo”，转向“连续运行多少天、成功完成多少真实任务、出现错误时多久恢复”。
趋势五：可迁移性会成为企业平台成熟度的一部分
在产品格局快速变化的市场里，没有人能保证某家供应商会永远经营同一款产品。越来越多企业会把导出、备份、互操作和替代方案纳入采购决策。
这不是对厂商的不信任，而是对业务连续性的正常要求。真正有长期竞争力的平台，应该通过不断提供价值留住客户，而不是通过难以迁出的配置把客户困住。
趋势六：大量简单 AI 应用会被“原生化”吸收
现在很多独立 AI 工具提供的功能，本质上是对某类现有软件操作的智能化改造：整理邮件、提取数据、生成摘要、分类文档、准备会议材料。这些能力如果直接内置进用户每天使用的工具，独立应用存在的必要性就可能下降。
但跨系统、跨部门、跨模型的复杂流程仍然需要统一执行与治理，因此“简单功能被吸收”与“复杂编排需求增长”完全可以同时发生。
趋势七：AI 的用户界面会变简单，后台系统反而可能变复杂
这也许是最反直觉的一点。过去是用户学习系统规则，未来是系统努力理解用户语言；前台减少操作步骤，后台却需要更多工具选择、权限校验、状态恢复、成本控制、日志追踪和人工接管。
因此，用户眼里的“无流程”，并不意味着技术上“没有流程”；恰恰可能意味着流程被更好地封装到了底层。
这七个判断并非既定事实。它们依赖模型可靠性、工具协议、企业采购习惯和平台经济的共同变化。但无论具体速度如何，其中一个方向很清楚：用户支付费用的对象，会越来越接近“稳定完成一件事”，而不是“拥有一套可以自己拼装的工具”。
17｜对开发者来说，最值得重新学习的可能不是新框架
每隔几个月，AI 生态就出现一批新名词：Agent、Multi-Agent、Skills、MCP、Workflow、Harness、Computer Use……学新工具当然重要，但如果开发者把主要精力都放在追逐名词和模板上，很容易陷入“知道很多产品，却做不出稳定系统”的尴尬。
我认为接下来真正值得沉淀的，是几种跨平台的基础能力。
首先是业务建模能力。能否从一句模糊的需求中识别真实用户、输入输出、责任边界和验收标准？在 AI 能越来越快生成代码之后，判断“究竟应该构建什么”的能力反而更有价值。
其次是系统集成能力。理解 API、身份认证、数据模型、消息机制、权限以及异常处理。一个 Agent 再聪明，也要通过这些连接到现实业务。会调用工具不等于懂业务系统，会接入插件不等于有能力设计完整的数据流和权限边界。
第三是可靠性工程能力。如何设计可重试任务、避免重复提交、保存状态、检测故障、处理回滚？这些知识来自长期的软件工程积累，不会因为模型升级而失效。
第四是质量评估能力。如何构建代表性测试样本、定义成功标准、分析失败案例、比较不同模型和提示词版本？不会评估的 AI 应用，很容易停留在演示阶段。
第五是产品判断能力。什么场景用一次模型调用就够了，什么场景适合规则工作流，什么场景需要自主 Agent，什么场景应当禁止自动化？能做出克制的判断，比把所有技术全部用上更难，也更专业。
这一点对产品经理、解决方案工程师和独立开发者都适用：掌握工具可以提高一时的效率，掌握问题与系统的本质才能跨越工具的生命周期。
18｜我最终的判断：会消失的是一类产品定位，不是工作流本身
现在可以回到文章最初的问题了。
扣子企业版宣布分阶段下线，是否意味着工作流性质的 AI 低代码平台面临淘汰？
我的答案不是简单的“会”，也不是一句“不会”。更准确的说法是：一种以手工拖拽节点、封装模型 API、快速制作简单 Demo 为主要卖点的平台形态，确实正在承受结构性的竞争压力；但面向业务可靠性的 Workflow 机制不会因此消失，反而可能成为 Agent 工程化不可缺少的一部分。
这并不是文字游戏，而是区分两个容易混淆的概念：
“工作流画布作为商品” 与 “工作流作为软件执行机制”。
前者可能被自然语言开发、AI 编程、通用 Agent 和业务软件内嵌 AI 分流；后者承担的确定性执行、状态管理、审计审批、系统集成和故障恢复，是企业 AI 应用越深入业务、越需要认真解决的事情。
所以，我更愿意把这场变化理解为三重重估。
第一重，是入口的重估。过去需要用户先学会平台，再把需求装进画布；未来平台需要先理解用户目标，再提供合适的构建与执行方式。
第二重，是价值的重估。过去比拼“搭建一个流程有多快”，未来更应该比拼“完成一次可信任务的总成本有多低、长期运行能否稳定”。
第三重，是平台关系的重估。过去平台希望用户把一切放在自己的生态里，未来成熟企业会越来越重视资产归属、标准接口、迁移能力和多技术组合。
站在这个变化面前，低代码产品并不是没有机会。恰恰相反，如果它能把 Agent 的灵活性与 Workflow 的确定性结合起来，把企业系统连接、运行治理、测试评测和持续交付做好，它依然可能是非常有价值的一类产品。
但它不能再只说“让人人都能拖出一个 AI 应用”。那个口号曾经改变过行业，现在已经不足以解释全部价值。
它必须回答一个更成熟，也更困难的问题：
当每个人都能让 AI 搭出一个应用，为什么企业仍然需要选择你的平台，并在三年之后继续使用它？
答案不会是更多节点、更炫酷的画布、更大的模型图标。答案应该是更低的总成本、更可靠的执行、更透明的治理、更深的场景理解，以及更少的系统依赖焦虑。
如果说上一阶段的关键词是“让 AI 应用变得容易创建”，那么下一阶段的关键词应该是“让 AI 应用值得信赖”。
对于工作流低代码平台而言，这不是简单的淘汰赛，而是一场从“工具”走向“基础设施”的资格赛。
写在最后
当年，拖动第一个节点、连起第一条线时，我们真正兴奋的并不是那条线有多漂亮，而是发现原来自己也能让软件按照一个想法行动。
今天，AI 让这件事变得更加容易，甚至让机器开始自己寻找路径。这当然会改变工具的外观、交互方式和市场格局。
但技术真正应该完成的事情从来没变：帮助人解决现实问题，让结果可用，让责任清楚，让系统能够持续运行。
所以，与其为一张画布可能退场而惋惜，不如关心它留下的那些能力，会被怎样重新组合。
我们可能正在告别一个“人人拖节点”的时代，但尚未告别工作流。
我们正在进入的，是一个不必亲手画出每条路径，却必须更加认真地设计边界的时代。
欢迎讨论：当你的 AI 已经可以自己规划并执行任务时，你还会花时间亲手搭建 Workflow 吗？更重要的是，你愿不愿意把最关键的业务交给一个完全不受约束的 Agent？
