OpenClaw 发展历程表：从 clawdbot 到 openclaw

这份时间线，是从 v2026.1.5 开始往后捋。按 release 命名和说明来看，这一版基本可以当成项目正式进入 clawdbot 阶段的起点。后面它先经历了 clawdbot、Clawdbot 这几个写法上的变化，中间还短暂改名成过 Moltbot，直到 v2026.1.29 前后才真正把名字切到 openclaw。

按时间排序的发展历程表

关键阶段解读

1. clawdbot 阶段的起点：v2026.1.5

v2026.1.5 之所以值得拿出来单说，不只是因为它加了 image model 和 image 工具，更重要的是，它在 release 名称里明确用了 clawdbot。

如果你是站在“发展史”这个角度往回看，很多时候真正重要的并不是某个单点功能，而是项目开始以什么名字、什么姿态稳定对外发布。v2026.1.5 给人的感觉就是：这个项目已经不是一个随手试验的小仓库了，它开始以 clawdbot 的名义连续往前推版本。

2. 能力开始外扩：v2026.1.14-1 到 v2026.1.16-2

我觉得这两个版本要放在一起看。

v2026.1.14-1 把网页搜索、网页抓取、浏览器接管、远程浏览器控制、通道插件这些能力拉进来了。紧接着 v2026.1.16-2 又把 hooks、媒体理解、PTY 执行、hook pack 安装、skill 命令这些东西补上。

放在一起就很明显了：项目已经不再只是“接一个大模型，然后把回复发出去”。它开始具备下面这些更像 agent 系统的特征：

• 能拿外部信息

• 能操作浏览器

• 能接更多消息渠道

• 能处理图片、音频、视频这类输入

• 能用 hooks 和 exec 把自动化流程串起来

这时候的 clawdbot 已经具备平台雏形。

3. Clawdbot 阶段的放大版：v2026.1.23 和 v2026.1.24

如果前面那几版是在扩边界，那 v2026.1.23 和 v2026.1.24 更像是在补产品感。

v2026.1.23 把 Telegram TTS 往 core 里推了一步，又加了 /tools/invoke HTTP endpoint。这个点挺重要的，因为它意味着外部系统不只是“接它的回复”，而是可以更直接地调它的工具能力。到了 v2026.1.24，Ollama discovery、LINE 插件、Edge TTS fallback、全渠道 /approve、Telegram DM topics、Control UI 设计系统刷新这些又一起上来了。

这些东西单独看都不算改天换地，但合起来会让人感觉：这个项目开始更像一个完整产品，而不是一堆厉害功能的集合。

最直观的变化大概有这几类：

• 部署方式更多

• 插件和渠道更丰富

• 审批和 TTS 这种实际使用中的流程更顺畅

• 控制界面更像真的要长期给人用的界面

• 本地模型这条路也更加清楚

4. Moltbot 短暂过渡期：2026-01-27

clawdbot 并不是直接一步改成 openclaw，而是先短暂改名成了 Moltbot。创始人谈及收到了Anthropic公司礼貌的请求改名的函件。

根据官方 lore 页面和当时的外部报道，2026-01-27 这一天，项目先短暂改名成了 Moltbot。 这次改名很短，后来又很快被 OpenClaw 取代，如果只看 GitHub release中的发布名称，很容易把这段历史忽略掉。

5. 正式改名：v2026.1.29

整条时间线里，如果只挑一个必须单独圈出来的版本，那大概率就是 v2026.1.29。

这一版不是那种“文案层面改个 logo”的改名。release 里写得很清楚：

• npm package / CLI 改名为 openclaw

• 提供 openclaw compatibility shim

• extensions 迁移到 @openclaw/*

• 自动迁移旧的 state/config 路径

• macOS 侧的 OpenClaw app rename 也收尾了

也就是说，这次改名是全链路的：

• 命令行入口

• 包名

• 扩展生态命名

• 本地状态目录和配置路径

• 桌面应用

所以从项目史的角度看，v2026.1.29 其实很适合直接写成一句话：OpenClaw 时代从这里开始。

6. 改名之后的收口：v2026.2.1

改名这件事，真正麻烦的往往不在改名当天，而在改完之后。

新名字换上去不难，难的是那些老路径、旧配置、残留命名、权限边界、默认行为到底有没有一起跟上。v2026.2.1 的价值就在这里。它把不少真正影响稳定性的边角补了起来：.clawdbot 到 .openclaw 的迁移继续完善，TLS 1.3 最低要求、安全修复、工具策略一致性、系统提示规则这些也都在继续修改为适配新品牌。

7. 更成熟的工作台阶段：v2026.3.12

如果说 v2026.1.29 是品牌上的拐点，那 v2026.3.12 更像是产品形态上的拐点。

这一版最醒目的东西是 dashboard-v2、fast mode、provider-plugin 架构、subagent 机制继续增强。它传递出来的信息很明确：OpenClaw 已经不只是继续“多接几个 provider、多补几个渠道”了，而是在往一个更统一的 AI 工作台走。

这里面我最看重的其实不是单个 feature，而是方向开始统一：

• Control UI 不再只是配置入口，而像一个真正的工作台

• provider 接入开始更模块化

• 多 agent / subagent 的编排能力还在继续长

• 安全治理也不再是零散修补，而更像系统性推进

换句话说，到这个阶段，OpenClaw 已经不是单纯“功能继续涨”的项目，它开始同时处理平台化和产品化这两件事。

8. 值得记下来的外部里程碑：2026-03-01

还有一个时间点绝对不该漏掉，虽然它不是一个 release 版本本身。

根据公开的 Star History 文章和当时的公开讨论，2026-03-01 这一天，OpenClaw 超过了 facebook/react，成为 GitHub 上 star 最多的非聚合型软件项目。 这句话要说严谨一点，因为它不是 GitHub 全站所有仓库里的绝对第一；排在前面的还有不少 awesome-*、教程合集、书单和资源索引类仓库。

但即便加上这个限定，这个节点依然很重要。因为它说明 OpenClaw 的影响力已经不只是停留在 agent 圈子、开源圈子或者 AI 工具用户内部了，它开始进入一种更广泛的技术社区共识：不管你喜不喜欢它，它都已经变成 GitHub 上最受关注的软件项目之一。

如果把这个时间点和 release 对起来看，它正好落在 v2026.3.1 发布前夜。也就是说，OpenClaw 在进入 v2026.3.1 这个阶段时，外部关注度已经冲到了一个很夸张的位置。后面 v2026.3.12 再往工作台化、平台化方向走，这个背景就更容易理解了：项目不只是用户多了，而是真的进入了“大众技术视野里的头部项目”区间。

如果只选 5 个必须高亮的版本

参考 release

• v2026.1.5: https://github.com/openclaw/openclaw/releases/tag/v2026.1.5

• v2026.1.14-1: https://github.com/openclaw/openclaw/releases/tag/v2026.1.14-1

• v2026.1.16-2: https://github.com/openclaw/openclaw/releases/tag/v2026.1.16-2

• v2026.1.23: https://github.com/openclaw/openclaw/releases/tag/v2026.1.23

• v2026.1.24: https://github.com/openclaw/openclaw/releases/tag/v2026.1.24

• v2026.1.29: https://github.com/openclaw/openclaw/releases/tag/v2026.1.29

• v2026.2.1: https://github.com/openclaw/openclaw/releases/tag/v2026.2.1

• v2026.3.12: https://github.com/openclaw/openclaw/releases/tag/v2026.3.12