OpenClaw 2026.5.22炸了-夜雨聆风

OpenClaw 2026.5.22炸了

如果你最近用 OpenClaw 时觉得：

Gateway 偶尔启动慢；
模型列表加载像“卡住”；
插件一多，配置读取就变重；
长期运行后排障成本越来越高。

那 OpenClaw 2026.5.22 这个版本，基本就是冲着这些痛点来的。

这不是一次单纯“加功能”的更新，而是一次非常典型的 运行时工程升级。

最炸的数据只有一个：

“

/models 和模型列表调用，从约 20 秒降到约 5 毫秒。
性能提升约 4100 倍。

这个数字不是营销口号，而是官方 release notes 里明确写出的优化结果。

核心原因也很直接：OpenClaw 在 Gateway 启动阶段预热 provider auth-state map，让模型列表热路径不再每次重复执行 provider 插件发现、外部 CLI 探测和认证状态检查。

先看重点

项目	内容
版本	OpenClaw 2026.5.22
发布时间	2026 年 5 月 24 日发布，对应 2026.5.22 release
主线	Gateway 性能、会议笔记、插件元数据、文档与配置、安全边界、QA 可观测性
最大亮点	`/models`：约 20s → 约 5ms
提升倍率	约 4100×
适合谁关注	自托管 OpenClaw、插件多、模型 provider 多、长期运行 Agent 的用户

简单说：

“

以前是“每次都临时翻箱倒柜”。
现在是“启动时整理好目录，热路径直接查表”。

一、Gateway 热路径：这次是真的动刀

OpenClaw 的核心是 Gateway。

它连接的不只是一个聊天窗口，而是一整套运行时：

Discord / Telegram / WhatsApp / Signal / Slack / Feishu / WebChat；
移动节点和远程节点；
插件通道；
Agent 会话；
模型 provider；
浏览器、文件、消息、媒体等工具链。

所以 Gateway 一慢，所有体验都会跟着慢。

典型表现包括：

状态检查慢；
ready 信号慢；
模型列表慢；
通道配置慢；
插件分发慢；
setup / secret metadata 读取慢。

2026.5.22 的第一组更新，几乎全是围绕 Gateway/perf 展开。

二、/models：20 秒变 5 毫秒

官方 release notes 里最值得拎出来的就是这条：

指标	旧路径	新路径
`/models` / 模型列表调用	约 20 秒	约 5 毫秒
提升倍率	–	约 4100×
主要成本	provider 插件发现、外部 CLI 探测、认证检查	启动预热后直接读取 auth-state map
体感变化	像卡死	秒开

过去的问题是：

用户只是想看一下模型列表，但系统背后可能要临时检查多个 provider、插件、外部 CLI 和认证配置。

这很不划算。

因为模型列表不是低频操作。它可能被这些地方反复触发：

Web UI；
/status；
doctor；
配置界面；
插件；
CLI；
Agent 初始化过程。

所以一次从 20 秒降到 5 毫秒，不只是“某个接口快了”，而是整个控制面都轻了。

新版怎么做？

关键动作有三个：

Gateway 启动时预热 provider auth-state map；
模型列表热路径直接读取已准备好的状态；
hot reload 后重置并重新预热，保证配置变化能生效。

这类优化特别像生产系统里的“控制面瘦身”。

不是模型更聪明了，而是运行时不再做无意义重复劳动。

三、这次 Gateway 还瘦了哪些路径？

除了 /models，这次还有几条很关键的性能优化。

1. 复用 channel catalog

Release notes 原话提到：

“

reuse process-stable channel catalog reads, avoid repeated bundled-channel boundary checks

翻译成人话就是：

“

进程内稳定的通道目录，不要每次都重新读、重新判断。

OpenClaw 通道很多。

内置通道、bundled channel plugins、外部插件都会参与启动、分发和配置读取。单次读取 catalog 也许不重，但热路径上反复出现，就会变成“蚊子腿堆成大象”。

这次把 process-stable 数据缓存起来，属于很典型的运行时瘦身。

2. 复用插件元数据快照

旧路径里，很多 reader 都可能重复访问插件文件：

startup；
config；
model；
channel；
setup；
secret metadata。

这会导致重复 file stat、重复 manifest registry reload。

新版改成复用 immutable plugin metadata snapshots。

也就是先把插件元信息整理成稳定快照，然后让多个读取路径共用。

这对插件生态非常关键。

OpenClaw 越强，插件越多；插件越多，扫描成本越容易膨胀。提前固化元数据快照，架构上更合理。

3. 懒加载未用的 handler 和 ACPX runtime

这次还做了 lazy-load：

startup-idle plugin work 懒加载；
core gateway method handlers 懒加载；
embedded ACPX runtime 懒加载。

结果是：

“

Gateway health 和 ready 信号，不再等待当前没用上的 handler trees 或 ACPX probes。

这点非常重要。

一个服务是否 ready，应该回答的是：

“

“核心能力现在能不能接请求？”

而不是：

“

“未来可能用到的所有边角能力是否都已经初始化？”

OpenClaw 这次明显在把 ready 路径变得更干净。

4. 缓存 SDK alias maps，跳过无关 PATH 探测

还有一个很接地气的细节：

缓存 plugin SDK public-surface alias maps；
跳过 irrelevant macOS Linuxbrew PATH probes。

很多性能问题并不是算法复杂度，而是大量不存在路径的 stat、fs walk、CLI 探测。

尤其 macOS 上 Homebrew / Linuxbrew、不同架构、不同安装路径一多，探测成本很容易变成启动噪音。

这次把无关探测跳过，把 alias map 缓住，是非常务实的优化。

四、会议笔记：从“听到了”到 capture pipeline

这次还新增了一个 source-only external meeting-notes plugin，并定义了 SDK source-provider contract。

关键能力包括：

能力	说明
source-only meeting-notes plugin	会议笔记作为外部 source 插件存在
SDK source-provider contract	明确数据源接入契约
auto-start capture config	支持自动开始采集配置
manual transcript imports	支持手动导入转写文本
read-only CLI access	`openclaw meeting-notes` 只读访问
Discord voice live source	Discord voice 作为第一个实时来源

这个变化不只是“加了会议纪要功能”。

它更像是把会议内容采集这件事标准化。

过去用户可能会说：

“

Agent 在语音里听到了某些东西。

现在系统开始向更明确的 pipeline 靠拢：

来源是谁？
是否自动开始采集？
能否手动导入 transcript？
CLI 是否只能只读访问？
第一个 live source 是什么？

对企业和团队场景来说，这种边界很重要。

会议笔记如果没有清晰 source contract，很容易变成隐私、授权和证据链问题。

五、文档补强：都是部署里会踩的坑

2026.5.22 的 docs 更新非常密。

它不是那种“写给官网看的漂亮文档”，而是大量真实部署痛点。

通道配置补强

这次新增或澄清了：

Signal configPath；
Telegram wildcard topic defaults；
local-time backup archive names；
Termux home fallback；
include-path validation；
secret-scanner-safe placeholder guidance；
Gemini CLI / Antigravity media guidance；
macOS VM auto-login guidance。

这些点看起来细碎，但对用户非常关键。

比如：

Termux home fallback 对 Android / 移动环境友好；
Telegram wildcard topic defaults 对群组 topic 场景友好；
secret-scanner-safe placeholder guidance 能避免示例密钥被误扫。

恢复路径更明确

OpenClaw 这种自托管 Gateway，最怕用户卡在“不知道哪里坏了”。

这次文档覆盖了很多排障场景：

WhatsApp QR / 408 recovery；
Gateway upstream 403 troubleshooting；
local dashboard recovery；
browser CDP diagnostics；
status-reaction timing defaults；
queue steering behavior；
limited-tool troubleshooting；
cron HEARTBEAT handling；
Telegram multi-agent groups；
Bitwarden SecretRef setup；
EasyRunner deployments。

这些不是炫技，而是降低维护成本。

尤其 Gateway upstream 403、WhatsApp QR、Telegram multi-agent groups，都是普通用户很容易碰到的问题。

密钥边界更清楚

同一个版本里还补了：

Bitwarden SecretRef；
password-store SecretRef；
plaintext secret boundaries；
media provider credentials；
Copilot / Voyage setup；
plugin SDK import allowlists；
Chinese glossary terms。

成熟 Agent 平台不能只告诉你“怎么连上”。

它还要告诉你：

“

密钥放哪里？
哪些地方是明文？
哪些能力不能随便暴露给插件？

这次 docs 的方向是对的。

六、包体积与发布安全：npm shrinkwrap 上线

这次还有两项和发布工程有关的更新。

1. npm tarball 瘦身

发布包排除了 documentation images 和 assets：

减少发布包体积；
不影响 runtime docs search；
不影响 CLI 行为。

2. shrinkwrap 锁依赖图

root npm package 和 OpenClaw-owned npm plugins 开始带 generated shrinkwrap。

这意味着：

发布安装使用 locked dependency graphs；
suitable plugin tarballs 支持 bundled plugin runtime dependencies；
lockfile / shrinkwrap 变更需要 review。

这对供应链安全非常关键。

自托管 Agent 可能接触聊天、文件、命令、浏览器和密钥。依赖图不锁定，就容易出现“同一个版本，不同依赖树”的不确定性。

shrinkwrap 能把这种不确定性压下去。

七、子 Agent 默认上下文隔离：隐私边界继续收紧

本次 release 还有一个很重要的安全点：

“

limit default sub-agent bootstrap context to AGENTS.md and TOOLS.md, keeping persona, identity, user, memory, heartbeat, and setup files out of delegated workers by default.

翻译一下：

“

默认子 Agent 启动上下文只带 AGENTS.md 和 TOOLS.md。
persona、identity、user、memory、heartbeat、setup 等文件，不再默认塞给 delegated workers。

这是非常正确的方向。

主 Agent 需要知道用户偏好、长期记忆、身份设定。

但被委派出去的子 Agent，不一定需要这些私人上下文。

上下文越多，泄漏面越大；

无关记忆越多，误用概率越高。

这次默认收紧，有两个好处：

子任务更轻量，启动上下文更短；
隐私边界更安全，减少无关记忆外泄。

这也是 OpenClaw 从“能跑”走向“可托管、可审计”的标志。

八、功能补强：UI、Discord、Grok、Plugin SDK

除了 Gateway 性能主线，这个版本还补了不少功能面。

Control UI：会话选择器更好用了

聊天 session picker 新增：

search；
Load More pagination；
初始加载保持有界；
老会话仍然可以找回。

长期使用 OpenClaw 后，会话数量会越来越多。

这个更新能避免 UI 一次性吃掉所有数据，也让旧会话更容易找。

Discord：长流程组件 TTL 可配置

Discord 支持配置 bounded agentComponents.ttlMs callback registry lifetime：

支持 per-account overrides；
上限 24 小时；
更适合长时间 component workflow。

这属于频道层“长期交互稳定性”的补强。

xAI / Grok：搜索链路更顺

本次 xAI/Grok 更新包括：

复用 xAI OAuth auth profiles 给 Grok web_search；
active-agent auth thread through web search；
新增 Grok model aliases；
media providers 可声明默认 operation timeouts。

这能减少 web_search、模型别名、媒体操作超时这些 provider 边界问题。

Plugin SDK：继续平台化

Plugin SDK 增加了：

generic channel-message poll sender；
row-level session workflow helpers；
deprecated loadSessionStore；
general embeddingProviders capability contract and registration API。

这意味着插件不只是“外挂脚本”，而是越来越像一组标准扩展面。

尤其 embeddingProviders contract，会让 embedding 从 memory-specific adapter 中独立出来，未来能被更多插件复用。

九、QA-Lab 与可观测性：Agent 平台开始像生产系统

这次 QA-Lab 更新非常多。

包括：

OpenTelemetry smoke harness；
Prometheus / observability smoke aliases；
runtime-parity audits；
mock JSONL replay fixtures；
tool-trace visibility scenario；
personal-agent privacy coverage；
live transport lane membership coverage；
release package integrity checks；
optional 100-turn runtime parity soak；
gateway restart recovery；
streaming final-integrity live-only lanes。

这些看起来很工程。

但这正是 Agent 平台进生产所需要的东西。

一个 Agent demo 能跑，不代表生产可用。

生产需要：

出问题能追 trace；
指标能进 Prometheus；
日志能导出；
包发布前能验证完整性；
长上下文、长会话、长时间运行能 soak；
工具调用能被审计；
隐私场景能被覆盖。

OpenClaw 2026.5.22 在这方面继续加码。

十、修复项：都是会影响真实体验的补丁

本次 Fixes 里有不少值得关注的点。

模块	修复内容
WebChat	内部 message-tool source replies 改为摘要，避免工具卡片重复可见回复正文
Gateway	保留 deferred lifecycle-error cleanup，provider timeout 后能持久化 failed session state
Agents/subagents	timeout summary 中报告 tool-only child progress，避免看起来“毫无输出”
Telegram/ACP	保留显式 `:topic:` conversation suffixes
Browser/proxy	本地 Chrome CDP readiness / DevTools WebSocket 绕过 managed proxy
Ollama	本地 embedding origin 绕过 managed proxy，同时保留 SSRF guardrails
OpenAI/images	Codex API key image generation 改走 native OpenAI Images API，避免 401
OpenAI-compatible	tool-free turn 省略空 tool payload 字段，兼容严格 vLLM 风格服务器
Sessions	锁获取时执行 max-hold policy，长持有锁可提前回收

这些不是“漂亮功能”，但非常影响真实使用体验。

为什么说这是 operator-speed release？

OpenClaw release pulse 里用了一个词：

“

operator-speed release

这个词很准。

所谓 operator-speed，不是模型生成速度，而是操作者日常管理、启动、检查、恢复、排障的速度。

这次优化正好打在这些点上：

Gateway ready 更快；
health check 更轻；
/models 秒开；
插件元数据少扫；
channel catalog 少读；
secret metadata 少重复；
文档把真实坑补上；
meeting notes 变成明确 pipeline；
shrinkwrap 锁依赖图；
QA/observability 更像生产系统。

真正的 Agent 产品，最后拼的不是第一次演示多炫。

而是：

“

每天运行时，少出多少幺蛾子。
出问题时，能多快定位。
长期运行时，边界是否清楚。

OpenClaw 2026.5.22 的价值就在这里。

快速升级

如果你已经安装 OpenClaw，可以直接更新：

npm install -g openclaw@latest

也可以使用 OpenClaw 自更新能力：

/update

或者直接让 Agent 自己检查更新：

check for updates

升级后建议检查：

openclaw status
openclaw gateway status
openclaw dashboard

如果你之前遇到这些问题：

/models 慢；
模型列表慢；
Gateway ready 慢；
插件启动慢；
provider 检查慢；
长期运行后会话/工具排障困难。

这个版本非常值得更新。

总结

OpenClaw 2026.5.22 不是那种“堆十个新功能骗眼球”的版本。

它更像一次扎实的底层提速和运行时工程升级。

最值得记住的数字：

关键项	数据
`/models` 旧耗时	约 20 秒
`/models` 新耗时	约 5 毫秒
性能提升	约 4100×
核心机制	provider auth-state map 预热 + 热路径短路

如果说之前的 OpenClaw 更像“能把 Agent 接到所有聊天软件上的超级网关”，

那 2026.5.22 之后，它更像一个正在变成熟的 生产级 Agent runtime。