Coze 谢幕之后：谁的流程定义，能成为 AI 读得懂的资产 - 张善友
内容提要
文章以扣子企业版下线为切入点，指出第一代智能体平台集体退场，根源在于低代码工作流只是模型能力不足时的补丁，存在三个死结：用确定性流程套概率性智能、私有画布AI读不懂、流程缺乏业务语义难以治理。未来方向是让流程成为AI可读、可改、可审的代码化资产，沉淀能随平台迁移的流程资产。
延伸解读
低代码工作流为何成为“补丁”
文章将低代码工作流定位为模型能力不足时的补丁：2023年模型不会规划、调工具，人类便替它画好流程。随着模型自身能拆任务、写代码、调度工具，这块补丁的使命便到期。这一视角解释了Coze等平台集体退场并非偶然，而是技术生态位被模型能力扩张所吞噬的必然结果。
三个死结揭示平台形态的硬伤
文章指出低代码工作流存在三个死结：确定性流程难以承载概率性智能，调试时难以定位问题节点；私有画布导出的JSON充满UI元数据，AI难以直接读写；流程节点缺乏业务语义，只有拓扑而无领域含义，导致治理无从谈起。三者叠加，使这类平台难以成为企业核心生产工具。
下一代流程资产的三条标准
文章提出流程定义应成为AI原生可读写的资产，具体拆为三条：AI能读，流程以代码级结构化形式存在；AI能改，修改可diff、review、回滚；AI能审，节点绑定领域语义，使规则与流程可相互验证。前两条解决效率，第三条解决信任，缺一不可。
迁移成本与资产沉淀的分水岭
文章提醒，选择智能体平台时应追问：沉淀的流程是AI读得懂、改得动、审得了的资产，还是又被锁进下一块画布？前者每次搭建都在积累资产，后者每次搭建都在积累迁移成本。Coze企业版下线后，用户画布上的工作流大多只能重做，正是这一判断的现实注脚。
Q&A
为什么扣子（Coze）企业版下线不是孤立事件？
因为国内第一代智能体平台几乎同时退场：豆包和千问下掉自定义智能体功能，腾讯元器停止服务，百度文心智能体平台关闭创建入口。这些平台集体退场的根源在于低代码工作流只是模型能力不足时的补丁，当模型能力增强后，补丁的使命就结束了。
低代码工作流平台存在哪些根本性缺陷？
存在三个死结：第一，用确定性的流程去套概率性的AI输出，导致结果不幂等且调试困难；第二，画布上的流程以私有格式存储，AI难以读取和修改，表达力也低于代码；第三，流程节点缺乏业务语义，只有拓扑结构，无法被治理和审计。
为什么说画布上的流程AI读不动？
因为导出的流程文件包含大量节点坐标、UI元数据和平台私有字段，业务逻辑被埋没，AI无法直接理解。而且拖拽画布的表达力天然低于代码，复杂分支和异常处理难以实现，与AI写代码的能力差距越来越大。
下一代流程定义应该具备哪些特征？
应该成为AI原生可读写的、带领域语义的资产，具体满足三点：AI能读，流程以代码级结构化形式存在；AI能改，AI可直接修改流程并支持diff、review和回滚；AI能审，流程节点绑定领域语义，使治理可计算。
目前有哪些平台或协议在向AI原生流程资产转型？
百炼转向CLI化并开源，扣子升级为扣子编程不再向新用户开放低代码，腾讯将元器工作流引擎迁移到CodeBuddy以让Agent能用，MCP因太重被Agent Skills取代，Perplexity弃用MCP转向Skills。这些案例都指向流程使用者和维护者从人变成Agent。
企业选择智能体平台时应该问什么关键问题？
应该问：我在这上面沉淀的流程，是以一种AI读得懂、改得动、审得了的形式存在，还是又被锁进了下一块画布里？前者积累资产，后者积累迁移成本。Coze用户的工作流无法带走就是教训。
