夜雨聆风三天三夜，三更半夜
3 月 31 日到 4 月 2 日，OpenClaw 在 GitHub 连续发布了三个正式版：v2026.3.31、v2026.4.1、v2026.4.2。
三天三版本，听着很勤快，但稍微看看 changelog 就会发现——这不是什么"敏捷发版"，而是一次经典的"大版本翻车 → 紧急追修"。
第一天：v2026.3.31——一个塞了太多东西的里程碑
3.31 是一个分量极重的版本。光 Breaking Changes 就有 7 项，changelog 长度堪比一篇论文。核心做了三件大事：
安全大加固——网关认证收紧 trusted-proxy 策略、node pairing 和命令权限分离、exec 环境变量过滤（屏蔽 Docker endpoint / proxy / TLS / Python index 劫持）、plugin 安装默认 fail-closed……至少 4-5 个外部安全研究者（AntAISecurityLab、kexinoh、zsxsoft、nexrin 等）的贡献被集中 merge 了进来，像是做了一轮密集的安全审计。
Task Flow 基础设施上线——Background tasks 从原来 ACP-only 的记账系统，升级为 SQLite-backed 的统一后台任务控制面，ACP、subagent、cron、background exec 全部收编到一条路径下，并新增了 openclaw flows CLI。这是架构层面的改动。
Plugin SDK 开始 deprecation——老的 provider compat 子路径和 channel-runtime shim 被标记废弃，推着插件生态往新 API 走。
除此之外还有一堆 channel 功能：QQ Bot 作为内置频道全新上线、LINE 多媒体发送、Matrix 消息流式渲染、飞书文档评论、WhatsApp emoji 反应、Nostr 签名验证……
看到这里你可能已经感觉到了——一个版本塞了太多东西。
第二天：v2026.4.1——救火
果不其然，3.31 发出去不到 24 小时，问题就开始冒了。先是出了一个 pre-release 应急，随后立刻转为正式版。
看 fix 列表就知道发生了什么：
- LINE 频道直接崩了
——changelog 原话是"LINE channels start correctly again after global npm installs on 2026.3.31"。全局安装后 LINE 直接启动不了。 - Gateway 启动后卡死
——task registry 的维护扫描在 SQLite 压力下阻塞了 event loop，gateway 启动约一分钟后 hang 住。这是那个全新 Task Flow 基础设施带来的回归。 - Bundled plugin 运行时依赖丢了
——3.31 做了一轮 plugin externalization，结果打包后 bundled plugin 丢失了声明的运行时依赖。 - Exec approval 机制大面积异常
——allow-always 表现像 allow-once、approval 流程死锁、cron isolated session 也受影响。 - Chat 错误信息泄露
——raw provider/runtime 报错直接暴露到外部聊天频道，用户看到的是一堆内部错误堆栈。
LINE 崩了、gateway 卡住、exec 权限全乱套——用户最基本的日常功能直接挂了。这要是 code review 到位，很多问题根本不该进 main 分支。
第三天：v2026.4.2——继续追
第三天又来了两个 Breaking Changes（xAI 和 Firecrawl 的配置路径迁移，继续 3.31 的 plugin 重构方向），同时：
- 继续修 3.31 回归
：exec loopback pairing 报错（空 token map fallback）、subagent sessions_spawn 崩溃（task registry 写入失败时整个 gateway 跟着挂）…… - 安全 transport 集中化
：一位叫 vincentkoc 的贡献者一个人提了六七个 PR，把 HTTP / stream / websocket 的 auth、proxy、TLS 路径全部收归集中处理。 - Task Flow 继续推进
：managed child task spawning、sticky cancel intent、plugin API seam——说明 Task Flow 是当前的开发重心，团队没有因为 3.31 的回归而放慢节奏。
翻译一下：到底发生了什么？
一句话总结：OpenClaw 团队在 3 月底 ship 了一个过于庞大的架构级版本，不可避免地引入了回归 bug，然后连续两天紧急追修。
这是开源项目中经典的"大版本发布周"模式。不能简单说是发布计划失误——Task Flow 上线、安全加固、Plugin SDK 迁移，这三件事每一件都足以成为独立的 release，但它们被塞进了同一个版本。
话说回来，修复速度确实快。LINE 崩了，隔天修好；gateway 卡死，隔天修好。三天出三个版本，换个角度看也是一种执行力。但回归的严重程度（日常功能直接不能用）也说明了发布前测试的不充分。
再拉远一点：龙虾狂热的另一面
聊完这三天的事件，我们拉远一点看看全局。
OpenClaw 在中国有多火？这么说吧——Meta 提出过 10 亿美元级别的估值，被创始人拒了。2 月份爆发了 ClawHavoc 供应链投毒事件，影响超过 13.5 万台设备。国内出现了大量 200-2000 元的"帮你部署 OpenClaw"付费服务，有兼职程序员表示从 1 月末到 3 月已经帮超过 30 人完成部署。Kimi Claw、MaxClaw 等国产对标产品相继上线，长三角和珠三角甚至形成了以"OpenClaw 标准"为核心的微型硬件生态链。
这个项目不只是 GitHub 上的技术热点，它已经变成了一个产业现象。
但产业现象的背后，是代码仓库本身的膨胀速度。这个 2025 年 11 月底才开源的项目，满打满算 4 个半月，数据是这样的：
⭐ 347,831 stars 🍴 69,465 forks 📝 6,552 个 open issues 🔀 10,484 个 open PRs ✅ 已关闭 issues 26,717 / 已关闭 PRs 15,364 👥 1,599 位 contributors 📦 4 个半月发了 81 个版本 🏠 Discord 社区 16.5 万成员
最让人注意的是 10,484 个 open PR。
作为参照——Linux kernel 的 open PR 基本为零（走 mailing list），Kubernetes 大约维持在 800-1000 个，VS Code 大约 400 个。OpenClaw 的 1 万多个 open PR 是一个非常不寻常的数字。
过去一周的数据更直观：
每天涌入约 300 个新 PR 同期只 merge 了约 95 个/天 每周 3,000+ commits（最近一周 2,890 个）
而项目的核心维护者非常集中——创始人 steipete 一个人贡献了 15,667 次 commit（占总量的压倒性多数），第二名 vincentkoc 是 2,191 次。bus factor 极低。
甚至在 PR 列表里，已经能看到标题为"feat: Auto contribution 2026-04-04"这样的自动提交——AI 生成 PR 的痕迹已经很明显了。
中国社区的参与度也在数据上有直接体现：飞书、微信、QQ Bot 三个国内主流通讯平台都已经是内置 Channel（v2026.3.31 新增了 QQ Bot），GitHub 上中文相关 issue 有 558 个、中文 PR 159 个，腾讯混元模型集成的 PR 今天刚刚提交。
一个 4 个多月的项目，35 万 star，1 万个 open PR，每周 3000 次 commit，1600 个贡献者，81 个版本——这些数字，无论从哪个维度看，都已经远远超出了人类 code review 的物理极限。从三天三版本的回归 bug 来看，至少工程质量上，这个项目正在为自己的爆炸式增长付出代价。
担忧
我不是在唱衰 OpenClaw。相反，我自己就是深度用户，我的 OpenClaw 龙虾 cc 每天在上面跑。
但三天三版本这件事，让我不得不思考一些问题：
- PR 堆积意味着什么？
1 万个 open PR，每天只 merge 不到 100 个——大量社区贡献者的代码在排队等待 review，有些可能永远等不到。这对社区热情是一种消耗。 - 安全加固和回归并存
。3.31 做了大量安全修复，但同时引入了日常功能的回归。赶着加固安全的同时把基本功能搞挂了，快速迭代的代价就是这么直接。 - AI 生成 PR 的涌入
。当提交 PR 的门槛降到"让 AI 跑一下"的程度，维护者的 review 压力会指数级增长。OpenClaw 可能是最早撞上这个问题的项目之一。
下一篇
数据太多，一篇写不完。下一篇我会详细分析 OpenClaw 的项目健康度——对比 Kubernetes、VS Code、Home Assistant 等成熟开源项目的 PR review 机制、bus factor、release 质量控制，聊聊 Vibe Coding 时代的开源工程质量该怎么守。
