多 OpenClaw 智能体共享 SKILL 库——从探索到落地的完整实录
背景:我的机器上同时跑了两个 OpenClaw 系智能体,一个安装在
C:\Users\Administrator\openclaw\,另一个是 Claude Code,安装在C:\Users\Administrator\claude\。两边各有各的 skills 目录,逐渐积累出大量重复和分散的 Skill,维护成本越来越高,而且最大的问题是很多技能我也记不得在哪个智能体上安装的了,这还是两个,如果再加上爱玛仕、WORKBUDDY,估计更乱,更无法管理。于是我开始琢磨:能不能让它们共享同一份 SKILL 库?
第一轮探索:Skill 能不能共用?
第一个问题很朴素——两个智能体装在同一个用户下,Skill 能不能直接共用?
翻了一下目录结构:
|
|
|
|
|---|---|---|
|
|
C:\Users\Administrator\openclaw\skills\ |
|
|
|
C:\Users\Administrator\claude\skills\ |
|
答案取决于 Skill 安装在哪一层:
-
用户级 ~/.openclaw/skills/—— 同一用户下所有 OpenClaw 实例理论上都能访问 -
项目级 {workspace}/.openclaw/skills/—— 仅当前项目生效
~/.claude/skills/,OpenClaw 读的是 ~/.openclaw/skills/,路径完全不同,互不相通。 各自硬编码了自己的根目录,不会去扫描对方的路径。结论:原生不支持跨智能体共享,需要手动干预。
第二轮探索:能不能合并到同一个目录?
既然两个目录互不相通,那把文件直接合并到一起呢?
我仔细看了一下两边的 Skill 内容,发现了几个关键问题:
1. 同名 Skill 内容不同
比如两边都有 github 这个 Skill,但 SKILL.md 的 frontmatter 格式有差异:
Claude Code 版本:
---name:githubdescription:"Interact with GitHub using the `gh` CLI..."---
OpenClaw 版本:
---name:githubdescription:"Interact with GitHub using the `gh` CLI..."description_zh:"管理 GitHub Issues、PR 和 CI"description_en:"Manage GitHub issues, PRs, and CI runs"version:1.0.0---
OpenClaw 版多了 description_zh、description_en、version 字段。物理合并只能保留一份,势必丢失某一侧的元数据。
2. SKILL.md 格式不完全兼容
不同平台对 frontmatter 字段的解析能力不同。多余字段通常被静默忽略不会报错,但如果某个平台做了强校验,就可能出问题。
3. 脚本路径硬编码
部分 Skill 内含 .sh / .py / .js 脚本,脚本里可能硬编码了相对路径。从不同平台的工作目录调起时,路径解析可能出错。
结论:直接物理合并风险较大,同名冲突不好处理,且后续更新会互相覆盖。
第三轮探索:Symlink 软链接方案
物理合并不行,那就用链接——文件只存一份,两个路径都能访问。
Windows 上的两种链接方式
|
|
|
|
|
|
|---|---|---|---|---|
| Junction(目录联接) | New-Item -ItemType Junction |
|
|
|
| Symlink(符号链接) | New-Item -ItemType SymbolicLink |
|
|
|
我检查了一下当前系统的权限状态:
whoami /priv | Select-String 'SeCreateSymbolicLinkPrivilege'# 输出:SeCreateSymbolicLinkPrivilege Create symbolic links Disabled
Symlink 权限未开启,普通用户无法创建。而 Junction 不需要额外权限,且我的两个目录都在 C 盘,完全满足条件。
决定:用 Junction。
第四轮探索:怎么链接?——三个方案对比
方案 A:把整个目录作为子目录挂载
New-Item -ItemType Junction ` -Path "C:\Users\Administrator\claude\skills\openclaw-shared" ` -Target "C:\Users\Administrator\openclaw\skills"
问题: 这样挂载后,openclaw-shared 会被当成一个 Skill 名字,但它里面嵌套了 37 个子 Skill。Skill 发现机制是扫描 skills/ 下的一级子目录,每个子目录应该是一个独立 Skill。结果:37 个 Skill 全部不会被识别,因为它们在二级目录里。
❌ 不可行。
方案 B:逐个 Skill 建立 Junction
New-Item -ItemType Junction ` -Path "C:\Users\Administrator\claude\skills\nuwa" ` -Target "C:\Users\Administrator\openclaw\skills\nuwa"
每个 Skill 一个链接,37 个 Skill 要建 37 个 Junction。而且还有同名冲突要先处理。
⚠️ 可行但非常繁琐,后续新增 Skill 还要手动建链接。
方案 C:让 Claude 的 skills 目录直接指向 OpenClaw 的(✅ 推荐)
思路: 把所有 Skill 统一存放在 OpenClaw 的 openclaw/skills/ 下,删掉 Claude 的 claude/skills/ 目录,用 Junction 让它指向 OpenClaw 的目录。
C:\Users\Administrator\openclaw\skills\ ← 实际文件存放位置(主库) ↑C:\Users\Administrator\claude\skills\ ← Junction,指向上面
两个智能体读的都是同一份文件,真正共享,零冗余。
✅ 最干净、最省事的方案。
落地:方案 C 执行计划
确认方案后,我制定了以下执行步骤:
第一步:差异对比——找出重叠和独有
先列出两边的 Skill 清单,标注重叠项:
┌─────────────────┬──────────┬──────────┐│ Skill 名称 │ OpenClaw │ Claude │├─────────────────┼──────────┼──────────┤│ github │ ✅ (v1.0) │ ✅ (精简) │ ← 重叠,需选版本│ nuwa │ ✅ │ ❌ ││ stock-watcher │ ✅ │ ❌ ││ ... │ ... │ ... │└─────────────────┴──────────┴──────────┘
对于重叠的 Skill,逐一对比 SKILL.md 内容,选择字段更完整的版本(通常是 OpenClaw 版本,因为它有 description_zh、version 等扩展字段)。
第二步:迁移 Claude 独有的 Skill
把 Claude 有而 OpenClaw 没有的 Skill,移动(不是复制)到 OpenClaw 的目录:
# 示例:移动 Claude 独有的 SkillMove-Item -Path "C:\Users\Administrator\claude\skills\some-unique-skill" ` -Destination "C:\Users\Administrator\openclaw\skills\some-unique-skill"
第三步:备份 Claude 原目录
# 整目录备份,防万一Copy-Item -Path "C:\Users\Administrator\claude\skills" ` -Destination "C:\Users\Administrator\claude\skills-backup-20260426" ` -Recurse
第四步:删除 Claude 原 skills 目录
Remove-Item -Path "C:\Users\Administrator\claude\skills" -Recurse -Force
第五步:创建 Junction
New-Item -ItemType Junction ` -Path "C:\Users\Administrator\claude\skills" ` -Target "C:\Users\Administrator\openclaw\skills"
验证:
# 确认 Junction 创建成功dir "C:\Users\Administrator\claude\skills"# 应该能看到和 openclaw/skills 一样的内容# 确认是 Junction 而非普通目录fsutil reparsepoint query "C:\Users\Administrator\claude\skills"
第六步:双端验证
分别在两个智能体中测试:
-
列出可用 Skills,确认数量和内容一致 -
调起一个原来 Claude 独有的 Skill,确认功能正常 -
调起一个重叠 Skill(如 github),确认无报错
注意事项与踩坑指南
🔴 删除 Junction 时的安全操作
删除 Junction 链接本身是安全的,不会影响源目录:
# ✅ 安全:只删链接Remove-Item -Path "C:\Users\Administrator\claude\skills" -Force# 或者用 rmdir,更明确cmd /c rmdir "C:\Users\Administrator\claude\skills"
⚠️ 千万不要加 -Recurse,某些情况下会穿透链接删除源文件:
# ❌ 危险!可能删除 openclaw/skills 下的所有文件Remove-Item -Path "C:\Users\Administrator\claude\skills" -Recurse -Force
🟡 SKILL.md 格式兼容性
OpenClaw 版的 SKILL.md 通常包含更多字段(description_zh、version 等),Claude Code 遇到不认识的字段一般会静默忽略,不会报错。但如果你遇到某个 Skill 在 Claude 侧表现异常,可以先检查 frontmatter 是否有特殊字段干扰了解析。
🟡 后续新增 Skill 的维护
共享后,无论从哪个平台安装新 Skill,文件都会写入 OpenClaw 的目录(因为 Claude 那边是 Junction 指向过去的)。两边立即可见,无需额外操作。
但如果某个平台的 Skill 安装器在安装时做了路径校验(检查是否真的在 claude/skills/ 下),可能会因为实际路径不符而报错。这种情况极少见,但值得留意。
🟡 跨分区场景
如果你的两个智能体安装在不同分区(比如 C 盘和 D 盘),Junction 就不能用了(它不支持跨分区)。这时需要:
-
开启 Windows 开发者模式(设置 → 更新和安全 → 开发者选项),获取 Symlink 权限 -
改用 Symlink: -
New-Item -ItemType SymbolicLink `
-Path "D:\Users\xxx\claude\skills" ` -Target "C:\Users\Administrator\openclaw\skills"
🟢 备份策略
建议在操作前保留备份目录一段时间(比如一周),确认双端运行正常后再删除。备份目录放在 Claude 侧即可:
C:\Users\Administrator\claude\skills-backup-20260426\
最终架构
C:\Users\Administrator\openclaw\skills\ ← 主库(所有 Skill 的实际存储位置) ├── github/ ├── nuwa/ ├── stock-watcher/ ├── ...(37+ 个 Skill) ↑ │ Junction(目录联接) │C:\Users\Administrator\claude\skills\ ← 指向主库的链接 ├── github/ → 实际读取 openclaw/skills/github/ ├── nuwa/ → 实际读取 openclaw/skills/nuwa/ └── ... → 全部指向主库
核心思路:一份文件,两个入口,零冗余,单点维护。
总结
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
-Recurse 可能穿透到源目录 |
|
|
|
写于 2026-04-26,环境为 Windows Server,OpenClaw + Claude Code 双智能体。 最后特别强调,今天所有的实践内容,我只进行了三轮问题,确认了策略后,是小龙虾生成操作代码并完成操作。这文章也是我让小龙虾根据今天的操作生成的公众号文章并自动发布到公众号的草稿箱,我只用AI设计了封面。
如果喜欢请点下关注,不定时有精彩落出。
你的OPENCLAW,为什么总在同一个地方摔倒?---谈小龙虾的自我进化
从张雪峰被AI复活看OPENCLAW思维蒸馏术—1小时打造4人顶级智囊团
给小龙虾装上眼睛:用 OpenClaw 打造一个 AI 视频监控助手
给你的小龙虾OPENCLAW装上IMA大脑- 技能安装全攻略
OPENCLAW怎么安全巡检:你的AI助手可能正在”越狱”?从 ClawAegis 开源看AI AGENT安全
告别单打独斗:OpenCLAWS 帮你组建专属 AI 工作团队(一)
告别单打独斗:OpenCLAWS 帮你组建专属 AI 工作团队(二)
夜雨聆风