OpenClaw 2026.3.11-beta.1：这次值得装 Beta，因为它封了一条真实的攻击路径

这是一个 预发布（beta）。线上环境请用“灰度 / 分阶段发布”的方式来跑。

来源：GitHub Release — https://github.com/openclaw/openclaw/releases/tag/v2026.3.11-beta.1

1）安全修复：强制校验浏览器来源的 WebSocket Origin（GHSA-5wcw-8jjv-m286）

如果你把 Gateway 放在反向代理后面（尤其启用了某种“trusted proxy”/代理信任模式），这条是重点。

Release 的核心信息（转述）：

Gateway/WebSocket 现在会对 所有来自浏览器的连接强制做 Origin 校验，不再因为存在 proxy headers 就放行。
这修复了 trusted-proxy 模式下的跨站 WebSocket 劫持路径，理论上可能让不受信任的来源拿到 operator.admin 级别访问。

落地建议：

如果你的 Gateway 能被浏览器访问（哪怕是内网），把它当作高优先级修补。
升级后做一次最小验证：控制台/仪表盘能正常连；来自异常来源的连接不应被接受。

（安全编号：GHSA-5wcw-8jjv-m286）

2）破坏性变更：isolated cron 的投递路径更严格（并提供 doctor 修复迁移）

这个 beta 收紧了 isolated cron job 的通知投递：

cron job 不能再用“临时 agent send / 回退到主会话摘要”的方式绕投
增加 openclaw doctor --fix 用于迁移老 cron 存储与老的 notify/webhook 元数据

如果你依赖 cron 做提醒/日报：

1）先在 staging 升级； 2）跑一遍 openclaw doctor，有提示就 --fix； 3）手动触发一条 cron，确认仍能投递到你期望的通道。

3）上手体验的改进（能明显减少“装完不会用”的工单）

Ollama 上手变成“一等公民”（Local / Cloud + Local）

向导新增：

本地模式、云端 + 本地混合模式
浏览器登录云端
更合理的模型建议
云模型场景下跳过不必要的本地 pull

如果你做“本地推理控成本”，这能减少大量绕路。

OpenCode：新增 Go provider + 更一致的 Key 管理

新增 OpenCode Go provider，同时把 Zen + Go 在向导/文档里作为一个 OpenCode 上手流程讲清楚，但运行时仍保持 provider 分离。

这类改动的价值在于：

少踩“profile A 能用、profile B 不能用”的坑
key 配置更不容易乱

4）macOS 聊天 UI：模型选择器 + thinking level 持久化

macOS 端增加：

聊天模型选择器
显式 thinking level 选择会跨重启保存
shared composer 的 provider-aware 模型同步更稳

对多模型/多 provider 用户来说，这属于“看起来小，但能避免大范围误会”的改动。

5）Discord：自动建线程可以配置归档时间

如果你用了 Discord 自动建线程，这版增加 channel 配置：

线程归档可选 1 小时 / 1 天 / 3 天 / 1 周

不再被 1 小时默认值卡住。对需要持续几天讨论的社群来说很实用。

6）Memory Search：可选的多模态索引（Gemini embedding）

这版为 memorySearch.extraPaths 增加“可选的图片/音频索引”，使用 gemini-embedding-2-preview，并包含：

更严格的 fallback 约束
scope 级别的 reindex 控制
embedding 输出维度可配、维度变化时自动触发重建索引

建议的采用方式：

只对少量路径/数据集先开（小范围验证），不要一上来全盘索引。
预期会有一次性 reindex 成本。
先验证检索质量，再决定是否推广到生产流程。

FAQ：准备决定要不要先上 2026.3.11-beta.1 时，最常先问哪三件事

如果我们现在最担心的是暴露面，这个 Beta 最值得优先看的是什么？

最值得先看的，不是“功能多了什么”，而是 WebSocket Origin 强制校验修复是否刚好命中你当前的部署形态。如果 Gateway 在反向代理后、又能被浏览器访问，这版的安全价值会高于一般功能 beta。

如果团队依赖 cron 做提醒或日报，为什么不能只看 release note 就直接升？

因为这次不是单纯加特性，而是 把 isolated cron 的投递路径收紧了。真正的判断标准不是“文档里说修好了”，而是你升级后跑 openclaw doctor --fix、再手动触发一条 cron，确认消息仍然进到原本的目标通道。

如果想先吃到安全修复，又不想把整套环境一起带进 Beta，怎么做更稳？

更稳的做法通常是先把它当成一次“安全补丁灰度”，而不是全面升级。也就是说，先在最接近生产的 staging 验证 Gateway 连接、cron 投递和最关键的 channel plugin，再决定要不要扩大范围。

Beta 灰度检查清单（偏运维实战）

1）如果 Gateway 可被浏览器访问：把 WebSocket Origin 修复作为优先补丁。 2）跑 openclaw doctor，有提示就执行 --fix（尤其是 cron）。 3）最小回归：仪表盘连接、cron 投递、你最重要的 channel plugin。 4）Discord 使用 auto threads 的话，把归档时间调到符合社群节奏。 5）多模态 memory 索引先小范围试点，再扩。

FAQ：团队准备扩大这版 Beta 覆盖面前，最该先想清楚什么

什么情况下，这个 Beta 值得即使偏保守的团队也优先灰度？

当这次安全修复正好命中你真实存在的暴露面时，它就值得优先灰度。尤其是 Gateway 放在反向代理后、又能被浏览器访问的部署，这时它不只是“提前试功能”，而是在更早移除一块真实攻击面。

验证这版 cron 变化时，最容易走错的路径是什么？

最容易走错的，是看到迁移命令成功或 release note 写得很清楚，就以为 cron 已经没问题。真正该看的不是命令有没有跑完，而是一条真实的定时任务，是否还能稳定投到团队真正依赖的那个目标通道，而不是继续偷偷吃 undocumented fallback。

为什么多模态 memory 索引一开始要故意控制范围？

因为最容易失控的，不只是 provider 或构建报错，而是运维面的外溢。一旦索引范围扩得太快，团队可能会先吃到 reindex 成本和检索噪音，却还没验证这块新 memory 面到底有没有帮到最关键的工作流。

OpenClaw News 编辑部