两层架构：系统工具 + Skill

整个 OpenClaw 可以看成两层积木。

第一层：系统自带工具（OpenClaw Core）

这是出厂自带的底层能力，包括：exec 执行命令行、read/write/edit 文件操作、browser 浏览器控制、message 发消息、canvas 画图/SVG、tts 文字转语音。

这相当于手机的 GPS 模块、摄像头、网络模块——不管你装什么 App，这些基础能力一直在。

第二层：Skill（技能包）

这是场景化的能力封装，把底层工具组合成特定场景的解决方案：

qclaw-env → exec 的高级封装，把安装工具做成一条流水线
xbrowser → browser 的高级封装，让 AI 能自动化操作网页
wechat-cloudrun-publisher → message 的高级封装，帮你推公众号
podcast → tts + exec 的封装，生成播客音频

类比：系统工具 = 手机的基础模块，Skill = 滴滴打车 App（封装地图+定位+支付 = 出行场景）。你的需求越复杂，需要的 Skill 就越多。

渐进式加载：三层架构

AI 的上下文窗口是有限资源，不能把所有 Skill 文档都塞进去。

OpenClaw 的解法是三层渐进加载：

第一层：元数据层（启动时加载）

只读 Skill 的名称 + 描述，用于语义匹配。用户说「装 ffmpeg」，系统扫描所有 Skill 描述，找到 qclaw-env。这一层只有几百字节。

第二层：指令层（匹配成功后加载）

加载 SKILL.md 完整内容。这里写死了执行流程：「先检测平台 → 再判断包管理器 → 最后执行安装」。这一层通常几 KB。

第三层：资源层（执行时才加载）

references/（详细手册）和 scripts/（复杂脚本）。100 行以上的脚本才放这里，按需加载。这一层可能几十 KB。

为什么这样设计？

传统方式是股脑全塞进去，结果是上下文窗口爆炸，AI 跑不动。三层渐进 = 按需分配内存，AI 每次只加载当前需要的部分。

简单说：不是把所有 Skill 都塞给 AI，而是让 AI 需要时再拿。

exec 工具：AI 的手

exec = Execute，AI 执行 shell 命令的工具。

这是今天的主角。OpenClaw 所有需要操作机器的能力，都靠 exec 来完成。

基本用法：

exec(“uname -s”) → 返回 “Darwin”（检测平台）
exec(“brew install ffmpeg”) → 执行安装命令
exec(“ls -la”) → 读取目录结构

核心参数：

background=true → 后台执行，不阻塞（飞机会用到）
timeout=120 → 超时自动 kill，防止卡死
pty=true → 交互式输入（填表单场景）
elevated=true → 申请管理员权限

exec 和安全机制的关系：

Skill 的 skill-config.yaml 定义了权限模式：

ask → 每次执行前问你确认（默认）
allow → 自动执行，不问
deny → 完全禁止

所以 exec 不是想跑就跑，它在权限管控之下。危险操作会弹窗让你确认。

完整执行链路：AI 怎么调动 Skill + exec

以「帮用户安装 ffmpeg」为例，看 AI 怎么一步步调度 Skill 和 exec：

步骤1：用户说「帮我装个 ffmpeg」

步骤2：系统语义匹配 → 找到 qclaw-env（描述里写了「安装 CLI 工具」）

步骤3：加载 qclaw-env/SKILL.md → AI 读懂完整流程

步骤4：AI 执行 SKILL.md 的步骤1：
 调用 exec(“uname -s && uname -m”)
 系统返回 “Darwin arm64”

步骤5：AI 继续执行步骤2：
 判断：Darwin 平台，用 brew 安装
 调用 exec(“brew install ffmpeg”)
 系统执行，返回安装结果

步骤6：AI 执行步骤3：
 调用 exec(“ffmpeg -version”)
 验证安装成功

关键理解：

SKILL.md = 剧本（定义流程）
exec = 工具（执行命令）
AI = 演员（读懂剧本 + 调用工具 + 根据结果继续下一步）

三层各司其职，AI 不是在乱跑命令，而是严格按剧本执行。

这就是为什么同一个 Skill 在 macOS 和 Windows 上都能跑——SKILL.md 里写了跨平台的判断逻辑，AI 会根据检测到的平台走对应分支。用户只说「装 ffmpeg」，不用管 brew 还是 scoop。

安全隔离：AI 的缰绳

exec 能跑命令，听起来很危险？系统有三层保护：

第一层：权限模式

skill-config.yaml 里定义了三种模式：

ask → 执行前弹窗问你（默认，推荐）
allow → 自动执行，不打扰
deny → 完全禁止

危险操作（如删除文件、修改系统配置）会触发 ask 模式。

第二层：沙箱隔离

每个 Skill 运行在独立进程中，破坏力有限。Skill A 崩了不会影响 Skill B。

第三层：Hooks 钩子

执行前/后触发自定义检查。比如可以写一个钩子：「如果 exec 的命令包含 rm -rf，直接拒绝」。

用户的操作指引规范：

如果 AI 判断某个任务「无法自动完成」，它必须给用户完整的操作步骤（编号+代码块+URL），而不是乱跑命令。这条规范写在 qclaw-env 的 SKILL.md 里：「必须输出可直接操作的完整指引」。

安全不是靠「不让 AI 做事」来保证的，而是靠「让 AI 按剧本做事」。

   第二层：沙箱隔离    Skill A  独立进程    Skill B  独立进程

   第三层：Hooks 钩子  执行前/后触发自定义检查 → 例如：检测到 rm -rf 命令，直接拒绝

自己开发一个 Skill

假设你要做一个「备份 MySQL 数据库」的 Skill，目录结构如下：

SKILL.md（必须）→ 核心指令
references/mysqldump.md（可选）→ 详细手册
scripts/backup.sh（可选）→ 复杂脚本

SKILL.md 写法：

触发条件：用户说「备份数据库」

执行步骤：

步骤1：检测环境 → exec(“which mysql”)
 → 如果没找到，返回「需要先安装 MySQL」

步骤2：执行备份 → exec(“mysqldump -u root mydb > backup.sql”)

步骤3：压缩 → exec(“tar -czf backup.tar.gz backup.sql”)

步骤4：验证 → read(“backup.tar.gz”)
 → 确认文件存在且有内容

关键发现：

整个 Skill 开发不需要写一行 Python/JS，只写 Markdown 格式的 SKILL.md 即可。

Skill 本质上是一个「场景化剧本」——你告诉 AI 什么场景做什么，AI 用内置工具去执行。

上传到 SkillHub 后，其他用户说「备份数据库」，系统就会匹配到你的 Skill，按剧本执行。

这就是 OpenClaw 的扩展机制：不需要改底层代码，只需要写剧本。

总结：一张图记住全貌

整个 OpenClaw 架构可以用一张图总结：（见文内 SVG 图示）

三层各司其职：

系统工具 = 基础能力（出厂自带，AI 直接调用）
Skill = 场景化封装（可扩展，把工具组合成能力）
AI = 读懂剧本 + 调用工具 + 智能决策

设计的核心哲学：「恰好而非更多」——AI 的上下文窗口是有限资源，不能把所有 Skill 内容都塞进去。三层渐进加载实现了按需分配，让 AI 在任何时候都只加载当前需要的部分。

理解了 Skill 系统，你就能理解为什么有些 AI Agent 只能聊天，有些却能帮你装软件、自动化网页操作、管理文件——区别不在于 AI 模型本身，而在于它们背后有没有好的 Skill 体系支撑。

工具箱就在那里，怎么用，全看你写什么剧本。