一文讲透：OpenClaw多agent模式下Skills的分层调用机制

一文讲透：OpenClaw多agent模式下Skills的分层调用机制 一文讲透：OpenClaw多agent模式下Skills的分层调用机制 Modified March 17 • /.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 • 配置额外声明的公共 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 才真正从“目录里的文件”，变成了多智能体系统里可维护、可扩展、可复用的能力单元。 🔗 原文链接： https://mp.weixin.qq.com/s/rFecRxZ1... https://mp.weixin.qq.com/s/rFecRxZ1... 原创 DracoVibeCoding DracoVibeCoding Draco正在VibeCoding2026年3月17日 07:30 海南 本文承接之前的两篇公众号文章： 从底层机制一文讲透：OpenClaw🦞如何运行多Agents 从底层机制一文讲透：OpenClaw🦞如何运行多Agents 我在企微里养了130个AI员工：OpenClaw+The Agency实战全记录 我在企微里养了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 看起来会像这样： 其中： 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