1. OpenClaw multi-agent 里 Skills 分层调用到底难在哪OpenClaw 跑 multi-agent 时Skills 分层调用机制是很多人绕不过去的一道坎。它决定了 main agent、agency-agents、sub-agent 各自能看到哪些 skill、执行哪些 workflow也决定了你写的 SKILL.md 和 scripts 到底有没有被真正加载。如果你正在用 OpenClaw 做多智能体协作或者刚接触它的 skills 体系这篇文章会帮你把 tool 与 skill 的区别、三层 skill 发现机制、以及跨 agent 可见性实测方法一次讲清楚。我见过太多人第一次配 OpenClaw 的 skills直接把 skill 当成 tool 来理解结果目录放错、sub-agent 读不到、同名 skill 生效的不是自己改的那份。更麻烦的是当模型请求通道和 skill 目录问题混在一起时你根本分不清是技能没被发现还是模型调用配置出了岔子。所以这篇会先把 skill 放置策略讲透再把模型通道统一到 TaoToken让每一层 agent 执行 SKILL.md scripts 工作流时都走同一条请求路径这样排障时才能把变量一个个隔离出来。核心检索词先摆在这OpenClaw 是什么、它能做什么、适合谁。OpenClaw 是一个支持多 agent 协作的运行时框架skill 是它的工作流方法层tool 是能力层。适合正在做 multi-agent 编排、想让 main agent 和 sub-agent 共享或隔离 workflow 的开发者。下面从 tool 与 skill 的本质区别开始拆。2. 先分清 tool 和 skill再谈分层2.1 tool 是能力skill 是方法在 OpenClaw 里tool 更像“手和脚”是 agent 能直接调用的操作能力比如 read、write、edit、exec、browser、sessions_spawn、memory_search。tool 决定的是“能不能做”——能不能读文件、能不能起子代理、能不能控制浏览器。skill 则是“作战手册”或“标准流程”。一个 skill 通常告诉 agent什么场景下启用它、先读哪个 SKILL.md、遇到问题走什么 workflow、需要哪些脚本和参考资料。skill 解决的是“应该怎么做、按什么步骤做”。一句话tool 是能力层skill 是方法层。所以“一个 agent 看得见某个 skill”不等于“它一定能执行成功”还要看 tool 权限、文件路径可访问性、workspace 资源可见性、以及 skill 过滤规则。2.2 一个 skill 目录里通常有什么最核心的入口文件是 SKILL.md此外还可能带 references/、scripts/、示例文件和配套说明。典型结构如下some-skill/ ├── SKILL.md ├── references/ │ └── workflow.md └── scripts/ └── helper.pySKILL.md 说明触发条件、执行顺序、需要读哪些参考文件、调用哪些脚本references/ 放 API 参考、工作流说明、复杂规则scripts/ 放真正复用的脚本。所以 skill 不是单个 markdown 文件而是一组围绕任务组织的资源。3. TaoToken 前置把模型通道统一起来在验证 sub-agent 能不能读到共享 skill 之前先把模型请求通道固定下来。这一步很关键因为如果每个 agent 走不同通道你排查 skill 可见性时就会混入模型调用配置的干扰。打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 Key然后把 Base URL 填成 https://taotoken.net/api。这样 OpenClaw 各层 agent 在执行 SKILL.md scripts 工作流时模型请求都走 TaoToken 统一通道。具体操作路径注册并登录后进入控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite在 API Keys 页面创建密钥https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite需要确认模型可用性时用模型对话页测试https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite接入细节查文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite如果你长期跑编码类 agent 或 Agent 编排可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite注意Base URL 只填 https://taotoken.net/api不要带任何路径后缀。Key 建议放在环境变量里不要硬编码进 SKILL.md 或 scripts。4. 可复制配置三层 skill 发现机制与目录放置4.1 三层 skill 来源OpenClaw 会从多个层次发现 skill可以理解成三层第一层是全局安装层随 OpenClaw 一起分发的通用 skill典型位置类似.../node_modules/openclaw/skills常见的有 skill-creator、healthcheck、tmux、clawhub、video-frames、weather。第二层是共享层扫描不属于某个单独 agent workspace 的公共目录例如~/.openclaw/skills、~/.agents/skills。这层适合放跨 agent 复用的自定义 skill。第三层是 agent 自己的 workspace 层例如~/.openclaw/workspace/skills、~/.openclaw/agency-agents/agent-id/skills、~/.openclaw/workspace/.agents/skills。这层是某个特定 agent 的本地技能库。4.2 环境变量与通道配置把模型通道写进 OpenClaw 的配置或环境变量让所有 agent 共用export TAOTOKEN_API_KEY你的Key export OPENCLAW_MODEL_BASE_URLhttps://taotoken.net/api export OPENCLAW_MODEL_API_KEY$TAOTOKEN_API_KEY如果 OpenClaw 用配置文件管理模型通道可以写成类似结构{ model: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKeyEnv: TAOTOKEN_API_KEY, model: claude-sonnet } }4.3 skill 放置策略对照层级典型路径适合放什么跨 agent 可见性全局安装层.../node_modules/openclaw/skills官方通用 skill最广通常各 agent 都可见共享层~/.openclaw/skills、~/.agents/skills机器级公共 workflow较广main 与 imported agent 大概率可见workspace 私有层~/.openclaw/workspace/skills、~/.openclaw/agency-agents/agent-id/skills角色专用流程仅本 workspace不默认共享把公共能力放共享层角色专用流程放各自 workspace这是最稳的架构原则。5. 验证请求抽样实测 sub-agent 的 skill 可见性5.1 先确认模型通道通了在验证 skill 之前先确认模型请求能走通。用 curl 打一次curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet, messages: [{role: user, content: ping}] }返回正常内容说明通道没问题。这一步排除掉模型调用配置的干扰后面 skill 可见性问题就纯粹是目录和发现机制的事了。5.2 抽样实测共享 skill 是否被 sub-agent 读到不要只靠猜目录。在共享层放一个测试 skill~/.openclaw/skills/visibility-probe/ ├── SKILL.md └── scripts/ └── probe.shSKILL.md 内容写清楚触发条件和执行步骤probe.sh 里输出当前 agent 身份和 workspace 路径#!/usr/bin/env bash echo agent$OPENCLAW_AGENT_ID echo workspace$OPENCLAW_WORKSPACE echo skill_path$(dirname $0)然后通过 sessions_spawn 拉起 sub-agent让它执行这个 skill观察输出里的 agent 身份和 skill_path。如果 sub-agent 能打印出共享层的路径说明共享层对它可见如果读不到再检查是不是被放到了 main 的私有 workspace 里。5.3 同名 skill 优先级实测如果同名 skill 同时出现在全局安装层、共享层、main 的 workspace/skills要确认系统最终用哪一份。在每份 SKILL.md 里加一行版本标记比如version: global、version: shared、version: workspace然后触发执行看输出的是哪个版本。这一步能避免“你以为改了 skill实际运行时读的是另一个目录同名版本”的坑。6. 本篇常见错排查6.1 sub-agent 读不到共享 skill先确认 skill 确实在共享层而不是只在 main 的 workspace 里。再检查 sub-agent 的 tools policy 是否允许读该路径以及是否有 skills filter 把它禁掉。最后用 5.2 的 probe 脚本实测别靠目录猜测。6.2 模型请求报错误判成 skill 问题如果 agent 执行 skill 时报的是模型调用错误先回到 5.1 用 curl 验证通道。Base URL 写成 https://taotoken.net/api不要多加/v1之外的路径。Key 失效或额度不足也会表现为 skill 执行失败先排除通道再查目录。6.3 同名 skill 生效的不是自己改的那份按 5.3 加版本标记实测优先级。维护 skill 时把来源标注清楚官方内置版、本机共享版、某 agent 私有版、本地覆盖版。这样后期排障成本会低很多。6.4 imported agent 之间 skill 不互通main agent 的本地 workspace skill 不天然等于所有 imported agent 的本地 skill。要让多个 agent 复用就放到~/.openclaw/skills或~/.agents/skills而不是藏在某个 workspace 里。7. 把技能放置和模型通道一起纳入编排Skill 不是“一个统一目录里的插件列表”而是一套分层发现、按 workspace 和共享范围组织起来的工作流系统。tool 是能力skill 是方法skill 可以来自全局安装层、共享层、各 agent 的 workspace 层main agent、agency-agents、sub-agent 不一定天然共享所有私有 skill。真正稳定的跨 agent 共享应该依靠明确的共享层而不是隐含假设。同时把模型通道统一到 TaoToken让各层 agent 执行 SKILL.md scripts 时都走同一条请求路径这样排障时才能把技能目录问题和模型调用配置问题分开。需要创建 Key 并接入的从这里开始https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite长期跑编码和 Agent 编排的看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite验证模型可用性https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite通用能力放公共层角色能力放私有层让 agent 在合适范围内共享合适的 workflow。这时候 skills 才真正从“目录里的文件”变成多智能体系统里可维护、可扩展、可复用的能力单元。