OpenClaw 2026.9.1 更新解读：Quick Start、Mermaid、Memory Reset 与个人 Skill Library

OpenClaw 已在 2026-09-03T18:31:33Z 发布 v2026.9.1 正式版，GitHub Release 标记为 prerelease: false。按中国时间是 2026-09-04 02:31:33。

这意味着此前 GitHub 上那个“误发成 v2026.9.1-beta.1、实际属于 8.1 beta”的历史记录，已经不能再用于判断当前版本。现在真正的 v2026.9.1 已经存在，而且是正式稳定 Release。

先说结论：谁值得现在升级

新安装用户可以直接以 2026.9.1 为当前稳定基线。Quick Start 明显缩短了“安装 → 配模型 → 打开 Web Dashboard”的路径。

个人单用户、普通桌面环境在备份和 dry-run 后可以升级，9.1 对 Web UI、Memory、长会话性能和 Skills 都有直接价值。

共享 Gateway、多 Agent、重度 subagent、官方插件很多、无人值守自动化或大型生产实例，建议先在副本或低风险节点验证。9.1 发布后的首批 issue 已经出现几类需要关注的边缘回归，本文后面单独列出；这些 issue 是社区现场报告，不等于官方确认所有环境都会受影响。

1. Quick Start：从安装到 Web Dashboard 更短

9.1 给 fresh install 增加了更短的 Quick Start 路径，包括 npx openclaw@latest 场景。

如果机器上已经有可复用的 Claude Code、Codex 登录或已有 provider key，OpenClaw 会优先发现并验证真实可用性，而不是让你重新走一遍完整配置向导。完成一个可用选择后，可以从前台 Gateway 直接进入 Web Dashboard；常驻 service 安装仍然是后续明确动作，不会因为“能聊天了”就默认替你装成后台服务。

对于 headless / VPS，官方路径会给出一次性的 authenticated dashboard link 和 SSH tunnel 模板，而不是把可长期复用的 Gateway 凭据直接暴露出来。

这对本站安装教程的实际影响是：“先装一堆东西，再手工配置所有 provider”不再是唯一默认起点。 完整 Custom setup 仍然保留，复杂部署不要为了快而跳过权限与网络边界检查。

2. Mermaid：聊天里可以直接看流程图和架构图

9.1 让 Mermaid code block 可以直接在以下聊天界面渲染成图：

• Control UI
• macOS
• iPhone / iPad
• Android

这对 OpenClaw 的实际使用价值比“支持 Mermaid”四个字更大。现在让 Agent 输出：

• 系统架构图
• 部署流程图
• Agent 调用关系
• 状态机
• 决策树
• 数据流图

可以直接在对话里阅读，不必复制到外部 Mermaid 编辑器。

渲染失败时仍应保留原始代码作为可恢复内容；不要把 Mermaid 当成可以执行任意 HTML / SVG 的通道。

3. Memory Reset：终于有“重建索引但不删记忆”的正式路径

这是 9.1 最值得运维用户记住的命令之一。

当 Memory index 损坏、版本不兼容、需要明确重建时，可以使用：

openclaw memory reset --agent main --yes

它清理的是 派生的 Memory index 与 embedding cache，不是用户原始内容。Session、transcript 和 Memory 文件仍保留。

之后可以按需要重新索引：

openclaw memory index --agent main
openclaw memory status --agent main --deep

这里有两个边界必须写清楚：

1. Memory Reset 不是隐私擦除。 想删除历史内容，不能把它当“清空聊天记录”。
2. 不要为了修索引直接删除 Agent SQLite 数据库。 9.1 已经提供更窄、更可恢复的正式 reset 路径。

9.1 同时减少普通 search 因 dirty state 反复做全量 rebuild 的情况，并把部分维护工作从用户等待的查询路径里移开。对于 Memory 很大的实例，这比增加一个新功能更有实际价值。

4. Personal Skill Library：共享 Gateway 上每个人可以有自己的 Skills

9.1 增加 Personal Skill Libraries。它和原来的 workspace Skills、ClawHub 安装不是一回事。

在共享 Gateway 中，已登录用户可以维护自己的 Skill Library，不需要为了每次调整 Skill 都拿到宿主机文件权限。个人 Skill 默认是私有的；分享与编辑权限也分开处理。

CLI 入口集中在：

openclaw skills library

官方支持创建、读取、更新、从 ZIP 导入、共享、回滚，并把 确定的 immutable revision 附到 Session。这样一条正在运行的 Session 不会因为 Library 后来被修改，就静默换成另一份内容。

对团队 Gateway 来说，这解决的是一个长期问题：

“所有 Skill 都塞进 workspace”会让个人实验、团队共享和宿主机权限混成一层。

现在更合理的边界是：

• workspace Skills：项目 / 工作区级能力；
• personal library：用户自己的可复用 Skills；
• ClawHub：外部发现与分发；
• plugin：更高权限、更宽运行面的 Gateway 扩展。

但 Personal Skill Library 不是跨不可信 Gateway 的安全沙箱。仍然要读 SKILL.md、审查脚本、依赖、网络和凭据范围。

5. Models / Providers：Control UI 更像真正的配置中心

9.1 继续把常用模型配置往 Control UI 收拢。Defaults 卡片可以更清楚地处理：

• main model
• utility model
• first fallback
• thinking
• Fast Mode

保存前还会显示改动落在哪个 scope，例如 Session、Agent 或 global，减少“我只想改当前会话，结果改了全局”的误操作。

Provider 登录和模型 catalog 的刷新也更动态，部分场景不需要为了看到新 provider / model 重启整个 Gateway。

如果你维护多个 Agent，仍建议把“默认模型、每 Agent override、每 Session override”分开记录，不要只凭 UI 当前显示的一个模型名判断最终 routing。

6. Automations：停机后是否补跑旧任务终于可以明确选择

9.1 为 recurring cron 增加了一个重要的 opt-in：

{
  "cron": {
    "skipMissedJobs": true
  }
}

开启后，Gateway 停机期间已经过期的 周期任务可以跳过，而不是恢复后集中补跑历史任务。

这对“每小时检查一次”“每天生成一次简报”这种任务很有用：恢复后一次性补十几轮通常没有意义，反而可能造成重复消息、重复 API 消耗或重复写入。

注意：

• 这是 opt-in，不是默认行为改变。
• one-shot 一次性任务不应被当作普通 stale recurring job 丢掉。
• 有业务补偿要求的任务，不能只因为“怕重复”就统一开启 skip。

7. 更新失败后的恢复更像诊断流程，而不是继续硬重试

9.1 的 updater 更强调 restart 之前先检查 readiness。

例如以下问题可以在重启前被拦住或给出明确处理路径：

• local-memory setup 不完整；
• plugin capability / consent 未解决；
• approval migration 未完成；
• migration warning 只影响部分能力但不需要直接让 Gateway crash-loop。

对于部分非致命 migration warning，9.1 可以让 Gateway 以明确 degraded 状态保持可达，再由 operator 跑 Doctor，而不是监督进程反复拉起、反复失败。

交互式 update 如果已经执行到操作阶段后失败，还可以把经过裁剪和脱敏的失败上下文交给现有 coding agent 或 Control UI 的 Ask OpenClaw 做调查。

但这个调查入口没有自动获得“再执行一次 update、修状态、重启 Gateway”的权限。诊断成功也不等于原更新成功。

常规升级顺序仍建议保守一点：

openclaw --version
openclaw update status
openclaw update --dry-run
openclaw update
openclaw doctor
openclaw gateway status --deep

如果 core 已经变更，但 plugin sync / doctor finalization 没完成，再使用：

openclaw update repair

8. 安全边界：9.1 的重点是“批准只在该批准的地方有效”

这轮安全改动里，最值得实际运维关注的是：

• durable MCP approval 更严格绑定到具体 agent / server / tool；
• remote Codex placement 的授权范围更窄，不应变成泛化权限；
• delegated agent 创建过程中，如果原请求已经失去 authority，会在后续持久化副作用前停止；
• browser、受保护 web fetch、automation webhook 可以增加 hostname blocklist；
• 新保存的 Codex reasoning 默认继续保持隐藏，除非显式开启显示。

这里不要把 hostname blocklist 写成“完整 egress firewall”。官方说明它是 destination policy：例如 wildcard 子域与 apex host 的语义不同，而且不是所有外部连接路径都天然受同一层策略覆盖。

9. 首发观察：复杂环境不要只看 Stable 标签

v2026.9.1 是正式 stable Release，但发布后数小时内已经出现若干值得跟踪的现场 issue。当前更适合把它们视为 升级风险信号，不是普遍故障结论。

长时间 subagent settle wake 可能被 120 秒 timeout 中断

Issue #137643 报告：在特定 sessions_spawn + sessions_yield + CLI-backed requester 场景下，子 Agent 已经完成，但 parent 的 settle-wake 验证执行超过默认 120 秒后会被取消，并可能重试、产生截断进度消息。

如果你的工作流依赖很长的 subagent 完成回收，不建议今天直接把全部生产节点切到 9.1。

plugins update --all 可能留下旧版官方插件

Issue #137624 在 9.1 上报告：core 已经是 9.1，但某些 tracked official plugin 仍停在 8.2；针对单个插件的更新可以解析到 9.1。

升级后不要只看：

openclaw --version

还要检查：

openclaw doctor --post-upgrade
openclaw gateway status --deep
openclaw plugins inspect <id> --runtime --json

大型 Linux Gateway 更新时可能出现较长离线窗口

Issue #137580 报告一个 21 Agent / 124 Session 的 Linux 实例从 8.2 → 9.1 时，core 最终升级成功，但 detached update 的 post-update finalization 期间 Gateway 约离线 20 分钟。

这不是“9.1 一定离线 20 分钟”，但足以说明：多 Agent 生产 Gateway 要把维护窗口、外部健康检查和回退路径准备好，不要在唯一消息入口里直接发一句“帮我更新”然后认为几秒就结束。

10. 8.2 的 Session visibility 风险没有因为 9.1 发布就自动消失

如果你从更老版本直接跳到 9.1，仍要知道 8.2 已改变的行为基线：unsandboxed Session 默认 tools.sessions.visibility = "agent"。

共享 Agent / 多用户 Gateway 仍应明确检查是否需要 tree 或更严格的 self。版本升级不会替你判断原来的共享 Agent 边界是否合理。

推荐升级策略

可以优先升

• 新安装；
• 个人单用户；
• 想用 Mermaid / 新 Web UI；
• Memory index 维护痛点明显；
• 想使用个人 Skill Library；
• 有测试环境和可回退路径。

先验证再升

• 多 Agent / 多用户 Gateway；
• 重度 sessions_spawn / sessions_yield；
• 官方或第三方插件较多；
• 依赖 agent 发起自更新；
• Gateway 是 Telegram / 飞书 / Slack 等唯一入口；
• 大量 Session、Memory、Agent roster 的生产实例。

本站会继续把“官方 Release 已发布”和“首发现场是否稳定”分开记录。当前版本状态看版本中心，新安装看安装中心，Skill 安装与个人 Library 的边界看Skill 安装与验证，升级异常从故障排查中心开始。