OpenClaw 2026.3.22-beta.1 升级解析：插件 SDK、安全加固与 Agent 引擎变化

OpenClaw 可以理解为一个面向开发和自动化任务的人工智能（AI）智能体平台：模型负责理解和推理，插件负责扩展能力，沙盒负责隔离执行环境，消息平台和浏览器集成负责把能力接到真实工作流里。

2026.3.22-beta.1 这个版本的变化不只是默认模型更新。影响更大的部分集中在三条线上：

• 插件系统从旧扩展接口切换到新的插件 SDK（Software Development Kit，软件开发工具包）。
• 安全边界补上了 Windows 路径、环境变量注入、Unicode 审批伪装、Webhook 预认证资源消耗等风险点。
• Agent 引擎、沙盒、消息平台和浏览器集成开始向更长期运行、更可控的生产形态靠拢。

如果正在维护 OpenClaw 插件，或者把 OpenClaw 暴露在公网环境里，这个版本需要认真评估。

OpenClaw 的整体结构

OpenClaw 的核心不是单个聊天界面，而是一套把大语言模型（LLM，Large Language Model）、工具调用、插件生态、沙盒执行和多端交互连起来的智能体运行框架。

可以把它拆成几层：

flowchart LR
    U[用户入口<br/>Web / Android / Telegram / 飞书] --> G[Gateway / Control UI]
    G --> A[Agent 引擎]
    A --> M[模型提供商<br/>OpenAI / MiniMax / Anthropic Vertex]
    A --> P[插件运行时]
    P --> S[Skills 技能]
    C[ClawHub 插件市场] --> P
    N[npm 包生态] --> P
    A --> X[沙盒管理器]
    X --> O[OpenShell 后端]
    X --> SSH[SSH 后端]
    G --> Sec[安全检查<br/>路径 / 审批 / Webhook / 环境变量]

这张结构图能解释为什么 3.22 的升级会同时影响插件、安全、模型、沙盒和客户端体验。OpenClaw 只要允许 Agent 执行工具，就必须处理三个问题：

1. 工具从哪里来，是否可信。
2. 工具在什么环境里运行，能不能越界。
3. Agent 长时间运行时，历史上下文、工具结果和超时策略是否稳定。

3.22-beta.1 的主要变化基本都围绕这三个问题展开。

升级点总览

插件系统：从旧扩展 API 切到新插件 SDK

3.22 最容易造成兼容性问题的变化，是旧扩展 API（Application Programming Interface，应用程序编程接口）被移除。

旧路径：

openclaw/extension-api

新路径：

openclaw/plugin-sdk/*

这不是简单的包名调整，而是插件运行方式的一次重新整理。旧接口没有保留兼容层，意味着还在引用 openclaw/extension-api 的第三方插件会直接受到影响。

迁移时至少要检查这些位置：

# 在插件项目中查找旧扩展 API 引用
grep -R "openclaw/extension-api" .

# 查找旧图像生成技能包装器或硬编码模型路径
grep -R "nano-banana-pro\|imageGeneration" .

旧的 nano-banana-pro 图像生成技能包装器也被移除，图像生成模型统一走 Agent 默认配置路径：

agents:
  defaults:
    imageGenerationModel: gpt-5.4

这个改动的好处是模型选择不再散落在不同技能包装器里，而是收敛到统一配置。代价也很明确：依赖旧包装器的插件需要改造。

插件安装链路变了

过去执行插件安装时，OpenClaw 会直接从 npm（Node.js 包管理生态）拉取包。3.22 之后，ClawHub 成为优先插件源，只有 ClawHub 找不到对应插件时才回退到 npm。

flowchart TD
    A[执行 openclaw plugins install 插件名] --> B{ClawHub 是否存在该插件}
    B -->|存在| C[从 ClawHub 获取插件元数据和包信息]
    B -->|不存在| D[回退到 npm 查询]
    C --> E[安装插件]
    D --> E
    E --> F[发现 Skills]
    F --> G[注册到 OpenClaw 技能体系]
    H[Claude / Codex / Cursor 插件包] --> F

这个链路变化解决的是插件供应链问题。

npm 是通用包生态，发布门槛低，适合分发大量 JavaScript 包，但它不是专门为 OpenClaw 插件治理设计的。ClawHub 作为首选源后，OpenClaw 可以把插件元数据、审核策略、兼容版本和技能声明收敛到更可控的地方。

但这也带来一个实际问题：内部插件、私有插件、还没提交到 ClawHub 的插件，需要确认是否仍然能通过 npm 回退安装，或者改成组织内部的明确分发流程。

外部插件生态开始被纳入

3.22 还新增了对 Claude、Codex、Cursor 三类开发工具插件包的发现与安装支持。关键点不是“能下载外部包”，而是 OpenClaw 可以把这些外部包里的 Skills 自动映射到自己的技能体系。

这意味着 OpenClaw 的插件模型不再只服务于自身生态，而是开始吸收其他智能编程工具里的能力。对插件开发者来说，技能声明、权限边界和输入输出结构会变得更重要，因为同一个 Skill 可能运行在不同工具框架中。

安全加固：补的是智能体执行链路里的关键风险

OpenClaw 允许 Agent 读取文件、加载媒体、调用构建工具、接收 Webhook、展示审批界面。只要这些能力进入真实工作流，安全问题就不再是“模型有没有越狱”这么简单，而是传统操作系统、网络协议、依赖注入和界面欺骗会一起出现。

3.22 修复的几个风险点都比较典型。

Windows SMB 凭证泄露

在 Windows 上，file:// 远程路径或 UNC（Universal Naming Convention，Windows 网络路径格式）路径可能触发 SMB（Server Message Block，服务器消息块协议）认证。

攻击流程大致是这样：

flowchart LR
    A[攻击者构造远程媒体路径<br/>file://host/share/a.png<br/>或 \\host\share\a.png] --> B[OpenClaw 媒体加载逻辑]
    B --> C[Windows 尝试访问远程共享]
    C --> D[触发 SMB 认证握手]
    D --> E[攻击者服务器获得认证握手信息]

问题的本质在于：用户或 Agent 看起来只是在“加载图片”，但 Windows 底层可能会尝试访问远程 SMB 共享，从而暴露认证握手信息。

3.22 在核心媒体加载和沙盒附件路径中拦截这类远程路径。对 Windows 桌面环境、带附件处理能力的 Agent、会加载外部媒体的工作流来说，这是必须补上的边界。

构建工具环境变量注入

很多构建工具会读取环境变量来改变运行参数。攻击者如果能影响执行环境，就可能借助这些变量注入额外参数或加载恶意依赖。

3.22 封锁的变量包括：

智能体平台里经常会出现“让 Agent 帮我构建项目、跑测试、执行脚本”的场景。只要执行环境继承了不可信变量，构建工具就可能变成攻击入口。

3.22 的处理方式是对这些高危环境变量做封锁和清理，减少沙盒逃逸、依赖劫持和隐式参数注入的机会。

Unicode 不可见字符审批伪装

智能体执行命令前，经常需要用户审批。审批界面的安全性取决于一个前提：用户看到的命令必须是真实命令。

Unicode 里存在一些不可见或显示效果特殊的字符，例如 Hangul Filler。攻击者可以把这类字符插进命令文本，使审批界面显示出来的内容和实际执行内容不一致。

3.22 在网关和 macOS 原生审批界面里对这类字符做了转义处理。转义后的字符会被显式展示，用户不容易被“看不见的命令片段”误导。

一个安全审批界面要满足两点：

不可见字符转义就是为了保证这两个要求。

语音通话 Webhook 预认证资源限制

Webhook（HTTP 回调）常见问题是：请求还没完成认证，服务端已经读了大量 body，或者长时间占用连接。

旧逻辑允许未认证调用者使用较大的读取窗口：约 1MB / 30 秒。攻击者可以批量发起请求，让服务端在认证前消耗内存、连接和读取时间。

3.22 把预认证读取限制压到：

body 最大 64KB
读取时间最多 5 秒
限制单 IP 并发预认证请求数

这个改动主要防资源消耗攻击。对于公网部署，尤其是接入语音通话或机器人回调的场景，预认证阶段的限制非常关键，因为攻击者不需要有效账号就能打到这层接口。

模型生态：默认模型统一到 GPT-5.4

3.22 把默认 OpenAI 模型升级到 GPT-5.4，并覆盖引导页、聊天页和语音页。这个细节很重要：默认模型如果只在聊天页更新，其他入口仍然走旧模型，就会造成行为不一致。

模型层面的变化可以按提供商来看：

对团队部署来说，模型生态扩张带来的价值不是“可选项变多”这么简单，而是可以按任务类型做路由：

OpenClaw 把默认模型、语音入口、聊天入口和 Agent 配置收敛在一起后，模型切换的管理成本会更低。

沙盒系统：从单一执行后端走向可插拔后端

智能体执行工具时，沙盒是安全边界。过去很多工具平台默认围绕 Docker 或类似容器方案设计，但容器并不适合所有环境：有些机器不能启 Docker，有些任务需要连远程主机，有些场景只需要轻量 shell 隔离。

3.22 新增了可插拔沙盒后端，首批支持 OpenShell 和 SSH。

flowchart TD
    A[Agent 需要执行任务] --> B[沙盒管理器]
    B --> C{选择后端}
    C --> D[OpenShell<br/>本地受控执行]
    C --> E[SSH<br/>远程主机执行]
    D --> F[返回 stdout / stderr / exit code]
    E --> F
    F --> A

可插拔后端带来的变化是：Agent 引擎不需要把“如何执行”写死在某一种沙盒方案里。调度层只关心任务输入、输出、权限和生命周期，具体执行可以交给不同后端。

不过后端变多之后，运维侧要额外关注这些问题：

沙盒后端越灵活，配置错误的空间也越大。升级后不能只看功能是否能跑，还要看每个后端的默认权限是否符合生产要求。

Agent 引擎：长对话压缩和长任务执行更稳定

Agent 平台运行一段时间后，最常见的稳定性问题有两个：

1. 对话历史太长，超过模型上下文或压缩失败。
2. 任务执行时间太长，被默认超时中断。

3.22 对这两点都做了调整。

长对话压缩机制更稳

长对话压缩机制通常叫 Compaction。它的作用是把冗长历史压缩成更短的摘要，让 Agent 能继续保留关键上下文。

一次正常的压缩流程应该是这样：

sequenceDiagram
    participant U as 用户
    participant A as Agent 引擎
    participant C as Compaction 压缩器
    participant M as 模型

    U->>A: 持续多轮对话和工具调用
    A->>A: 检测上下文压力
    A->>C: 请求压缩历史
    C->>C: 延长压缩截止时间
    C->>C: 修复孤立 tool_result 块
    C-->>A: 返回压缩后的上下文
    A->>M: 使用压缩上下文继续请求
    M-->>A: 返回后续结果

这里有两个关键修复。

一个是压缩过程中自动延长运行截止时间。大型会话压缩本身可能很耗时，如果还按普通任务的短超时处理，压缩很容易做到一半被杀掉，导致会话无法继续。

另一个是修复孤立的 tool_result 块。很多模型协议要求工具结果必须和前面的工具调用严格对应。如果历史里残留了没有对应调用的 tool_result，后续请求可能会被 Anthropic 等模型接口拒绝。3.22 会在压缩后清理这类不一致状态。

空会话压缩死循环也被修复。这个问题看似边缘，但在自动化系统里很常见：只要某个状态机没有正确处理空输入，就可能反复触发同一个动作，浪费资源甚至卡住队列。

默认 Agent 超时从 600 秒延长到 48 小时

旧默认超时是 600 秒，也就是 10 分钟。对简单聊天足够，但对长时间编码、批量迁移、复杂测试、远程执行任务来说不够。

3.22 把默认 Agent 超时拉到 48 小时。这个变化对 ACP（Agent Client Protocol，智能体客户端协议）长会话尤其重要，因为这类任务可能需要持续运行、等待外部工具返回、反复调用子智能体。

超时变长不是单纯“放宽限制”。生产环境还要配套这些限制：

默认超时延长后，长任务不容易被误杀，但失控任务也会活得更久。资源治理要跟上。

/btw：旁路问题不污染主上下文

新命令 /btw 用来在当前会话里插入一个“旁路问题”。它会让 AI 快速回答一个临时问题，但不把这个问题混入主任务上下文。

示例：

/btw 这个错误码 429 一般表示什么？

适合的场景是：Agent 正在执行代码迁移，你临时想问一个概念、错误码、命令参数含义，但不希望它改变正在进行的任务目标。

这种设计解决的是上下文污染问题。主任务上下文越长，越容易被临时问题带偏。把临时问答放到旁路里，可以减少 Agent 在后续步骤中误把题外话当成任务要求的概率。

多端交互：从聊天窗口走向工作流入口

3.22 的 UI 和消息平台更新比较分散，但共同方向很清楚：让 OpenClaw 更容易嵌入真实工作流。

其中，飞书审批卡片和 Telegram 话题命名更偏工作流能力。Agent 不只是回答问题，还要在群聊、审批、任务卡片、浏览器环境中执行动作。界面越结构化，误操作和上下文丢失的概率越低。

浏览器集成改为通过 userDataDir 连接 Chromium 内核浏览器，也更贴近自动化场景。userDataDir 保存浏览器用户数据，例如登录态、Cookie、扩展配置。直接连接 Brave、Edge 等浏览器后，自动化任务不必强依赖旧的 Chrome 扩展中继路径。

升级前需要重点检查什么

3.22-beta.1 带有明显的破坏性变更。升级策略应该按角色区分。

一个实用的升级顺序可以这样安排：

flowchart TD
    A[拉取 2026.3.22-beta.1 到测试环境] --> B[检查插件兼容性]
    B --> C{是否存在旧 extension-api}
    C -->|存在| D[迁移到 plugin-sdk]
    C -->|不存在| E[验证插件安装源]
    D --> E
    E --> F[验证安全边界<br/>路径 / 环境变量 / Webhook / 审批]
    F --> G[验证模型与 Agent 长任务]
    G --> H[验证沙盒后端和浏览器连接]
    H --> I[灰度到生产环境]

如果只从功能角度看，GPT-5.4、MiniMax M2.7、飞书卡片、Telegram 话题命名更容易被注意到；但从工程角度看，插件 SDK 重构、安全补丁、长任务超时和沙盒后端才是这次升级的核心。

适合尽快升级的情况：

需要谨慎灰度的情况：

发布页地址：

https://github.com/openclaw/openclaw/releases/tag/v2026.3.22-beta.1

3.22-beta.1 的重点不是“功能更多”，而是 OpenClaw 开始把插件供应链、执行安全、长任务稳定性和多端工作流放到同一个工程框架里处理。对个人尝鲜用户来说，这是一次大版本更新；对团队部署来说，这是一次需要认真做兼容性测试和安全回归的基础设施升级。