本文由 莫潇羽@源码七号站（www.fuyuan7.com）原创整理，转载请注明出处。
快速摘要
核心结论一览（往下有完整拆解）
这是 OpenClaw 迄今为止影响范围最广的一次版本更新。 停更 9 天之后，v2026.3.22 在 2026 年 3 月 22 日正式发布，它的意义不仅仅是"加功能"，而是从底层逻辑上重新定义了这个平台的玩法边界。
以下是你最需要知道的几个核心结论：
- 插件系统彻底换血：旧的
openclaw/extension-api被一刀切移除，全新的模块化openclaw/plugin-sdk/*接管，没有任何兼容层，所有老插件必须迁移 - ClawHub 成为官方插件市场：执行
openclaw plugins install时，系统现在优先走 ClawHub，只有找不到时才回退到 npm，安全性与生态纯净度大幅提升 - 默认模型升级至 GPT-5.4，同时原生支持 MiniMax M2.7 高速模型、小米 MiMo V2 系列以及通过 Google Vertex AI 接入的 Claude 模型
- 一口气打了十余项安全补丁，覆盖 Windows SMB 凭证泄露、JVM 环境变量注入、Unicode 零宽字符审批伪装等高危漏洞，公网部署用户务必更新
- Agent 默认超时从 10 分钟拉长到 48 小时，长任务终于不再被系统掐死
- 老用户升级前必须备份配置，尤其是浏览器连接方式有破坏性变更，需要运行
openclaw doctor --fix完成迁移
OpenClaw 是什么？从"会说话"到"会干活"
在正式进入更新内容之前，有必要先解释一下 OpenClaw 到底是什么东西，特别是对刚接触这个项目的朋友来说。
你可能用过很多 AI 对话工具，它们能帮你写文案、解答问题、生成代码，但这些工具有一个共同的局限：它们只能"说"，不能"做"。你让它帮你整理文件，它会给你一段操作步骤；你让它发一封邮件，它会帮你写好内容，但点击发送这个动作还是得你自己来。
OpenClaw 做的事情完全不同。它是一个运行在你自己设备上的 AI 智能体平台，本质上更像一个"能动手的同事"——你通过微信、飞书、Discord、Telegram 等聊天软件发一句指令，它就能在你的电脑上真实执行：读写文件、操控浏览器、运行终端命令、调用 API、管理日程……只要是你用电脑能完成的事，它基本都能替你做，而且全程在你自己的设备上运行，数据不经过第三方服务器。
这个项目由独立开发者 Peter Steinberger 创建，代号"龙虾"（🦞），在 GitHub 上增长极为迅猛，是近两年开源社区中话题度最高的 AI 工具之一。它支持 macOS、Linux 以及 Windows（通过 WSL2），支持几十种通信渠道接入，支持几乎所有主流大模型提供商，并通过一套名为 Skills（技能包）的插件体系不断扩展能力边界。
v2026.3.22 这次更新，可以说是 OpenClaw 从"一个好用的 CLI 工具"向"可信赖的 AI 智能体操作系统"蜕变过程中最关键的一步。
OpenClaw 的核心工作原理：Gateway + Channels + Skills
在深入讲更新内容之前，我想多花一些篇幅讲讲 OpenClaw 的基础架构，因为理解了这个架构，后面很多更新的意义才能真正读懂。
OpenClaw 的运行模型由三个核心概念构成：网关（Gateway）、通信渠道（Channels） 和 技能包（Skills）。
网关（Gateway） 是整个系统的心脏。它是一个运行在本地的后台服务进程，负责接收来自各个渠道的消息、调度模型调用、执行工具调用、管理会话状态。你可以把它想象成一个"大脑中枢"，所有的指令流和数据流都经过它来调度和分发。网关一旦启动，即使你关掉终端窗口，它也会继续在后台运行（通过 launchd 或 systemd 守护进程管理）。网关提供了一个本地的 WebSocket 接口，其他组件通过这个接口与它通信。
通信渠道（Channels） 是你与 OpenClaw 对话的入口。OpenClaw 支持数十种通信渠道，包括微信（通过 WeCom/企业微信）、飞书、Telegram、Discord、Slack、WhatsApp、Signal、iMessage、Google Chat、Line、Matrix 等。每个渠道背后都有一个对应的插件处理消息的收发和格式转换，让网关不需要关心不同渠道的通信协议差异，只需要处理统一格式的消息体。对国内用户来说，飞书和企业微信是最常用的接入方式，因为不需要境外网络就能使用，稳定性也更有保障。
技能包（Skills） 是 OpenClaw 能力的扩展层。基础安装的 OpenClaw 已经内置了一些核心工具（文件读写、终端命令、浏览器控制等），但很多专业场景需要额外的技能包支持。比如处理 PDF 文件、调用特定的 API 服务、操作特定的 SaaS 工具，都需要安装对应的技能包。Skills 本质上是一段 JavaScript 代码，定义了一组可以被 Agent 调用的工具（Tools），当 Agent 判断某项任务需要某个工具时，会自动调用对应的技能。一个设计良好的 Skill，能让 Agent 在完成复杂任务时做到完全自动化，无需人工干预每一个步骤。
这三层架构的好处是职责分离非常清晰：网关负责核心逻辑，渠道插件负责对外通信，技能包负责扩展能力。每一层都可以独立更新和扩展，而不需要动其他层。v2026.3.22 这次对插件体系的重构，就是在技能包（Skills）这一层进行的。新的 plugin-sdk 让技能包的开发更加规范，ClawHub 让技能包的分发更加安全可靠。
还有一个值得了解的概念是 ACP（Agent Control Protocol），这是 OpenClaw 定义的一套智能体间通信协议，允许多个 Agent 之间协同工作——一个主 Agent 可以拆分子任务，分发给专门化的子 Agent 来并行处理，子 Agent 完成后把结果返回给主 Agent 汇总。这种多智能体协作模式在处理复杂任务时效率非常高，v2026.3.22 里 ACP 会话超时时间从 600 秒提升到 48 小时，对这种长时间多步骤协作任务的支持大幅增强。整个框架运行在你自己的设备上，没有数据上传到任何云服务，对于对数据安全有要求的场景来说，这是一个重要的优势。
停更 9 天的背后：这次到底憋了什么
OpenClaw 的更新频率通常比较高，隔几天就会有新版本出来。所以当 GitHub 连续 9 天没有任何提交动作时，社区里开始有人猜测发生了什么。项目主 Peter Steinberger 当时只发了一张龙虾图片，暗示正在做大事。
3 月 22 日的更新发布之后，答案揭晓了：这 9 天被用来完成一次影响范围极广的底层重构，涉及插件系统架构、安全防护机制、浏览器连接方式等多个核心模块。这种程度的改动，在正常的迭代节奏下根本来不及做，只能一次性停下来集中处理。
从工程角度看，这是一次非常清晰的信号：OpenClaw 团队已经过了"堆功能冲星标"的阶段，开始认真考虑这个平台在生产环境中的可靠性、安全性和可维护性。接下来我们就逐一拆解这次更新的重点内容。
一、插件系统换骨：ClawHub 时代正式开启
旧 API 的终结，没有任何缓冲
这次更新最具破坏性的变化，是对插件体系的彻底重构。
旧的 openclaw/extension-api 模块被完全移除，没有兼容层，没有过渡期，直接一刀切。官方给出的迁移文档地址是 https://docs.openclaw.ai/plugins/sdk-migration，如果你是插件开发者，这是目前最重要的参考资料。
取而代之的是全新的 openclaw/plugin-sdk/* 模块化接口体系。与旧 API 相比，新 SDK 采用更细粒度的子路径导入设计，每个功能模块都有独立的入口，而不是从一个统一的大根节点引入所有内容。这种设计让打包体积更小，依赖关系更清晰，也更方便做按需加载。
举个具体的例子：过去你可能在插件里这么写
// 旧写法（已失效）
import { SomeAPI } from 'openclaw/extension-api';新版必须改成类似下面这样，通过 plugin-sdk 的具体子路径引入：
// 新写法
import { agentRuntime } from 'openclaw/plugin-sdk/runtime';
import { channelAdapter } from 'openclaw/plugin-sdk/channels';需要特别注意的是，插件里如果有主机侧的操作（比如调用网关 API 启动一个嵌套的 Pi Agent），现在必须通过注入的 runtime 对象来执行，例如 api.runtime.agent.runEmbeddedPiAgent，而不是直接 import 某个函数。
另外，ChannelMessageActionAdapter 里的 listActions、getCapabilities、getToolSchema 这三个旧方法也被移除，必须统一迁移到新的 describeMessageTool(...) 方法。
ClawHub：官方插件市场正式上线
这次更新里最值得普通用户关注的，是 ClawHub 这个官方插件市场的上线。
过去安装插件时，openclaw plugins install <包名> 这条命令会直接去 npm 拉包。npm 是个通用的 JavaScript 包管理器，任何人都可以发布包到上面，质量参差不齐，偶尔还会出现恶意包冒充合法工具的问题。
从 v2026.3.22 开始，安装逻辑发生了根本性的变化：系统会优先去 ClawHub 查找包，只有 ClawHub 上没有的，才会回退到 npm。ClawHub 是 OpenClaw 官方维护的插件注册表，所有上架的插件都经过审核，来源更可控，安全性更高。
# 优先从 ClawHub 安装（新行为）
openclaw plugins install <package-name>
# 明确指定从 ClawHub 安装
openclaw plugins install clawhub:<package-name>
# 搜索 ClawHub 上的技能包
openclaw skills search <关键词>
# 安装 ClawHub 技能并追踪更新元数据
openclaw skills install <skill-name>
# 列出可用插件
/plugins同时，新版还支持在聊天界面直接使用 /plugins 和 /plugin 命令，列出已安装的插件、查看详情、启用/禁用——这对不喜欢手动敲命令行的用户来说非常友好。
跨生态兼容：Claude、Codex、Cursor 插件互通
这是一个格局层面的重大扩展，值得单独说一下。
v2026.3.22 新增了对 Claude、Codex、Cursor 三大主流开发工具插件包的发现与安装支持。也就是说，如果你在这三个平台上积累了一些好用的插件，现在可以直接把它们导入到 OpenClaw 里运行，系统会自动把外部插件包里的 Skills 映射到 OpenClaw 的技能体系中。
这一步的战略意义非常明显：OpenClaw 不再是一个封闭的工具框架，而是开始有意识地吸纳外部生态。未来随着更多开发工具的接入，技能库的丰富程度会以指数级增长，用户的选择空间也会越来越大。
二、新插件 SDK 迁移：给开发者的操作指引
如果你是 OpenClaw 插件的开发者，这一节需要认真看。如果你只是普通用户，可以略过直接看后面的模型和安全部分。
官方提供了完整的 SDK 迁移文档，地址是 https://docs.openclaw.ai/plugins/sdk-migration，以及 SDK 总览文档 https://docs.openclaw.ai/plugins/sdk-overview。
迁移过程中需要特别注意以下几点：
- 移除所有对
openclaw/extension-api的引用，这个包已经从注册表中删除，导入会直接报错 - 改用细粒度子路径引入，不要再从
openclaw/plugin-sdk的根路径一次性 import 所有内容，要按功能模块分别引入 - 主机侧操作改用注入 runtime，任何需要与网关通信的操作都走
api.runtime.*命名空间 - 消息工具发现接口迁移到
describeMessageTool，旧的三个方法会直接抛出undefined is not a function
以下是一个典型的迁移前后对比示意：
// ============ 旧版写法（已废弃，会报错）============
import { MessageActionAdapter } from 'openclaw/extension-api';
class MyPlugin extends MessageActionAdapter {
async listActions(context) { /* ... */ }
async getCapabilities() { /* ... */ }
async getToolSchema() { /* ... */ }
}
// ============ 新版写法（v2026.3.22+）============
import { ChannelMessageActionAdapter } from 'openclaw/plugin-sdk/channels';
class MyPlugin extends ChannelMessageActionAdapter {
async describeMessageTool(context) {
return {
name: 'my_tool',
description: '描述你的工具功能',
parameters: { /* ... */ }
};
}
// 具体的运行时逻辑保留在插件包内部
}另外，过去那个内置的 nano-banana-pro 图像生成技能包装器也在这次更新中被一并清除，官方将图像生成路径统一到了 agents.defaults.imageGenerationModel 这个配置项下。如果你之前手动复制了 nano-banana-pro 的配置，需要删掉并改用新路径。
三、模型生态大扩张：GPT-5.4、MiniMax M2.7 与小米的加入
默认模型升级至 GPT-5.4
这次更新将 OpenAI 的默认模型从之前的版本切换到了 openai/gpt-5.4，同时编程特化版本仍然保持 openai-codex/gpt-5.4。与此同时，gpt-5.4-mini 和 gpt-5.4-nano 也做了前向兼容预置，等这两个轻量版本正式上线，可以直接无缝切换。
这次切换还做了一个很有意义的工程优化：把 OpenAI 的聊天、图像、TTS（文字转语音）、转写、嵌入这五类能力的默认模型配置集中到了同一个共享模块里管理，以后 OpenAI 更新模型时，不需要到处改配置，一处修改全部生效。
MiniMax M2.7：国内用户的性价比之选
对国内用户而言，MiniMax M2.7 的原生集成是这次更新最值得关注的亮点之一。
MiniMax 在 OpenClaw 社区里一直有相当高的呼声。OpenClaw 的作者 Peter Steinberger 本人也曾公开表示，用 MiniMax 模型跑 OpenClaw 是一个不错的选择，其成本相较于主流顶级模型有明显优势。M2.7 是 MiniMax 在 2026 年 3 月推出的新一代 Agent 模型，在 SWE-Pro 基准测试中得分 56.22%，接近顶级闭源模型水平，工具调用和指令遵循能力尤为突出。
v2026.3.22 在 M2.7 的适配上做了不少细节工作：默认模型从 M2.5 升级到 M2.7，同时把之前分离的 API 接口和 OAuth 两个独立插件入口合并成了单一的 minimax 插件，配置复杂度大幅降低，用户不需要再搞清楚"什么时候用哪个入口"这种令人困惑的问题。
此外还专门为 M2.7 优化了快速模式，让高速推理场景下的响应延迟更低。
在 OpenClaw 中接入 MiniMax M2.7 的方式（新版已支持 onboard 时直接选择）：
# 方式一：通过 onboard 重新配置，选择 MiniMax 提供商
openclaw onboard
# 方式二：手动修改配置文件（~/.openclaw/openclaw.json）
# 找到模型配置部分，将默认模型改为 minimax-portal/MiniMax-M2.7
# 方式三：通过命令行直接设置
openclaw models set minimax-portal/MiniMax-M2.7
# 修改完成后重启网关
openclaw gateway restart小米 MiMo V2 系列加入
这次更新同步收录了小米的 MiMo V2 Pro 和 MiMo V2 Omni 模型元数据。MiMo 是小米在 AI 推理方向上的重要布局，V2 系列在数学推理和逻辑分析方面表现不俗。对于希望在 OpenClaw 上尝试国产推理模型的用户来说，这是一个新的选项。
Anthropic Vertex AI 接入：云端 Claude 的企业路径
对于已经在 Google Cloud 平台上运营的团队，这次更新带来了一个非常实用的新接入方式：通过 Google Vertex AI 调用 Claude 模型。
这条路径的特别之处在于，它走的是 GCP（Google Cloud Platform）的认证体系和服务账号管理，支持自动发现可用的 Claude 模型，不需要单独去申请 Anthropic API Key。对于已经把基础设施搭在 Google Cloud 上的企业来说，这意味着权限管理、账单归并、审计日志都能统一在 GCP 的框架下处理，大大降低了运维复杂度。
为什么 MiniMax 在 OpenClaw 社区这么受欢迎
这个问题值得单独展开来讲，因为很多新用户会有疑问：OpenClaw 支持这么多模型，为什么国内用户特别喜欢用 MiniMax？
答案主要来自几个维度。第一是可访问性：MiniMax 的 API 服务部署在国内，不需要境外网络就能直接访问，对于在网络环境受限的场景下部署 OpenClaw 的用户来说，这是一个很实际的优势。第二是工具调用能力：OpenClaw 的核心功能依赖大量的工具调用（Tool Use）——Agent 需要频繁调用文件读写、终端命令、浏览器控制等工具，模型对工具调用格式的遵循度直接影响 Agent 的可靠性。MiniMax M2.5 和 M2.7 在工具调用方面的表现都相当稳定，在社区反馈中的指令遵循率属于一线水平。第三是性价比：相比顶级闭源模型，MiniMax 的定价更有竞争力，让长时间运行的 Agent 任务成本更可控。
M2.7 相比 M2.5，工具调用的稳定性和指令遵循能力又有了明显提升，社区里用 M2.7 跑 OpenClaw 的反馈普遍是"出现不回复的情况少了很多"、"任务完成率更高"。这也是 v2026.3.22 把 MiniMax 默认模型从 M2.5 升到 M2.7 的直接原因。
如果你是国内用户，正在为选择哪个模型接入 OpenClaw 而纠结，可以参考以下简单原则：如果追求稳定性和工具调用质量，MiniMax M2.7 是目前社区验证最充分的选项之一；如果追求极致的推理深度，可以选择带思考功能的模型；如果希望快速处理大量简单任务，快速模式（fast mode）配合 MiniMax M2.7 是一个不错的组合。
这次更新还涵盖了以下几个模型方面的改动，虽然没有上面几个显眼，但同样值得记录：
- xAI 的 Grok 模型目录同步更新到最新版本
- Z.AI 的 GLM 系列更新到 4.5/4.6，包括
glm-5-turbo - Mistral 的定价元数据修正，不再显示"零成本"的误导性信息
- 增加了每个智能体独立的推理配置（per-agent reasoning），允许为不同的 Agent 分别设置思考模式、推理深度、快速模式等参数，并且会自动还原不被当前模型支持的配置项，避免静默失败
每个 Agent 独立推理：per-agent reasoning
这个功能细节上很小，但在实际使用中影响挺大。
过去所有 Agent 共用同一套推理配置，换一个任务场景想改参数，要么改全局配置影响所有 Agent，要么每次手动切换，很不方便。
现在每个 Agent 都可以有自己的 thinking/reasoning/fast 三种模式配置。比如你有一个专门做代码审查的 Agent，可以给它开启深度推理模式；另一个处理日常对话的 Agent，可以开启快速模式降低延迟。两个 Agent 互不干扰，各自跑在最适合自己的推理策略上。同时，如果某个配置在当前模型上不支持，系统会自动还原到该 Agent 的默认配置，不会让 Agent 陷入报错或卡死的状态。
四、三大搜索引擎内置：Exa、Tavily、Firecrawl
过去 OpenClaw 的联网搜索能力比较单一，很多时候需要用户自行配置第三方搜索工具才能使用。v2026.3.22 一次性内置了三个业界主流的专业搜索工具，作为 bundled plugins 直接随系统安装，开箱可用。
Exa 是一个面向 AI 应用场景优化的语义搜索引擎，与传统关键词搜索不同，Exa 擅长理解搜索意图，返回的结果与查询的语义更匹配。在这次更新里，Exa 支持原生的日期范围筛选和内容提取功能，可以精准限定结果的时间范围，非常适合需要获取特定时期信息的 Agent 任务。比如你让 Agent "搜索 2026 年 3 月关于大模型安全研究的最新论文"，Exa 会比普通搜索引擎返回更精准的结果，而不是把相关但时间不对的旧文章也夹杂进来。
Tavily 是一个专门为 AI Agent 设计的搜索 API，提供专用的搜索工具和内容提取工具两个独立接口。搜索工具负责找到相关页面，提取工具负责把页面的核心内容结构化输出，两步分离让 Agent 可以更灵活地控制信息获取的粒度。Tavily 的一个突出特点是它会自动过滤掉低质量的广告页面和无关内容，让 Agent 得到的搜索结果更干净，减少后续处理的噪声。
Firecrawl 则专注于网页抓取和内容解析，能处理 JavaScript 渲染的动态页面，把网页内容转换成 AI 友好的 Markdown 格式。对于那些需要深入读取特定页面、而不仅仅是搜索摘要的场景，Firecrawl 是最合适的工具。比如你需要 Agent 定期监控竞品的产品页面变化，或者把某个文档网站的所有内容批量转换成可检索的格式，Firecrawl 都能很好地胜任。
这三个工具各有侧重，在不同场景下互相补充。Exa 适合语义搜索和时间限定查询，Tavily 适合快速获取高质量的综合搜索结果，Firecrawl 适合对特定页面做深度内容提取。在实际使用中，Agent 会根据任务特点自动选择最合适的工具，当然你也可以在指令里明确指定使用哪个。
此外，核心的 web_fetch 回退逻辑也与这三个工具对齐，确保在主搜索工具不可用时，降级路径的行为是可预期的。
要在对话中使用这些搜索工具，你可以直接用自然语言指令，比如"用 Exa 搜索 2026 年最新的大模型发布情况"，或者"用 Firecrawl 抓取这个页面的主要内容"，Agent 会自动调用对应的工具。
五、安全大修：这次补的都是真漏洞
安全问题在 v2026.3.22 里被摆到了非常高的优先级，一次性修复了十多处安全隐患。对于公网部署的用户，这次更新是"必须升级"而不是"建议升级"。
漏洞一：Windows 上的 SMB 凭证泄露
这是这批补丁里危险程度最高的一个。
攻击者可以通过在 OpenClaw 的媒体内容（图片、文件等）加载路径中注入精心构造的 file:// 路径或 UNC（通用命名约定）路径，触发 Windows 系统自动发起 SMB 认证握手。在这个过程中，Windows 会把当前用户的 NTLM 认证凭证发送出去，而 OpenClaw 还以为自己只是在加载一张普通图片。
这个攻击方式在 CTF（网络安全竞赛）和渗透测试圈子里被称为"SMB 中继攻击"的一个前置步骤，危害相当大，因为被窃取的凭证可以用于进一步的横向渗透。
v2026.3.22 在核心媒体加载逻辑和沙盒附件路径中全面拦截了远程路径，file:// 和 UNC 路径在经过白名单检查之前不再被直接解析。
漏洞二：执行环境沙盒的环境变量注入
这个漏洞利用的是构建工具链中环境变量加载机制的特性。
一些主流构建工具（Maven、SBT、Gradle 等 JVM 系工具，以及 .NET 生态的工具）会在启动时自动读取特定的环境变量并将其作为额外参数传入。如果攻击者能控制这些环境变量的内容，就可以向构建过程注入任意代码，从而逃逸出沙盒的限制，访问宿主机上的文件和进程。
v2026.3.22 直接封锁了 MAVEN_OPTS、SBT_OPTS、GRADLE_OPTS 等 JVM 注入路径，堵住了 GLIBC_TUNABLES 利用通道，并拦截了 .NET 的 DOTNET_ADDITIONAL_DEPS 依赖劫持路径。主流构建工具链的环境变量注入攻击，一次性全部堵上。
漏洞三：Unicode 零宽字符审批伪装
这是一个非常隐蔽的社会工程学漏洞。
Unicode 标准里存在一些"零宽度"字符，比如韩文填充码位（Hangul Filler，U+3164），它们在屏幕上不占任何空间，肉眼看不见，但实际上会出现在字符串里。攻击者可以在命令字符串里插入这些不可见字符，让审批界面显示的内容看起来像一条无害指令，而实际执行的命令却是完全不同的内容。
v2026.3.22 在网关层和 macOS 原生审批界面里全面转义了这类 Unicode 零宽字符，确保审批界面上显示的内容与实际将要执行的内容完全一致。
漏洞四：语音通话 Webhook 的预认证资源耗尽
这个漏洞影响所有开放了语音通话功能的公网部署实例。
旧版本允许未经认证的调用者在身份验证完成之前，触发服务器以 1MB/30 秒的速率缓存请求体。这意味着攻击者只需要不断发送未认证的请求，就能持续消耗服务器的内存和网络带宽，形成拒绝服务（DoS）攻击。
新版把预认证阶段的 body 读取限制压缩到 64KB/5 秒，并限制了单个 IP 地址的并发预认证请求数，从根本上杜绝了这种资源耗尽攻击的可能性。
除了以上四个主要漏洞，这次更新还包括：命令执行审批中对 time 等透明调度封装器的正确识别（防止批准了 time xxx 之后实际绑定的是 time 命令本身而不是 xxx）、以及对 Telegram、Discord 等 Webhook 通道的签名验证强化。
安全更新的整体思路：从被动修补到主动设防
值得一提的是，这次安全更新并不只是"发现一个补一个"的被动修补模式，而是对整个安全边界做了系统性的梳理。
以执行审批这个功能点为例，它是 OpenClaw 一个非常核心的安全机制：当 Agent 准备执行某个终端命令时，如果这个命令不在已批准的白名单里，系统会弹出一个审批提示，要求用户确认。这个机制本来是防止 Agent 误操作或者被恶意指令劫持的第一道防线，但如果审批界面显示的内容本身就被伪造了，整个机制就形同虚设。
Unicode 零宽字符漏洞、透明调度封装器问题，其实都是在攻击这道防线——让操作者在审批时看到的内容与实际执行的内容不一致。这次 OpenClaw 把这类攻击面做了全面清理，确保"你批准的就是实际要执行的"这个基本假设在所有路径下都成立。
对于在公司内网环境部署 OpenClaw、或者开放到公网供团队使用的用户，这次安全更新的价值很难用一两句话说清楚，但简单来说：在这次补丁之前，有几个相对容易利用的漏洞，如果你的 OpenClaw 实例被攻击者触达，后果可能会比较严重。补丁之后，整体防护水平有了质的提升。这是建议"必须更新"而不是"建议更新"的根本原因。
六、浏览器连接方式的底层变革：告别扩展中继，拥抱原生 CDP
旧方式为什么被废弃
之前 OpenClaw 控制浏览器的方式，是通过一个内置的 Chrome 扩展作为"中继站"——OpenClaw 先和这个扩展通信，扩展再去操作浏览器页面。这种方式有几个明显的局限：
- 依赖特定的 Chrome 扩展版本，一旦 Chrome 更新 API，就可能失效
- 中继层增加了通信延迟，自动化任务的响应速度较慢
- 在 Docker 环境、无头浏览器场景下兼容性较差
- 扩展的权限模型限制了某些底层操作的可行性
新方式：直接走 CDP 协议
v2026.3.22 彻底移除了旧的 Chrome 扩展中继路径（包括 driver: "extension" 配置项和 browser.relayBindHost 参数），改为直接通过 Chrome DevTools Protocol（CDP）连接浏览器。
CDP 是 Chromium 内核提供的原生调试协议，所有主流 Chromium 内核浏览器（Chrome、Brave、Edge 等）都原生支持。通过 userDataDir 参数，OpenClaw 可以直接连接到特定用户数据目录下的浏览器实例，不需要任何中间层。
这样做的好处是非常明显的：延迟更低、兼容性更强、维护负担更小。特别是对于喜欢用 Docker 或无头模式跑自动化任务的用户，这个改动是实实在在的体验提升。
官方文档地址：https://docs.openclaw.ai/tools/browser
老用户如何迁移
如果你在升级前用的是旧的扩展中继方式，升级完成后需要运行一条修复命令：
# 迁移浏览器配置到新的 CDP 连接方式
openclaw doctor --fix这条命令会自动检测你的配置文件，把旧的扩展中继相关配置替换成新的 CDP 连接配置。如果你想提前了解 doctor 会做什么，可以先运行：
# 只检查问题，不做任何修改
openclaw doctordoctor 命令的文档：https://docs.openclaw.ai/gateway/doctor
七、Agent 引擎升级：压缩更聪明，超时更宽松，旁白更顺手
默认超时从 600 秒拉长到 48 小时
这是这次更新里对长任务用户影响最直接的变化。
过去 ACP（Agent Control Protocol）会话有 600 秒（10 分钟）的默认超时限制，很多需要较长时间的任务会在中途被系统强制终止。用户不得不额外配置超时参数，或者把任务拆成多个小段来规避这个问题。
v2026.3.22 把默认超时时间直接拉到了 48 小时。对于长时间运行的研究任务、大型代码库分析、批量文件处理这类场景，终于不需要再担心任务被掐断了。
长对话压缩机制的迭代
OpenClaw 有一套"Compaction"（压缩）机制，用于在对话历史超出模型上下文窗口时，自动对历史消息进行摘要压缩，保留关键信息，丢弃冗余内容，让 Agent 能够处理比上下文窗口更长的任务。
这次对压缩机制做了几处重要的修复：
- 自动延长压缩截止时间：大型会话在压缩过程中需要较多时间，旧版本偶尔会出现压缩进行到一半被超时终止的情况，导致历史记录损坏。新版在压缩过程中会自动延长运行截止时间，确保压缩能够完整完成
- 修复孤立的 tool_result 块：压缩完成后，有时会出现
tool_result消息块失去配对的tool_use的情况（术语叫"孤立的 tool_result"），这会导致 Anthropic API 拒绝后续请求。新版会在压缩后自动修复这类结构性问题 - 修复空会话的无限循环：过去空会话触发压缩时，有概率进入死循环，CPU 占用飙升但没有任何实际进展。这个 bug 在新版中被修复
/btw 旁白命令：不打断主流程的即兴提问
这是一个小功能，但用起来相当顺手。
假设你的 Agent 正在执行一个复杂的多步骤任务，任务到一半时你突然想问它一个不相关的问题，比如"刚才那段代码里的这个变量是什么意思"或者"帮我算一下这个数学题"。
过去你只有两个选择：要么打断当前任务开一个新会话，要么等任务完成后再问。前者会打断 Agent 的工作流，后者又可能等很长时间。
现在有了 /btw 命令，你可以在任何时候插入一个"旁白问题"，Agent 会快速给你一个答案，但这个答案不会进入当前的会话上下文，不影响正在进行的主任务。就像开会时侧过身低声问同事一句题外话，问完继续开会，完全不打断会议的节奏。
/btw 帮我解释一下 TCP 三次握手是什么意思这条命令会在当前会话里弹出一个可关闭的快速回答卡片，同时主任务继续在后台运行，互不干扰。
原生 PDF 支持：文档处理能力的重要补充
除了上面提到的这些 Agent 引擎改进，v2026.3.22 还新增了一个文档工作场景下非常实用的功能：原生 PDF 处理支持。
之前 OpenClaw 处理 PDF 文件需要借助第三方技能包，配置相对繁琐。新版直接在核心层提供了 PDF 处理能力，支持配置最大页数限制和文件大小限制，在文本提取失败时还有备用解析路径。
这对需要处理大量文档的用户来说意义重大——比如让 Agent 读取合同文件并提取关键条款、分析研究报告生成摘要、从财务报告中提取数据生成表格，这些任务现在都可以直接在 OpenClaw 里无缝完成，不再需要先把 PDF 转成其他格式再处理。
多渠道统一发送适配器
这次更新还把多个平台的消息发送逻辑统一到了一个 sendPayload 适配器下。过去 Discord、Slack、WhatsApp、Zalo、Telegram 各自有独立的发送逻辑，有时候同一个 Agent 任务的结果消息，在不同平台上的呈现方式会有细微差异。统一适配器之后，消息格式的一致性和可靠性都有了保障，对于同时在多个平台上使用 OpenClaw 的用户来说，体验会更统一。
高级密钥管理（Secrets Management）
v2026.3.22 还引入了一套生产级别的密钥管理机制，支持 SecretRef（密钥引用），最多可以管理 64 个凭证目标。
这个功能解决的是一个实际问题：当你的 Agent 需要连接多个外部服务（各种 API、数据库、SaaS 工具）时，这些服务的 API Key 需要安全存储和按需调用。旧方式通常是直接把 Key 写在配置文件里，一旦配置文件被意外泄露，所有 Key 全部暴露。新的 SecretRef 机制让 Agent 只能通过引用名称来访问密钥，密钥的实际值不会出现在日志、配置快照或者任何可以被 Agent 直接读取的地方，从根本上降低了凭证泄露的风险。
Android 深色模式全面覆盖
Android 端这次新增了跟随系统的深色模式适配，覆盖范围从引导页（Onboarding）一直到聊天页面再到语音通话页面，做到了全链路统一。过去打开 OpenClaw Android 版切换到深色系统后，部分页面还是白底，非常割裂，这个问题终于被修掉了。
Control UI 圆角滑块
这是个很小的细节，但用过的人会觉得挺有意思。Control UI（控制面板）新增了一个"圆角程度"滑块，用户可以自定义界面元素的圆角大小，从完全方正到全圆形卡片，可以按照自己的审美随意调节。听起来像是在卷颜值，但对于长期盯着这个界面工作的用户来说，能按照自己的喜好定制视觉风格，体验上是有实际差别的。
Telegram：DM 话题自动命名
这对重度使用 Telegram 与 OpenClaw 交互的用户来说是个大改进。
过去每条 DM（私信）对话在论坛话题模式下，都会有一个系统生成的无意义 ID 作为话题标题，随着时间积累，你的 Telegram 里会堆满一堆叫"Thread_12345"这种名字的话题，根本不知道哪个对应什么任务。
新版里，第一条消息进来之后，系统会用 LLM 分析消息内容，自动生成一个有意义
