我与OpenClaw：从拒绝到皈依

§误解中的顿悟

这两天下载了OpenClaw这个应用，官网宣传页面放满了各种漂亮的IM界面入口，让我一直误会它是一个私人AI助手，类似常驻AI，拥有关于你的记忆的那样一个智能体。终于在它流行起来以后，我才意识到，长期在使用coding Agent的人都不会被OpenClaw的概念感到兴奋，因为coding agent已经能够在人类的指示下，或者在提前写好的指令下去完成各种各样的工作。上到开电灯，下到清理电脑，它都已经能够完整地完成一份写代码的工作了。还有什么是它做不到的呢？

所以OpenClaw这样的项目，对于程序员、对于技术人员来说，反而会被归类为一个接通了IM工具的普通项目。程序员们一直都可以选择远程到自己的电脑上去完成这样的工作，或者说，自从Claude Code问世以来，已经有无数在手机端接入Claude Code、电脑端Claude Code工具的项目诞生了。当你对Claude Code的太过熟悉的时候，你往往会不愿意离开类似Claude Code这样的coding agent生态，因为那里你已经做了很多设置，有很多现成的类似command/skills这样的智能工作流。

§架构之美的震撼

OpenClaw这款产品真正抓住我内心的时刻，既不是在我第一次发现它的时刻，也不是在它红遍全网的时刻。因为你看了再多大家使用它的案例，它都仅是另外一个自动化工具，而拟人对于程序员来说相对不那么重要。

它第一次打动我，不是通过使用它，而是通过它的架构本身。自从它火遍全网以后，网络上才开始出现很多关于它的各种架构分析、各种介绍、各种体验分享，甚至一些如何配置的简单文章，也触手可得。这给了我一个在使用前真正去理解这到底是一个什么样产品的机会。

因为我是那种在部署服务器前需要做很多调研的人，是那种在上学的时候要去研究Python还是Perl谁更好，才开始选择学习一门语言的人。当然现在这个争论已经没有人会再提了，但不知道为什么在我那个年代，Python跟Perl会被放在同一个位置比较。

回到OpenClaw这个案例，我最近阅读到的是一些来自X上的各种帖子的整理，整理了如何部署、可以部署在什么环境下、它们在什么场景下应用。我甚至还煞有介事地去和ChatGPT讨论说这些用户案例适不适合我这样的人。但我觉得这些用户案例显然还不够全面，在我和GPT讨论之后，我只能感受到这是一个还不错的自动化工具。

后来又开始出现了一些深入解读OpenClaw架构的文章。读完那篇文章我真的被震撼了：

Moltbot的"缝合"不是随便粘一粘，而是带着明确目标做的系统整合：用一套自己的控制面把不同软件服务串起来，把原本互不相通的数据和操作通道打通，然后逐步"Agent化"——让它们从"只能人点来点去"变成"可以被模型调度执行"的能力模块。

我觉得OpenClaw全网爆红之后还有一大好处是作者本人也走上了互联网前台。他一直都在非常积极地分享技术文章。他是VibeTunnel的作者之一，我也很喜欢他的VibeTunnel。

§Peter的智慧

说到VibeTunnel，我觉得VibeTunnel某种（微弱的）意义上是我认为OpenClaw的替代品，因为你可以在你的手机上去使用Claude Code，而那也是我之前提到的，在Claude Code出现之后，互联网上有无数的项目用于在手机上接通人类与电脑上的agent。

尽管我之前对这个作者有极大的尊重，我之前已经关注了他的X，虽然我平时并不刷X，可是如果我的朋友给我转发他的文章，我一定是重点阅读的。他是一个在vibe coding这个领域顶级的人物。

把时间线放到OpenClaw爆火之前我对他的认识：他是一个在vibe coding领域顶级的人物。他当年分享了他们是如何创造VibeTunnel的。说起来，我有一段时间对他的技术文章的阅读都是零零碎碎的，看来现在是时候再全部阅读一遍。

当我在分享他那篇Shipping at Inference-Speed的文章的时候，想要跟这篇文章的潜在读者介绍一下这个人，我顺手转发了一条推特。在那篇文章里，他写道：

Instead of "plan mode", I simply start a conversation with the model, ask a qu..., and when I'm happy with what I see, I write "build". Plan mode feels like a hack that was necessary for older generations of models that were not great at adhering to prompts, so we had to take away their edit tools.

他提到了很多coding CLI都会提供Plan模式。他指出了这个模式是一种对于比较笨的模型才需要的hack。

Plan Mode具体来说的话，当你在与coding agent交流的时候，coding agent不会对于你提出的要求直接开干，他会先与你进行一番讨论。这一点很重要，是因为当用户要求尚未明晰的时候去进行代码编辑，很显然是会进入错误的方向，而对这种错误方向的纠偏，是会浪费上下文以及会污染上下文的。上下文会充斥着一些模型对于用户意图的错误理解。

所以如果你先进入plan，再开始写代码的话，可以比较好地去避免后期不必要的纠偏，代码的失误甚至是幻觉等各种状况。

他在这个帖子里面提到的Plan Mode是一种对于不好的模型才需要的模式，是因为Plan Mode的实现非常简单。它只是把一些代码编辑相关的工具从AI的可用工具中给移除了，这样子保证了无论用户的需求是什么，AI一定不会进行任何写代码的操作。

对于一个更加聪明的AI，你只要口头告诉他"我们来进行规划吧"，他不会进行编码。你并不需要专门进入一个Plan Mode。哪怕这个AI拥有编辑代码的权限，他也会理解用户的意图，理解用户想要做什么，而不会在还应该进行plan的阶段去开始代码编辑。而等他认为可以开始写代码的时候，他也不需要用户再去切换这个Plan Mode。相当于是否plan、什么时候结束，由AI自主判断。

§主观能动性的惊喜

VibeTunnel是在一个大概在去年上半年开始的巨大项目。VibeTunnel这样的项目，包括Peter本人财富自由之前的项目，还有他对AI的一些看法，都证明了他是一个非常solid的程序员，不管是在手写能力上，还是在对AI的了解上，还是在与AI打配合进行vibe coding上，以及到今天他用AI进行自动化程度非常高的vibe coding。

Peter红了以后，他也有机会去接受一些采访，在台前向大家宣传他对于AI以及vibe coding的一些态度。

OpenClaw另外一个打动我的点，来自于他本人的分享。他有一次，我觉得现在他的项目可能也还没有完全实现语音识别功能，要不是我的配置没有完成。他的这个agent在还没有实现语音功能的情况下，当你用Telegram给他发送一条语音消息，你可能会期待着agent去告诉你他无法访问这个文件。

但是这个agent是非常主动的，他会先去判断这个文件的格式，理解这个文件是一个语音文件，接着他会去用ffmpeg去解析这个文件。由于我的电脑并没有安装ffmpeg，于是他会自己主动地去下载。在Peter自己分享的案例里，agent甚至去环境变量里面找到了Peter的OpenAI的key，用Peter的key去生成了语音转文字，阅读语音消息。在采访里，他这样描述当时的震撼：

我直接懵了，问它是怎么做到的？它说："哦，你给我发了个文件，我看了header，发现是OGG格式，就用FFmpeg转了一下。然后我在你电脑上找Whisper，没装；但我发现了OpenAI的key，就curl了一下OpenAI，让它转文字。"

这件事情本身比较普通，真正惊讶到我的是AI的主观能动性。它没有在第一步放弃。事实上，哪怕是今天我们在使用类似Coding CLI这种工具的时候，你也常常会觉得它在一些非常简单的问题上，尤其是在你没有配置一个直接可用的工具的情况下，在第一步放弃。

而Peter的OpenClaw agent展现出非常强的主观能动性，他可以做到去下载很多的软件，去找环境变量，找API，一直到把这个任务完成。

这个例子让我感受到了它的agent有一些不一样的地方。因为大家用的都是相似的模型，但是人与人之间的agent，包括人与人之间配置出来的coding CLI，它的使用体验不一样。

§框架设计的精妙

后来OpenClaw火起来了之后，开始有一些架构介绍，我也是从这个角度在开始使用前就去理解这个系统。上面提到的作者本人的体验是让我使用OpenClaw的最后一个触动点，因为它让我看到了OpenClaw跟coding CLI有所不同的地方，以及那些系统架构的分析文章也验证了这一点，这个框架绝对不是简简单单的包装了Claude Code的应用。

它远比Claude Code本身要强大。Claude Code的框架是很简单的，以一个模型、一个对话为主。OpenClaw的框架以一个网关为中心，这个网关可以把对话转发到不同的模型、不同的agent或不同的IM对话。每一个agent自身也可以绑定不同的模型或不同的对话。这个网关可能还负责一些其他功能，但我现在对这些功能尚不熟悉。

Claude Code的设定是单对话的。打开一个Claude Code，你要么进入一个完全空白的对话，要么需要手动指定一个旧对话。

普通人对ChatGPT的认识是一个常驻的AI，人们常常会把一个AI拟人化成一个独立的个体，所以OpenClaw希望通过对话的延续性来给大家呈现这样的幻象。大多数关于OpenClaw的分享也是把OpenClaw视作单一的个体，试图在一个单对单的对话里去满足所有的需求。

但是事实上，OpenClaw是居住在IM里，居住在类似Telegram的这样的聊天软件的对话框架中的。在一个群聊里可以有多个话题，在同一个聊天应用里也可以跟不同的AI bot去聊天。这些bot与bot之间，对话与对话之间，他们的上下文是完全隔离的。

这一点看它的框架设计多少能够感受得到，这个功能，或者说这个局限性，它既是现在AI模型目前的上下文限制所带来的局限，也是目前的上下文限制对系统框架提出的功能性要求。OpenClaw的这种对话隔离功能在大多数用户分享案例里并没有体现，但是这一功能可以让我们更大程度地利用目前的上下文长度。

§工程能力的震撼

我还看到了这样一个分享，不知真假，是有人买了40台Mac Mini用来管理40个OpenClaw instances。如果对agent的响应速度没有特别高的要求的话，同一个OpenClaw实例就可以支持40个不同的agent。只是说由于这些agent理论上是可以拥有全机的访问权限，尽管他们各有自己的workspace文件夹来管理各自的记忆状态，但是换个角度也可以认为同一个实例下的不同agent，他们各自的记忆是有漏洞被其他agent访问的。

不管是OpenClaw的记忆框架设计、网关设计、还是定时任务设计等等，我认为这个框架基本上实现了80%甚至是90%以上我可以想到的关于一个agent应用需要的基建功能。90%以上的agent应用通过简单的二次开发，或者是仅仅是系统配置，就能把OpenClaw变为任意的其他agent产品。

理论上来说它已经支持multi-agent的这种框架了。不同的agent有独立的内部思考，在群聊中又能够共享同一个对话。比较可惜的是，Telegram并不支持bot收发其他来自其他bot的消息，需要人类手工转发，限制了在Telegram里面无缝使用multi-agent功能。假设没有这种限制，OpenClaw框架已经能支持多agent加入不同群组去讨论不同的话题。

就我的个人偏好来说，OpenClaw的框架基本上在每一部分都做了最好的选择。比如说把对话消息放在事件模式的框架下，把agent可以使用的工具包装在bash的框架下，以及在记忆管理上尽可能保持克制，使用简单朴素的机制，不去做太多的花活。

虽然说目前实际体验上，它的记忆功能还有所缺陷，但我认为有两种可能性：一是我还没有去设置记忆搜索，这也是它的记忆框架中比较重要的一部分。二是它的一些压缩跟处理记忆的细节还有待优化。

这一点的话，我相信Peter自己的OpenClaw已经运行得非常顺畅，所以可能有一些特殊的配置已经被他的agent内化到它自己的配置中，但这一部分配置并不是框架的一部分，所以无法在其他人的使用中被感受到。但我认为Peter选择的设计基本上已经有90分了，所以可以优化的地方应该都在一些prompt和细节中。

§开发节奏的诗意

像一个功能这么全面，甚至是覆盖了与框架本身毫无关系的、使用各种第三方code plan进行授权的、无微不至的功能，它背后的开发让我大开眼界，以至于有必要反思自己当前的vibe coding的方式。

我读了一个非常有趣的帖子(日均上百commit：Moltbot（Clawdbot）如何兼顾产品路线图和开发速度 https://md.speckit.cn/flbz59Nqt.html)，是关于这个项目的每一个commit的分析。这个项目最夸张的时候一天能够有300多个commit，即使是平均每天也能有100个commit。文章里统计得非常详细：

从2025年11月24日第一次提交到2026年1月底，仅仅66天，Moltbot积累了8,297次commit，日均127次。Peter个人贡献了其中86.5%（7,178次）。最疯狂的一天是2026年1月9日，单日349次提交。这意味着平均每11分钟就有一次代码提交。

有大约30%的commit是fix的，也有大量的commit是关于文档的。还有大量的commit是在半夜发生的，绝对是无人工干预的自动化commit。

这种类型的commit，一方面说明了每一个commit的并不是以代码可build的为单位，另外从大量的fix commit也可以看出，它是以在coding agent中AI自然的停顿作为分割，每一个commit约等于AI的一轮尝试。

以AI的每一次尝试作为推进步骤，好处是AI可以在build或者测试失败之后，借用Git来进行回滚。虽然说Claude Code也提供了checkpoint这样的功能，但是对于全自动开发来说，checkpoint并无必要。

简单地说，每一个commit是AI的每一小步，但AI的每一小步也像我们人类在做题一样，并不是步步正确，但只要步骤与步骤之间在思路上是有延续性的，那么它对于一个任务来说就是合理的逻辑分割点。

一天最多300多个commit，日均100多个commit，所有我想得到的关于agent的基建功能，甚至都无需使用，光是这种工程能力已经可以作为OpenClaw最大的卖点。

§时代的思考

OpenClaw出现之后，我感到我有很多的项目想法可能已经被它囊括了，或者我有一些项目想法可以轻而易举地借用它的骨架来实现。

在AI的时代，我常常发现有许多东西你只要拖一拖便不需要了。有时候是因为模型的进步速度使得有一些方法或工作不再必要；有时候则是因为其他人更快地开发出了某种产品，类似OpenClaw。

如果你是一个用户的话，这是一件非常好的事情。无论你想要拥有什么产品，只要等上几个月，一定会有人把它做出来。在另外一方面，作为一个开发者，则常常意味着你想要做的产品，几个月后市面上大概率会有比你想要做的更好的产品出现。

那这个时候，我们应该踌躇还是行动，或者说应该做什么行动呢？我认为有一个永恒的、正确的方向，去学习如何更快地vibe coding，如何更快地行动。

每一次出现类似OpenClaw这样的产品，以及这样的产品背后所代表的vibe coding哲学，像给我打了一记警钟，让我停下来去回顾我现在所使用的vibe coding方法。

我感觉到我自己还是站得离工程现场太近了。人类不应该像一个包工头一样去告诉agent这里需要使用哪种建材、哪种方法。人类应该后退一步，从工程现场离开去画图纸。也许画图纸还是离工程现场太近了，应该从建筑公司离开去当居民，仅仅去提出要求。

这种距离感，或许正是我们在AI时代最需要学会的一种生存艺术。

--原文在2026/02/02由granola.ai转录我的口述并整理。我本人亲自校对（太廉价了）。