OpenClaw 2026.4.5 深度解读:从 Agent Runtime 走向多模态 Agent OS

逐项拆解 OpenClaw 2026.4.5 的核心更新：视频与音乐生成、Dreaming 记忆系统、Prompt Caching 工程化、Claude/OpenAI 深度整合，以及 Control UI 与审批能力升级。

总体判断

2026.4.5 不是一个“小修小补版”，而是一版明显的 平台跃迁版。

如果说 2026.4.2 的主线是：

core / plugin 边界重划
Task Flow substrate 回归
transport / exec / approvals 安全收口

那么 2026.4.5 的主线已经变成：

媒体能力产品化（music/video generation 进入内建工具）
记忆系统产品化（dreaming 从实验机制开始向可配置、可观测、可恢复演进）
CLI/ACP/Claude/OpenAI 运行时深度整合
prompt caching 工程化
Control UI 与移动审批/多语言正式抬升为一等入口
pairing / auth / plugin / SSRF / allowlist 等边界继续 fail-closed

一句话：

2026.4.5 是 OpenClaw 从“强大的 agent runtime”继续往“完整的多模态 agent OS + 运维控制面”推进的一版。

我是 AI灵感闪现，使用 OpenClaw 小龙虾让 AI 自主管理工作和生活上的问题；使用 Claude Code + BMAD AI 驱动敏捷开发框架，让 AI 自主开发和交付软件来表达想法和灵感。是 MoneyMind 省钱思维 App 和 HeartPetBond 心宠纽带 App 开发者。正在实践和分享让 AI 自主解决健康、生活、投资和等方面的问题。我尽可能让 AI 自己完成从目标到交付以及演进的闭环，以最少的人为交互与监督，让 AI 自己跑流程。我只给 AI 想法或目标，全程不陪跑，让 AI 自主运行类似 Tesla FSD 自动驾驶。

一、Breaking

1) Config：清理 legacy public config aliases

变化内容 移除旧公共配置别名，例如：

talk.voiceId / talk.apiKey
agents.*.sandbox.perSession
browser.ssrfPolicy.allowPrivateNetwork
hooks.internal.handlers
channel/group/room 的 allow toggle

统一改用 canonical public path 和 enabled。

背景问题 过去 OpenClaw 长期背着一批“历史兼容别名”。这短期方便升级，长期会造成：

schema 文档与真实配置分裂
doctor / setup / UI 展示口径不一致
插件和渠道文档越来越难解释“到底该写哪个字段”
config migration 永远无法真正收敛

使用场景

老部署升级到 2026.4.5
维护多个实例的统一配置模板
依赖 openclaw config set/get、schema、doctor 自动修复的集群

例子以前你可能写：

talk:apiKey:xxxvoiceId:yyy

现在应改到新的 canonical path；旧字段在 load-time 仍兼容，但不再是公开推荐路径。

注意事项

这是 breaking，但属于“温和 breaking”：加载仍兼容，并支持 openclaw doctor --fix
真正风险在于：你自己的模板仓库、脚本、文档、样板配置、自动 diff 工具如果还盯着旧字段，后续会越来越失真
如果你管理多实例，建议统一跑一轮 doctor + config diff

和 2026.4.2 的关系 2026.4.2 已经把 xAI / Firecrawl 等插件配置从 legacy core path 往 plugin-owned path 挪；2026.4.5 继续把“遗留公共别名”清掉。

趋势判断 OpenClaw 现在已经从“尽量兼容历史写法”转向“兼容加载，但不再容忍 schema 漂移”。

二、Changes：主线解读

下面不机械复述每条，我按主题分组逐项解释。

主题 A：OpenClaw 正式进入多模态生成时代

2) `video_generate` 内建工具

变化新增 built-in video_generate，agent 可以直接调用配置好的 provider 生成视频，并把媒体直接回到回复里。

背景问题 之前 OpenClaw 的图像生成已逐步成熟，但视频仍偏 provider-specific、工作流级或外部集成级。用户想让 agent “生成一个视频” 时，路径不统一。

使用场景

营销素材
社交媒体短视频 demo
说明型动画
通过对话直接产出视频文件

例子用户说：

“做一个 5 秒钟的产品转场视频”
“把这张参考图变成动态短片”

现在 agent 可以走 video_generate，而不是靠外部脚本或手搓 provider 请求。

注意事项

视频生成多数是异步 / 长耗时 / 大文件
渠道媒体上限、临时文件持久化、direct-send 与 wake-notify 的交付路径要特别关注
不同 provider 对 prompt、时长、分辨率、参考图支持差异很大

竞品对比

NanoClaw：更偏极简 assistant，不强调内建多模态媒体工具
Nanobot：可通过 MCP 接外部视频能力，但不是内建产品层能力
IronClaw：安全与工具执行强，媒体生成不是当前主叙事
PicoClaw / ZeroClaw：轻量化更强，但多模态产品栈一般不如 OpenClaw 完整

判断这条意味着 OpenClaw 从“会聊天、会调用工具”走向“原生内容生产平台”。

3) `music_generate` 内建工具

变化新增 built-in music_generate，内置 Google Lyria、MiniMax，以及基于 Comfy 工作流的支持；包含 async task tracking 与完成后 follow-up delivery。

背景问题 音乐生成 provider 一般都是异步、有任务状态、参数差异大。没有统一工具层时，agent 很难稳定地“接单 → 跟踪 → 回传音频”。

场景

生成背景音乐 / jingles
做产品演示音效
自动化内容工作流

例子 “生成一段 15 秒未来感开场音乐。”

注意事项

某些 provider 不支持部分 hint，比如 durationSeconds
这版专门把“不支持的可选 hint”改成 warning 而不是 hard fail，这非常实用
如果你做自动化流水线，warning 比 fail-fast 更适合多 provider 兼容

判断 OpenClaw 的 media tool 已经从 image 扩成 image + music + video，这不是补 feature，而是把“agent 做内容生产”当正式能力。

4) Providers/ComfyUI：media workflow plugin

变化新增 bundled comfy workflow media plugin，支持：

local ComfyUI
Comfy Cloud
image_generate
video_generate
workflow-backed music_generate
prompt injection
可选 reference-image upload
live tests
output download

背景问题 ComfyUI 生态强，但 workflow 节点复杂、调用方式碎片化。之前更多是高手自己接；现在 OpenClaw 直接把它纳入统一媒体能力层。

场景

本地部署 ComfyUI
需要高度自定义媒体 pipeline
想要比纯 SaaS provider 更可控的生成链路

例子产品设计团队可以用 Comfy 跑自定义视频或音乐工作流，而用户仍然只对 agent 说自然语言。

注意事项

Comfy 的强项是灵活，不是标准化
一旦 workflow schema 变更，调试复杂度仍高于直接 provider
但 OpenClaw 把其包装成统一工具后，门槛大幅下降

和竞品对比 OpenClaw 在这块明显更平台化。其他几家更多是“留给用户自己接”。

5) 新增一批 provider：Qwen / Fireworks / StepFun / MiniMax TTS / Ollama Web Search / MiniMax Search

背景问题 多 provider 不是简单“多几个模型名”，而是要把聊天、TTS、搜索、多模态、兼容路由一起接顺。

实际意义

中国生态覆盖更广：Qwen、StepFun、MiniMax
自托管 / 本地生态更强：Ollama Web Search
内容生产链更完整：MiniMax TTS

趋势 OpenClaw 已经不是“OpenAI/Anthropic 二选一”平台，而是一个provider federation runtime。

6) Amazon Bedrock + Mantle support

变化

inference-profile discovery
automatic request-region injection
Mantle bearer token 走 AWS credential chain 自动生成

背景问题 Bedrock 的问题一直不是“不能接”，而是：

区域注入麻烦
profile/route 复杂
IAM / bearer token / env 配置容易误配

场景企业 AWS 环境、统一 IAM 认证、多模型路由

判断这说明 OpenClaw 正在认真服务企业云环境，而不是只服务个人桌面用户。

主题 B：记忆系统从“能记”走向“会做梦”

7) Memory/dreaming（experimental）大扩展

这是 2026.4.5 最有辨识度的新主线之一。

新增内容

weighted short-term recall promotion
/dreaming 命令
Dreams UI
multilingual conceptual tagging
doctor/status repair support
将 dreaming 从 competing modes 重构为三阶段：light / deep / REM
各阶段独立 schedule 和 recovery behavior
aging controls：recencyHalfLifeDays, maxAgeDays
verbose logging
REM preview tooling：openclaw memory rem-harness, promote-explain
replay-safe deep promotion
dreaming trail 写入顶层 dreams.md
Dream Diary surface
docs/UI 把 phases 降为实现细节
staging 时把 daily notes 近邻行分组成 coherent chunks
去掉 generic 日期标题噪音

背景问题 传统 assistant memory 的常见问题：

什么都记 → 污染上下文
什么都不记 → 没长期价值
promotion 规则黑盒化
rerun 会重复写 MEMORY.md
短期笔记太碎，难以抽出“lasting truths”

这次在解决什么 这不是“多了个记忆命令”，而是在做：

把长期记忆提升（promotion）变成一个可调、可观察、可恢复、可解释的后台流程。

使用场景

个人长期助手
项目持续运营
需要把 daily notes 慢慢沉淀到长期记忆
希望 agent 能自己整理“哪些事实值得长期保留”

例子比如日记里多次出现：

用户长期偏好某些 provider
某个集群隧道维护方式固定
某工作流经常失败的根因反复出现

Dreaming 机制会把这些“短期片段”经过权重、阶段、衰减、chunking，提炼成更 durable 的知识。

注意事项

这仍是 experimental
自动 promotion 一旦配置过激，可能把噪音当事实
dreams.md 独立于默认 recall 很聪明：既保留轨迹，又避免污染默认记忆检索
对你这种多实例 manager 来说，这套机制很适合整理 cluster lessons learned，但需要谨慎控制频率

和 2026.4.2 的关系 4.2 还主要在做 runtime 和 plugin 边界；4.5 已经在做“assistant cognition layer”的工程化。

竞品对比

NanoClaw：有 memory，但更偏简洁日志/文件，不强调多阶段 promotion
Nanobot：更重 MCP host，不以内建 durable memory 为核心卖点
IronClaw：有 workspace filesystem + hybrid search，但 dreaming 这种“认知管线”公开叙事不如 OpenClaw 激进
PicoClaw：有 JSONL memory store，但更偏轻量记录，不是多阶段 memory lifecycle
ZeroClaw：轻量导向，长期记忆治理深度通常不如 OpenClaw

判断这是 OpenClaw 想走向“不是只会响应，而是会内化经验”的关键一步。

主题 C：Prompt caching 正式工程化

8) Prompt caching 一整组改进

变化内容 包括：

transport fallback 下更可复用的 prompt prefixes
deterministic MCP tool ordering
compaction 与 cache 兼容
embedded image history 更稳
normalized system-prompt fingerprints
openclaw status --verbose cache diagnostics
去掉 agent system prompt 中重复的 in-band tool inventory
live cache diagnostics / break diagnostics
whitespace / line endings / hook-added context / capability ordering normalization
Codex Responses / Anthropic Vertex 走 boundary-aware cache shaping
HEARTBEAT.md 迁出稳定 prefix cache boundary
保持 3-turn image window
transcript fallback 显示 cacheRead/cacheWrite

背景问题 Prompt cache 最怕两件事：

语义没变但字节变了，命不中缓存
你以为命中了，实际上因为系统提示抖动、工具顺序抖动、心跳文件变化而 miss

场景

高频 follow-up 聊天
图像/工具混合会话
Claude / Codex / Vertex 等有 prompt cache 的 provider
追求低成本和低延迟的大量交互

例子之前只是 HEARTBEAT.md 注释变一下，整个 system prompt prefix 可能就 miss；现在明确把 HEARTBEAT.md 放到 cache boundary 下面。

注意事项

这是“看不见但非常值钱”的优化
对重度用户，cache 稳定性直接影响成本、速度、体验
同时，这也解释了为什么 system prompt、tool inventory、capabilities ordering 都越来越讲究

判断 OpenClaw 已经把 prompt caching 当作核心基础设施，而不是 provider 附带能力。

主题 D：Claude CLI / ACPX / OpenAI 运行时深度整合

9) Claude CLI 通过 loopback MCP bridge 暴露 OpenClaw tools

变化背景 Claude CLI 运行现在可通过 loopback MCP bridge 使用 OpenClaw tools；并改为 stdin + stream-json partial-message streaming。

背景问题 旧方式的问题：

prompt ride on argv，不安全也不优雅
长回复没实时进度
工具能力与 OpenClaw runtime 脱节

效果

prompts 不再出现在 argv
长回复可实时显示
final session / usage metadata 仍可干净落地
Claude CLI 背景运行更像真正的 OpenClaw agent backend，而不是外接脚本

注意事项 这版还做了大量 Claude CLI 安全补丁：

清理 CLAUDE_CONFIG_DIR / CLAUDE_CODE_PLUGIN_*
清理 provider-routing / managed-auth env override
强制 --setting-sources user
malformed --permission-mode fail-safe
保持 non-interactive bypassPermissions
session binding / reuse / relogin invalidation / image path hydration

判断这说明 OpenClaw 现在对“借外部 CLI 做 agent runtime”不再是简单壳调用，而是在做受控内嵌运行。

10) ACPX/runtime 内嵌

变化

ACP runtime 直接嵌进 bundled acpx plugin
去掉额外外部 ACP CLI hop
live ACP session binding/reuse 更稳
增加 generic reply_dispatch hook

背景问题 多一层 CLI hop 的代价：

transport overhead
session 绑定脆弱
reply interception 需要 core hardcode

判断和 4.2 的 Task Flow / plugin seam 一脉相承：OpenClaw 正在把“外部 authoring runtime”拉回统一宿主控制面。

11) OpenAI/GPT/Codex 深度调优

重点变化

forward-compat openai-codex/gpt-5.4-mini
opt-in GPT personality
GPT-5 prompt contributions provider-owned
降低 verbosity，缩短确认回复
对“只是讲计划不动手”的 turn 做 one-shot retry
preserve reasoning.effort: "none" and strict schemas where supported
commentary buffered until final_answer
live progress 更清晰
Codex contextWindow / contextTokens 分离
strict schema 兼容修复
tool-call / work-item lifecycle event 更明确

背景问题 GPT-5/Codex 类模型常见毛病：

太爱解释计划，不动手
回复像 memo
strict tool schema 挑剔
reasoning / commentary 容易泄漏到用户侧
usage / token totals 不稳定

判断 OpenClaw 不再把 OpenAI 当“普通 provider”，而是在做 provider-specific behavioral tuning。

主题 E：Control UI、审批、移动端真正成熟起来

12) Control UI 多语言

支持：

简中、繁中、巴葡、德、西、日、韩、法、土、印尼、波兰、乌克兰

意义这不只是翻译，而是在说 Control UI 已经是正式产品入口，而非管理附属页面。

13) Skills 面板集成 ClawHub

变化在 Skills panel 里直接做 ClawHub search / detail / install。

意义技能市场从 CLI 世界走进 UI 世界。对非 CLI 管理者非常重要。

14) iOS / Matrix exec approvals

变化

iOS：APNs 批准通知 + app 内 modal
Matrix：原生 exec approval prompt，支持 account-scoped approver、房间/DM 投递、线程分辨

背景问题 审批体验如果不原生，就会沦为“技术上可用，实际不顺手”。

判断 OpenClaw 正在把 approvals 做成跨平台系统，而不是聊天插件附属功能。

15) Control UI/chat thinking-level picker

变化每会话 thinking-level 可视切换，移动端也有。

意义 “推理深度”开始成为普通用户可理解、可调的产品变量，而不是只存在 config 里。

主题 F：渠道上下文治理更细

16) `contextVisibility` per channel

变化新增 contextVisibility：

all
allowlist
allowlist_quote

背景问题 之前 quote / thread / fetched history 往往“收到什么就全喂给模型”。这对群聊、半公开协作、不同 sender 信任等级来说不总是合适。

场景

群聊
企业频道
只希望引入 allowlist sender 的上下文

例子群里有人引用了很多历史内容，但你只信任管理员或白名单成员的引用内容进入模型。

判断这是多渠道上下文安全/治理能力的明显升级。

主题 G：Providers/request overrides 统一

17) shared request transport overrides

变化对 OpenAI / Anthropic / Google / compatible provider paths 统一支持：

headers
auth
proxy
TLS

背景问题 你此前已经看到 4.2 在收 transport boundary；4.5 进一步把“请求覆写控制面”公开化、统一化。

意义对企业代理、私有网关、审计头、mTLS、特殊认证都很关键。

注意这功能很强，也更危险。越强的 override，越要注意不要破坏 provider-native 行为或安全边界。

主题 H：Lobster in-process、Plugin/SDK 更内聚

18) Lobster workflow in-process

变化不再 spawn 外部 CLI，而是在进程内跑 bundled Lobster workflows。

意义

减少 transport overhead
更易与 runtime 原生集成
resume / validation / embedded runtime loading 更稳

这和 ACPX 内嵌一样，都是“把外部 authoring runtime 内收”。

三、Fixes：真正值得关注的修复面

这版 fixes 太多，逐条展开会变成电话簿。我按“值得你在升级时重点关注”的问题域来拆。

1) Security 面：fail-closed 继续贯彻

重点包括：

preserve restrictive plugin-only tool allowlists
/allowlist add/remove 需要 owner access
before_tool_call hook crash 时 fail closed
browser SSRF redirect bypass 更早拦截
auth-choice inference 限于 bundled / trusted plugins
paired-device 不能跨设备 rotate/revoke token
plugin HTTP routes 不再在 scope 缺失时误铸 admin 级 runtime scopes
browser-origin auth throttling 按 normalized origin 作用域化
shared-secret auth attempts 串行化以守住 rate limit
pairing/bootstrap scope 边界更严格
Android canvas URL exact match
Synology Chat TLS verify 默认打开
marketplace symlink escape 阻断
Telegram local Bot API 绝对路径读取必须受信根目录
outbound text 去掉 <tool_call> / <function_calls> / 特殊 token 泄漏
hardlinked files 在跨设备 rename fallback 中拒绝

总体判断 OpenClaw 的安全关注点已经很成熟：

不只是 prompt injection
不只是 exec allowlist
还包括 plugin route scopes、device pairing、marketplace symlink、UI bridge exact-origin、Bot API local file roots、commentary leak、SSRF redirects

这比很多“轻量开源 agent”高一层。