Agent Skills 会不会淘汰 Coze、Dify、N8N、织信等低代码平台？

最近，后台收到一位朋友的留言。他问了一个很有意思的问题：

Agent Skills会不会淘汰Coze、Dify、N8N、织信等低代码平台？

把这个问题拆开来看，他担心的是：Agent已经会读Skill、会调用工具了，企业还有没有必要再搭Workflow？

但看完几家平台最近的变化后，我的判断是：这个问题的前提已经变了。Agent Skills与Workflow并没有沿着两条互斥路线发展，反而正在彼此调用。

扣子官方文档已经把过去以拖拉拽闻名的“低代码项目”称为较早版本，并说明这条入口不再向新注册用户开放。现在的方向，是让AI根据自然语言开发Skill、Agent、Workflow和应用。

织信的产品文档里，也已经有了AI Skill。Agent读取SKILL.md以后，可以调用平台的数据表、自动化、BPMN工作流、仪表盘和脚本等能力。原来需要人在设计器里完成的一部分操作，现在可以直接交给Agent。

一边是AI开始替人搭Workflow，另一边是Agent开始调用低代码平台原有的执行能力。

只看表面，很像是Agent Skills赢了：以前要在画布上拉二十个节点，现在写一份SKILL.md，再配几段脚本和参考资料，Agent就能自己判断该读什么、调用什么、下一步怎么做。

可这两个产品都没有因此放弃Workflow。扣子编程允许用户通过自然语言生成和修改Skill、Agent、Workflow与应用；织信让Agent通过Skill调用平台能力，但数据模型、工作流、自动化和权限仍然负责承接业务规则与执行结果。

这说明Agent Skills最先冲击的，是“编排流程必须靠人拖拉拽”这件事。至于企业为什么仍然需要Workflow，答案要到系统开始改数据以后才看得出来。

一、先别把Skill、Agent和Workflow当成同一层东西

讨论之前，先把三个概念摆正。

Agent负责接住目标，理解当前情况，并决定下一步调用什么工具。

Skill是交给Agent的一套做事方法。按照Agent Skills的开放规范，一个Skill至少有一份SKILL.md，还可以带脚本、参考资料和模板。Agent遇到合适的任务时，再按需读取这些内容。

Workflow管的是一项任务怎样运行：先做哪一步，什么条件走哪条分支，失败后停在哪里，谁来审批，恢复时从哪里继续。

三者可以放在一起，但职责并不相同。

另外，把Coze、Dify、n8n和织信统称为低代码平台，便于讨论，却不够严谨。Coze正在向AI编程发展，Dify更偏AI应用与Agent开发，n8n的根基是业务自动化和系统集成。

织信的起点更偏企业应用底座。数据模型、BPMN工作流、自动化、权限和系统集成是它原有的执行基础，AI Agent和Skill再接入这套基础。四者定位不同，但有一个共同点：都在提供可执行的编排能力，让模型、工具、数据和人工判断按一定规则协同工作。

所以，今天要比较的并不是一个文件夹和四个产品，而是两种控制任务的方式：

• 把方法交给Agent，由它根据现场情况决定怎么做；
• 把关键路径交给执行系统，由系统保证该做的步骤按规则完成。

二、Skills先改掉的，是流程的搭建方式

假设一家制造企业每天要处理供应商延期。

采购希望AI自动找出未来两周可能延迟的采购订单，读取供应商邮件里的最新承诺，结合现有库存和生产缺料情况，判断哪些订单会影响交付，再给出催交、换供应商或调整排产的建议。

这类任务很适合做成Skill。

Skill里可以写清楚：去哪里查未结采购订单，怎样识别供应商对交期的表述，哪些物料要结合BOM和生产计划判断，风险分成几级，输出时必须附上订单号、缺料日期和判断依据。

同样是延期，Agent可以根据现场材料走不同路线。

供应商只说“尽快”，它会继续追问明确日期；物料有充足安全库存，它可以把风险降级；同一物料有合格替代供应商，它会补做替代方案比较；客户订单已经锁定，它会提高处理优先级。

如果把这些判断全部硬编码成Workflow里的固定分支，流程很容易越画越复杂。Skill则允许Agent先理解材料，再选择工具和步骤。业务临时增加“优先看战略客户订单”这样的要求，也可以直接放进本次任务，不一定要为它重画一条流程。

这正是Skills吸引人的地方：入口自然，方法可复用，对例外情况更有弹性。在开放规范下，Skill通常以一组文件存在，可以进入Git做版本管理。它的方法和文件也更方便迁移，但具体脚本、工具接口与权限配置，仍要根据新的运行环境重新适配。

因此，单纯依靠“帮用户画节点”建立价值的平台，压力确实会越来越大。用户以后可能只负责说清目标，越来越多的流程图、代码和测试样例会由AI生成。

但到这里，AI还只是在分析风险、形成建议。接下来一旦要求它创建供应商异常单、修改ERP预计到货日期、通知计划员和销售，问题就变了。

三、Skill写清了步骤，为什么还接不住一次“半成功”？

还是前面的供应商延期任务。

Agent完成分析后，连续做了三件事：

1. 在供应链系统里创建一张延期异常单；
2. 把ERP里的预计到货日期从9月22日改到9月28日；
3. 给计划员和销售发送影响通知。

前两步成功，第三步因为消息接口超时失败了。

这时不能简单地把整项任务重新跑一遍。重新执行可能再建一张异常单，也可能重复修改订单、重复发送后续通知。可如果完全不重试，计划员不知道交期已经变化，仍会按旧日期排产。

系统至少要回答六个问题：

• 这次任务已经做到哪一步？
• 第一步再次执行，会不会生成重复单据？
• 第三步恢复以后，应该继续还是从头开始？
• 订单日期是谁批准修改的？
• 如果改错了，怎样撤回或做补偿处理？
• 一个月后追责，能否还原当时使用的规则、数据和操作记录？

Skill可以写“创建异常单后更新ERP，再发送通知”。这句话描述了顺序，却不会自动生成运行状态、幂等控制、断点续跑、补偿动作和审计记录。

这就是Skill和生产级Workflow之间最容易被忽略的差别：一份做事说明，可以告诉Agent怎样完成任务；执行系统还要对每一次已经发生的业务后果负责。

当然，换成Workflow并不代表重复建单、错误重试和数据回滚会自动消失。幂等标识怎么生成，哪些节点可以重试，改错数据后如何补偿，失败到什么程度必须转人工，仍然需要项目组逐项设计。Workflow的价值，是让这些规则有明确的状态、节点和运行记录可以承载。

微软在Agent Framework的官方文档里给了一个很实用的判断：需要创造性和适应性的任务，可以优先用Skill；如果步骤会产生副作用，例如发邮件、扣款，重试时不能随便重复，就更适合用Workflow。需要固定顺序、断点恢复、人工审批和多系统协同时，同样应由Workflow承担主干。

这里的“副作用”是一个技术词，翻成业务语言很简单：这一步做完以后，外部世界被改变了。

查一份库存报告，错了可以重查。扣掉一批库存、修改客户信用额度、向供应商发出正式通知，错一次就可能带来账实不符、错误承诺或责任争议。

四、Workflow平台留下来的价值，已经不只是一张画布

如果只比较“自然语言写步骤”和“拖节点画步骤”，Skills当然更轻。

可企业把AI接进生产环境，买的并不只是一种编排界面。它还需要一套执行控制层，至少把下面几件事接住：

第一，状态。 一项长任务运行了两小时，系统要知道哪些步骤已经完成，哪些仍在等待，不能因为会话中断就全部失忆。

第二，重复控制。 同一个请求重试两次，付款、建单、发货、发消息等动作不能跟着重复两次。

第三，失败恢复。 接口超时后，系统要记录失败位置，再根据预先设定的规则决定从该节点重试、执行补偿动作，还是转交人工处理，不能只留下一句“执行失败”。

第四，权限和审批。 Agent可以提出修改交期的建议，但什么金额、什么客户、什么物料必须由谁确认，要由系统规则拦住。

第五，追踪和版本。 系统需要保留足够的运行信息，让人事后查到哪一版流程、哪一版Skill、哪个模型和哪些输入数据共同产生了结果。

这些能力已经出现在各家平台当前的产品方向里。

Dify的Workflow Studio强调人工审核、节点级运行追踪、失败分支和发布版本恢复，还可以把一条Workflow发布成MCP工具，反过来供Agent调用。Coze的工作流接口会返回调试地址，可以查看每个节点的输入输出，也支持异步任务、中断和恢复。n8n保留执行历史和失败重试，同时把Agent、人工审批和传统业务自动化放进同一张执行链路。

织信的做法更容易看清Skill与低代码平台的关系。它当前的AI Skill把数据表、自动化、工作流、仪表盘和脚本等系统方法开放给Agent调用。一旦任务进入审批、修改业务数据或跨部门流转，BPMN流程实例、流程变量和用户任务负责承接运行状态，版本机制则用来区分当前采用的是哪一版流程规则。Skill负责告诉Agent可以调用什么、怎样调用，平台继续负责谁有权执行、流程走到了哪里、当前运行的是哪一版规则。

这说明行业并没有走向“Skills取代Workflow”。两边正在向中间靠拢：Workflow平台让AI参与生成和判断，Skill运行环境则开始补权限、沙箱、日志、审批和评测。

画布可能会退到后台，控制能力不会消失。

五、企业怎么选？先算一遍“执行错一次”的代价

很多人会用“简单任务用Skill，复杂任务用Workflow”来区分。这个标准不够用。

有些任务步骤很多，但全程只读，失败了重新跑即可；有些任务只有一步，比如向客户发送报价，却可能直接形成商业承诺。

更实用的判断，是看动作的后果。

项目立项时，还可以连续问四个问题：

1. 这项任务会不会修改外部系统或向外部人员发送内容？
2. 同一步骤重复执行两次，会不会造成重复单据、重复扣减或重复通知？
3. 中途失败后，是可以从头再来，还是必须从上一个成功点继续？
4. 出现争议时，是否需要说明谁批准、系统做了什么、依据是哪一版规则？

只要其中一个问题的答案是肯定的，就要考虑增加受控执行；肯定答案越多，Workflow、审批和审计需要承担的责任越重。

六、企业Know-how不能全部塞进SKILL.md

Skills有一个很大的价值：过去散落在老师傅经验、实施顾问脑子和操作手册里的方法，终于可以被Agent按需读取和调用。

但企业经验并不都适合写成自然语言说明。

供应商说“月底前尽量交”，怎样结合历史履约、当前缺料和客户优先级判断风险，这类带语义、经验和上下文的知识，适合放进Skill。

采购订单超过多少金额必须升级审批，哪类物料不能使用替代料，普通采购员不能改已审核交期，库存扣减必须保留批次记录，这些是硬规则。它们应该进入数据校验、权限、审批流和系统接口，不能只在Skill里提醒Agent“请注意”。

判断方法只有一句：

如果模型漏读、误解了这条规则，系统仍然必须守住吗？

答案是“必须”，这条规则就不能只放在Skill里。

企业AI比较稳妥的结构，会分成三层：

• Skill沉淀判断方法、行业知识和处理例外的经验；
• Agent根据当前任务选择Skill、读取上下文并形成方案；
• Workflow、权限和数据模型负责审批、执行、记录与恢复。

织信把这三层放在了同一套企业应用底座里：AI Skill和Agent负责理解任务、调用系统方法，数据模型、BPMN工作流、自动化与多层权限负责约束写入动作和业务流转。这种组合说明，Skill不是绕过低代码平台，反而可能成为调用低代码平台的新入口。

这样做，AI有处理复杂情况的空间，企业也不会把关键业务完全交给模型的一次概率判断。

七、会被淘汰的，是“拖拉拽就是平台价值”这套逻辑

现在可以回答标题里的问题了。

Agent Skills不会直接淘汰Coze、Dify、n8n或织信。前文几家平台的变化已经说明：AI正在替用户生成和修改Workflow，Workflow也正在成为Agent可以调用的执行能力；织信这类企业应用底座，则把Skill、Agent与数据表、自动化和BPMN工作流放在同一套执行环境里。

二者的关系更像分工重组：Agent和Skill负责理解目标、适应变化，Workflow负责承接状态、权限和业务后果。它们会彼此调用，而不是只留下其中一个。

受到最大冲击的，是把“画流程图更方便”当成主要竞争力的平台。以后用户未必愿意自己找节点、连线、调参数，AI可以替他完成大部分搭建。

平台能否继续存在，要看它在画布背后还剩下什么：有没有稳定的连接器，有没有权限和凭证管理，能不能处理长任务和部分失败，能不能做人工审批、版本发布、运行追踪和责任审计。

Skills让Agent更会做事。

Workflow让企业知道这件事做到了哪一步、造成了什么结果、出了问题怎么接回来。

企业既需要前者的灵活，也需要后者对业务后果负责。下一代AI应用平台的竞争，也会从“谁的节点更多、画布更好用”，转向一个更难的问题：谁能让AI在该灵活的地方灵活，在不能出错的地方守住规则。