我与OpenClaw：从拒绝到皈依

从误解到惊艳，OpenClaw如何用架构之美征服技术极客的心？

如果你第一次看到OpenClaw的官网，大概率会被那些漂亮的IM界面入口迷惑住——乍看之下，它像一个私人AI助手，一个拥有关于你记忆的常驻智能体。说实话，我当初也是这么误会的。

直到它真正流行起来，才意识到：长期使用coding agent的人，通常不会被OpenClaw的概念本身所兴奋。毕竟，coding agent已经能在人类指示下，或者按照提前写好的指令，完成从开电灯到清理电脑的各类工作。还能有什么是它做不到的呢？

所以，对于程序员和技术人员来说，OpenClaw这样的项目，反而容易被归类为“一个接通了IM工具的普通项目”。程序员们一直都可以远程连接到自己的电脑完成这类工作。更何况，自从Claude Code问世以来，手机端接入、电脑端配合的项目早已数不胜数。当你对Claude Code太过熟悉时，往往不愿意离开那个生态——那里你已经做了很多设置，有大量现成的command、skills之类的智能工作流。

§误解中的顿悟

真正抓住我内心的时刻，既不是第一次发现它的时候，也不是它红遍全网的时刻。因为看了再多用户案例，它都只是另一个自动化工具——而“拟人化”对程序员来说，相对不那么重要。

它第一次打动我，不是通过使用，而是通过它的架构本身。火遍全网后，网络上开始出现各种架构分析、介绍、体验分享，甚至一些配置教程也变得触手可及。这给了我一个机会，在使用之前真正去理解这到底是一个什么样的产品。

事实上，我是那种在部署服务器前需要做大量调研的人，是那种在上学时为了研究Python和Perl谁更好，才开始选择学习一门语言的人。

回到OpenClaw这个案例。最近读到一些来自X上帖子的整理——关于如何部署、能在什么环境下运行、在什么场景下应用。还煞有介事地和ChatGPT讨论了这些用户案例是否适合我这样的人。但显然这些案例还不够全面。和GPT讨论之后，唯一能感受到的是：这是一个还不错的自动化工具。

直到后来，出现了深入解读OpenClaw架构的文章。读完，真的被震撼了：

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

OpenClaw全网爆红之后，一个意外收获是：作者本人也走到了技术社区的前台。他一直都在非常积极地分享技术文章。他是VibeTunnel的作者之一，而VibeTunnel本身也是一个极具魅力的项目。

§Peter的智慧

说到VibeTunnel——某种意义上，它曾被认为是OpenClaw的替代品。你可以在手机上使用Claude Code，而这也正是Claude Code出现后，互联网上无数项目的共同方向：用手机接通人类与电脑上的agent。

尽管对这个作者早已抱有极大的尊重——在OpenClaw爆火之前就关注了他的X，平时虽不常刷，但朋友转发他的文章一定重点阅读。他在vibe coding这个领域，称得上是顶级人物。

他当年分享过如何创造VibeTunnel。说起来，那段时间对他技术文章的阅读零零碎碎的，现在看来是时候全部重读一遍了。

分享他那篇《Shipping at Inference-Speed》的文章时，想向读者介绍这个人，顺手转发了一条推特。他在那篇文章里写道：

与其用“plan mode”，我直接和模型开始对话，问一个问题……等看完觉得满意了就写“build”。Plan mode感觉像是一种hack，是旧一代不太擅长遵守prompt的模型才需要的——所以我们不得不把它们的编辑工具拿走。

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

具体来说，Plan Mode的逻辑是：当你与coding agent交流时，它不会对你的要求直接开干，而是先与你讨论一番。这一点很重要——用户要求尚未明晰时直接进行代码编辑，很容易走入错误方向。而对这种错误方向的纠偏，会浪费上下文、污染上下文，让模型对用户意图的理解充斥错误。

所以，先进plan再写代码，可以比较好地避免后期不必要的纠偏、代码失误甚至幻觉。而他指出的核心在于：Plan Mode的实现非常简单——只是将代码编辑相关的工具从AI的可用工具中移除了。这样一来，无论用户的需求是什么，AI一定不会进行任何写代码的操作。

对于一个更聪明的AI，你只要口头告诉它“我们来规划吧”，它就不会进行编码——你并不需要专门进入一个Plan Mode。即使它拥有编辑代码的权限，也会理解用户的意图，不会在应该plan的阶段开始编辑。等到可以写代码时，也不需要用户再去切换。是否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甚至去环境变量里找到了他的OpenAI key，用他自己的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是“居住”在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的分析。这个项目最夸张的时候一天能有300多个commit，即使平均每天也能有100个。文章里统计得非常详细：

从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时代最需要学会的一种生存艺术。