理柴德波浪技术我是那种喜欢把东西拆开看的人。拿到OpenClaw的第一天，我打开它的目录结构，翻了半天文档，心里一直有个疑问：这个叫Skill的东西，到底和插件、和MCP有什么区别？为什么官方教程反复强调Skill是扩展OpenClaw能力的核心方式？后来真正动手写完第一个Skill，我才反应过来——它其实没有我想的那么玄乎，本质上就是一份给AI看的"操作说明书"，外加几个脚本。这篇就从头讲讲，我自己是怎么开发第一个OpenClaw Skill的，踩了什么坑，以及最后把它打磨到稳定好用的完整过程。
如果你是刚装好OpenClaw、还不知道下一步该干嘛的人，或者你已经能用OpenClaw聊天，但希望它真正帮你干活——比如查资料、算日期、调API、读文档、生成固定格式的报表——那这篇内容正好适合你。
1. 先搞明白一件事：Skill到底是什么
在动手写代码之前，我建议你先花十分钟搞清楚OpenClaw里Agent的工作方式，不然你写出来的Skill大概率就是"能用但不好用"。
1.1 Agent不是靠代码驱动的，是靠"说明书"驱动的
OpenClaw的底层是一个大模型驱动的Agent。这个Agent本身没有什么固定能力，它的一切行为都来自大模型的推理。那大模型是怎么知道"哦，这时候应该调用这个工具"的？答案是它读取了每个Skill的description（描述）。
你想想这个链路：用户问了一句"帮我看看我的服务器日志里有没有报错"，Agent接收到这句话后，会把它自己可见的所有工具的description都扫一遍，然后根据语义匹配，判断"这个问题应该用哪个Skill来处理"。匹配上了，它就把对应的SKILL.md文档读进上下文，照着文档里的指令去执行脚本、解析结果，最后把结果整理成自然语言回复给用户。
所以，Skill的本质是一份给人看的文档、但主要给AI看的操作手册。你写Skill的时候，不是写给编译器看的，而是写给一个"很聪明但有时候会犯迷糊的实习生"看的。
1.2 Skill、Plugin、MCP这堆概念到底有什么区别
我自己刚接触的时候，这三个概念绕了很久。后来用一个类比才彻底捋清楚：
- Plugin：相当于给程序装了一个"内嵌模块"。它往往是编译进进程里的代码，改造的是程序本身的能力，开发成本高、和平台耦合深。
- MCP（Model Context Protocol）：相当于一个"标准电源插头"。它定义了一套统一的协议，让Agent能通过这个插头去调用任何外部服务——数据库、浏览器、第三方API，只要对方实现了MCP的服务端，Agent就能即插即用。它解决的是"工具怎么被连接"的问题。
- Skill：相当于"岗位手册+随身工具包"。它由一份SKILL.md文档（手册）和若干可执行脚本（工具）组成。它解决的是"Agent怎么把一个活干好"的问题——怎么做、分几步、遇到什么情况怎么处理、输出什么格式。
三者不是竞争关系，而是互补关系。我现在的做法很简单：凡是标准的、通用的工具对接，优先考虑MCP；凡是需要组合逻辑、多步骤流程、业务规则的自定义能力，写成Skill。
| 维度 | Skill | MCP |
|---|---|---|
| 本质 | 技能包（文档 + 脚本） | 标准工具调用协议 |
| 开发成本 | 低，会Markdown和简单脚本即可 | 中等，需要实现协议接口 |
| 适用场景 | 教会Agent新能力、组合流程 | 对接外部系统、复用已有工具 |
| 运行方式 | LLM读文档、按指令执行脚本 | Agent通过协议调用服务端工具 |
| 典型例子 | 日期计算、报告生成、文档摘要 | 数据库查询、浏览器操作、Git操作 |
1.3 Skill在OpenClaw里的完整运行链路
理解完概念，再看运行链路就清楚了。一次完整的Skill调用大概分五步：
- 用户输入请求。
- Agent（也就是LLM）根据请求内容，结合所有已加载Skill的description，选出一个最匹配的Skill。
- Agent读取该Skill目录下的SKILL.md，把文档里的指令当作行动指南。
- 如果指令里定义了要执行脚本，Agent就启动脚本，传入参数，等待输出。
- Agent拿到脚本输出后，结合原始用户请求，组织成自然语言回答用户。
这个链路最关键的优化点在第2步和第5步：description写得好不好，决定了Agent能不能在正确的时候选中这个Skill；SKILL.md里对输出字段的解释清不清楚，决定了Agent能不能正确理解脚本的输出。 这两个点，正是新手最容易忽略的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手前先摸清OpenClaw的Skills目录和文件约定
写Skill不需要改OpenClaw框架的源码，但你需要知道它把Skill放在哪、以什么格式识别。这一步要是搞错了，后面全白搭。
2.1 Skills目录到底在哪
我第一次找这个目录就找了半天。OpenClaw没有把所有的东西都塞到一个地方，它的Skills目录位置取决于你的部署方式：
- 本机命令行方式安装：通常在
~/.openclaw/skills/目录下。 - Docker方式部署：通常在挂载卷里的某个路径，比如
/app/assets/skills/或/data/skills/，具体看你的docker-compose.yml里怎么配的。 - 项目源码方式运行：在项目根目录下的
skills/子目录。
最稳的定位方法是直接看启动日志。OpenClaw启动时会在日志里打印"scanning skills from ..."这样的信息，你顺着日志就能找到实际路径。我前前后后装了好几次OpenClaw，每次都会先来这么一步：启动后立刻去日志里确认skills目录路径，避免后续所有操作都建立在错误前提上。
2.2 SKILL.md是谁在读取
这个文件是整个Skill的灵魂。它采用Markdown格式，开头有一个YAML格式的front-matter区域，里面定义了这个Skill的元信息：
yaml复制---
name: skill_name
description: 一句话说明这个Skill是干嘛的、什么场景下调用、需要哪些参数
---
name 是Skill的标识符，description 是给Agent看的"征友启事"。description写得好不好，直接决定Agent会不会在合适的场景下点开你的Skill。 我见过很多新手（包括我自己第一次）把description写成一两句话，比如"处理日期查询"，结果Agent在用户问"后天星期几"时完全想不起来用这个Skill。
后面我会专门展开讲description怎么写，这里先记住一句话：description是给大模型做语义匹配用的，不是给你自己看的，你要把各种问法都写进去。
2.3 Skill目录的文件布局约定
一个标准的Skill目录长这样：
code复制skills/
└── date_time/
├── SKILL.md
├── scripts/
│ └── datetime_helper.py
└── assets/ # 可选，放参考文档、模板等
SKILL.md：必填，Agent的操作手册。scripts/：可选，放可执行脚本。Python、Shell、Node.js都行，只要是SKILL.md里写清楚怎么调用。assets/：可选，放Skill运行时要读取的参考文件。
目录命名我建议统一用小写字母加下划线（date_time），这样在命令行和文档里引用都方便。OpenClaw对目录名和name字段之间没有强制一致的要求，但为了排查方便，强烈建议保持一致。
3. 从零写一个"日期时间查询"Skill：完整实现过程
理论讲再多，不如动手写一个。我选的这个例子特意强调"简单但完整"：不用注册API、不需要密钥、不依赖外部服务，但涵盖了Skill开发的所有核心要素——目录结构、SKILL.md写法、脚本调用约定、参数传递、结果解析。
3.1 需求分析：这个Skill要能干什么
日期时间查询是Agent最常被问到的需求之一。我想让这个Skill具备以下几个能力：
- 返回当前本地日期和时间（精确到秒）。
- 返回当前是星期几。
- 返回时区相关信息。
- 支持计算"n天后是几号"这种相对日期。
换成大白话，用户问"现在几点了"、"今天星期几"、"三天后是什么日子"、"现在这个时间是什么时区"，Agent都能立刻调用这个Skill，然后给出准确答案。
3.2 创建目录结构
确定需求后，先创建目录。打开终端，执行：
bash复制mkdir -p ~/.openclaw/skills/date_time/scripts
如果你的skills目录不在这个位置，换成你实际找到的路径就行。
3.3 编写SKILL.md"操作手册"
创建 ~/.openclaw/skills/date_time/SKILL.md，内容如下。我特意把注释和说明写得非常详细，因为这份文档不仅给Agent看，也是给未来的自己看的。
markdown复制---
name: date_time
description: 获取当前日期、时间、星期、时区信息，支持计算 n 天前/后的日期。当用户询问"现在几点""今天几号""明天是星期几""三天后是什么日子""当前时区""最近有什么日期"等问题时使用。可选参数 days_offset 为整数，如 1 表示明天，-1 表示昨天，不带参数表示当前时间。
---
# 日期时间查询技能
## 功能
- 返回当前本地时间，精确到秒
- 返回当前日期和星期
- 返回当前时区名称和 UTC 偏移
- 可选返回 n 天前/后的日期
## 调用方式
```bash
python scripts/datetime_helper.py [days_offset]
```
## 参数说明
- days_offset（可选）：整数，计算相对今天偏移 n 天的日期。正数表示未来，负数表示过去。
## 返回值说明
脚本输出 JSON 格式，字段含义如下：
- current_time：当前本地时间（YYYY-MM-DD HH:MM:SS）
- date：当前日期（YYYY-MM-DD）
- weekday：英文星期名
- timezone_name：时区名称（如 CST）
- utc_offset_hours：相对 UTC 的小时偏移
- days_offset：请求的偏移天数，0 表示未请求偏移
- target_date：偏移后的日期，未请求时为空
## 使用示例
用户问"现在几点"，直接运行 `python scripts/datetime_helper.py`。
用户问"10天后几号"，运行 `python scripts/datetime_helper.py 10`。
将脚本输出中的 target_date 字段以自然语言回复用户。
写这个文件时有三个点需要注意：
第一，description里要包含多种问法。 我写了"现在几点""今天几号""明天是星期几""三天后是什么日子"等至少四五个触发场景。这样Agent在遇到不同问法时都能精准匹配到它。
第二，body部分要给Agent明确的执行指引。 不要写"如果用户问时间，就告诉用户时间"这种废话，而是写清楚"调用哪个命令、参数怎么传、输出里哪个字段是用户要的答案"。Agent看到这段文档，就像实习生拿到一本写着"第一步做A，第二步做B"的SOP。
第三，返回值说明一定要写。 Agent拿到脚本输出后，如果是JSON格式但不知道每个字段的含义，它就会瞎猜，然后给用户一个错误答案。这一步是很多Skill"结果不对"的根本原因。
3.4 编写Python脚本
创建 ~/.openclaw/skills/date_time/scripts/datetime_helper.py，内容如下：
python复制#!/usr/bin/env python3
import sys
import json
from datetime import datetime, timedelta, timezone
# Windows下防止stdout编码问题
if hasattr(sys.stdout, "reconfigure"):
sys.stdout.reconfigure(encoding="utf-8")
def main():
try:
days_offset = 0
if len(sys.argv) > 1:
days_offset = int(sys.argv[1])
now = datetime.now()
target = now + timedelta(days=days_offset)
result = {
"current_time": now.strftime("%Y-%m-%d %H:%M:%S"),
"date": now.strftime("%Y-%m-%d"),
"weekday": now.strftime("%A"),
"timezone_name": now.astimezone().tzname() or "unknown",
"utc_offset_hours": round(
now.astimezone().utcoffset().total_seconds() / 3600, 2
) if now.astimezone().utcoffset() else 0,
"days_offset": days_offset,
"target_date": target.strftime("%Y-%m-%d") if days_offset else None,
}
print(json.dumps(result, ensure_ascii=False, indent=2))
except Exception as e:
print(json.dumps({"error": str(e), "hint": "请检查 days_offset 参数是否为整数"}, ensure_ascii=False))
sys.exit(1)
if __name__ == "__main__":
main()
这个脚本的逻辑不复杂，但有几个细节对Agent场景特别重要：
- 用JSON格式输出：JSON是结构化数据，LLM解析起来比自由文本可靠得多。我在SKILL.md里已经定义了每个字段的含义，Agent拿到输出后就知道用什么字段回复用户。
- 捕获异常并输出结构化错误：如果用户传了个非整数参数，脚本不会直接崩栈，而是输出一个带
error和hint的JSON。Agent看到这个错误信息，能自己理解"哦，参数传错了"，然后在回复里提示用户改正。 - 处理stdout编码：这行
sys.stdout.reconfigure(encoding="utf-8")是我在Windows上踩了坑之后加上的。OpenClaw在Windows下调用Python脚本时，如果脚本输出包含中文或特殊符号，很容易触发编码错误。
3.5 重启OpenClaw，测试效果
Skill写完后，需要重启OpenClaw才能生效。重启之后，你直接问Agent："现在几点了？"。
正常情况下，Agent会在内部调用 python scripts/datetime_helper.py，拿到JSON输出后，用自然语言告诉你当前时间。
如果Agent没有调用你这个Skill，先去看日志。我这里说的日志是指OpenClaw的运行日志，一般在 ~/.openclaw/logs/ 下，里面会记录Agent的逐步思考过程和工具调用记录。日志里会明确告诉你Agent有没有选中这个Skill，选中后有没有尝试执行脚本，执行后输出是什么。排查问题的时候，日志是第一助手。
如果你不想跟日志较劲，也有个笨办法但很有效：直接在终端手动运行一遍脚本，确认脚本本身没有报错：
bash复制cd ~/.openclaw/skills/date_time
python scripts/datetime_helper.py 3
如果脚本自己跑没问题，但Agent就是调不对，那问题多半出在SKILL.md的说明上——要么是description没匹配上，要么是调用方式写得不清晰。
4. 把Skill从"能用"做到"好用"：四个被忽略的细节
第一个Skill跑通之后，你可能会觉得"也就这么回事"。但等你再写两个Skill，你就会发现"跑通"和"好用"之间差了十万八千里。下面这四个细节，是决定一个Skill是"玩具"还是"生产力工具"的分水岭。
4.1 description要话多，不要话少
前面提过，description是Agent做语义匹配的依据。你写的时候就要假设：Agent在茫茫工具列表里扫一眼，能不能在0.1秒内判断"这个问题该用这个Skill"。
我之前写过一个"报告生成"Skill，description只写了"生成报告"。结果Agent在用户说"帮我写一份本周工作周报"的时候，果断没有调用它，而是自己硬编了一段内容，格式全乱。
后来我把description改成：
code复制根据用户提供的原始数据和模板，生成指定格式的工作周报、日报、月报或项目总结。支持从文本、表格、文档中提取关键信息并整合。当用户说"写周报""写日报""生成项目总结""整理会议纪要"时使用。
效果好多了。原因很简单：description里的触发词越多、场景描述越具体，Agent的语义匹配准确率就越高。
在写法上，我的习惯是：
- 先写技能是什么：获取什么信息、生成什么内容。
- 再写典型的提问句式：当用户说"XX""XX""XX"时使用。
- 最后写参数和限制：需要什么参数、什么情况下不要用。
4.2 脚本运行要有边界：幂等、超时、控制输出
Skill的脚本和普通脚本最大的区别是：它是由LLM随机触发的，不是由人稳定触发的。 这意味着你无法预测它被调用的时机、频率、环境。所以脚本设计必须考虑三个"边界"：
第一，幂等性。同一个脚本，同一份输入，无论执行多少次，结果都应该一致，而且不应该对系统状态产生副作用。比如你的Skill是"发送邮件"，那就不要让每次测试都真的发一封邮件。最好在SKILL.md里写明"加个dry-run参数，测试时传dry-run=True"。
第二，超时控制。OpenClaw对脚本执行一般有超时限制，如果你的脚本跑了一分钟还没返回，Agent就会报错。处理办法是把重活拆分，或者给脚本加超时退出机制。比如用网络请求时，设置 requests.get(..., timeout=10)，避免因为外部接口响应慢而卡死整个Agent。
第三，输出长度控制。脚本输出会直接进入Agent的上下文窗口，如果输出的是十几万字节的日志或文档，不仅浪费token，还可能把上下文撑爆。一个实用的做法是：在脚本里对输出做截断或摘要，只输出关键信息。比如"读取文件并总结"的Skill，脚本读完内容后先做简单截断，控制输出在几千字节以内，剩下的交给Agent去组织语言。
4.3 错误处理要面向LLM，而不是面向人
普通脚本的报错信息是给人看的，人看一眼就知道怎么回事。但Skill脚本的报错信息是给LLM看的，LLM会根据错误信息决定下一步怎么走。所以，错误信息里最好带上"修复建议"。
举个实际例子。我写过一个调用天气API的Skill，需要API Key。如果Key没配，脚本直接报"API Key 未配置"，Agent看到这个错误，就只会把这句话原封不动地转述给用户，用户还得自己琢磨怎么配Key。
后来我在脚本里把错误改成：
json复制{
"error": "WEATHER_API_KEY environment variable not found.",
"hint": "Please set the WEATHER_API_KEY environment variable, then restart OpenClaw and try again."
}
Agent拿到这个输出后，就可以直接告诉用户："天气查询接口没有配置密钥，你需要先设置环境变量 WEATHER_API_KEY，然后重启OpenClaw再试。" 这一下就把"报错"变成了"解决方案指引"。
你可能会问，这有什么难的？但实际操作中，很多人写的Skill脚本错误处理就是 print("Error occurred")，没有给LLM留任何修复线索。结果就是Agent遇到错误就摆烂，整个Skill就是废的。
4.4 返回结果要结构化，别让Agent去猜
LLM虽然能解析自然语言，但解析结构化JSON要可靠得多。Skill脚本的输出，我建议一律用JSON格式，并在SKILL.md里写清楚每个字段的含义和类型。
看个反面例子。我早期写的一个"查询数据库"Skill，脚本返回的是这种文本：
code复制查询结果：找到了3条记录，分别是：A，B，C。
Agent拿到这段文本后，要自己推断"到底返回了几条记录""记录的名字是什么"，不但容易出错，而且不同模型的理解差异很大。
后来我把输出改成：
json复制{
"record_count": 3,
"records": ["A", "B", "C"],
"query_time_ms": 42
}
同时SKILL.md里写明：record_count 是记录总数，records 是记录名称列表，query_time_ms 是查询耗时毫秒数。Agent拿到这个JSON后，直接提取字段就能准确回复用户，几乎不会出错。
你在写Skill脚本的时候，就把自己当成一个被AI呼来唤去的后端工程师：你的职责是输出干净、准确、自解释的数据结构，而不是替AI做完所有的事。
5. 我第一次写Skill时踩过的坑，以及完整排查思路
再好的教程也替代不了踩坑的经历。我把自己的坑写出来，每个坑都会附上排查思路，希望你遇到了能少走弯路。
5.1 坑一：SKILL.md的name和目录名不一致，Skill隐身了
症状：我在SKILL.md里写了 name: date_helper，但目录名叫 date_time。结果OpenClaw启动时没有报错，但Agent就是完全"看不见"这个Skill。
排查链路：
- 先看启动日志，确认OpenClaw扫描了哪个skills目录。
- 用
ls确认SKILL.md确实在正确的目录下。 - 看日志里有没有加载这个skill的提示，结果发现日志里扫到了
date_time目录但提示 "name mismatch"。 - 打开SKILL.md一看，front-matter里的name和目录名对不上。
原因：OpenClaw识别Skill时，既看目录名也看front-matter里的name，两者不一致会导致加载异常。
解决方案：目录名和name字段保持完全一致。这个要求没有写进官方文档，但我测试下来是最稳的。
5.2 坑二：Windows环境下Python脚本输出一堆乱码
症状：Skill脚本在Windows上被Agent调用时，返回的内容全是乱码或直接报 UnicodeDecodeError。
排查链路：
- 手动在终端运行脚本，输出正常。
- 通过OpenClaw调用，输出乱码。
- 打开OpenClaw日志，看到错误信息里有
cp936/gbk之类的编码字样。 - 定位到问题：OpenClaw在Windows下调用子进程时，默认编码与Python脚本的输出编码不一致。
解决方案：在脚本开头加上：
python复制if hasattr(sys.stdout, "reconfigure"):
sys.stdout.reconfigure(encoding="utf-8")
或者，在SKILL.md的调用命令里写明使用 python -X utf8 scripts/datetime_helper.py，强制Python以UTF-8模式运行。两个方法选一个就行。
这个问题在macOS和Linux上不会出现，但Windows用户特别容易踩，我强烈建议写脚本时从一开始就加上编码处理。
5.3 坑三：模型配置不对，Agent根本起不来
症状：安装OpenClaw后，启动报错 agent failed before reply: unknown model: deepsee。
排查链路：
- 先看OpenClaw的配置文件，确认
model字段写的是什么。 - 发现自己把模型名
deepseek写成了deepsee，少了一个字母。 - 改成正确的模型名之后，Agent恢复正常。
这个坑和Skill开发没有直接关系，但它会浪费你大量时间。你在开发Skill之前，一定要先确认Agent能正常对话、能正常调用工具，否则你会误以为是自己写的Skill有问题，然后浪费几个小时排查。
我在本地和服务器上都遇到过配置文件里模型名写错的情况，很常见。OpenClaw支持的模型名以你使用的服务商为准，不要凭记忆写，去查一下确认无误再填。
5.4 坑四：UI服务没启动，但不影响命令行开发
症状：执行OpenClaw相关命令时，报错 openclaw control ui did not start。
排查链路：
- 查看OpenClaw日志，发现UI服务进程启动失败，但核心Agent进程正常。
- 使用命令行方式继续交互，发现功能正常。
- 判断是UI组件的环境依赖问题，不影响Skill开发。
结论：如果你遇到"UI没起来"的错误，先别慌。OpenClaw的UI只是辅助界面，Skill开发和测试用命令行交互模式完全够用。 你可以在修复UI的同时，继续推进Skill的开发。
5.5 坑五：Agent调用了Skill但给出的答案是错的
症状：Agent确实调用了Skill，脚本输出也正常，但Agent给用户的回复是错的——比如脚本输出 target_date: "2025-06-20"，Agent回复用户时却写成了"6月21日"。
排查链路：
- 在日志里确认脚本的原始输出。
- 发现脚本输出是正确的，问题出在Agent对JSON字段的理解上。
- 检查SKILL.md里的"返回值说明"，发现自己只写了字段名，没有写"这个字段代表什么格式、怎么转换成自然语言"。
- 在SKILL.md里补充说明：
target_date是偏移后的日期，格式为YYYY-MM-DD，直接以 "X月X日" 的形式回复用户即可。
原因：LLM不是计算机，它对字段含义的理解完全依赖于你在SKILL.md里怎么说。你不说清楚，它就按自己的理解来，哪怕理解错了它也不知道。
这个现象在我同时写多个Skill之后变得特别明显。后来我养成了一个习惯：SKILL.md里只要有输出字段，就一定写死"每个字段怎么用、怎么转述给用户"，绝不偷懒。
| 问题 | 核心原因 | 解决方案 |
|---|---|---|
| Agent找不到Skill | name和目录名不一致 | 两者保持完全一致 |
| 脚本输出乱码 | Windows下编码不一致 | 脚本内强制UTF-8输出 |
| Agent启动失败 | 模型名配置错误 | 对照服务商文档确认模型名 |
| UI启动失败 | UI组件环境问题 | 先用命令行模式开发 |
| Agent返回错误答案 | SKILL.md未说明输出字段含义 | 补全字段说明和使用示例 |
6. 进阶玩法：把Skill接入API、读文档、组合成更大流程
你跑通了第一个Skill之后，很快就会发现它的想象空间非常大。下面这几个方向，是我自己实际验证过、强烈推荐的进阶路径。
6.1 接外部API：从"查时间"到"查天气、查股价、发邮件"
日期查询Skill没有外部依赖，但真实世界的需求往往需要对接第三方服务。写一个"查天气"的Skill，核心逻辑和日期查询完全一样：
- SKILL.md里写明：当用户问"今天天气怎么样""明天会不会下雨""北京气温"等问题时，调用这个Skill。
- 脚本里通过外部天气API获取数据，需要API Key时，从环境变量读取，不要硬编码到脚本里。
- 返回JSON结构化的天气数据，包括温度、天气状况、风力等。
这里有一个安全习惯：API Key、密钥等信息一律放在环境变量里，不要写进SKILL.md正文，也不要写进脚本的代码里，更不要提交到任何版本仓库。 SKILL.md会被Agent读入上下文，如果里面包含密钥，就相当于把密钥暴露给了每次对话，风险很大。
6.2 读本地文档：让Agent基于你的资料库回答问题
Skill允许脚本访问本地文件。你可以在assets目录下放一些参考文档，让Skill脚本读取并总结。
比如我写过一个"项目文档问答"Skill，脚本接收一个文档路径，读取内容并截断到指定长度，输出结构化摘要。Agent拿到摘要后，就可以基于文档内容回答用户问题。
需要注意一个细节：不要在SKILL.md里用相对路径引用assets文件，除非你确定Agent执行脚本时的当前工作目录是哪。 我在这个问题上栽过跟头。更靠谱的做法是让脚本自己定位：在脚本里用 os.path.dirname(__file__) 拿到脚本所在目录，再向上定位到assets目录。这样无论Agent在哪个目录执行脚本，都能正确找到文件。
6.3 多个Skill组合：让Agent像组装积木一样干活
一个Skill可以完成一件小事，多个Skill组合起来就能完成一件大事。OpenClaw的Agent天然支持多Skill协作——它可以根据任务需要，先调用"文档读取"Skill把文件内容读出来，再调用"摘要生成"Skill生成总结，再调用"报告生成"Skill整理成固定格式。
你不需要自己去实现这个组合逻辑，Agent会用它的推理能力来编排。你要做的，是保证每个Skill本身足够可靠、输出足够标准化。只要每个Skill的输出是结构化JSON，Agent把多个Skill串联起来就非常顺畅。
6.4 和MCP怎么协作：该用哪个方案
最后说一下Skill和MCP怎么选。我的判断标准很简单：
- 如果是对接现成的、标准的服务（比如数据库、Git、浏览器），用MCP，因为生态里已经有现成的MCP Server，直接用就好。
- 如果是自定义的业务流程（比如"读取销售数据，结合模板生成周报，再推送通知"），用Skill，因为它更灵活、开发成本更低。
- 两者可以混用：Skill脚本内部可以通过MCP提供的工具来执行具体操作。Skill负责"怎么干"，MCP负责"和外部系统怎么连接"。
6.5 渠道接入和Skill开发没有关系
很多人在群里问"OpenClaw怎么接入微信、飞书、钉钉"。这里我想说清楚一点：IM渠道接入是OpenClaw传输层的事情，跟你开发Skill完全解耦。 你在本地命令行里测好的Skill，接入微信之后一样能用。渠道的问题可以放到后面解决，不用在开发Skill阶段操心。
我个人一直推荐的做法是：先在本地把Skill调好、调稳，再考虑渠道接入。因为渠道接入之后，你还要面对消息格式转换、权限、群聊上下文等问题，调试起来更麻烦。先稳住核心能力，再扩展应用面，省心很多。
写了这么久，最后分享一个我自己的体会。Skill开发最吸引我的地方，不是它技术上有多少高深的东西，而是它能让我以极低的成本把Agent变成一个"真正能干活的员工"。你不需要写框架代码，不需要编译，只需要写清楚"什么情况下做什么事、怎么做、遇到问题怎么反馈"，Agent就真的能按你说的去做。这种"以文档驱动AI"的开发方式，会越来越成为主流。你现在拿这个日期查询Skill练手，跑通了，再改造成你真正需要的技能，就顺理成章了。