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. <workspace>/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 了，但我们的知识呢，他该如何处理？