不再拉上百 MB 无用依赖:OpenClaw v2026.5.12 用隔离思路让安装和通道都更轻

瘦身 · 隔离 · Telegram 独立线程 · pnpm 11 · 安全加固
——
openclaw/openclaw v2026.5.12 把过去散落在核心运行时中的
Provider 与通道依赖逐一拆出，
同时为 Telegram 接入了独立轮询通道和本地持久化回放能力。

什么是 OpenClaw

OpenClaw 是一款开源的个人 AI 助手框架，
支持所有主流操作系统（macOS、Windows、Linux）。
它的技术形态是运行时 + 插件体系：
核心提供 Agent 调度、通道分发、模型路由和 Gateway 网关，
而 WhatsApp、Slack、微信、飞书等通道以及 Bedrock、Vertex 等 Provider
都以插件形式接入。

截至 v2026.5.12，仓库拥有 37 万+ Star，社区活跃度极高。
用户可以在一个统一配置下，把 AI 助手部署到多个聊天平台、
绑定不同的模型后端，并利用插件生态扩展能力边界。

安装膨胀与通道不稳，老用户的日常痛点

用过 OpenClaw 一段时间的人，大概都有过这样的体验：

安装体积失控。
npm install -g openclaw 会把 WhatsApp 的 Baileys 库、
AWS SDK 全家桶、Anthropic Vertex 的依赖、Slack 的 SDK 全部拉下来。
即使你只用 Telegram 聊天，也要等数百 MB 的无关依赖下载编译。
这在容器部署和 CI 场景下尤为痛苦。

Telegram 接入稳定性不足。
当 Bot API 轮询和主事件循环跑在同一个进程里时，
一旦主循环卡住（例如 LLM 流式输出卡在工具调用的某个步骤），
Telegram 的 getUpdates 轮询也会停摆，导致消息丢包。
此外，流式回复中的 HTML/Markdown 格式化在懒调度场景下会退化为字面标签，
群组媒体消息在 requireMention 模式下的处理也存在多余下载。

插件安装容易卡住。
升级到 pnpm 11 后，部分插件的 peer-dependency 解析出现失败；
source install 时 git 依赖的子模块（如 WhatsApp 的 libsignal）
也经常因为 pnpm 版本不匹配而卡住。
更新后的运维流程常常需要手工介入。

这版改变了什么

安装即瘦身，按需取用。
Amazon Bedrock、Bedrock Mantle、Slack 插件、Anthropic Vertex
以及 WhatsApp 的完整依赖包被正式移出核心运行时 bundle。
现在 npm install openclaw 只拉取核心与纯通道编排代码；
只有当你真正安装并启用对应插件时，其依赖树才会被解析。
WhatsApp 通道已转为 ClawHub/npm 外部插件，
Baileys 升级至 7.0.0-rc11，
libsignal 改用 registry 而非 GitHub tarball 安装。
这意味着 Docker 镜像体积可以显著缩小，容器启动速度更快。

Telegram 获得独立轮询通道。
核心改动是将 Bot API 的 getUpdates 轮询迁移至隔离的工作线程，
并配以本地持久化 spool 层。
即使主事件循环因 LLM 响应延迟而阻塞，
Telegram 消息的接收也不会中断。
轮询断连检测也从所有 API 请求的综合超时
改为只观察 getUpdates 本身的存活信号，
避免出站 API 调用掩盖入站轮询故障。
同时，流式回复和定时回复中的 HTML/Markdown 标签已被修复，
不会再出现链接退化为文字标签的问题；
群组中 requireMention 模式下的媒体处理也避免了多余下载。

插件安装与更新更稳固。
构建系统已升级至 pnpm 11，保留了 Docker、安装和发布工作流的兼容性。
插件的 peer-dependency 管理得到增强：
当已安装插件更新版本区间时，
OpenClaw 会刷新自己管理的 peer 固定版本，
同时在重新计算共享依赖树时保留用户自己标记的依赖。
第三方 peer-dependency 在插件卸载后也会被清理。
对于 pnpm GitHub 源更新，
构建过程中会审批 OpenClaw 包自身的构建，
确保 source install 的 prepare/prepack 生命周期完整执行。

安全与权限加固。
Windows 沙箱增加了 USERPROFILE 黑名单防止凭证泄露；
Gateway 代理访问和浏览器设备配对要求显式授权；
设备令牌的 Scope 管理被限制在管理员作用域之下；
插件安装期间的代码安全扫描
从全部文件收敛到仅扫描插件自有运行时入口点。

UI 与 Agent 体验提升。
Control UI 和 WebChat 新增了持久化自动滚动模式，
可在「跟随底部」「实时跟随流式输出」「手动滚动」三者之间切换。
Agent 子会话在会话选择器中用 +- 前缀层级嵌套，
让父子关系一目了然。
/context map 命令可以发送当前会话上下文贡献者的热力图图片，
帮助理解令牌构成。

架构思路：三条隔离线的落地

回看 v2026.5.12 的改动，可以用三条清晰的隔离线索来理解设计意图：

依赖隔离。
OpenClaw 把 Provider 和通道插件视为「偶发消费者」而非核心组成部分。
核心运行时只保留与模型路由、Agent 调度、Gateway 协议等基础能力相关的依赖；
每个外部插件有自己的 package.json、依赖树和构建入口。
这样做的好处是：npm 安装时不需要解析 AWS SDK 的千级传递依赖，
pnpm install 的锁文件也不会因为某个插件的升级而发生大面积冲突。
核心与插件之间通过 openclaw/plugin-sdk 定义的契约交互，
而非硬编码的 import 引用。

进程隔离。
Telegram 接入的痛点归根结底是「单进程单线程」模型的局限。
将 getUpdates 轮询移至独立 worker 后，
网络 I/O 和消息入站队列独立于主事件循环运行；
即使 LLM 调用卡住 30 秒，Telegram 的 ingress 通道依然存活。
本地 durable spool 进一步保证即使 Gateway 短暂重启，
在 spool 中的消息也不会丢失。
这一思路未来也可能扩展到其他通道。

策略隔离。
安全方面的改动大量集中在「缩小默认权限面」：
沙箱环境不再信任 Windows 的 USERPROFILE、
Gateway 代理访问必须经过配对审批、
插件代码扫描只扫自有入口。
每条改动都在把一个几年前为了方便而打开的默认权限改为显式授权，
从而降低被滥用或配置失误导致的安全风险。

这三条隔离线共同指向一个方向：
让 OpenClaw 在大规模部署和多种通道混合使用的场景下，
保持安装简洁、运行稳定、安全可控。
对于只使用 Telegram + OpenAI 的用户，
这版更新意味着更小的安装体积、
更可靠的通信入口和更少因插件冲突导致的维护困扰。