OpenClaw 2026.3.11：这次对站长/运维真正重要的更新是什么

OpenClaw 2026.3.11 这版如果只是扫一眼 changelog，很容易觉得它只是“更新点很多，但没一个特别炸”。但如果你是真的在跑 OpenClaw，而不是只把它当一个会聊天的壳，这版的重点其实很明确：安全更稳、cron 更收口、memory 更能扩、onboarding 更顺、各种边角故障更少。

官方 GitHub Release： https://github.com/openclaw/openclaw/releases/tag/v2026.3.11

TL;DR

如果你时间不多，先记这四件事：

如果你有浏览器控制面、trusted proxy 或反向代理场景，这版值得尽快升。
如果你有 cron 自动投递，升级后要主动复核一次投递链路。
如果你在认真用 memory，这版值得重新看 Gemini embedding 和多模态索引能力。
如果你经常被 onboarding、渠道、runtime 小毛病拖时间，这版会比看起来更值。

1）安全：这是这版最不该忽略的一条

这次 release 里最该优先看的，不是 UI，也不是新 provider，而是安全修复：

Gateway/WebSocket 现在会对浏览器来源连接强制做 origin 校验；
即使有 proxy headers，也不会再因为 trusted-proxy 模式而放松这层校验；
这次修的是一个跨站 WebSocket 劫持风险，影响的是本来不该被信任的来源却有机会拿到高权限访问的问题。

换成人话就是：

如果你把 OpenClaw Gateway 放在反代后面；
如果你有浏览器控制入口；
如果你过去对“代理层已经帮我处理好了信任边界”这件事默认得比较乐观；

那这版更新，属于应该认真升级，而不是“有空再说”的级别。

2）cron：更安全，但也更不允许“差不多能跑”

这版 breaking change 不多，但有一条对实际跑 cron 的人很关键：

isolated cron delivery 变严格了；
以前那种靠 ad hoc agent send 或 fallback main-session summary 的投递捷径，不再应该被当成有效路径；
官方也给了 openclaw doctor --fix 作为老 cron 存储和旧 notify/webhook 元数据的迁移入口。

这意味着什么？

cron 行为会更明确；
旧的“好像还能跑”路径会被逐步收紧；
如果你的自动任务要稳定投到指定聊天面，就别再赌旧 fallback 还会一直帮你兜底。

对站长/运维来说，这不是坏事。它的本质是：少一点隐式魔法，多一点可验证的正确投递。

3）memory：不是只补模型，而是开始更像一层能力系统

这版里 memory 相关的变化，值得认真看：

加强了 gemini-embedding-2-preview 的 memory search 支持；
支持可配置输出维度，并在维度变化时自动重建索引；
对 memorySearch.extraPaths 增加了图片/音频的可选多模态索引能力，并带有 fallback gating 和按范围 reindex 的控制。

它真正有意思的地方在于：

OpenClaw 的 memory 不再只是“加个 embedding 就算完”；
而是在往可调、可扩、可做基础设施化运维的方向走；
但与此同时，reindex 成本、索引范围、配置变更影响，也开始值得被当成正式运维问题去看。

所以这块的正确姿势不是“新功能全开”，而是：想清楚你的 memory 到底要解决什么问题，再开。

4）onboarding：新用户和第二设备少踩坑，实际很值

很多真实故障不是发生在生产链路，而是发生在“人还没接进来”这一步。这版对 onboarding 补了不少实用东西：

Ollama onboarding 更像一等公民了，支持 Local / Cloud + Local、浏览器 cloud sign-in、模型建议更完整；
OpenCode onboarding 把 Zen 和 Go 的接入讲得更清楚，向导和文档路径更统一；
macOS onboarding 对远程 gateway 共享 auth token 的说明也更清楚了。

为什么这对站长有价值？

因为 onboarding 顺了，后面的支持成本就会低很多。尤其是多人协作、远程设备、第二终端接入这类场景，少踩一次坑，就是省一轮 support。

5）ACP、pending work、运行时控制面继续在补

这版还有一些不那么显眼，但方向很明确的更新：

sessions_spawn 在 runtime: "acp" 下支持 resumeSessionId，也就是 ACP/Codex 会话可以续接，不用每次都从零开始；
Gateway/node 增加了 pending work queue primitives，为休眠节点的任务投递打基础；
CLI 子进程环境现在会带 OPENCLAW_CLI，方便下游识别是谁拉起的执行链路。

这几项单看都不算“爆点”，但放在一起看，就很清楚：

OpenClaw 还在持续把它的控制面，往更长链路、更可恢复、更适合复杂自动化的方向补齐。

6）稳定性修复：这类更新通常最省时间

fixes 列表很长，但站长最该看的不是每一条，而是它们共同在解决什么：

减少那种“没有完全坏，但就是很别扭、很难排”的状态。

几个比较值得点出来的例子：

Control UI 的 auth token 处理更安全、作用域更明确；
Gateway auth 在 shared-token mismatch 时有了更合理的重试与提示；
config 校验错误会在顶层直接给出更多有用信息；
billing recovery / model failover 在多个 provider 上都更聪明了；
Feishu 本地图自动转换恢复；
Telegram preview / final delivery 行为更稳；
Discord / Telegram 的 runtime config 投递链路更可靠；
memory flush 与 context pruning 的边缘场景更稳。

这些更新不一定最适合做宣传海报，但非常适合做一句真实评价：

这版会减少很多运维上“被小毛病磨时间”的情况。

升级后建议优先检查什么

如果你升到 2026.3.11，建议优先做这 5 个检查：

浏览器控制面 / Gateway 暴露面
- 如果你跑在反代或 trusted proxy 后面，重新验证浏览器侧访问边界。
cron 投递链路
- 对每个关键定时任务，确认它真的投到了目标会话/渠道。
memory 配置
- 如果你想用 Gemini embedding 或多模态索引，先看索引范围和 reindex 预期。
主渠道回归
- 把你最重要的一条入站/出站链路跑一遍。
远程接入 / onboarding
- 如果你有 macOS 或多设备接入路径，重新验证 auth 说明与实际行为是否一致。

最后一句判断

OpenClaw 2026.3.11 不是那种“靠一个新功能带你兴奋 3 分钟”的版本。它更像一次对安全边界、投递正确性、memory 能力、接入体验和运行稳定性的系统性补强。

所以它真正的价值不在“更新点多不多”，而在：

它能帮正在认真跑 OpenClaw 的人，少掉一批原本会消耗你时间的坑。

FAQ：升级到 2026.3.11 之后，站长最该先验证什么

怎么判断这次浏览器来源安全修复，真的保护到了你的部署？

不要只看 Gateway 进程本身是否能启动，而要检查反向代理后真正对浏览器开放的那条控制链路。如果原本不该被信任的来源，升级后已经不能再建立同样的控制入口，这次升级才算真正降低了跨来源风险，而不只是把日志内容换了一种写法。

什么时候说“cron 投递更严格”会从改进变成升级风险？

当你的定时任务其实一直依赖某些没写清楚的 fallback 习惯时，它就会变成风险。比如默认认为 main session summary 或 ad hoc agent send 总会继续替你兜底，但实际上 notify 路径从来没有被明确定义。这版更安全的前提，是每条定时投递链路都能被端到端验证。

这次 memory 能力升级里，最容易犯的错是什么？

把更强的 memory 索引能力当成一个可以随手全开的免费开关。一旦 embedding 维度、多模态输入或 extra paths 发生变化，reindex 成本和检索范围就都变成了正式运维选择，所以团队应该先决定“希望 memory 帮自己找回什么”，再决定“要不要继续喂更多内容进去”。

来源

GitHub Release： https://github.com/openclaw/openclaw/releases/tag/v2026.3.11