OpenClaw Skills: 从原理到提效实践

目标：理解Skill的核心原理，学会利用Skill来提升工作效率；

如果你已经在使用OpenClaw服务，你可能已经觉得它很强了——— 可以写代码，回答问题，分析文档，好像什么都能做。

但用过一段时间后你就会发现，总有那么一些地方差一点点：有些事情它做的不够好，做的好的想法留不下来，团队之间没法共享经验，Skill 就是用来解决这些问题的；

但Skill不是一个你”听说过就行”的概念。要真正用好它，你需要理解它的工作原理，知道去哪里找，那里安装，怎么用。

# 结构

• 为什么需要Skills ——— 从OpenClaw裸用的天花板说起，理解Skill解决了什么问题
• Skills核心概念 ——— 深入理解Skill的组成结构，工作原理和技术架构
• 热门Skill推荐和安装 ——— 掌握Skill的查找渠道、安装方法，附带技术人必装清单
• 实操演示 ——— 以 高德地图 实操为例，完整跑通从安装到使用的全流程

第一章 为什么OpenClaw 需要Skills

如果你已经在使用OpenClaw服务，你可能已经觉得它很强了——— 可以写代码，回答问题，分析文档，好像什么都能做。那么我们为什么还需要Skills呢？我们从最基本的使用方式说起；

1.没有Skills的OpenClaw是怎么用的

没有Skills的OpenClaw就像是一个通用型的Ai助手，你跟它聊什么都行，写代码，改Bug，写文档，做分析，来者不拒，确实还都能给你一个不错的回复；

但仅此而已，它只能用自己的通用能力来应付你的需求，没有专业的方法可以遵循，没有外部工具可以调用，也没有你过去积累的经验可以复用，每一次对话，都是从零开始。

用久了你会发现，总有一些地方——差那么一点。这个”差一点”，可以总结为三个天花板。

2.OpenClaw裸用的三个天花板

天花板一：有些事它不专业

没有Skills的OpenClaw，就像一个 很聪明的实习生。他脑子好使，学习能力强，你交代什么他都能听懂。但问题是——没人教过他具体怎么干活。

举个例子。你让他帮你做代码审查，他能给你一些通用的建议：”这个变量名不够语义化”、”这里可以加个空值检查”。但他不知道你们团队的编码规范是什么，不知道你们项目的架构约定，也不知道你们最容易踩的坑在哪里。

他给的意见是正确的，但不够 专业、不够贴合你的实际情况。

再比如搜索。OpenClaw本身有搜索能力，但原生搜索返回的是大量原始网页内容，AI需要自己去筛选和理解，既慢又费token。装上TavilyWebSearch之后，搜索结果是专门为AI优化过的——结构化、已提炼、直接可用，效率高了很多。

还有前端开发。你让OpenClaw帮你生成一个网页，它写的代码能跑——但打开一看，八成是千篇一律的”AI风格”：圆角卡片、Inter字体、紫色渐变背景，每次做出来长得都差不多。

这不是编码能力的问题，而是它缺乏设计的专业方法论。装上专门的前端设计Skill之后，AI会按照专业设计师的工作流来做——先规划布局，再确定配色方案和字体搭配，然后设计交互动效，最后才写代码。同样是”帮我做个页面”，产出质量天差地别。

这就是第一个天花板：没有经过”培训”的 OpenClaw，有些事做不了，有些事做得不够专业。

天花板二：好的用法留不住

你可能有过这样的经历——花了半小时，在一轮对话里反复调整，终于让OpenClaw按你想要的方式输出了一份代码审查报告。格式工整，检查点全面，你很满意。然后你关掉了对话。

第二天，你想再做一次同样的事。打开新对话，凭记忆把昨天的要求重新描述了一遍。结果发现——效果没昨天好了。你漏掉了几个约束条件，措辞也跟昨天不太一样，输出的质量打了折扣。

问题出在哪里？ 你的”好用法”留在了你的脑子里，而不是留在了系统里。每次关掉对话，那些你精心调教出来的流程、格式、约束条件，就全部清零了。下一次，你又得从头来过。

天花板三：经验没法共享

这个问题在天花板二的基础上更进一步。你花了时间摸索出一套用OpenClaw做代码审查的最佳实践，效果很好。但你的同事想用，怎么办？你可以把你的Prompt复制给他。

但问题是：你的Prompt里隐含了很多你没写出来的上下文——你脑子里知道这段Prompt的前因后果、适用场景和注意事项，你的同事不知道。他拿过去一用，效果差了一大截，还以为是OpenClaw不行。结果就是： 团队里每个人都在重复摸索，重复踩坑。一个人积累的经验，没法变成团队的能力。

小结

让我们回顾一下这三个天花板：

天花板	核心问题
有些事做不好	没经过”培训”，缺乏专业能力和特定工具
好的用法留不住	经验留在人的脑子里，关掉对话就清零
经验没法共享	个人经验无法沉淀为团队能力

这三个天花板，本质上指向同一个问题：OpenClaw很聪明，但它需要有”专业技能培训”——需要有人把专业知识、工作流程、工具能力系统化地交给它。

这个”培训”，就是 Skill。

3. Skill 是什么：给 OpenClaw 做专业技能培训

一个聪明的实习生，如果你给他做一次专项技能培训，会发生什么：

• 他知道了该按什么流程来做事（不再瞎摸索）
• 他学会了使用专业的工具（不再只靠蛮力）
• 他手边有了参考资料可以随时查阅（不再凭感觉）

给OpenClaw装一个Skill，就是给它做了一次这样的专业技能培训。

培训完之后，它既掌握了方法流程，又具备了动手执行的能力。同样是做代码审查，没装 Skill 的时候它只能给你泛泛而谈的建议；装了 Skill 之后，它能按照你定义好的规范、流程和检查清单来执行，输出稳定、专业、可重复。

而且这个”培训成果”是持久的——不会因为你关掉对话就消失。下次再需要做同样的事情，OpenClaw 自动加载对应的 Skill，不需要你重新交代一遍。你的同事也可以装上同一个 Skill，获得同样的能力。

三个天花板，一次解决。

第二章 Skill核心概念

我们讲了三个天花板：有些事做不好、好用法留不住、经验没法共享。而 Skill 就是解决这些问题的方案——给 OpenClaw 做专业技能培训。

但我们还没有回答一个关键问题：Skill到底长什么样？

我们就来拆开一个 Skill，看看它的内部结构。你会发现，它比你想象的简单得多。

2.1Skills：具有专业知识的工作流

很多人第一次听到”Skill”，会以为它是一段很复杂的代码，或者是某种需要编译安装的插件。其实没有那么复杂。

摘一段官方的skills定义（https://agentskills.io/home）

Agent Skills are a lightweight, open format for extending AI agent capabilities with specialized knowledge and workflows.

Agent Skills 是一种轻量级、开放的格式规范，旨在通过注入专业知识与工作流，全面拓展 AI 智能体的能力边界。

——from  https://agentskills.io

一个 Skill，对应一个由指令(instructions)、脚本(scripts)、资源(resources) 组织好的文件夹。

注：如果是本地部署的 OpenClaw，可以直接去安装根目录下的 workspace/skills 中查看具体的 Skill 文件夹详情，如下图所示：

• 本地安装的 Skills 示例：

• self-improving-agent 这个 Skill 的文件夹详情：

文件夹里放了一组材料，告诉 AI “遇到某类任务该怎么做”。

打个比方。你入职一家新公司，第一天 leader 给你发了一个文件夹，叫”代码审查指南”。打开一看，里面有三样东西：

• 一份操作手册：写了代码审查的步骤流程、检查要点、输出格式
• 几个自动化脚本：比如一键拉取 PR 差异、自动跑静态分析
• 一些参考资料：团队的编码规范文档、常见问题清单、历史审查报告模板

有了这个文件夹，你就不用从零摸索了——照着手册干活，用脚本提效，查资料补知识。

Skill给AI的，就是这么一个”工作指南文件夹”。

对应到技术实现，一个 Skill 的目录结构示例是这样的：

jenkins-deploy-task/
├── references                       # 参考资料
│   ├── env-config.md                # 环境变量
│   └── usage-examples.md            # Jenkins部署任务使用示例
├── scripts                          # 自动化脚本
│   ├── jenkins-confirm-deploy.sh    # 确认之后可发布
│   ├── jenkins-quick-deploy.sh      # 快速发布脚本
│   ├── jenkins-task-resolver.sh     # 任务名称解析 简写转换为完整的Job名称
│   └── test-build.sh                # 简单的Jenkins构建测试脚本
└── SKILL.md                         # 操作手册：任务流程和指令

三大组成部分，各司其职：

组成部分	对应文件	作用
指令	SKILL.md	核心文件。描述任务流程、执行步骤、输出要求。这是 Skill 的”大脑”
脚本	scripts	可执行的代码，如Pythony/Shell脚本等。让 AI 不只是”说”，还能”做”——跑数据处理、调用 API、生成文件
资源	references/，assets/	参考材料。编码规范、模板文件、领域知识文档等，AI 需要时随时查阅

其中，只有SKILL.md是必须的。scripts/和references/是可选的——最简单的 Skill 可以只有一个SKILL.md文件，就是一个文件夹里放一个 Markdown 文档，就这么简单。

2.2 SKILL.md 文件剖析

SKILL.md是一个 Skill 的核心——所有指令都写在这里。如果说一个 Skill 是一个”工作指南文件夹”，那SKILL.md就是里面那份”操作手册”。

它的格式非常直接：上面是 YAML 元数据，下面是 Markdown 指令，用 — 分割。

元数据部分（YAML frontmatter）

先看上半部分。每个 SKILL.md 文件的开头，都有一段用 — 包裹的 YAML 格式元数据：

---
name: jenkins-deploy-task
description: Jenkins任务自动化部署技能，支持快速发布和无确认发布两种模式。当用户需要部署Jenkins任务时使用，特别是针对586视图和Alph视图的快速发布，以及ali_server视图的确认发布。支持任务名称简化（如586-micro-auth-server只需输入"auth"）。触发器："部署Jenkins任务"、"发布微服务"、"Jenkins构建"、"快速发布"、"确认发布"。
---

必填字段只有两个：

字段	是否必填	说明
name	必填	Skill 的唯一标识。小写字母、数字和连字符，最多 64 个字符。必须和文件夹名一致
description	必填	描述这个 Skill 做什么、什么时候该被触发。最多 1024 个字符

还有一些可选字段：

字段	说明
license	许可证信息
compatibility	兼容性要求，比如”需要 git 和 docker”
metadata	自定义的键值对，比如作者、版本号
allowed-tools	预授权的工具列表（实验性功能）

大多数情况下，你只需要关心name和description这两个必填字段。

这里有一个容易忽视的重点：description字段不是给人看的，是给 AI 看的。

AI 靠这段描述来判断”用户的当前任务需不需要激活这个 Skill”。所以写description的时候，要包含具体的关键词和使用场景，而不是写一句”帮助处理这个任务”就完事了。

好的 description：

description: Jenkins任务自动化部署技能，支持快速发布和无确认发布两种模式。当用户需要部署Jenkins任务时使用，特别是针对586视图和Alph视图的快速发布，以及ali_server视图的确认发布。支持任务名称简化（如586-micro-auth-server只需输入"auth"）。触发器："部署Jenkins任务"、"发布微服务"、"Jenkins构建"、"快速发布"、"确认发布"。

差的 description：

description: 帮助处理任务相关的事情。

指令部分（Markdown body）

元数据下面，就是 Markdown 格式的指令正文。这部分没有固定格式——你用什么标题、分几个小节、怎么组织，完全自由。

但根据实践经验，一个好的SKILL.md通常会包含这几个方面：

• 使用场景：什么情况下应该用这个 Skill
• 执行步骤：具体的操作流程，按顺序排列
• 输出规范：结果应该是什么格式、包含哪些内容
• 边界条件：异常情况怎么处理、哪些事情不应该做

记住，这些指令是写给 AI 看的。写的时候，把 AI 当成一个能力很强但对你的业务一无所知的新同事——流程要清晰，规则要明确，不要留模糊空间。

示例走读：一个真实的 Skill

说了这么多概念，不如看一个真实的例子。下面是SkillVetter——一个专门用来审查其他 Skill 安全性的 Skill（没错，Skill 可以用来审查 Skill）。后面也会推荐大家安装它。

先看它的 SKILL.md（展示关键部分）：

---
name: skill-vetter
version: 1.0.0
description: Security-first skill vetting for AI agents. Use before installing any skill from ClawdHub, GitHub, or other sources. Checks for red flags, permission scope, and suspicious patterns.
---

# Skill Vetter 🔒

Security-first vetting protocol for AI agent skills. **Never install a skill without vetting it first.**

## When to Use

- Before installing any skill from ClawdHub
- Before running skills from GitHub repos
- When evaluating skills shared by other agents
- Anytime you're asked to install unknown code

## Vetting Protocol

### Step 1: Source Check
Questions to answer:
- [ ] Where did this skill come from?
- [ ] Is the author known/reputable?
- [ ] How many downloads/stars does it have?
- [ ] When was it last updated?
- [ ] Are there reviews from other agents?


### Step 2: Code Review (MANDATORY)
Read ALL files in the skill. Check for these **RED FLAGS**:
🚨 REJECT IMMEDIATELY IF YOU SEE:
─────────────────────────────────────────
• curl/wget to unknown URLs
• Sends data to external servers
• Requests credentials/tokens/API keys
• Reads ~/.ssh, ~/.aws, ~/.config without clear reason
• Accesses MEMORY.md, USER.md, SOUL.md, IDENTITY.md
• Uses base64 decode on anything
• Uses eval() or exec() with external input
• Modifies system files outside workspace
• Installs packages without listing them
• Network calls to IPs instead of domains
• Obfuscated code (compressed, encoded, minified)
• Requests elevated/sudo permissions
• Accesses browser cookies/sessions
• Touches credential files
─────────────────────────────────────────

### Step 3: Permission Scope

Evaluate:
- [ ] What files does it need to read?
- [ ] What files does it need to write?
- [ ] What commands does it run?
- [ ] Does it need network access? To where?
- [ ] Is the scope minimal for its stated purpose?

### Step 4: Risk Classification

| Risk Level | Examples | Action |
|------------|----------|--------|
| 🟢 LOW | Notes, weather, formatting | Basic review, install OK |
| 🟡 MEDIUM | File ops, browser, APIs | Full code review required |
| 🔴 HIGH | Credentials, trading, system | Human approval required |
| ⛔ EXTREME | Security configs, root access | Do NOT install |


## Output Format

After vetting, produce this report:

SKILL VETTING REPORT
═══════════════════════════════════════
Skill: [name]
Source: [ClawdHub / GitHub / other]
Author: [username]
Version: [version]
───────────────────────────────────────
METRICS:
• Downloads/Stars: [count]
• Last Updated: [date]
• Files Reviewed: [count]
───────────────────────────────────────
RED FLAGS: [None / List them]

PERMISSIONS NEEDED:
• Files: [list or "None"]
• Network: [list or "None"]  
• Commands: [list or "None"]
───────────────────────────────────────
RISK LEVEL: [🟢 LOW / 🟡 MEDIUM / 🔴 HIGH / ⛔ EXTREME]

VERDICT: [✅ SAFE TO INSTALL / ⚠️ INSTALL WITH CAUTION / ❌ DO NOT INSTALL]

NOTES: [Any observations]
═══════════════════════════════════════

我们来拆解一下这个 Skill 做了什么：

元数据层面：name是skill-vetter，description写了三个关键信息——做什么（”Security-first skill vetting”）、什么时候用（”before installing any skill”）、怎么用（”Checks for red flags, permission scope”）。AI 看到用户说”帮我检查一下这个 Skill 安不安全”的时候，就知道该激活它了。

指令层面：：四个步骤，从来源检查、代码审查、权限评估到风险分级——一套完整的安全审查流程。最后还定义了输出格式，确保每次审查的结果结构一致、可对比。

注意几个设计细节：

• “When to Use”单独列出使用场景——让 AI 更准确地判断何时激活
• Step 2 给出了明确的”红旗清单”——不需要 AI 自己去想该检查什么，照着清单逐项扫描就行
• Step 4 的风险分级表——用表格做结构化分类，AI 可以直接对号入座，而不是模糊地说”有点风险”
• Output Format 定义了输出模板——保证每次审查的报告格式一致，便于对比和存档

这就是一个完整的 Skill。没有复杂的代码逻辑，核心就是把工作流程清晰地写出来。你也会发现，这个 Skill 没有用到scripts/和references/目录——它只有一个SKILL.md文件，但已经足够完成安全审查的工作了。

Skill Vetter 实战：它真的能抓出问题吗？

看了 Skill Vetter 的流程，你可能会想：”听起来很专业，但它真的管用吗？”

我们来做个实验。ClawHub 上有一个叫AgentRetro（agent-retro））的 Skill，功能是”每日复盘”——让 AI 回顾当天的对话记录，总结经验教训，自动沉淀到长期记忆里。听起来很实用对吧？

让 Skill Vetter 检查一下，看看它怎么说：

让我根据现有信息进行分析。现在，让我按照Skill Vetter的流程来进行检查：
📋 SKILL VETTING REPORT
SKILL VETTING REPORT
═══════════════════════════════════════
Skill: agent-retro (可能指agentic-retrospective或retrospective技能)
Source: GitHub (ClawdHub搜索结果)
Author: daax-dev
Version: 未知（需要通过package.json获取）
───────────────────────────────────────
METRICS:
• Downloads/Stars: 3 stars (agentic-retrospective仓库)
• Last Updated: 2026-03-22 (非常近期更新)
• Files Reviewed: 部分目录结构已检查
───────────────────────────────────────
RED FLAGS: 
🚨 需要进一步检查的项目：
• [ ] 完整的SKILL.md文件内容
• [ ] 具体的代码实现
• [ ] 所需的权限范围
• [ ] 是否存在外部网络调用
• [ ] 是否访问敏感文件
⚠️ 已发现的情况：
1. 仓库相对较新（3个stars）
2. 作者daax-dev可能不是知名作者
3. 需要完整代码审查
───────────────────────────────────────
PERMISSIONS NEEDED:
• Files: 未知（需要查看SKILL.md）
• Network: 未知（需要查看代码）  
• Commands: 未知（需要查看代码）
───────────────────────────────────────
RISK LEVEL: 🟡 MEDIUM (基于有限信息)
初步判断原因：
1. 仓库较新，社区验证较少
2. 需要完整代码审查才能确定安全性
3. 技能名称"retrospective"可能涉及回顾/反思功能，需要特别注意数据访问
VERDICT: ⚠️ INSTALL WITH CAUTION (需完整代码审查)
NOTES: 
1. 需要完整的SKILL.md文件来了解技能用途
2. 需要检查retrospective技能的具体实现
3. 建议先查看skills/retrospective/目录的所有文件
4. 如果涉及MEMORY.md等敏感文件访问，需要特别谨慎
═══════════════════════════════════════

注意，这个 Skill不是恶意软件。它没有偷密码、没有反弹 Shell、没有把数据发到外部服务器。它的功能确实是”每日复盘”，作者大概率没有恶意。

但SkillVetter还是给了🟡 MEDIUM的风险评级。

因为它触犯了几条核心安全原则：

1. 权限过大：一个”复盘”功能，却要同时修改 SOUL.md (决定AI性格) 、AGENTS.md（决定 AI 行为边界）、USER.md（用户画像）和 MEMORY.md（长期记忆）——这相当于给了它改写 AI “人格”的权力。做个类比：你请了个同事帮你写周报总结，结果他不光写了总结，还顺手改了你的简历、你的绩效考核标准、甚至你的工作流程手册。功能上说得通，但权限范围明显超标了。

2.没有安全阀：它直接修改文件后才告诉你改了什么，没有预览、没有确认步骤。你甚至不知道它改了什么，直到改完了。

3.元数据不诚实：它实际需要读写~/.openclaw/agents/目录下的敏感文件，但在元数据里没有声明——这意味着渐进式披露机制无法正确评估它的风险。

这个例子特别有教育意义，因为它代表了现实中最常见的安全风险类型——不是蓄意作恶，而是设计上的粗糙导致了过大的权限和缺失的防护。恶意 Skill 毕竟是少数，但”功能正常、权限过大、缺乏防护”的 Skill 到处都是。Skill Vetter 的价值，恰恰在于它能帮你识别出这类”看起来没问题，但细想不对劲”的风险。

2.3 渐进式披露：Skill 如何节约上下文

讲完了 Skill 的结构，你可能会有一个疑问：

“如果我装了几十个 Skill，每个 Skill 的指令都好几百行，那 AI 的上下文窗口不是一下子就被塞满了吗？”

这个问题问得好。如果所有 Skill 的全部内容都一股脑加载进上下文，那确实会出问题——上下文窗口是有限的稀缺资源，塞得越满，AI 的表现越差。

但实际上，Skill 的设计者早就考虑到了这个问题，采用了一种叫做**渐进式披露（Progressive Disclosure）**的机制。

什么是渐进式披露？

简单说，就是不是所有内容都一次性加载，而是分层按需加载

想象你去图书馆。你不会把图书馆里所有的书都搬到桌上来——你先看书架上的书名（找到可能需要的），再抽出来翻目录（确认是不是你要的），最后才打开具体章节细读（获取你需要的信息）。

Skill 的加载也是这个逻辑，分三层：

层级	加载内容	何时加载	上下文开销
第一层：发现	只有name和description	启动时，所有已安装Skill的元数据全部加载	每个 Skill 约 50~100 tokens
第二层：激活	SKILL.md的完整指令内容	当 AI 判断当前任务匹配某个 Skill 时	建议控制在 5000 tokens 以内
第三层：执行	scripts/、references/中的文件	指令中引用到具体文件时才加载	按需加载，脚本甚至可以执行而不加载到上下文

举个例子

假设你装了 30 个 Skill。

启动时，OpenClaw 只加载这 30 个 Skill 的名字和描述——每个大约50-100 个 tokens，总共也就 1500-3000个 tokens。相对于现代模型动辄十几万甚至上百万的上下文窗口来说，这个开销微乎其微。

然后你说：”帮我审查一下这段代码。”

匹配阶段，OpenClaw 扫一遍这 30 个 Skill 的描述，发现code-review这个 Skill 的描述里提到了”审查代码”、”Review PR”——命中了。于是它把code-review这个 Skill 的完整SKILL.md指令加载进来。注意，另外 29 个 Skill 的指令完全不会被加载

执行阶段，AI 按照指令开始工作。指令第三步说”参考references/style-guide.md里的编码规范”——这时候才去读取这个文件。其他没被引用到的参考文件，也不会被加载。

为什么这个设计很重要？

因为它解决了一个核心矛盾：你想装很多Skill来覆盖各种场景，但上下文窗口的容量是有限的。

渐进式披露让这两个诉求可以共存：

• 你可以放心安装几十个 Skill，不用担心”装太多会影响性能”
• 每次对话只有真正相关的 Skill 内容会被加载，上下文保持干净
• 脚本文件可以被执行而不需要加载到上下文里，进一步节省空间

反过来说，这也给 Skill 开发者一个设计原则：SKILL.md 的指令部分要精炼，不要什么都往里塞。详细的参考资料、长文档、数据文件，应该放到references/或assets/目录里，让 AI 需要时再去读取。官方建议是把SKILL.md控制在 500 行以内。

2.4 Skill 在 OpenClaw 中的扩展

前面三节讲的都是 AgentSkills 的通用标准——任何支持这个标准的 AI 工具都遵循同样的规范。

OpenClaw 在AgentSkills 基础上，做了几项平台级的扩展：

• 依赖声明
• 多层存放与覆盖
• 命令派发
• ClawHub 生态

这些扩展让 Skill 在 OpenClaw 里更好用、更强大。

依赖声明

通用标准里，SKILL.md只有一个compatibility字段来描述环境要求，而且它是纯文本的，只是给人看的提示信息——AI 并不会真的去检查。

OpenClaw 把这件事做到了机器可读、自动检查的层面。

在 OpenClaw 中，一个 Skill 可以声明自己需要什么才能运行：

• 需要哪些命令行工具（比如git、docker、uv）
• 需要哪些环境变量（比如 API Key）
• 需要哪些配置项是否开启

OpenClaw 在加载 Skill 时会自动检查这些依赖，如果不满足，这个Skill就不会被加载——不会报错，而是静默跳过。

这个机制的好处是：你可以安装很多 Skill，即使某些 Skill 依赖的工具你还没安装，也不会出问题——它们只是安静地等着，直到条件满足时才会生效。

多层加载与 Agent 隔离

通用标准只定义了 Skill 的文件格式，但没有规定”Skill 应该放在哪里”。这是各个平台自己决定的事情。

OpenClaw 设计了一个三层加载体系，每一层都有明确的路径和作用范围：

层级	路径	优先级	谁能用
工作区Skills	<当前 Agent 的工作区>/skills/	最高	仅当前 Agent
用户区Skills	~/.openclaw/skills/	中等	本机所有 Agent 共享
内置 Skills	随安装包分发（npm 包或 OpenClaw.app 内部）	最低	所有 Agent

如果多个位置有同名Skill，高优先级的会覆盖低优先级的。比如你觉得内置的某个 Skill 不完全符合需求，可以在工作区放一个同名的 Skill，用自定义版本覆盖默认行为——不需要去改系统文件，也不影响其他 Agent。

这里有一个关键细节容易被忽略：工作区级别的Skill是Agent隔离的。

OpenClaw 支持多 Agent 模式——你可以有一个专门处理飞书消息的 Agent、一个处理微信的 Agent、一个跑在 Web 端的 Agent。每个 Agent 都有自己独立的工作区（workspace），工作区里的skills/目录只对该 Agent 可见。

打个比方。一栋办公楼里有好几间办公室（每个 Agent 就是一间办公室）。每间办公室里有自己的工具柜（工作区 Skills），只有坐在这间屋里的人能用。而楼层公共储物间（~/.openclaw/skills/）是所有人共享的，谁都能用。大楼物业配的消防器材（内置 Skills）则是基础设施，每间办公室自动都有。

这就引出了一个实际中很多同学踩过的坑：在A渠道让Agent安装的Skill，换到B渠道的Agent就找不到了。

OpenClaw 支持多 Agent 模式——你可以有一个专门处理飞书消息的 Agent、一个处理微信的 Agent、一个比如你通过飞书对话让 Agent 安装了一个 Skill，它被装进了飞书 Agent 的工作区；后来你切到 Web 界面想用同一个 Skill，却发现不生效——因为 Web 端是另一个 Agent，它看不到飞书 Agent 工作区里的东西。解决办法很简单：把 Skill 安装到~/.openclaw/skills/（共享层），所有 Agent 都能访问到。

另一个常见问题是缓存没刷新。OpenClaw 在会话开始时会给 Skill 列表拍个”快照”，整个会话期间复用这个快照。如果你在会话中途安装了新 Skill，当前会话可能看不到它——新开一个会话就好了。

命令派发

通常情况下，你对 AI 说一句话，AI 需要先理解你的意图，然后决定调用什么工具——这中间有一个”模型推理”的过程。

OpenClaw 的命令派发功能允许某些 Skill 跳过这个推理步骤：用户输入特定命令，直接触发工具调用，中间不经过模型。速度更快，结果更确定。

这个功能适用于那些不需要 AI”思考”的场景——比如格式化代码、运行测试、提交代码等固定操作。

ClawHub 生态

精选推荐：必装清单

ClawHub 上有四万多个 Skill，而且还在持续不断地增加。你不可能一个个去看。这一节我们按场景分类，推荐一批热门、实用、高质量 Skill，帮你快速建立起一套实用的 Skill 工具箱。汇总如下：

AD：《熊孩子博客》熊孩子QQ:443060965