大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



本文来自微信公众号： 叶小钗 ，作者：叶小钗，原文标题：《OpenClaw 会不会淘汰 Coze、Dify 这类平台？》

熟悉我的同学会知道，在学习这个事情上，我是非常建议大家尽早的建立一套知识框架的，我之前在做管理课题的时候有一套自己的框架；

同样，在做AI课题的时候，我依然有自己的框架，这套框架的逻辑是：不要管市面上出了多少产品，你就站在我要做这个产品的角度出发，将他进行分类，分类后再对每个品类的产品，做参数区分，也就是思考如何做选型，只要做到这一步，那么你的基础知识框架就算建立了，比如这个AI框架：

只要形成了自己独有的知识体系，就不容易被市面上各种震惊体带偏，比如我们群里有个粉丝就在感叹：

龙虾这玩意对于我而言，没什么明显的优点。龙虾会的，我自己写脚本都能做，龙虾还没自己做得好。但缺点很明显，就是太费钱

其实，粉丝这句话已经接近了OpenClaw的本质了。大家要思考一下，OpenClaw核心代码也就4000来行，但是服务于他的Skills却已经到了1.6万个了，而且这个数字会进一步膨胀。

那么我们应该如何对OpenClaw进行分类呢？如果只从承载SOP/Workflow/Skills的角度出发，我会认为他应该跟Coze、Dify这种智能体框架放到一起。

然后，我这里收集了一些粉丝对OpenClaw的使用信息：

2.房东家的铲屎官装了，做浏览器定时数据采集。对于开发来说用处不大，对于运营等非专业人士方便，三言两语可以实现自己的采集需求。

3.tim哥装了，没用

4.张一白装了在尝试把每天繁碎的事情交给他目前没有帮助

……

9.方凯康装了，搜寻并整理了几份资料

10.TimeLorder.2.04.00非常认真的学习研究了很多版本，以及各大厂的流程，和专业人工智能实验室的小伙伴评估了一下，决定不装，因为没用。

11.树帮我改公众号文章，写web前端页面（streamlit）好用容易上手，但是要进一步优化——比如：如果不给它配置wiki它把它自己的配置文件都能改崩溃掉

……

26.czhiming装了，并且配置了slack channel，目前还没有用起来

27.YYJ，没装，感觉token消耗太大，而且权限太高，没有特别适合的场景，最近是在用codex客户端搭配gpt5.4，用默认权限模式来做一些本机操作，作为开发辅助感觉还不错

28.随心录装了，没深度使用

29.全栈（伪）-南港听夏刚装，准备跑本地轻量模型用来获取我关注的up的标题和地址。虽然用n8n建立过自动化运行过滤的信息渠道，但是我想让它一直开机，每天早上自动推送到我邮箱。真正简单开发用trae已经可以了。

30.安装了。很新奇，但使用了几天，没什么大作用，只能做小事

大家会发现OpenClaw被用的并不好，并且他能做的，Coze几乎全部能做，于是这里问题就来了：

OpenClaw是不是正在积压Coze/Dify等平台的生存空间？

为了回答这个问题，我们这里先给一个能力对比图，再逐渐展开叙述：

OpenClaw VS Coze

从使用者视角看，OpenClaw的核心在于围绕Skills去组织能力：先筛选、安装、组合，再按需调整和修改。最终会形成在某个能力符合心意的助理；

而对于Coze来说，他的工作本身就是编排Workflow，围绕Workflow、Knowledge、Plugin这些平台模块，把一个AI应用编排出来。

接下来，我们用个简单案例让大家看得更直观：

自动整理今日重要邮件，并将附件保存到指定文件夹，最后生成一份摘要报告

这个案例虽然简单，却五脏俱全，它同时包含两类能力：

1. 一类是认知能力：判断什么算重要邮件、提炼邮件内容、生成摘要。
2. 另一类是执行能力：读邮件、下载附件、保存文件、输出结果；

而这正好对应了两种完全不同的产品思路：

1. Coze会把这件事拆成一条Workflow
2. OpenClaw会把这件事交给一个装好了Skills和工具的Agent去持续完成

在Coze的语境里，任务就是任务，他不存在“助理自由发挥”的可能，他回归的是业务流程设计问题，比如这个案例会变成标准流程：

1. →定时触发
2. →获取今日邮件
3. →逐封判断重要性
4. →有附件则下载
5. →存入指定文件夹或外部系统
6. →汇总成摘要报告
7. →发送到目标位置

这就是Coze的思路：先有流程骨架，再把模型、插件、知识、代码节点往里填。

Coze的官方文档也明确把Workflow描述成一个用节点去实现业务逻辑的系统，同时提供Plugin、Knowledge、Model等模块来补齐能力。

Coze的流程

为了帮助大家更好的理解，我们这里再做细点，Coze可以分为5个节点：

1. 定时触发节点。比如每天早上9点启动一次流程；
2. 邮件读取节点。通过插件、HTTP请求，或者接入外部邮件系统API来实现，方法多得很；
3. 重要性判断节点。这个稍微复杂点，需要一定策略，也就是你需要建模，比如来自老板、客户、财务、法务的优先，然后模型节点根据这些规则打标签；
4. 附件处理节点。如果邮件带附件，就把附件下载下来，再通过插件或其他系统保存到指定存储系统。这一步最能体现Coze的本质：它不是在“模拟一个人点开邮件再保存文件”，而是在“编排一串系统之间的接口调用”；
5. 摘要输出节点。最后把今天的重要邮件汇总成一份报告：今天有几封重要邮件、每封邮件的核心内容是什么…前面是流程，后面是模型内容生成；

这里总结一下，Coze的核心是Workflow，他最终目标是搭了一条邮件处理流水线，并且他非常稳定。

另外，Coze官方提供了很多模板，大家可以自由选择（因为Coze大家很熟悉，我这里说得比较简单）：

然后就是OpenClaw的流程了：

OpenClaw的流程

到OpenClaw“叙事逻辑”上就与Coze有很大不同了，它更像一个self-hosted的agent runtime：先有agent、workspace、skills、plugins、sessions、cron，然后你再往里面装能力。

官方文档也明确把这些作为OpenClaw的基础组成，同样这个整理邮件的任务，在OpenClaw里更像下面这个过程。

第一步：先定义“这个助理要会什么”

在OpenClaw里，需要先定义一个会整理邮件的agent。并确定他的能力：

1. 会读邮件
2. 会判断重要性
3. 会保存附件
4. 会写总结

这也是为什么OpenClaw的Skills会显得特别重要。

官方文档明确说，Skills是用来“teach the agent how to use tools”的skill folders；

每个skill是一个目录，至少有一个SKILL.md，也可以带supporting files、scripts、metadata。

ClawHub则把它们组织成一个可搜索、可安装、可更新的公共registry。

第二步：先找有没有现成Skills

OpenClaw之所以强大，是因为他不需要自己从头写一堆Skills。

用户可以去ClawHub search、install、update、publish skills。所以这个邮件案例里，一个真实用户大概率会这么干，先去搜索：

1. 有没有邮件相关skill
2. 有没有文件保存相关skill
3. 有没有日报相关skill

如果找到了合适的skill，就直接install到当前workspace。

这里如果要与Coze类比下的话，他很像：在Coze里找一个workflow template，然后拿过来改。

从产品本质上讲，OpenClaw的“找Skill”跟Coze的“找模板”是一类动作。只是前者找的是能力包，后者找的是流程图

第三步：Skills的作用域

具体执行的时候，Skills会从三个位置加载：

1. bundled skills
2. ~/.openclaw/skills里的managed/local skills
3. /skills里的workspace skills

优先级是：workspace>local>bundled。这里主要是考虑SKills是否有共享而设计，我们这里做案例说明，就不展开了。

第四步：检查Skills

一个skill不是装上就万事大吉，它还要看当前环境里有没有需要的依赖、有没有对应工具、有没有满足配置条件。

所以做这个邮件案例时，你不会只是装上一个邮件skill就结束，而是还要检查：

1. 当前环境有没有对应的依赖
2. 需要的配置项有没有填
3. 它能不能访问你要保存附件的目录
4. 会不会和已有skill冲突
5. session里最终加载到的是哪个版本
6. …

第五步：不够用怎么办

在邮件案例里，你可能会遇到这种情况：

1. 现成skill会判断重要邮件，但你的“重要”定义和它不一样
2. 它会存附件，但默认目录不是你要的
3. 它会写摘要，但格式不是你要的日报格式
4. 它默认按主题筛选，但你想按发件人+附件+项目关键词综合判断

这时候，在Coze里你大概率会去改workflow节点。而在OpenClaw里，更自然的路径是：直接改SKILL.md：

name:email-daily-digest

description:每天整理今日重要邮件，保存附件，并生成摘要报告

version:0.1.0

tags:

-邮件

-摘要

-附件

-自动化

#邮件日报助手

这个Skill是干什么的

当用户要求你“整理今天的重要邮件、保存附件、输出摘要报告”时，使用这个Skill。

触发条件

当用户提出以下类似需求时启用：

-整理今日邮件

-找出重要邮件

-下载并保存附件

-输出邮件摘要或日报

任务目标

你需要完成以下事情：

1.读取今天的邮件列表

2.判断哪些邮件属于“重要邮件”

3.下载重要邮件的附件

4.将附件保存到指定文件夹

5.生成一份简明摘要报告

重要邮件判断规则

满足以下任一条件，可以判定为重要邮件：

-发件人属于老板、客户、财务、法务、核心合作方

-邮件主题包含以下关键词：合同、付款、报价……

-邮件带有附件，且内容与当前项目相关

-邮件明确要求回复、确认或执行下一步动作

以下情况默认不算重要：

-群发营销邮件

-系统通知

-无明确事项的普通抄送

-广告或订阅内容

执行步骤

请严格按下面顺序执行：

第一步：读取邮件

读取今天收到的邮件，提取以下信息：

-发件人

-标题

-时间

-正文摘要

-是否有附件

-附件名称

第二步：筛选重要邮件

根据“重要邮件判断规则”筛选出重要邮件。

第三步：保存附件

如果重要邮件带有附件：

-下载附件

-保存到以下目录：

./workspace/email_attachments/today/

保存时使用以下命名规则：

发件人_日期_原文件名

第四步：生成摘要报告

输出一份Markdown格式的摘要报告，格式如下：

#今日重要邮件摘要

……

输出要求

-报告必须简洁

-不要重复原邮件全文

-重点提炼“谁发的、说了什么、为什么重要、下一步要做什么”

-如果没有重要邮件，明确写“今日无重要邮件”

注意事项

-如果目标文件夹不存在，先创建文件夹

……

从这里大家应该就看到了OpenClaw不是没有Workflow，而是把Workflow藏进了Skills，并且在用自然语言做描述

然后，整个OpenClaw就可以运行起来了，我们这里走下流程：

OpenClaw是如何运行的

首先是任务触发，他可能是个定时器，也有可能是我在聊天窗口（比如钉钉）说了一句：整理今日重要邮件，于是整个任务开始运转：

第二步，OpenClaw会做任务理解，也就是我们常说的意图识别，他需要去判断：

1. 这不是普通问答
2. 这是一个执行型任务
3. 里面包含“邮件处理+文件处理+摘要生成”三类需求

这里主要目的是决定用哪个Skills，这里的Skills不是直接执行器，而是教agent如何使用tools的方法包。

官方文档原话就是：Skills are used to teach the agent how to use tools.

第三步，当模型识别完任务类型后，就会优先去匹配当前环境里和这个任务最相关的Skills。

比如“整理今日重要邮件”这个任务，模型会发现它需要的不是全部能力，而是更偏向邮件读取、重要性判断、附件处理、摘要总结这一类能力。

所以这时候，OpenClaw并不是把所有Tools一股脑交给模型去乱选，而是先通过Skills，把这次任务真正相关的方法范围收缩出来。

第四步，模型会去读取对应Skill里的说明，然后按照Skill里面预设好的方法，展开这次任务的执行步骤。比如这个任务，在Skill里面大概率已经隐含了一条处理链路：

1. 先获取今日邮件
2. 再判断哪些邮件重要
3. 提取关键信息
4. 下载附件
5. 保存到指定文件夹
6. 生成摘要报告

你会发现，这其实已经是一条Workflow了。

只不过在Coze里，这条Workflow往往是直接摆在画布上的；而在OpenClaw里，这条Workflow更多是被封装在Skills里面。

第五步，在Skill把任务步骤展开后，模型才会进一步判断：这一步具体该调用哪些Tools。

也就是说，Skill决定“怎么做”，Tool决定“具体怎么执行”。比如：

1. 读取邮件，要调用邮件相关Tool
2. 保存附件，要调用文件处理相关Tool
3. 生成摘要，要调用模型本身的总结能力

到了具体执行步骤时，模型会基于已暴露的tool schema发起实际的工具调用。Skill提供方法说明和任务偏好，Tool提供实际执行接口，Skill会影响模型如何选择和组织Tool。

他不是先把所有Tool都胡乱装上去，而是在模型已经明确任务、选定相关Skills、拆出执行步骤之后，再去调用真正需要的那些Tools。

第六步，当这些Tools被逐步调用后，任务就开始真正落地执行了：

1. 拉取今天的邮件
2. 按规则筛选重要邮件
3. 下载对应附件
4. 把附件保存到目标目录
5. 汇总邮件内容，生成摘要报告

最后，再把结果回传给用户。这里整体流程就出来了：

用户提需求→模型先做意图识别→选择相关Skills→按Skill内部预设流程拆解任务→再决定调用哪些Tools去执行

在了解了OpenClaw与Coze后我们就要回归最初的问题了：

当你已经用代码/Coze/Dify跑通工作流了，OpenClaw的出现意味着什么，Coze/Dify这些选手会被淘汰吗？

OpenClaw会淘汰Coze吗？

这里先给结论：我认为相当长一段时间来说是不会的，而且我预估OpenClaw会比Coze、Dify优先被忘记…

这里有个最核心的逻辑：大多数企业和用户，真正需要的不是“一个会自由发挥的助理”，而是一条稳定、可控的自动化流水线。

换句话说：Coze/Dify完成的功能更为原始，在真实业务里，最重要的往往不是“像人”，而是：

1. 流程能不能看得见
2. 权限能不能控得住
3. 出问题能不能排查

这些都不是Agent现在要处理的，他们是工程治理问题，OpenClaw和Coze/Dify其实还是在满足不同的层次需求；

只不过现在大家还没把OpenClaw玩明白，总是盯着Workflow的场景折腾，原因也简单：这些任务简单、好实现嘛…

OpenClaw倒闭平台升级

OpenClaw的出现，一定会对Coze、Dify这类平台形成压力，但这个压力不一定表现为你死我活，而更可能表现为：用户对AI应用平台的预期，被整体抬高了。

以前大家对平台的要求，大概是这些：

1. 能不能接模型
2. 能不能拉工作流
3. 能不能调插件

但OpenClaw火起来之后，用户会开始提出新的要求：

1. 能不能常驻运行
2. 能不能像助理一样持续记事
3. 能不能通过能力包快速扩展
4. 能不能在聊天里直接交办任务
5. …

OpenClaw把市场注意力，从搭一个AI应用，往养一个AI助理上推了一步。它会倒逼Coze、Dify这类平台，往三个方向继续长：

一、Workflow要更Agent化

不再只是死板节点图，而是允许模型在流程中做更强的动态决策。这背后的逻辑是，提升Workflow的泛化能力，不要一小点变动，原来那套就用不了了。

其次就是之前还是在画布上自己拖拽，以后这种Workflow搭建，要尽可能可以用自然语言完成。

二、平台要更智能化

曾经这些工作流平台追求的是用完就走，但现在逻辑变了，要求可能不只是“运行一次流程”，而是要能有session、状态、定时任务、长期上下文、事件触发等。

三、更强的生态

OpenClaw的Skills/ClawHub之所以有传播力，本质上是因为它把能力复用这件事做得很直观。

这里对应的对Coze/Dify等平台的要求就是，插件贡献者要足够多，生态也要繁荣起来。

结语

就现在OpenClaw的发展，已经暴露了很多问题了，包括：

1. skill太多怎么治理
2. 权限太大怎么约束
3. 结果不稳定怎么排查
4. 团队协作怎么交接
5. 给企业交付时怎么标准化

而Coze、Dify往前走，也一定会遇到agent化的问题：

1. 用户不想每次都画流程
2. 用户想直接对话交办任务
3. 用户希望应用长期在线
4. 用户希望系统自己记忆、自己计划、自己触发

所以两边最后都会向中间靠：OpenClaw会越来越像平台；Coze、Dify会越来越像运行时。

只不过，从AI应用三要素来说，KnowHow会形成SOP/Workflow/Skills，这个无论是Coze/Dify还是OpenClaw都完成的不错，也就是：

在不需要额外知识的情况下，当前的AI是很强的，尤其是OpenClaw，他让老板们/个人形成了整理SOP的习惯

只不过，这依旧是第一阶段的玩法，Coze/Dify这种平台，用Workflow解决点简单自动化任务轻而易举，这些动作对于OpenClaw也不会太难，只不过知识呢？

Coze/Dify的知识库是很难用的，而就现在市场上都没几个把AI客服玩得明白的公司。这里的点是：

当前各种AI框架已经能很好的承载SOP/Workflow/Skills了，但我们的知识呢，他该如何处理？