微信扫码
添加专属顾问
我要投稿
探索多智能体共享SKILL库的实战经验,解决技能管理混乱的痛点。核心内容: 1. 多智能体环境下技能库分散带来的管理挑战 2. 尝试原生共享和目录合并两种解决方案的探索过程 3. 发现同名技能内容差异等关键问题的技术细节
背景:我的机器上同时跑了两个 OpenClaw 系智能体,一个安装在
C:\Users\Administrator\openclaw\,另一个是 Claude Code,安装在C:\Users\Administrator\claude\。两边各有各的 skills 目录,逐渐积累出大量重复和分散的 Skill,维护成本越来越高,而且最大的问题是很多技能我也记不得在哪个智能体上安装的了,这还是两个,如果再加上爱玛仕、WORKBUDDY,估计更乱,更无法管理。于是我开始琢磨:能不能让它们共享同一份 SKILL 库?
第一个问题很朴素——两个智能体装在同一个用户下,Skill 能不能直接共用?
翻了一下目录结构:
C:\Users\Administrator\openclaw\skills\ |
||
C:\Users\Administrator\claude\skills\ |
答案取决于 Skill 安装在哪一层:
~/.openclaw/skills/{workspace}/.openclaw/skills/~/.claude/skills/,OpenClaw 读的是 ~/.openclaw/skills/,路径完全不同,互不相通。 各自硬编码了自己的根目录,不会去扫描对方的路径。结论:原生不支持跨智能体共享,需要手动干预。
既然两个目录互不相通,那把文件直接合并到一起呢?
我仔细看了一下两边的 Skill 内容,发现了几个关键问题:
比如两边都有 github 这个 Skill,但 SKILL.md 的 frontmatter 格式有差异:
Claude Code 版本:
---
name:github
description:"Interact with GitHub using the `gh` CLI..."
---
OpenClaw 版本:
---
name:github
description:"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 字段。物理合并只能保留一份,势必丢失某一侧的元数据。
不同平台对 frontmatter 字段的解析能力不同。多余字段通常被静默忽略不会报错,但如果某个平台做了强校验,就可能出问题。
部分 Skill 内含 .sh / .py / .js 脚本,脚本里可能硬编码了相对路径。从不同平台的工作目录调起时,路径解析可能出错。
结论:直接物理合并风险较大,同名冲突不好处理,且后续更新会互相覆盖。
物理合并不行,那就用链接——文件只存一份,两个路径都能访问。
| Junction(目录联接) | New-Item -ItemType Junction |
|||
| Symlink(符号链接) | New-Item -ItemType SymbolicLink |
我检查了一下当前系统的权限状态:
whoami /priv | Select-String 'SeCreateSymbolicLinkPrivilege'
# 输出:SeCreateSymbolicLinkPrivilege Create symbolic links Disabled
Symlink 权限未开启,普通用户无法创建。而 Junction 不需要额外权限,且我的两个目录都在 C 盘,完全满足条件。
决定:用 Junction。
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 全部不会被识别,因为它们在二级目录里。
❌ 不可行。
New-Item -ItemType Junction `
-Path "C:\Users\Administrator\claude\skills\nuwa" `
-Target "C:\Users\Administrator\openclaw\skills\nuwa"
每个 Skill 一个链接,37 个 Skill 要建 37 个 Junction。而且还有同名冲突要先处理。
⚠️ 可行但非常繁琐,后续新增 Skill 还要手动建链接。
思路: 把所有 Skill 统一存放在 OpenClaw 的 openclaw/skills/ 下,删掉 Claude 的 claude/skills/ 目录,用 Junction 让它指向 OpenClaw 的目录。
C:\Users\Administrator\openclaw\skills\ ← 实际文件存放位置(主库)
↑
C:\Users\Administrator\claude\skills\ ← Junction,指向上面
两个智能体读的都是同一份文件,真正共享,零冗余。
✅ 最干净、最省事的方案。
确认方案后,我制定了以下执行步骤:
先列出两边的 Skill 清单,标注重叠项:
┌─────────────────┬──────────┬──────────┐
│ Skill 名称 │ OpenClaw │ Claude │
├─────────────────┼──────────┼──────────┤
│ github │ ✅ (v1.0) │ ✅ (精简) │ ← 重叠,需选版本
│ nuwa │ ✅ │ ❌ │
│ stock-watcher │ ✅ │ ❌ │
│ ... │ ... │ ... │
└─────────────────┴──────────┴──────────┘
对于重叠的 Skill,逐一对比 SKILL.md 内容,选择字段更完整的版本(通常是 OpenClaw 版本,因为它有 description_zh、version 等扩展字段)。
把 Claude 有而 OpenClaw 没有的 Skill,移动(不是复制)到 OpenClaw 的目录:
# 示例:移动 Claude 独有的 Skill
Move-Item -Path "C:\Users\Administrator\claude\skills\some-unique-skill" `
-Destination "C:\Users\Administrator\openclaw\skills\some-unique-skill"
# 整目录备份,防万一
Copy-Item -Path "C:\Users\Administrator\claude\skills" `
-Destination "C:\Users\Administrator\claude\skills-backup-20260426" `
-Recurse
Remove-Item -Path "C:\Users\Administrator\claude\skills" -Recurse -Force
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"
分别在两个智能体中测试:
github),确认无报错删除 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
OpenClaw 版的 SKILL.md 通常包含更多字段(description_zh、version 等),Claude Code 遇到不认识的字段一般会静默忽略,不会报错。但如果你遇到某个 Skill 在 Claude 侧表现异常,可以先检查 frontmatter 是否有特殊字段干扰了解析。
共享后,无论从哪个平台安装新 Skill,文件都会写入 OpenClaw 的目录(因为 Claude 那边是 Junction 指向过去的)。两边立即可见,无需额外操作。
但如果某个平台的 Skill 安装器在安装时做了路径校验(检查是否真的在 claude/skills/ 下),可能会因为实际路径不符而报错。这种情况极少见,但值得留意。
如果你的两个智能体安装在不同分区(比如 C 盘和 D 盘),Junction 就不能用了(它不支持跨分区)。这时需要:
-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 工作团队(二)
金山SKILLS×OpenClaw×云电脑:不吃不喝的新同事来了(附安装教程)
告别手动下载!OpenClaw 自动备份 WPS 近期打开文档实战
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-04-26
谷歌开源一个神级 Skill,斩获 23000+ GitHub Star!
2026-04-26
CLI + Skill 才是造垂直 Agent 的最短路径:从重构飞书知识库说起
2026-04-26
在微信里使用 Claude Code,刚刚在 GitHub 上开源了这个 Skill 。
2026-04-26
写一个Skill: format-markdown:笔记格式美化、AI智能总结排版
2026-04-26
思维系列-如何提升自我思维能力,实现从知识库到经验模式库的跃迁
2026-04-26
数据库 AI Skill 不是 Prompt:从 demo 到可用,中间差的是工程化
2026-04-26
为电脑上的所有 Agent,统一一套 Skill 库
2026-04-26
一句话生成Skill进阶指南:从"能用"到"专业"的跨越
2026-04-05
2026-03-03
2026-03-04
2026-03-03
2026-03-17
2026-03-10
2026-03-17
2026-03-05
2026-03-26
2026-03-05