OpenClaw的skills机制分层组织，包括全局安装层、共享层和各agent的workspace层。skills与tools不同，tools决定"能不能做"，skills决定"怎么做"。不同类型agent间的技能共享取决于skills所在层次，不应默认main的私有技能会被所有sub-agent共享。稳定的多agent协作应依靠明确的共享层设计而非隐含假设。

---

一文讲透在同时拥有130多个Agents的OpenClaw实例中，如何进行Skills的管理和调用。

---

很多人第一次接触 OpenClaw 的 skills 机制，都会把几件事混在一起：

• • skill 和 tool 到底是不是一回事
• • skill 应该放在哪个目录下
• • main agent 能用的 skill，sub-agent 能不能用
• • 不同 agent 之间能不能共享 skill
• • 同名 skill 如果同时出现在多个位置，系统到底会用哪一份

如果这些边界不先讲清楚，后面一旦开始做 multi-agent 协作，目录结构和行为就会越看越像“玄学”。

这篇文章的目标很简单：

• • 先讲清楚 OpenClaw 里的 skill 本质是什么
• • 再讲清楚 skill 的目录层次
• • 最后说明 main agent、agency-agents、sub-agent 之间和 skill 的关系

为了避免把某一台机器的目录写死，下面统一使用通用路径写法：

• • ~/.openclaw
• • ~/.openclaw/workspace
• • ~/.openclaw/agents
• • ~/.openclaw/agency-agents

这样更适合作为可复用的机制说明。

---

一、先别把 skill 和 tool 混为一谈

这是最核心的一层。

在 OpenClaw 里，skill 和 tool 不是同一个东西。

1. tool 是能力

tool 更像“手和脚”，是 agent 真正可以直接调用的操作能力，例如：

• • read
• • write
• • edit
• • exec
• • browser
• • sessions_spawn
• • memory_search

tool 决定的是：

• • 能不能读文件
• • 能不能写文件
• • 能不能起子代理
• • 能不能查网页
• • 能不能控制浏览器

也就是说，tool 解决的是“能不能做”。

2. skill 是工作方法和操作说明

skill 更像“作战手册”或者“标准流程”。

一个 skill 通常会告诉 agent：

• • 在什么场景下应该启用它
• • 先读哪个 SKILL.md
• • 遇到这个问题应该走什么 workflow
• • 需要用哪些脚本、参考资料或外部命令

所以，skill 解决的是：

• • 应该怎么做
• • 按什么步骤做
• • 什么时候用这套流程最合适

一句话概括就是：

• • tool 是能力层
• • skill 是方法层

这也是为什么“一个 agent 看得见某个 skill”，并不自动等于“它一定能把这个 skill 完整执行成功”。

因为 skill 只是指导，真正落地还取决于：

• • tool 权限是否足够
• • 文件路径是否可访问
• • 当前 workspace 是否能看到对应资源
• • 这个 skill 是否被 agent 的技能过滤规则允许

---

二、一个 skill 目录里通常有什么

OpenClaw 的一个 skill，最核心的入口文件是：

• • SKILL.md

除此之外，还可能带一些辅助资源，例如：

• • references/
• • scripts/
• • 示例文件
• • 配套说明文档

一个典型 skill 看起来会像这样：

some-skill/

├── SKILL.md

├── references/

│ └── workflow.md

└── scripts/

└── helper.py

其中：

SKILL.md

负责说明：

• • skill 什么时候触发
• • 应该先做什么，再做什么
• • 需要额外读哪些参考文件
• • 需要调用哪些脚本或工具

references/

负责放详细说明，例如：

• • API 参考
• • 工作流说明
• • 复杂规则
• • 错误处理手册

scripts/

负责放真正复用的脚本，例如：

• • 格式转换脚本
• • 导入导出脚本
• • 自动化辅助工具

所以 skill 不是“只有一个 markdown 文件”，而是一组围绕某种任务组织起来的资源。

---

三、OpenClaw 里的 skill 来源，不止一层

理解 skills 机制，最容易误解的地方，就是以为“skill 只有一个统一目录”。

实际上，OpenClaw 会从多个层次去发现 skill。

可以把它理解成三层：

第一层：全局安装层

这是 OpenClaw 安装包自带的一批 skills，典型位置类似（以腾讯云轻量应用服务器的OpenClaw镜像为例）：

• • .../node_modules/openclaw/skills

这里放的通常是：

• • 随 OpenClaw 一起分发的通用 skill
• • 偏系统级、官方级、基础能力级的 skills

例如你可能会看到：

• • skill-creator
• • healthcheck
• • tmux
• • clawhub
• • video-frames
• • weather

这层可以理解成：

OpenClaw 安装级别的全局技能库

---

第二层：共享层

这是很多人真正关心、但最容易没讲清的部分。

从机制上看，OpenClaw 还会扫描一些不属于某个单独 agent workspace 的公共目录，例如：

• • ~/.openclaw/skills
• • ~/.agents/skills

这类目录更适合放“跨 agent 复用”的自定义 skill。

也就是说，如果你的目标是：

• • main agent 能用
• • imported agents（例如agency-agents）能用
• • 通过 sessions_spawn 拉起的 sub-agent 也更大概率能看到

那比起只放到某个 agent 的私有 workspace 里，更适合放到这种公共共享层里。

这层可以理解成：

机器级、配置级、跨 workspace 的共享技能库

---

第三层：agent 自己的 workspace 层

每个 agent 自己的 workspace 下面，也可能有 skills 目录，例如：

• • ~/.openclaw/workspace/skills
• • ~/.openclaw/agency-agents/<agent-id>/skills
• • ~/.openclaw/workspace/.agents/skills
• • ~/.openclaw/agency-agents/<agent-id>/.agents/skills

这一层更像：

某个特定 agent 的本地技能库

这类 skill 最大的特点是：

• • 更接近这个 agent 自己的工作区
• • 更适合放该 agent 专用的 workflow
• • 不应默认假设别的 agent 也一定能自动共享到

---

四、main agent 和 agency-agents 的 skill 关系，不是天然完全一致

这部分最值得讲透。

1. main agent 通常有自己的 workspace

例如：

• • ~/.openclaw/workspace

那么它的本地 skill 往往会放在：

• • ~/.openclaw/workspace/skills

2. imported agency-agents 通常各自也有 workspace

例如：

• • ~/.openclaw/agency-agents/software-architect
• • ~/.openclaw/agency-agents/product-manager
• • ~/.openclaw/agency-agents/security-engineer

那么这些 agent 各自的本地 skill 往往放在：

• • ~/.openclaw/agency-agents/software-architect/skills
• • ~/.openclaw/agency-agents/product-manager/skills
• • ~/.openclaw/agency-agents/security-engineer/skills

这意味着一个关键事实：

main agent 的本地 workspace skill，并不天然等于所有 imported agent 的本地 skill。

也就是说：

• • main 能看到的 skill
• • 其他 imported agent 不一定天然就看得到

它们能否共享，要看 skill 究竟放在哪一层。

---

五、sub-agent 能不能用 main agent 的 skill？

这是大家最容易直接问的问题。

更准确的回答不是“能”或者“不能”，而是：

要看这个 skill 是落在私有层，还是落在共享层，以及子代理运行时的可见范围和边界策略。

不过把机制说完之后，可以把判断逻辑归纳成下面这几种情况。

情况 A：skill 在全局安装层

例如这个 skill 在 OpenClaw 自带的全局 skills 目录里。

那么通常：

• • main agent 可以用
• • imported agents 也大概率可以用
• • sessions_spawn 拉起的 sub-agent 通常也可以用

前提是：

• • tools 权限允许
• • agent 没有额外的 skills filter 把它禁掉

这类 skill 属于“最像公共能力”的那种。

---

情况 B：skill 在共享层

例如放在：

• • ~/.openclaw/skills
• • ~/.agents/skills

那么它也更像一份机器级共享能力。

这种放法通常适合：

• • 希望多个 agent 复用
• • 希望 main 和 imported agents 都能稳定发现
• • 希望把某个 workflow 做成公共基础设施

如果你要做“公司内部通用 skill”或者“整套 multi-agent 公共工作流 skill”，这层通常比某个 workspace 私有目录更合适。

---

情况 C：skill 只在 main 的 workspace 层

例如：

• • ~/.openclaw/workspace/skills/tencent-docs-safe-write

这时要注意：

• • main agent 当然最容易用到它
• • imported agent 或 sub-agent 是否也能用，不应默认想当然

因为这里至少有三种可能：

1. 1. 子代理真的可以直接读到 main 的那条路径
2. 2. 这份 skill 恰好也同步到了子代理自己的 workspace 里
3. 3. 当前环境存在更宽的技能发现或文件访问边界

所以对于“只放在 main workspace 的 skill”，最稳妥的态度不是拍脑袋，而是做实测。

---

六、一个很重要的实测经验：不要只靠猜目录，要验证“当前环境里的真实行为”

在实际排查中，很容易出现一种情况：

• • 从源码逻辑推断，某个 agent 不该天然看见 main 的 skill
• • 但实测却发现，它确实能读取这份 skill

这并不矛盾。

因为真实运行时，还可能受到这些因素影响：

• • 该 skill 是否已经存在于目标 agent 自己的 workspace 下
• • 当前 agent 的路径边界是否允许访问主 workspace
• • 该 skill 是否被提前同步、安装、拷贝到了多个 agent 中
• • 当前配置是否启用了额外共享目录

所以，对于 multi-agent 环境里的 skill 共享问题，最务实的结论往往是：

机制上先看层次，落实上一定要抽样实测。

尤其是当你在调试：

• • main 的 skill 能不能被 agency-agent 复用
• • imported agents（例如agency-agents） 之间是否都能共享某个 workflow
• • 一个 skill 到底是私有、共享，还是已经被复制分发过

这时候实测比纯目录猜测更可靠。

---

七、不同 agent 之间到底是“共享 skill”，还是“各自一套 skill”？

答案其实是：

两者都存在，只是层不同。

更准确地说：

共享的是公共层

例如：

• • OpenClaw 安装级 skills
• • ~/.openclaw/skills
• • ~/.agents/skills
• • 配置额外声明的公共 skill 目录

这些更像公共技能池。

不共享的是各自私有 workspace 层

例如：

• • ~/.openclaw/workspace/skills
• • ~/.openclaw/agency-agents/<agent-id>/skills

这些目录天然更偏向“谁的 workspace，谁优先看自己的那一份”。

所以如果你问：

• • 不同 agent 能不能共享 skill？

最好的回答不是“能”或“不能”，而是：

• • 可以共享公共层 skill
• • 不应默认共享彼此私有 workspace 层 skill

---

八、为什么 skill 共享问题在 multi-agent 里特别重要

因为一旦你开始认真使用 sessions_spawn 做多智能体协作，技能放置策略会直接影响工作流设计。

1. 如果 skill 只放在某个 agent 的私有 workspace 里

那它更适合：

• • 这个 agent 独享
• • 或者少量特定 agent 专用
• • 偏角色定制型 workflow

例如：

• • 某个销售 agent 的私有跟单流程
• • 某个安全 agent 的专用审计模板
• • 某个内容 agent 的特殊排版工作流

2. 如果 skill 放在共享层

那它更适合：

• • main 和多个 sub-agent 共用
• • 被当成基础设施反复复用
• • 跨角色统一采用

例如：

• • 通用 GitHub issue 分析 skill
• • 通用腾讯文档安全写入 skill
• • 通用搜索、汇总、报告生成 skill

所以 skill 放哪，不只是目录问题，而是架构问题。

---

九、实务上该怎么设计 skills 的层次

如果要给出一套比较稳的实践建议，可以这样分。

第一类：官方通用 skill

放在：

• • OpenClaw 安装级全局目录

适合：

• • 随系统分发
• • 大多数环境都能复用
• • 不依赖你的私人目录结构

---

第二类：机器级共享 skill

放在：

• • ~/.openclaw/skills
• • 或 ~/.agents/skills

适合：

• • 你自己这台机器上的多个 agent 共同使用
• • 你想把它当作跨 agent 的公共能力
• • 你希望 main 和 agency-agents 都更稳定看到它

如果你的目标是打造一套长期复用的 multi-agent 能力层，这一层最关键。

---

第三类：workspace 私有 skill

放在：

• • ~/.openclaw/workspace/skills
• • ~/.openclaw/agency-agents/<agent-id>/skills

适合：

• • 某个特定 agent 的专用流程
• • 某个项目临时用的 skill
• • 不想全局暴露的本地 workflow

这类 skill 非常有价值，但不要默认把它当作“全系统共享能力”。

---

十、再回到一个经典问题：sub-agent 到底在“继承”什么？

很多人会把 sub-agent 想成“main agent 的完全克隆”。

其实更准确的理解是：

sub-agent 是在 OpenClaw 运行时里，按目标 agent 配置启动出来的一个子会话实例。

它继承和受影响的东西包括：

• • 目标 agent 的身份与配置
• • 目标 agent 的 workspace
• • 目标 agent 的 tools policy
• • 目标 agent 的 model / subagent 相关设置
• • 当前系统能发现的 skills

所以 sub-agent 不是简单复制 main。

它更像：

由 main 发起，但按目标 agent 角色和环境运行的子任务执行者。

这也是为什么 skill 是否可用，必须同时看：

• • 这个 skill 在不在当前可发现范围里
• • 这个子代理有没有执行所需 tools 的权限
• • 这个 skill 的资源文件在它的边界内能不能读到

---

十一、如果同名 skill 同时存在于多个层，该怎么理解

这也是工程上很容易踩坑的一点。

比如某个 skill 同时出现在：

• • 全局安装层
• • ~/.openclaw/skills
• • main 的 workspace/skills

那么就会出现两个现实问题：

1. 1. 系统最终优先用哪一份
2. 2. 你修改的是不是当前真正生效的那一份

这类问题如果不去确认优先级，就容易出现：

• • 你以为自己改了 skill
• • 实际运行时却读的是另一个目录里的同名版本

因此，一旦开始系统化维护 skill，最好把来源标注清楚，例如：

• • 这是官方内置版
• • 这是本机共享版
• • 这是某个 agent 私有版
• • 这是对官方 skill 的本地覆盖版

这会大幅降低后期排障成本。

---

十二、给 multi-agent 场景的一套简单原则

如果只保留最实用的几条经验，我会建议这样记：

原则 1

把 tool 和 skill 分开想。

• • tool 决定能不能做
• • skill 决定怎么做

原则 2

把 skill 分层放。

• • 公共能力放共享层
• • 角色专用流程放各自 workspace

原则 3

不要默认 main 的本地 skill 会天然被所有 sub-agent 共用。

有时会，有时不会。

最稳的方式不是猜，而是根据层次设计，再配合实测确认。

原则 4

如果一个 skill 需要被很多 agent 复用，就别只把它藏在 main 的 workspace 里。

更适合放到：

• • ~/.openclaw/skills
• • ~/.agents/skills
• • 或其他明确配置成公共加载目录的位置

原则 5

如果一个 skill 只服务某个角色，就让它留在那个角色自己的 workspace 里。

这会让职责边界更清楚。

---

十三、最后总结

如果只用一句话概括 OpenClaw 的 skills 机制，那就是：

skill 不是“一个统一目录里的插件列表”，而是一套分层发现、按 workspace 和共享范围组织起来的工作流系统。

更完整一点说：

• • tool 是能力
• • skill 是方法
• • skill 可以来自全局安装层、共享层、以及各 agent 自己的 workspace 层
• • main agent、agency-agents、sub-agent 不一定天然共享所有私有 skill
• • 真正稳定的跨 agent 共享，应该依靠明确的共享层，而不是隐含假设

当你把这套机制看清楚之后，很多原本模糊的问题就会变得很直白：

• • 为什么有些 skill main 能用，别的 agent 不一定能用
• • 为什么有些 skill 明明同名，却可能不是同一份
• • 为什么 multi-agent 要认真设计 skill 的放置层级

一旦这些边界建立起来，OpenClaw 的 skills 体系就不再神秘，而会变成一套很清晰的工程结构：

• • 通用能力放公共层
• • 角色能力放私有层
• • 让 agent 在合适的范围内共享合适的 workflow

这时候，skills 才真正从“目录里的文件”，变成了多智能体系统里可维护、可扩展、可复用的能力单元。

大模型入门学习教程 （附PDF文档，文末获取）

现在国内外关于大模型入门教程做的比较好的并不多，这其实也是一件好事，有难度和有门槛才能避免烂大街，现在大模型入门教程热度最高的包括李宏毅老师、吴恩达老师、Datawhale开源社区等

选择合适的入门学习教程，能少走弯路，抓住核心内容，快速达到前沿的水平，甚至是发表大模型相关的论文都是可以的

这一期主要是给大家推荐李宏毅老师的最新课程：大模型入门学习教程

这个教程的主要内容如下（总共11讲）：

第1讲：总体介绍

这一讲主要介绍现在大模型作为生成式人工智能，其发展的历史过程，以及大模型落地的主要应用方向，了解大模型主要学习什么内容，难度不大，简单看一下就行

第2讲：提示词和AI代理人

首先介绍什么是提示词工程，提示词就是人类和大模型交互的语言，对于大模型的引导需要通过提示词来完成，然后介绍如何引导模型进行思考，比如COT是什么，在模型训练过程中提供额外信息

第3讲：生成策略

同一个问题，多次询问大模型，大模型会给出不同的回答，如何提高回复的准确率以及稳定性，是一个重要的大模型生成策略。了解大模型的生成概率与什么有关，比如top_p, top_k，temperature等

第4讲：深度学习和Transformer

这一部分先介绍一些深度学习基础内容，大模型的模型都是深度学习模型，了解深度学习中基础内容是有必要的，比如损失函数，反向传播，梯度下降等，然后介绍大模型的基础框架transformer，transformer模型结构一定要非常熟悉，很重要

第5讲：大模型评估和道德问题

这一部分先介绍大模型的评估标准，现在有很多benchmark从各个方面来评测大模型的不同能力，评估指标很多，开源的模型往往会选择有利于自己的指标进行展示，然后介绍大模型中存在的道德问题，因为大模型不能随意生成一些不符合道德社会文明的内容

第6讲：AI的可解释性

给大模型一个输入，只能得到一个输出，但是我们并不清楚大模型的思考过程是怎么样的，这个问题，大模型是怎么思考的，提升大模型的可解释性有助于后续研究如何提升大模型的推理性能，像COT就是显式展示大模型的思考过程，然后还可以让语言模型来解释语言模型

第7讲：视觉大模型

常说的大模型，都指的是文本大模型，输入是文本，输出也是文本，而现实世界中，可能我们的输入既有文本，又有图片和视频，输出也可能是多样化的，视觉大模型就是能解决文本和视觉两种模态的大模型

第8讲：GPT-4o

前面都是关于大 模型的理论，这一部分是拆解一个完整的大模型是怎么样的，以GPT-4o为例进行说明，GPT**-4o是首个端到端多模态通用模型**，是迈向AGI的一步，能够实现文本，音频和图片的多模态交互

上面就是大模型的入门教程的所有内容，学完这些可以去看看关于大模型微调，大模型训练，大模型推理加速，RAG和Agent等相关的内容，后面最好整一两个项目来实践一下

上述资料获取：

1. 关注公众号【大模型应用开发LLM】领取即可获取

2. 这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】