本文承接之前的两篇公众号文章：
从底层机制一文讲透：OpenClaw🦞如何运行多Agents
我在企微里养了130个AI员工：OpenClaw+The Agency实战全记录
一文讲透在同时拥有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. 子代理真的可以直接读到 main 的那条路径 2. 这份 skill 恰好也同步到了子代理自己的 workspace 里 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. 系统最终优先用哪一份 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 才真正从“目录里的文件”，变成了多智能体系统里可维护、可扩展、可复用的能力单元。
