OpenClaw v2026.3.11 更新了哪些内容？Ollama、记忆检索、ACP 会话恢复、Cron 迁移与通道修复解析

🔥个人主页：杨利杰YJlio

❄️个人专栏：《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》

《微信助手》 《锤子助手》 《Python》 《Kali Linux》

《那些年未解决的Windows疑难杂症》

🌟让复杂的事情更简单，让重复的工作自动化

1. 写在前面：OpenClaw v2026.3.11 这版重点是什么？

大家好，我是杨利杰YJlio。

这篇文章继续整理OpenClaw 版本更新记录。本文重点看的是OpenClaw v2026.3.11。

先说结论：
v2026.3.11 是一个偏“模型接入、记忆系统、ACP 会话恢复、安全加固、Cron 迁移和多通道修复”的版本。

它不是单纯加几个小功能，而是把 OpenClaw 在长期使用中容易遇到的几个问题集中处理了一遍：

• Ollama 接入变得更正式：支持 Local 或 Cloud + Local 模式；
• OpenCode Go Provider 加入 onboarding：Provider 生态继续扩展；
• Memory 支持 Gemini Embedding 2 与多模态索引：图片、音频也可以进入记忆检索范围；
• ACP 支持恢复已有会话：resumeSessionId让会话续接更自然；
• Gateway / WebSocket 做安全加固：收紧浏览器来源校验；
• Cron / doctor 有破坏性迁移提醒：旧 cron 通知和 webhook 元数据需要迁移；
• Discord、Feishu、Kimi Coding、macOS LaunchAgent 等问题被修复。

如果你正在使用 OpenClaw 做本地 Agent、通道机器人、记忆检索或多模型接入，v2026.3.11 值得认真看。

从上图可以看到，这版更新主要集中在 6 个方向：

• 本地与云端模型接入；
• Memory 记忆系统增强；
• ACP 会话恢复；
• 安全与兼容；
• 运维迁移；
• 消息与通道修复。

我的理解是：v2026.3.11 的价值不在于“功能炫”，而在于让 OpenClaw 更适合长期运行和复杂场景使用。

2. 版本更新总览：这一版主要改了哪些地方？

如果把 OpenClaw v2026.3.11 的更新拆成几条主线，可以这样理解。

这一版最明显的关键词是：

Ollama / Memory / ACP / Cron / WebSocket / Discord / Feishu / Kimi Coding

如果你只是本地简单体验 OpenClaw，这版可能感知不算特别强；但如果你已经开始接入模型、通道、记忆、自动任务和网关，这版就非常关键。

3. 关键机制图：v2026.3.11 背后的升级逻辑

这版更新不是孤立的功能堆叠，而是围绕一个方向展开：

让 OpenClaw 更容易接入模型、更容易记住上下文、更容易恢复会话、更安全、更适合长期运维。

下面这张图更适合放在“机制说明”位置。

3.1 Ollama 一等支持：本地模型入口更正式

v2026.3.11 中，Ollama onboarding 得到了增强。

它支持：

• Local 模式；
• Cloud + Local 模式；
• 浏览器式云端登录；
• 模型建议；
• 对云端模型进行处理，避免不必要的本地拉取。

这说明 OpenClaw 对本地模型 / 云端模型混合使用的支持越来越明确。

简单说，以后 OpenClaw 不只是接云端大模型，也会越来越重视本地模型体验。

对于喜欢本地部署、隐私优先、离线实验、内网环境的用户来说，这个方向很有意义。

3.2 OpenCode Go Provider：Provider 生态继续扩展

这一版加入了新的OpenCode Go Provider。

从用户视角看，Provider 增加意味着：

• 可选模型入口更多；
• Runtime 路由更灵活；
• 不同 Provider 可以承担不同任务；
• Agent 能力组合空间更大。

但 Provider 越多，配置也越要规范。不要只看“能接入”，还要看认证、模型路由、工具调用和日志是否正常。

3.3 Memory 增强：Gemini Embedding 2 与多模态索引

Memory 是这一版非常值得关注的部分。

v2026.3.11 增加了：

• gemini-embedding-2-preview支持；
• 可配置输出维度；
• 维度变更后的自动重新索引；
• memorySearch.extraPaths下图片与音频的 opt-in 多模态索引；
• 严格 fallback gating；
• scope-based reindexing。

说人话就是：

OpenClaw 的记忆检索不再只是“搜文字”，而是在向图片、音频、多模态索引扩展。

这对长期运行的 Agent 很关键，因为 Agent 不只是要记住文字，还可能需要记住截图、图片资料、音频材料和外部文件线索。

3.4 ACP 会话恢复：resumeSessionId 的价值

这一版为runtime: "acp"的sessions_spawn增加了可选参数：

resumeSessionId

它的作用是：
让 spawned ACP sessions 可以恢复已有 ACPX / Codex conversation，而不是每次都重新开始一个新会话。

这对以下场景很有价值：

• 长任务中断后继续；
• 多轮 Codex 工作流；
• 复杂代码任务恢复；
• Agent 子任务续接；
• 避免上下文断裂。

如果你经常让 Agent 处理长任务，会话恢复能力比单次响应速度更重要。

3.5 WebSocket 安全加固：别忽视这一点

v2026.3.11 的 Security 部分提到：
Gateway / WebSocket 对所有 browser-originated connections 强制执行 browser origin validation。

它解决的问题是：
在trusted-proxy模式下，不可信来源可能通过 cross-site WebSocket hijacking 路径获得operator.admin访问能力。

这不是普通小修，这是安全边界修复。只要你暴露 Gateway、使用代理、浏览器控制 UI 或远程管理，就应该重视这类更新。

4. 升级与验证流程：不要只升级，不验证

很多人升级工具有一个坏习惯：

看到新版本 → 直接安装 → 出问题再说。

这不是成熟的运维方式。
更稳的做法是：先备份，再升级，再修复，再重启，再验证，最后记录。

下面这张图可以作为升级流程参考。

4.1 第一步：确认当前版本

升级前先确认当前版本：

openclaw--version

这一步看似简单，但非常重要。
因为你要知道自己是从哪个版本升级上来的。

比如：

• 从 v2026.3.8 升级；
• 从 v2026.3.11-beta 升级；
• 从更旧版本升级；
• 从 dev / beta 分支切换到 stable。

不同来源版本，升级后的验证重点不一样。

4.2 第二步：备份配置和工作区

如果你的环境里已经有 Agent、Memory、Gateway、Channel、Cron 等配置，升级前必须先备份。

推荐至少记录：

~/.openclaw/ 当前配置文件 当前 workspace 路径 已安装插件 已启用通道 当前模型 Provider Cron jobs Gateway 启动方式

如果你的版本已经支持备份命令，可以先执行：

openclaw backup create openclaw backup verify

备份不验证，等于只完成了一半。

4.3 第三步：按原安装方式升级

如果你是 npm 全局安装方式，可以参考：

npminstall-gopenclaw@2026.3.11

如果你是 pnpm、Docker、源码或其他方式安装，请按原安装方式处理。

不要把不同安装方式混用，否则后续排查时很容易出现“命令路径不是同一个 OpenClaw”的问题。

可以通过下面命令确认实际命令路径：

whichopenclaw openclaw--version

Windows 环境可用：

where openclaw openclaw--version

4.4 第四步：运行 doctor 修复迁移问题

v2026.3.11 的 Breaking 部分明确提到 Cron / doctor 迁移。

升级后建议执行：

openclaw doctor

如果检测到 legacy cron storage 或 notify / webhook delivery metadata 相关问题，再执行：

openclaw doctor--fix

如果你在自动化环境中执行，可以根据实际情况加入非交互参数：

openclaw doctor--fix--non-interactive--yes

注意：Cron 相关变更属于破坏性调整，旧环境升级后不要跳过 doctor 检查。

4.5 第五步：重启 Gateway 并验证通道

如果你使用 Gateway，升级后建议重启：

openclaw gateway restart

如果 macOS LaunchAgent 状态异常，可以考虑先检查服务是否正常注册。

macOS 上可以关注：

launchctl list|grepopenclaw

如果是 systemd 用户环境，可以关注：

systemctl--userstatus openclaw-gateway

验证通道时，可以关注：

openclaw channels status openclaw channels status--probe

升级成功不是版本号变了，而是 Agent、Gateway、Memory、Cron 和 Channel 都能正常工作。

5. 重点修复项：这一版修了哪些真实问题？

v2026.3.11 的 Fixes 部分信息量也很大。
下面我按使用场景做归类。

5.1 模型输出清理：GLM-5 / DeepSeek 控制标记泄露

这一版修复了 assistant text 中泄露模型控制标记的问题，例如：

<|...|> <｜...｜>

这些内容原本不应该出现在用户可见回复里。

这个修复对中文用户很有价值，因为 GLM、DeepSeek 这类模型在中文场景中使用频率较高。

如果你之前遇到过回复里出现奇怪控制符、内部 delimiter、格式异常，这个修复就值得关注。

5.2 macOS LaunchAgent 修复

v2026.3.11 修复了 macOS launchd restart 和 LaunchAgent install 权限相关问题。

包括：

• explicit restart 时保留 LaunchAgent 注册；
• self-restart 通过 detached launchd helper 处理；
• config / hot reload restart 路径恢复；
• install 时收紧 LaunchAgent 目录和 plist 权限；
• 避免 home 路径或 plist 权限异常导致 bootstrap 失败。

如果你在 macOS 上长期运行 OpenClaw Gateway，这类修复很实用。

5.3 Discord 长回复分段修复

Discord 方向修复了长回复分段问题。

以前可能出现：

• 长回复被意外拆分；
• 默认 17 行限制影响输出；
• chunkMode在 fast send path 中没有正确保留；
• maxLinesPerMessage没有按配置生效。

这一版修复后，Discord 回复分段会更稳定。

5.4 Feishu 本地图片修复

Feishu 方向修复了本地图片 auto-convert。

问题大概是：
允许的本地图片路径原本应该上传为 Feishu 图片，但异常时会退回成原始路径文本。

这版通过传递mediaLocalRoots到sendTextlocal-image shim，让允许路径下的本地图片可以正常作为 Feishu 图片上传。

如果你用飞书做通知、日报、图片回传或自动化消息，这个修复很值得关注。

5.5 Kimi Coding 工具调用修复

Kimi Coding 方向修复了工具调用格式问题。

这一版让kimi-coding重新以 native Anthropic format 发送anthropic-messagestools，避免工具调用退化成 XML / plain-text pseudo invocations。

简单说：工具调用不应该只是“看起来像调用”，而应该是真正的 tool_use blocks。

这对代码类 Agent 很关键。

6. 常见问题与易错点：这版升级最容易忽略什么？

下面这张图更适合放在常见问题部分。

6.1 易错点一：只升级，不跑 doctor

v2026.3.11 有 Cron / doctor 迁移相关内容。

如果你升级后不跑 doctor，可能会出现：

• legacy cron storage 仍存在；
• notify / webhook 元数据未迁移；
• Cron 通知行为不符合预期；
• 自动任务看似存在但实际投递异常；
• 后续排查成本变高。

建议升级后固定执行：

openclaw doctor openclaw doctor--fix

Cron 是自动化任务链路，不是可有可无的小功能。旧环境升级后必须验证。

6.2 易错点二：忽略 WebSocket 安全修复

很多人看到安全修复会觉得和自己没关系。

但如果你的 OpenClaw 使用了：

• Gateway；
• Browser Control UI；
• 远程代理；
• trusted-proxy 模式；
• 管理端网页访问；
• 多设备连接；

那 WebSocket origin validation 就和你有关。

凡是涉及远程入口和管理权限的组件，都不能只看功能，还要看安全边界。

6.3 易错点三：Provider 增加后配置变乱

Ollama、OpenCode Go、OpenRouter、Kimi Coding 等 Provider 越来越多。
这本身是好事，但也会带来配置复杂度。

容易出现：

• 当前模型不是你以为的那个模型；
• runtime provider 配置和 onboarding 记录不一致；
• 工具调用格式不兼容；
• 本地模型与云模型路由混乱；
• 多 Provider 日志不好排查。

我的建议是：

每新增一个 Provider ↓ 单独测试模型调用 ↓ 单独测试工具调用 ↓ 记录配置位置 ↓ 再接入 Agent 工作流

6.4 易错点四：Memory 变强后不做索引管理

Memory 支持多模态以后，确实更强，但也更需要管理。

要关注：

• extraPaths是否配置过宽；
• 图片 / 音频是否真的需要被索引；
• embedding 维度变化后是否触发重新索引；
• reindex 是否影响运行成本；
• 旧索引是否需要清理或重建。

记忆能力增强不是无脑开启，索引范围越大，后续维护成本越高。

6.5 易错点五：把“版本升级成功”理解成“功能全正常”

这也是常见误区。

真正的升级成功至少要验证：

• openclaw --version正确；
• openclaw doctor无关键异常；
• Gateway 正常；
• Agent 正常；
• Memory 正常；
• ACP 会话恢复正常；
• Cron 任务正常；
• Discord / Feishu / Telegram 等通道正常；
• 日志里没有持续异常。

版本号只是入口，功能验证才是结果。

7. Mermaid：v2026.3.11 升级验证流程图

下面我把这版升级验证流程整理成一张 mermaid 图，方便后续复用。

这套流程和 Windows 桌面运维里的升级验证逻辑其实一样：

• 先固定当前状态；
• 再执行变更；
• 再验证关键路径；
• 出问题要有回退；
• 最后沉淀记录。

成熟的升级流程不是“点更新”，而是“有备份、有验证、有日志、有回退”。

8. 推荐升级检查清单

如果你准备升级到 OpenClaw v2026.3.11，可以按下面清单执行。

8.1 升级前检查

1. 记录当前 OpenClaw 版本 2. 记录当前安装方式：npm / pnpm / Docker / 源码 3. 备份 ~/.openclaw 目录 4. 记录当前 workspace 路径 5. 记录当前 Provider 配置 6. 记录当前 Memory 配置 7. 记录当前 Cron jobs 8. 记录当前 Gateway 启动方式 9. 记录当前通道插件：Discord / Feishu / Telegram / Matrix 等 10. 确认是否有回退方案

8.2 升级后验证

1. openclaw --version 2. openclaw doctor 3. openclaw doctor --fix 4. openclaw gateway restart 5. openclaw channels status 6. 验证模型调用是否正常 7. 验证 Memory 搜索是否正常 8. 验证 ACP 会话是否能恢复 9. 验证 Cron 是否正常触发 10. 验证通道是否能收发消息 11. 检查日志是否有持续异常

8.3 我的建议

本地学习用户：可以升级体验，但也要先备份。

多模型 / 多通道用户：升级后必须重点验证 Provider、Gateway、Channel 和 Memory。

生产或长期运行环境：不要无脑升级，先在测试环境验证 Cron、ACP、Gateway 和通道行为。

9. 总结复盘：v2026.3.11 最值得记住的 5 点

最后用这张图做总结。

OpenClaw v2026.3.11 最值得记住的是这 5 点：

9.1 第一，模型接入更完整

Ollama 一等支持和 OpenCode Go Provider 说明：

OpenClaw 正在继续强化多模型、多 Provider、本地与云端混合接入能力。

这对本地模型用户和 Agent 工作者都很关键。

9.2 第二，Memory 记忆系统更强

Gemini Embedding 2、多模态图片 / 音频索引、维度变更自动 reindex，让 Memory 的能力更进一步。

但记忆越强，越要控制索引范围和维护成本。

9.3 第三，ACP 会话恢复更适合长任务

resumeSessionId让 ACP spawned sessions 可以恢复已有会话，而不是每次重新开始。

这对：

• Codex 工作流；
• 长代码任务；
• 多轮 Agent；
• 中断恢复；

都有实际价值。

9.4 第四，安全边界更严格

Gateway / WebSocket origin validation 修复说明：

OpenClaw 的远程入口和管理权限不能只看便利性，还必须看安全边界。

如果你使用 trusted-proxy、远程 Gateway、Browser Control UI，这类更新非常重要。

9.5 第五，升级后必须做 doctor 和通道验证

Cron / doctor 迁移、Discord 分段、Feishu 图片、Kimi Coding 工具调用、macOS LaunchAgent 修复都说明：

这一版升级后不应该只看版本号，必须做功能链路验证。

10. 我的最终建议

如果你只是本地学习 OpenClaw，v2026.3.11 可以作为一个值得跟进的版本。

如果你已经把 OpenClaw 用在比较复杂的场景，比如：

• 本地 Ollama；
• 多 Provider；
• Memory 记忆检索；
• ACP / Codex 会话；
• Discord / Feishu / Telegram 通道；
• Cron 自动化任务；
• macOS Gateway 长期运行；

那升级时一定要谨慎。

我建议按这个顺序：

看 Release Notes ↓ 备份配置 ↓ 升级版本 ↓ 执行 doctor ↓ 修复迁移 ↓ 重启 Gateway ↓ 验证模型 / 记忆 / ACP / Cron / 通道 ↓ 记录结果 ↓ 沉淀升级 SOP

本文最重要的结论是：

OpenClaw v2026.3.11 的重点不是单个功能，而是整体运行链路的增强：模型、记忆、会话、安全、自动任务和通道都被继续补强。

如果你重视本地模型、长期记忆、多通道接入和稳定运行，这一版值得认真看。

真正适合长期使用的 Agent 工具，不只是能跑，而是能升级、能验证、能恢复、能排查。

后续我会继续整理 OpenClaw 后续版本更新，把每个版本的重点变化、适合人群、升级风险和验证动作讲清楚。

让复杂的事情更简单，让重复的工作自动化。

🔝 返回顶部

点击回到顶部

[1]: https://github.com/openclaw/openclaw/releases/tag/v2026.3.11?utm_source=chatgpt.com "Release openclaw 2026.3.11 · openclaw/openclaw · GitHub"