Skills 装好了却不调用,这个问题我最近碰得比安装失败还多。因为它看起来像“功能坏了”,实际上往往只是触发条件、权限或者环境变量没有对上。
所以这篇不再讲怎么安装,我只讲怎么排。你可以把它当成一个现场排查清单来用。
先判断是没加载、没资格、没触发,还是被环境和权限挡住了。
一、第一步先看它有没有资格被调用
openclaw skills list
openclaw skills list --eligible
openclaw skills info deploy-helper如果 list 能看到、但 list --eligible 看不到,这时就别再怀疑提示词了,先去查依赖。
| 表现 | 先查什么 | 我通常怎么修 |
|---|---|---|
技能完全不在 list 里 | 目录位置和文件名 | 先确认是不是放错了目录, |
在 list 里,但不在 eligible 里 | 二进制和环境变量 | 优先看 |
eligible 正常,但还是不触发 | 提示词是否具体 | 第一次调试时我会直接点名 Skill,先验证链路,再追求自然触发。 |
本机能跑,沙箱里不行 | 容器内依赖 | 宿主机有命令不代表隔离环境也有,需要把依赖一并装进容器。 |
偶发触发、偶发不触发 | 工作区范围 | 检查 Skill 是全局的还是项目级的,别在 A 项目里调 B 项目的技能。 |
二、环境变量是最容易漏的点
很多 Skill 看起来像是“不会调用”,实际是它要求的环境变量根本不存在。这个坑尤其容易出现在你换了终端、换了启动方式或者换了用户之后。
echo "$KUBECONFIG"
echo "$GITHUB_TOKEN"
which kubectl
which rg我一般会把 openclaw skills info <name> 输出里的依赖抄出来,和当前 shell 里的变量、命令逐个核一下,别凭感觉猜。
顺序别反了:先确认资格,再查环境,再修提示词,最后再看权限策略。
三、提示词写得太泛,也会让技能像没装一样
反例:帮我看看这个项目。
正例:请用 deploy-helper 这个 skill 检查 test 命名空间里 payment 服务的 deployment、pod 和 events。不是说每次都必须手动点名 Skill,而是排查阶段要故意把问题收窄。这样你能很快分清楚到底是触发规则的问题,还是技能本身根本不可用。
四、如果你怀疑是日志问题,我会这么看
[skills] skipped deploy-helper: missing env KUBECONFIG
[skills] skipped repo-grep: missing bin rg inside sandbox
[skills] deploy-helper loaded and eligible上面这种日志格式是我现场经常会整理出来的关键点,不一定和你环境里一模一样,但排查思路是一样的:先找 skipped 原因,再找 eligible 结论。
五、最后给你一个最小排查顺序
先跑
openclaw skills list,确认它被扫描到了。再跑
openclaw skills list --eligible,确认不是依赖缺失。用
openclaw skills info <name>对照环境变量、PATH 和配置项。把提示词改成非常具体的场景,最好第一轮直接点名 Skill。
如果宿主机正常、沙箱异常,再补容器内依赖。











还没有评论,来说两句吧...