把OpenClaw从“聊天窗口”变成“干活的手”就差一个Skills我见过太多人把OpenClaw跑起来之后兴冲冲地丢给它一句“帮我把 downloads 文件夹里超过500MB的文件列出来”结果它回了一段完美的Python代码然后客气地补了一句“你可以手动运行这段脚本”。那一刻你会觉得这家伙就是个会打字的百科全书有脑没手。我自己刚接入的时候也踩过这个坑折腾了大半个晚上才搞明白问题不在模型本身而在于我没有告诉OpenClaw“你的手在哪”。这个“手”就是Skills。简单说Skills是OpenClaw用来执行真实操作的能力模块它能调用系统命令、读写文件、请求接口、处理数据并把执行结果交还给模型去整理和汇报。没有Skills模型只能生成“文本”有了Skills模型才能产生“动作”。这篇文章适合两类人一类是刚把OpenClaw跑起来、觉得它只会聊天不会干活的另一类是已经写了几个Skills但发现触发率极低、形同虚设的。我会从原理讲到实操再把最容易翻车的几个坑按排查顺序展开最后聊一聊怎么把零散的Skills组织成一套能让模型“主动起来”的体系。1. 为什么OpenClaw天生只会“答”不会“做”模型与系统之间的断桥如果你不先理解这个断桥后面写Skills也只会靠蒙。大语言模型的本质是一个“文本续写器”。它输入一段文字输出下一段最合理的文字。你说“帮我删掉临时文件”它能理解这句话也能生成一段删除文件的bash命令——但它生成的是“描述动作的文本”不是“动作本身”。就像一位资深顾问可以写出一份详细的施工方案但不会亲自搬砖。要让模型真的去执行必须在模型和操作系统之间架一座桥模型先在对话里声明“我要怎么办”桥接层拿到声明后调用真实工具工具执行完把结果写回对话模型再把结果整理成人话。OpenClaw里的这座桥就是Skills。这个机制在业界有各种叫法Function Calling、Tool Use、插件、动作包。OpenClaw的Skills只是其中一种工程实现但它有几个独特的设计倾向Skill以独立目录存在声明文件、脚本文件、参数定义放在一起模型通过读取Skill的描述来决定“什么时候用、用什么参数”执行环境通过配置决定“哪些Skill允许自动跑、哪些需要人工确认”。理解这三层你才能理解为什么“只写了脚本”不等于“有了Skill”。没有配置Skills的时候OpenClaw面对你的操作请求只有三个选择给出步骤让你自己执行生成代码让你复制去跑或者明确说“我无法直接操作系统”。并不是它不想做而是它没有“可调用动作”的清单。你可以把模型想象成一个新来的实习生他满肚子理论知识但你既没给他门禁卡也没告诉他操作手册在哪他当然只能把建议写在纸上递给你。Skills要解决的就是发门禁卡、定操作手册、规定什么活必须请示、什么活自己看着办这一整套流程。2. 第一个Skills的完整解剖从目录结构到最小执行闭环我习惯用一个非常小、但能完整走通闭环的任务来做第一个Skill比如“日志异常巡检”读取指定的日志文件筛出带有ERROR/WARN的行统计数量并展示前十条。这个任务足够具体、不涉及破坏性操作、结果能直观验证特别适合跑通整条链路。一个Skill在OpenClaw下通常就是这个样子skills/ └── log-inspector/ # 技能目录名字一般用短横线连接 ├── SKILL.md # 给模型看的“说明书” ├── skill.yaml # 给执行器看的“配置单” └── inspect.sh # 真正干活的脚本SKILL.md是给模型看的。OpenClaw会把文件内容塞进模型决策时能看到的上下文里。模型就是通过这份说明来判断“这个技能是干什么的、什么时候该调它、参数怎么填”。所以这份文件的写法直接决定了模型“想不想得到”这个技能。# Log Inspector 分析指定日志文件中的 Error / Warning 级别记录。 当用户提到日志文件、报错信息、异常记录、排查现场时优先考虑使用本技能。 参数说明 - path: 必填日志文件绝对路径 - keyword: 选填追加过滤关键字例如 timeout这里有个容易忽略的点描述里除了写“能干什么”还要写清楚“什么时候用”。模型在对话里看不到你的日志内容它只能靠描述里的关键词去做匹配。如果你只写“分析日志文件”触发率会低得可怜一旦补上“当用户提到日志、报错、异常、排查现场”触发率会明显上升。skill.yaml是给执行环境看的它定义了入口脚本和参数传递方式。一个最小可用的配置大概长这样name: log-inspector description: 日志异常巡检 entry: inspect.sh parameters: - name: path required: true type: string description: 日志文件路径 - name: keyword required: false type: string description: 附加过滤词执行脚本inspect.sh的核心逻辑不需要多复杂关键是三点从参数里拿到path对文件做过滤统计把结果按固定格式输出到标准输出因为OpenClaw会捕获脚本的stdout作为执行结果回传给模型。脚本可能是这样的#!/bin/bash path$1 keyword$2 if [ ! -f $path ]; then echo ERROR: file not found: $path exit 1 fi if [ -n $keyword ]; then patternERROR|WARN echo Lines matching ($pattern) and containing $keyword grep -E $pattern $path | grep $keyword else echo Error/Warning count grep -Ec (ERROR|WARN) $path || true echo First 10 lines grep -E (ERROR|WARN) $path | head -10 fi把这三个文件放进skills目录并在配置文件里声明“skills目录在这”一个最小闭环就成了用户说“看下/etc/app/logs/error.log有没啥异常”模型读到了SKILL.md里“日志、报错、异常”这些关键词决定调用log-inspector参数path被填成/etc/app/logs/error.log脚本跑完把统计结果打印出来模型拿到输出后整理成一句“查到47条错误记录前十条如下……”。到这一步OpenClaw才算真正“做”了一件事而不只是“说”了怎么做。3. 从“能跑”到“主动干活”关键配置与权限边界的设置第一个Skill跑通之后你很快会发现一个尴尬的局面你得明确命令它“用log-inspector去看日志”它才动手。如果不提Skills的名字它又退回纯聊天的老路。这不怪模型是因为OpenClaw默认的决策策略是“按需调用”用户明确要求了模型才会考虑是否调用工具。要让Skill被“主动想起”你必须调整两层东西一是提示词层面的工具可见性二是执行层面的自动运行权限。先说工具可见性。OpenClaw在组装上下文时会从配置的skills目录里读取每个Skill的声明但具体塞多少技能描述进去、哪些优先取决于上下文长度和配置。如果你的配置文件里把skills目录设成了全局目录而里面塞了三十个不相关的技能模型真正拿到的有效描述可能只剩前十项你的log-inspector如果排第二十位模型压根没看见它自然想不起来用。解决办法是避免在一个目录里堆大量低相关度的技能把强相关技能放到同一个目录或者把高优技能写在模型系统提示词里让它们永远出现在模型视野的前排。再说自动运行权限。这是“主动干活”最核心的一道开关。默认情况下OpenClaw把Skill当成“半自动”工具模型可以生成执行请求但执行环境需要等用户确认。这意味着你每次都要点一下确认体验上跟手动跑脚本没太大区别。要实现真正的自动执行需要打开autonomy相关的配置并设置允许自动执行的技能白名单。以我用的配置为例它会解析类似下面这样的配置段skills: directory: ./skills auto_approve: enabled: true allowlist: - log-inspector - file-stats - http-ping ask_for_confirmation: - file-delete - service-restart这里的思路是分级授权低风险、只读类技能放进自动执行白名单模型判断需要时可以直接跑删除文件、重启服务这类有副作用的技能无论模型多想自动都强制要求人工确认。这种设计比较像给实习生发了两把钥匙一扇门随时能进另一扇门必须主管刷卡。OpenClaw的“主动干活”本质上就是在这个授权边界之内允许模型自己判断“现在的场景该不该调用工具”。一旦配置好它会主动调用log-inspector去巡检、主动调用http-ping去探测连通性用户只需要看最终汇报。配置完之后必须验证一件事用一句模糊的、不点名工具的话去测试。比如不说“用log-inspector”只说“我感觉服务最近不太稳你帮我看看日志里有没有异常”。如果模型能自动定位到Skill并执行说明自动决策链路通了如果它只是回你“可以查看日志”那就要检查描述关键词和技能可见性。4. 实测中翻车率最高的三个环节排查思路与解决办法跑通自动执行只是开始真实使用里你会遇到各种“明明配置了却像没配置”的怪现象。我总结出三个翻车率最高的点按排查顺序写在这里大家以后遇到可以先照着检查。第一类问题模型完全不知道有Skill存在。现象是日志里根本没有工具调用记录模型全程在纯文本回答。排查链路是先确认配置里的skills目录路径是否正确再看启动日志里有没有成功加载该Skill的记录然后检查模型上下文里到底有没有出现SKILL.md的内容。很多时候问题出在技能描述太长被上下文管理器截断了或者目录权限不对文件根本没被读取。选型排查的要点是“先看日志再猜模型”不要凭感觉改提示词。第二类问题Skill被调用了但参数解析失败。现象是日志里能看到模型尝试调用工具但脚本秒退或报“parameter error”。这类问题九成出在模型生成的JSON参数和skill.yaml定义不一致。比如模型以为字段叫file_path而你的配置里写的是path或者模型把路径参数填成了数组而不是字符串。我的处理经验是在脚本入口加一层防御性解析不要信任模型生成的JSON结构# 防御性参数解析示例 import sys, json raw sys.argv[1] if len(sys.argv) 1 else {} try: params json.loads(raw) except Exception: params {} path params.get(path) or params.get(file_path) or params.get(target)这样哪怕模型生成了别名参数脚本也能兜住。第三类问题执行成功了但结果没回到对话里。这是最隐蔽的坑。脚本可能把结果写进了result.txt或者只打印到了日志文件但OpenClaw只会捕获脚本的stdout内容作为执行结果。你看模型回复“我已经完成了”可它压根没看到执行结果只是基于“调用成功”的假象在推测。解决方法是养成一个习惯任何Skill脚本关键结论必须打印到标准输出文件路径、退出码、统计结果、异常摘要全都得让模型看得见。你宁可多打印也别让模型“盲猜”。排查这三类问题时我有两个顺手的小工具一是在配置里打开详细执行日志能看到模型决策时到底看到了哪些技能描述二是写一个极简的“echo技能”什么也不干只把传入参数原样打印出来。用它来测试参数链路是否通顺特别快成本几乎为零。5. 让Skills“主动起来”的体系设计从单技能到分工协作单个Skill能自动执行离“主动干活”还有一段距离。我见过很多人配了十个技能最后只有一两个会被频繁触发其余全吃灰。问题在于技能之间没有形成“协作感”模型面对的任务往往需要多个动作组合而你只给了它零散的动作孤岛。要让OpenClaw从“你说一步它动一步”变成“交个目标它自己拆解”需要做三层设计。第一层是触发设计。每个Skill的描述里都要明确“什么时候必须用”“什么时候不要用”这不仅提升命中率还能降低误触发。比如给log-inspector加一句“当用户只是在闲聊网络问题时不要使用本技能”给restart-service加一句“只处理生产环境服务本地开发服务直接拒绝”。负面清单比正面描述更能帮模型做排除决策实测效果非常明显。第二层是分层设计。把技能分成基础技能、判断技能、编排技能。基础技能是真实动作如读日志、发请求、执行备份判断技能不直接干变化性的活只检查环境状态比如“磁盘剩余量是否低于20%”“端口是否在监听”编排技能不自己动手而是负责设计流程先跑判断技能拿到结果后才决定是否调用基础技能组合成一条可执行链路。举个我常用的例子夜间巡检流程OpenClaw会先调用disk-check判断磁盘使用率如果超过阈值再调用log-inspector看是哪个服务在写大量日志然后定位到具体目录执行清理只有当所有条件都满足时才会调用需要人工确认的清理脚本。这就是一个典型的“判断技能驱动基础技能”的编排结构。第三层是失败回退设计。技能执行不可能永远成功日志文件不存在、接口超时、权限不足。一开始我写的Skill失败后只会return 1模型就回一句“执行失败”然后结束。正确的做法是让每个Skill在失败时输出可读的错误原因和可能的替代方案比如“文件不存在请检查路径或尝试用find技能定位日志位置”。模型拿到这些信息后会自己另想办法。这套机制的投入产出比极高一个小时的改进能消灭大量“卡死在半路”的情况。最后是复盘。用了一个月之后我去翻了执行日志发现三个技能从未被触发。逐一检查后发现一个是描述里的关键词离真实对话太远一个是功能被另一个成体系的高优Skill覆盖还有一个纯粹是因为上下文太长被挤出了名单。修完它们的共同思路不是改代码而是改SKILL.md里的“何时使用”描述并给高优先级流程做一次上下文拼接优化。这个过程让我确信Skills体系不是一次性搭建而是持续调参才能越来越聪明的。6. 关于“主动干活”这件事我的几点真实体会跑了一段时间之后我对“OpenClaw Skills 主动干活”这件事最大的感受是它不会像科幻电影里那样突然开窍而是一个渐进增强的过程。最开始它是“你推一步它走一步”配置好白名单后它变成“能看到局部目标并自行行动”等技能分层和回退设计做完它才开始像“能承接一个模糊目标并拆分执行”的初级数字员工。这中间的变量不是模型本身而是你给它的“手”够不够清晰、够不够可靠。如果你正准备上手我的建议是不要一口气写十个Skills。挑一个你每天都在重复的、低风险的、结果容易验证的小任务比如日志巡检、磁盘统计、定时网页抓取先把一个Skill的自动触发链路跑顺。确认它能主动干活了再考虑第二个。另外一个小技巧可能对其他人都适用在SKILL.md里先写“什么时候不要用”再写“什么时候用”这会让模型的决策准确率高出一截因为我实测过只写正向触发条件的Skill误触发率大概在15%到20%加上负面清单后能降到5%以下。先让模型知道“不要干涉什么”它才知道“该主动去做什么”。
把OpenClaw从“聊天窗口”变成“干活的手”就差一个Skills我见过太多人把OpenClaw跑起来之后兴冲冲地丢给它一句“帮我把 downloads 文件夹里超过500MB的文件列出来”结果它回了一段完美的Python代码然后客气地补了一句“你可以手动运行这段脚本”。那一刻你会觉得这家伙就是个会打字的百科全书有脑没手。我自己刚接入的时候也踩过这个坑折腾了大半个晚上才搞明白问题不在模型本身而在于我没有告诉OpenClaw“你的手在哪”。这个“手”就是Skills。简单说Skills是OpenClaw用来执行真实操作的能力模块它能调用系统命令、读写文件、请求接口、处理数据并把执行结果交还给模型去整理和汇报。没有Skills模型只能生成“文本”有了Skills模型才能产生“动作”。这篇文章适合两类人一类是刚把OpenClaw跑起来、觉得它只会聊天不会干活的另一类是已经写了几个Skills但发现触发率极低、形同虚设的。我会从原理讲到实操再把最容易翻车的几个坑按排查顺序展开最后聊一聊怎么把零散的Skills组织成一套能让模型“主动起来”的体系。1. 为什么OpenClaw天生只会“答”不会“做”模型与系统之间的断桥如果你不先理解这个断桥后面写Skills也只会靠蒙。大语言模型的本质是一个“文本续写器”。它输入一段文字输出下一段最合理的文字。你说“帮我删掉临时文件”它能理解这句话也能生成一段删除文件的bash命令——但它生成的是“描述动作的文本”不是“动作本身”。就像一位资深顾问可以写出一份详细的施工方案但不会亲自搬砖。要让模型真的去执行必须在模型和操作系统之间架一座桥模型先在对话里声明“我要怎么办”桥接层拿到声明后调用真实工具工具执行完把结果写回对话模型再把结果整理成人话。OpenClaw里的这座桥就是Skills。这个机制在业界有各种叫法Function Calling、Tool Use、插件、动作包。OpenClaw的Skills只是其中一种工程实现但它有几个独特的设计倾向Skill以独立目录存在声明文件、脚本文件、参数定义放在一起模型通过读取Skill的描述来决定“什么时候用、用什么参数”执行环境通过配置决定“哪些Skill允许自动跑、哪些需要人工确认”。理解这三层你才能理解为什么“只写了脚本”不等于“有了Skill”。没有配置Skills的时候OpenClaw面对你的操作请求只有三个选择给出步骤让你自己执行生成代码让你复制去跑或者明确说“我无法直接操作系统”。并不是它不想做而是它没有“可调用动作”的清单。你可以把模型想象成一个新来的实习生他满肚子理论知识但你既没给他门禁卡也没告诉他操作手册在哪他当然只能把建议写在纸上递给你。Skills要解决的就是发门禁卡、定操作手册、规定什么活必须请示、什么活自己看着办这一整套流程。2. 第一个Skills的完整解剖从目录结构到最小执行闭环我习惯用一个非常小、但能完整走通闭环的任务来做第一个Skill比如“日志异常巡检”读取指定的日志文件筛出带有ERROR/WARN的行统计数量并展示前十条。这个任务足够具体、不涉及破坏性操作、结果能直观验证特别适合跑通整条链路。一个Skill在OpenClaw下通常就是这个样子skills/ └── log-inspector/ # 技能目录名字一般用短横线连接 ├── SKILL.md # 给模型看的“说明书” ├── skill.yaml # 给执行器看的“配置单” └── inspect.sh # 真正干活的脚本SKILL.md是给模型看的。OpenClaw会把文件内容塞进模型决策时能看到的上下文里。模型就是通过这份说明来判断“这个技能是干什么的、什么时候该调它、参数怎么填”。所以这份文件的写法直接决定了模型“想不想得到”这个技能。# Log Inspector 分析指定日志文件中的 Error / Warning 级别记录。 当用户提到日志文件、报错信息、异常记录、排查现场时优先考虑使用本技能。 参数说明 - path: 必填日志文件绝对路径 - keyword: 选填追加过滤关键字例如 timeout这里有个容易忽略的点描述里除了写“能干什么”还要写清楚“什么时候用”。模型在对话里看不到你的日志内容它只能靠描述里的关键词去做匹配。如果你只写“分析日志文件”触发率会低得可怜一旦补上“当用户提到日志、报错、异常、排查现场”触发率会明显上升。skill.yaml是给执行环境看的它定义了入口脚本和参数传递方式。一个最小可用的配置大概长这样name: log-inspector description: 日志异常巡检 entry: inspect.sh parameters: - name: path required: true type: string description: 日志文件路径 - name: keyword required: false type: string description: 附加过滤词执行脚本inspect.sh的核心逻辑不需要多复杂关键是三点从参数里拿到path对文件做过滤统计把结果按固定格式输出到标准输出因为OpenClaw会捕获脚本的stdout作为执行结果回传给模型。脚本可能是这样的#!/bin/bash path$1 keyword$2 if [ ! -f $path ]; then echo ERROR: file not found: $path exit 1 fi if [ -n $keyword ]; then patternERROR|WARN echo Lines matching ($pattern) and containing $keyword grep -E $pattern $path | grep $keyword else echo Error/Warning count grep -Ec (ERROR|WARN) $path || true echo First 10 lines grep -E (ERROR|WARN) $path | head -10 fi把这三个文件放进skills目录并在配置文件里声明“skills目录在这”一个最小闭环就成了用户说“看下/etc/app/logs/error.log有没啥异常”模型读到了SKILL.md里“日志、报错、异常”这些关键词决定调用log-inspector参数path被填成/etc/app/logs/error.log脚本跑完把统计结果打印出来模型拿到输出后整理成一句“查到47条错误记录前十条如下……”。到这一步OpenClaw才算真正“做”了一件事而不只是“说”了怎么做。3. 从“能跑”到“主动干活”关键配置与权限边界的设置第一个Skill跑通之后你很快会发现一个尴尬的局面你得明确命令它“用log-inspector去看日志”它才动手。如果不提Skills的名字它又退回纯聊天的老路。这不怪模型是因为OpenClaw默认的决策策略是“按需调用”用户明确要求了模型才会考虑是否调用工具。要让Skill被“主动想起”你必须调整两层东西一是提示词层面的工具可见性二是执行层面的自动运行权限。先说工具可见性。OpenClaw在组装上下文时会从配置的skills目录里读取每个Skill的声明但具体塞多少技能描述进去、哪些优先取决于上下文长度和配置。如果你的配置文件里把skills目录设成了全局目录而里面塞了三十个不相关的技能模型真正拿到的有效描述可能只剩前十项你的log-inspector如果排第二十位模型压根没看见它自然想不起来用。解决办法是避免在一个目录里堆大量低相关度的技能把强相关技能放到同一个目录或者把高优技能写在模型系统提示词里让它们永远出现在模型视野的前排。再说自动运行权限。这是“主动干活”最核心的一道开关。默认情况下OpenClaw把Skill当成“半自动”工具模型可以生成执行请求但执行环境需要等用户确认。这意味着你每次都要点一下确认体验上跟手动跑脚本没太大区别。要实现真正的自动执行需要打开autonomy相关的配置并设置允许自动执行的技能白名单。以我用的配置为例它会解析类似下面这样的配置段skills: directory: ./skills auto_approve: enabled: true allowlist: - log-inspector - file-stats - http-ping ask_for_confirmation: - file-delete - service-restart这里的思路是分级授权低风险、只读类技能放进自动执行白名单模型判断需要时可以直接跑删除文件、重启服务这类有副作用的技能无论模型多想自动都强制要求人工确认。这种设计比较像给实习生发了两把钥匙一扇门随时能进另一扇门必须主管刷卡。OpenClaw的“主动干活”本质上就是在这个授权边界之内允许模型自己判断“现在的场景该不该调用工具”。一旦配置好它会主动调用log-inspector去巡检、主动调用http-ping去探测连通性用户只需要看最终汇报。配置完之后必须验证一件事用一句模糊的、不点名工具的话去测试。比如不说“用log-inspector”只说“我感觉服务最近不太稳你帮我看看日志里有没有异常”。如果模型能自动定位到Skill并执行说明自动决策链路通了如果它只是回你“可以查看日志”那就要检查描述关键词和技能可见性。4. 实测中翻车率最高的三个环节排查思路与解决办法跑通自动执行只是开始真实使用里你会遇到各种“明明配置了却像没配置”的怪现象。我总结出三个翻车率最高的点按排查顺序写在这里大家以后遇到可以先照着检查。第一类问题模型完全不知道有Skill存在。现象是日志里根本没有工具调用记录模型全程在纯文本回答。排查链路是先确认配置里的skills目录路径是否正确再看启动日志里有没有成功加载该Skill的记录然后检查模型上下文里到底有没有出现SKILL.md的内容。很多时候问题出在技能描述太长被上下文管理器截断了或者目录权限不对文件根本没被读取。选型排查的要点是“先看日志再猜模型”不要凭感觉改提示词。第二类问题Skill被调用了但参数解析失败。现象是日志里能看到模型尝试调用工具但脚本秒退或报“parameter error”。这类问题九成出在模型生成的JSON参数和skill.yaml定义不一致。比如模型以为字段叫file_path而你的配置里写的是path或者模型把路径参数填成了数组而不是字符串。我的处理经验是在脚本入口加一层防御性解析不要信任模型生成的JSON结构# 防御性参数解析示例 import sys, json raw sys.argv[1] if len(sys.argv) 1 else {} try: params json.loads(raw) except Exception: params {} path params.get(path) or params.get(file_path) or params.get(target)这样哪怕模型生成了别名参数脚本也能兜住。第三类问题执行成功了但结果没回到对话里。这是最隐蔽的坑。脚本可能把结果写进了result.txt或者只打印到了日志文件但OpenClaw只会捕获脚本的stdout内容作为执行结果。你看模型回复“我已经完成了”可它压根没看到执行结果只是基于“调用成功”的假象在推测。解决方法是养成一个习惯任何Skill脚本关键结论必须打印到标准输出文件路径、退出码、统计结果、异常摘要全都得让模型看得见。你宁可多打印也别让模型“盲猜”。排查这三类问题时我有两个顺手的小工具一是在配置里打开详细执行日志能看到模型决策时到底看到了哪些技能描述二是写一个极简的“echo技能”什么也不干只把传入参数原样打印出来。用它来测试参数链路是否通顺特别快成本几乎为零。5. 让Skills“主动起来”的体系设计从单技能到分工协作单个Skill能自动执行离“主动干活”还有一段距离。我见过很多人配了十个技能最后只有一两个会被频繁触发其余全吃灰。问题在于技能之间没有形成“协作感”模型面对的任务往往需要多个动作组合而你只给了它零散的动作孤岛。要让OpenClaw从“你说一步它动一步”变成“交个目标它自己拆解”需要做三层设计。第一层是触发设计。每个Skill的描述里都要明确“什么时候必须用”“什么时候不要用”这不仅提升命中率还能降低误触发。比如给log-inspector加一句“当用户只是在闲聊网络问题时不要使用本技能”给restart-service加一句“只处理生产环境服务本地开发服务直接拒绝”。负面清单比正面描述更能帮模型做排除决策实测效果非常明显。第二层是分层设计。把技能分成基础技能、判断技能、编排技能。基础技能是真实动作如读日志、发请求、执行备份判断技能不直接干变化性的活只检查环境状态比如“磁盘剩余量是否低于20%”“端口是否在监听”编排技能不自己动手而是负责设计流程先跑判断技能拿到结果后才决定是否调用基础技能组合成一条可执行链路。举个我常用的例子夜间巡检流程OpenClaw会先调用disk-check判断磁盘使用率如果超过阈值再调用log-inspector看是哪个服务在写大量日志然后定位到具体目录执行清理只有当所有条件都满足时才会调用需要人工确认的清理脚本。这就是一个典型的“判断技能驱动基础技能”的编排结构。第三层是失败回退设计。技能执行不可能永远成功日志文件不存在、接口超时、权限不足。一开始我写的Skill失败后只会return 1模型就回一句“执行失败”然后结束。正确的做法是让每个Skill在失败时输出可读的错误原因和可能的替代方案比如“文件不存在请检查路径或尝试用find技能定位日志位置”。模型拿到这些信息后会自己另想办法。这套机制的投入产出比极高一个小时的改进能消灭大量“卡死在半路”的情况。最后是复盘。用了一个月之后我去翻了执行日志发现三个技能从未被触发。逐一检查后发现一个是描述里的关键词离真实对话太远一个是功能被另一个成体系的高优Skill覆盖还有一个纯粹是因为上下文太长被挤出了名单。修完它们的共同思路不是改代码而是改SKILL.md里的“何时使用”描述并给高优先级流程做一次上下文拼接优化。这个过程让我确信Skills体系不是一次性搭建而是持续调参才能越来越聪明的。6. 关于“主动干活”这件事我的几点真实体会跑了一段时间之后我对“OpenClaw Skills 主动干活”这件事最大的感受是它不会像科幻电影里那样突然开窍而是一个渐进增强的过程。最开始它是“你推一步它走一步”配置好白名单后它变成“能看到局部目标并自行行动”等技能分层和回退设计做完它才开始像“能承接一个模糊目标并拆分执行”的初级数字员工。这中间的变量不是模型本身而是你给它的“手”够不够清晰、够不够可靠。如果你正准备上手我的建议是不要一口气写十个Skills。挑一个你每天都在重复的、低风险的、结果容易验证的小任务比如日志巡检、磁盘统计、定时网页抓取先把一个Skill的自动触发链路跑顺。确认它能主动干活了再考虑第二个。另外一个小技巧可能对其他人都适用在SKILL.md里先写“什么时候不要用”再写“什么时候用”这会让模型的决策准确率高出一截因为我实测过只写正向触发条件的Skill误触发率大概在15%到20%加上负面清单后能降到5%以下。先让模型知道“不要干涉什么”它才知道“该主动去做什么”。
原理与调优实战：从算法到线上内存排查)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
