OpenClaw:关公战秦琼

未来的哇咔咔6 分钟阅读

封面图

上次发了篇文章聊 OpenClaw 先驱准备成先烈,评论区不少读者评论说 OpenClaw 不好用,不如 WorkBuddy。

如果说 OpenClaw 不如 Hermes、不如 nanoclaw、nanobot,甚至不如 Claude Code,我觉得都行,各有利弊。但拿 WorkBuddy 来比,就有点关公战秦琼了。

我是个小透明,能读到我文章的人,肯定是 AI 的深度用户。如果他们都分不清这些产品的区别,那能分清的人恐怕更少。甚至从用户视角,很多人说不清楚自己到底需要什么样的 AI 助手。所以我想试着写点东西说明一下。

面对新事物的时候,人类语言是匮乏的。词不达意的。天才如乔布斯,描述个人电脑也只能比喻成"大脑的自行车"。我不敢对这些 agent 产品下定义,它们的产品经理也未必说得清楚。我只是尝试用对比的方式,说明 A 和 B 的区别。

OpenClaw 的基因

OpenClaw 是从 Claude Code 的使用经验中演化出来的。或者更准确地说,它的出现是为了解决 Claude Code 解决不了的问题——持久记忆、远程控制、常驻进程等等。正因为如此,二者在项目管理逻辑上非常相似,甚至一致。

用 Claude Code 做多项目开发的人都知道,你会平行管理很多项目文件夹。项目之间彼此独立,但共用一些基础能力和工具。每个文件夹里除了代码,还有配置项:skills、agents 等等,这些完全只服务于当前项目。这个文件夹,在 OpenClaw 里就对应 workspace。

为什么最早的一批 OpenClaw 用户几乎都是 IDE 工具的用户?因为主体逻辑完全一致——只是把 Claude Code 这类"无状态"的 agent 改造成了有常驻进程的 agent。二者在 Agent 设计逻辑上非常相似,只是服务于不同的场景。

为什么要多 Agent 协同

这引出一个核心问题:多 Agent 协同。

我有很多不一样的工作。光是一个产品,就有 web 开发、APP 开发、APP 营销,这些工作需要完全不一样的能力配置。想象一下,在公司里是不是也需要设置不同的岗位?

有人说一个 Agent 不就干了吗?还真不行。

网站开发和 APP 开发是完全不一样的技术栈,不可能在一个文件夹里放不同的项目。营销和开发关注的内容也完全不一样。强行放一起,且不提文件管理效率,所有 skill、MCP 等工具堆在一起,context 就爆炸了,agent 会变成傻子。

所以无论是从项目管理的角度,还是模型能力的角度,不同的任务必须交给不同的 agent。甚至为了保证效率,一个营销 agent 还不够,还需要拆成小红书运营、抖音运营。每个都需要单独的知识库、记忆、技能。因为真实的工作流就是这么复杂。

有了 agent,如何沟通?像 Claude Code 那样一个项目开一个窗口就行吗?远远不够。

一个小红书运营 agent,是不是得讨论选题?是不是需要发日报周报?是不是需要内容生产?工作会产生并行。如果你在一个窗口里管理,agent 会因为上下文污染发生错乱。

所以不是一个项目一个 agent 一个窗口就行的。而是一个项目一个主 agent、一堆子 agent、一堆任务窗口(专属频道、协同群聊)。

到了这个阶段,除了 Hermes 能跟 OpenClaw 谈谈功能替代,其他的都不行。Claude 系列的产品在这个方向上倒是也有迭代,未来肯定有新东西放出来。

到这里为止,其实我们还没讨论agent应用中更复杂的记忆系统、harness 工程、知识库建设等,多 Agent 协同,就是这么复杂,是 Agent 产品中的圣杯,没有上限的那种。

WorkBuddy 不是竞品

回过头,我们再看为什么 WorkBuddy 不是 OpenClaw 的竞品。

WorkBuddy 这一批桌面产品,确实是随着 OpenClaw 的热潮宣传起来的,但它们之间几乎没什么关系,最大的交集可能就是都能用 IM 工具通讯(所谓的“Claw”)。产品架构、应用场景完全不一样。

WorkBuddy 的近亲是 Claude 的 CoWork,它的出现和 CoWork 类产品的成功应该非常有关系,都是桌面级的白领 AI 工作台。它们也是从 Claude Code 中延伸出去的,不过不是多 agent 模式,是单 agent 模式。

可以这样说,OpenClaw 的出现是为了解决 Claude Code 解决不了的一些场景问题,而 WorkBuddy 这类工具则是 Claude Code 能力外溢的产物。大家在使用 IDE 的 AI 能力的时候发现,这东西不光可以编程,做通用工作也很好。为了让更多非程序员用上这套能力,最好是套一个新的皮,这就有了这类桌面工具。

WorkBuddy 的功能设计非常简洁,基本就是隐藏了 IDE 复杂的交互和界面信息,显性化了能力的部分(skill、subagent),弱化了团队协作、多 agent 协同、版本控制等高阶功能,让它成为了一个非常通用的 AI 产品。

但是万事万物都有代价。WorkBuddy 简化的架构虽然看起来仍然可以处理多项目的管理(创建多个文件夹),但是会牺牲执行效率(无法针对单个项目做工具定制和优化),这是最大的问题。具体到产品功能上可以看到 WorkBuddy 的交互可以支持手动选择 subagent 和 skill,这可以看作是打补丁,把 agent 的职责转移到了人的身上,不够 “native”。

如果说 OpenClaw 是面向 agent 做的加强设计,WorkBuddy 则是后退一步,面向用户做的简化设计。

对于一个工作内容比较一致的用户来说,WorkBuddy 是非常好的产品,类似于新时代的 Office 套件。做产品的时候能做减法其实是很不容易的,WorkBuddy 看样子是已经得到了很多用户的认可。

不过对于这类工具,我最喜欢的其实是 Manus,它的出现真是领先了同类产品 6 个月以上,产品力、技术力、审美都在线,在过去一年的时间里算是一枝独秀的原创产品吧?其他的中国产品基本都是在”借鉴”Cursor、Claude 系列、OpenClaw,不太鼓舞人心。

几类产品的粗略区分

虽然一开始说不下定义,但对比完之后,可以根据结果从agent应用的角度粗略区分一下:

  1. OpenClaw 类:多 Agent 协同工具。面向多角色、多项目的工作流
  2. Claude Code 类:单 Agent 工作台。主要服务深度开发和深度项目管理
  3. WorkBuddy 类:AI 辅助工作台。专业的垂类工作,聚焦于技能和工作流程的编排

面向的用户不同,任务不同,能干的事也不同。


最后多说几句。

我也是小白在学习,说错了多包涵。讨论产品不搞鄙视链,比如说"xxx 就是垃圾就是玩具",多探讨事物存在的合理之处,更有利于个人进步。

AI工具越来越多,学习起来确实很费劲,后续看评论中大家关注什么,能写我就多写点。个人学习的账号最近突然有了一点流量,感谢你的喜欢。