（十）Skills的魔法（下）— 从社区到自定义

（十）Skills的魔法（下）— 从社区到自定义

系列第10篇
作者：挖AI金矿

---

上篇文章我们讲了如何创建和管理自己的Skill。但一个人的力量总是有限的——Hermes Agent真正强大的地方，在于它有一个活跃的社区生态：。你可以直接复用上千名开发者贡献的技能，也可以把自己的技能分享出去。

今天我们就来深入社区生态，同时聊聊如何把粗糙的"部署脚本"升级为高质量的AI可理解Skill。

1.安装社区Skill：clawhub CLI 使用教程

clawhub 是Hermes Agent的官方技能市场客户端。它和 npm/pip 类似，但专门为 AI Agent Skill 设计。

1.1安装clawhub

如果你还没有安装clawhub：

# 检查是否已安装clawhub--version# 如果未安装，用pip安装pipinstallclawhub-cli# 或者通过Hermes自带安装hermes toolsinstallclawhub

安装完成后，先配置访问凭证（社区市场需要认证）：

clawhub configsettoken your_api_token

如果你没有token，可以去 注册一个账号，在个人设置页面生成。

1.2搜索技能

社区上的Skill数量增长很快。搜索是你找到合适技能的第一道门槛：

# 按关键词搜索clawhub search kubernetes# 搜索结果显示名称、描述、评分、安装量# 输出:# NAME DESCRIPTION RATING INSTALLS# k8s-debug Kubernetes Pod 调试流程 ⭐4.8 1,234# k8s-rollback Kubernetes 回滚操作 ⭐4.6 892# k8s-ingress-check Ingress 配置审查 ⭐4.5 456

1.3查看详情

安装之前，先看看技能的具体内容是否满足你的需求：

# 查看技能详情clawhub show k8s-debug# 这会显示完整的YAML frontmatter和Markdown正文# 包括前置条件、使用示例、依赖的工具等

特别关注这几个字段：

• dependencies：该Skill依赖哪些外部工具（如kubectl、helm等）
• requirements：需要Agent具备哪些能力（如文件读写、网络访问等）
• compatibility：兼容的Hermes版本号
• examples：使用示例，帮你快速上手

1.4安装技能

确认适合后，安装到本地：

# 安装技能clawhubinstallk8s-debug# 安装成功后，会提示# ✓ 已安装 k8s-debug v2.1.0# 路径: /home/user/.hermes/skills/k8s-debug/

安装后可以立即使用，无需额外配置。

1.5卸载和更新

发现自己装的技能太多，或者某个技能有更好替代？

# 卸载clawhub uninstall k8s-debug# 检查所有已安装技能是否有更新clawhub update--check# 更新所有可更新的技能clawhub update--all# 更新指定技能clawhub update k8s-debug

更新后最好测试一下新版是否兼容你的使用习惯。如果不喜欢新版，可以回退：

# 回退到上一版本clawhub rollback k8s-debug# 回退到指定版本clawhubinstallk8s-debug@1.3.0

2.安装后Skill去哪了？~/.hermes/skills/ 目录结构

所有Skill——无论是内置的、你自己创建的、还是从社区安装的——都存放在同一个目录下。理解这个目录的结构对管理技能库很有帮助。

# 查看所有Skillls-la~/.hermes/skills/

典型结构：

~/.hermes/skills/ ├── builtin/# 内置技能（只读，不建议修改）│ ├── code-review/ │ │ └── SKILL.md │ ├── git-workflow/ │ │ └── SKILL.md │ └──... ├── api-performance-triage/# 你的自定义技能│ ├── SKILL.md │ ├── templates/ │ │ └── report.md │ └── scripts/ │ └── check_pool.sh ├── k8s-debug/# 从社区安装的技能│ ├── SKILL.md │ └── README.md ├── disabled/# 禁用的技能（不会加载）│ └── old-deploy-flow/ │ └── SKILL.md └── index.json# 技能索引，自动生成

关键目录说明：

• builtin/：Hermes预装的技能。它们是只读的，不要直接修改这些文件。如果你想修改某个内置技能，可以用skill_manage fork复制一份。
• disabled/：暂时不想用的技能移到这里，既不会丢失也不会被加载。
• index.json：Hermes自动维护的索引文件，记录了所有可用技能的元数据。通常不需要手动修改。

如果你好奇某个社区Skill安装后长什么样，直接看它的SKILL.md：

cat~/.hermes/skills/k8s-debug/SKILL.md|head-30

这能帮你学习其他开发者的Skill设计思路。

3.修改和适配社区Skill为自己所用

社区Skill是通用化的设计，直接拿来用可能不完全符合你的场景。好消息是——所有社区Skill安装到本地后，你可以随意修改。

3.1分叉（Fork）一个Skill

如果你需要修改内置技能或社区技能，建议先fork一份再改，保留原始版本：

# fork社区技能到你的自定义空间skill_manage fork k8s-debug my-k8s-debug# 现在修改你的副本skill_manage edit my-k8s-debug

3.2适配的实际案例

假设你安装了社区Skill “docker-troubleshoot”，但你的团队用的是Docker Compose，而社区版本只针对单容器场景。你需要修改：

1. 增加docker-compose logs的检查步骤
2. 增加多容器网络联通的排查
3. 把输出格式改成符合你们团队报告模板的样子

# 先forkskill_manage fork docker-troubleshoot my-docker-troubleshoot# 编辑你的版本skill_manage edit my-docker-troubleshoot

修改后的SKILL.md可能包含这样的步骤：

---name:my-docker-troubleshootdescription:Docker Compose 多容器排障（团队定制版）version:1.1.0trigger:docker|容器|container|compose---# Docker Compose 排障流程## 1. 检查所有容器状态```bash docker-compose ps

4.2. 查看每个容器的日志

# 检查是否有容器频繁重启docker-composelogs--tail=100|grep-ierror

5.3. 网络连通性检查

# 进入某个容器测试其他容器是否可达docker-composeexecapppingdb

6.4. 资源限制检查

# 检查容器是否被OOM Killdocker-composelogs|grep-i"killed\|OOM\|exit code 137"

7.5. 卷挂载检查

# 确认挂载路径是否正确dockerinspect<container>|jq'.[].Mounts'

修改完后重新加载： ```bash skill_manage reload my-docker-troubleshoot

7.1贡献回社区

如果你觉得你的适配版本对很多人也有用，可以发布回社区：

# 发布前确保版本号已更新clawhub publish my-docker-troubleshoot# 填写发布信息：描述、分类、兼容版本等

社区审核通过后，其他人就能搜索到你的技能了。

8.自定义Skill最佳实践：触发条件 + 步骤化 + 验证

经过社区大量优秀Skill的洗礼，我总结出三个核心实践：触发条件要准、执行步骤要清晰、验证机制要到位。

8.1实践一：精准的触发条件

trigger字段是Skill的入口。写得好，Agent能精确匹配你的意图；写得差，要么该触发时不触发，要么不该触发时乱触发。

反面案例：

trigger:部署|上线|发布

这个太宽泛了。当你说"我们上线了一个新功能"，Agent可能误触发部署流程。

正面案例：

trigger:部署Go服务|go build|go build&&deploy|编译部署Go|发布Go微服务|go deploy

更精准的关键词组合，减少了误触发的概率。技巧：把你常用的口语化表达也加进去。

另外还有一个高级用法——正则触发（如果Hermes版本支持）：

trigger_pattern:部署(go|golang|Go)服务|开(启|始)(编译|构建)(并)?部署

8.2实践二：步骤化思维

一个Skill本质上是Agent的执行清单。步骤化思维把复杂的任务拆解成Agent能理解和执行的最小单元。

好步骤的标准：

1. 原子性：每步只做一件事
2. 可验证：每步都有明确的完成标志
3. 可恢复：如果某步失败，有明确的处理方式

steps:-检查前置条件（确认kubectl配置、集群可达）-拉取最新代码到指定分支-编译项目并运行单元测试-构建Docker镜像并推送-更新Kubernetes Deployment-验证部署状态-如果失败，回滚到上一版本

在Markdown正文中，对每一步展开详细说明：

## 步骤1：检查前置条件 ```bash kubectl cluster-info kubectl get nodes

如果集群不可达，停止执行并报告错误。

9.步骤2：拉取代码

gitcheckout maingitpull origin maingitlog--oneline-3

### 实践三：验证机制每个Skill都应该包含验证步骤。这是很多人忽略但至关重要的部分。 ```yaml --- name: deploy-go-service validation: - type: health_check endpoint: /healthz expected_status:200- type: metric_check metric: http_request_duration_seconds threshold:0.5- type: log_check pattern:"server started"---

验证确保技能执行后，确实达到了预期效果，而不是"看起来运行了，实际上没生效"。

10.Skill更新：迭代升级你的技能库

技能库不是一次性建好的。就像代码需要重构，Skill也需要持续迭代。

10.1版本号管理

遵循语义化版本（SemVer）：

• major：技能逻辑大变，可能不兼容旧的使用方式
• minor：新增步骤或功能，向后兼容
• patch：修复bug，优化表述

# 升级版本skill_manage version bump api-performance-triage--patch# 查看版本历史skill_manage log api-performance-triage

10.2基于使用数据优化

Hermes会记录每个Skill的使用情况：

skill_manage stats api-performance-triage

输出：

技能: api-performance-triage 使用次数:47最近使用:2024-01-15 平均完成时间:3.2轮对话 成功率:91.5% 最常见失败步骤: 步骤3（慢查询分析）

如果成功率低，说明Skill设计有问题——可能是步骤不清晰，或者需要更多前置条件说明。

10.3定期清理

建议每个月检查一次技能库：

# 列出使用次数最少的技能skill_manage stats--sort=usage--limit=5# 列出超过30天未使用的技能skill_manage stats --older-than=30d

对于从未使用的技能，要么删除，要么移到disabled/目录。

11.案例：从一个"部署脚本"到AI可理解的Skill

很多人的第一个Skill是从shell脚本"翻译"过来的。但直接把脚本塞进去，Agent可能无法正确执行。我们来看一个真实的案例。

11.1起点：一个原始的部署脚本

假设你有这样一个deploy.sh：

#!/bin/bashset-ecd/opt/appgitpull go build-oapp systemctl restart appecho"部署完成"

11.2第一步：提炼元数据

脚本本身没有上下文信息。我们需要告诉Agent这个Skill是用来做什么的、什么时候用、需要什么前提条件。

---name:deploy-go-backenddescription:部署Go后端应用到生产服务器version:1.0.0author:挖AI金矿trigger:部署Go应用|上线后端|go deploycontext:requires:-对服务器的SSH访问权限-/opt/app 目录存在-systemctl 管理权限provides:-编译后的二进制文件-重启后的应用服务---

11.3第二步：步骤化脚本

把脚本中的每一步拆开并补充说明：

## 步骤1：SSH连接到服务器 ```bash ssh user@production-server

12.步骤2：进入应用目录

cd/opt/app

13.步骤3：拉取最新代码

gitcheckout maingitpull origin main

查看最近的commit信息，确认拉取的版本正确。

14.步骤4：编译

go build-ldflags="-s -w"-oapp.

如果编译失败，检查Go版本和依赖：

go version go mod tidy

15.步骤5：重启服务

systemctl restart app systemctl status app

确认服务状态为 active (running)。

16.步骤6：验证

curl-shttp://localhost:8080/healthz|grep-q"ok"&&echo"健康检查通过"tail-n20/var/log/app.log|grep-i"started"

### 第三步：添加错误处理脚本的`set-e`在遇到错误时直接退出，但Agent需要知道每个错误的具体含义和处理方式。 ```markdown## 异常处理### 编译失败- 检查Go是否安装：`go version`- 检查依赖：`go mod tidy`- 检查语法错误：`go vet ./...`### 服务启动失败- 查看日志：`journalctl-uapp-n50--no-pager`- 检查端口占用：`ss-tlnp|grep8080`- 检查SELinux：`getenforce`### 健康检查不通过- 检查进程是否存在：`psaux|grepapp`- 检查配置是否正确：`diff/opt/app/config.yaml /opt/app/config.yaml.bak`

### 最终效果升级后的Skill不再是"按顺序执行几个命令"，而是一个具备完整上下文、异常处理机制、验证步骤的可复用AI技能。Agent执行时，即使某一步出错了，它也知道该如何处理，而不是简单地报错然后停止。## 提醒：当Skill过时了怎么办？patch更新技术栈在变，Skill也需要跟着进化。以下信号说明你的Skill可能需要更新：1. **执行时频繁报错**：命令参数变了、API不兼容了2. **使用率骤降**：可能是因为不准确，用户不愿意用了3. **社区有更好版本**：检查clawhub上同类Skill是否有更新4. **依赖工具升级**：比如kubectl命令格式变化、Docker API变化### 执行patch更新对于小修改，直接用`skill_manage edit`编辑就行。对于更系统的更新操作： ```bash# 1. 备份旧版本cp-r~/.hermes/skills/deploy-go-backend{,.bak}# 2. 升级版本号skill_manage version bump deploy-go-backend--patch# 3. 应用更新skill_manage edit deploy-go-backend# 4. 测试后重新加载skill_manage reload deploy-go-backend

16.1监控技能健康度

配置自动监控，当技能执行成功率低于阈值时通知你：

# 在Skill的SKILL.md中添加监控配置---monitoring:enabled:truesuccess_threshold:0.85notify_on_downtrend:true---

如果成功率持续低于85%，就应该审查Skill内容是否需要更新了。

16.2处理废弃的技能

当你发现某个技能已经完全不适合当前工作流时：

# 1. 停用，而不是删除（以防将来需要）skill_manage disable old-deploy-flow# 2. 添加废弃说明skill_manage annotate old-deploy-flow"已于2024年3月废弃，改用deploy-go-backend"# 3. 一个月后确认不再需要，再删除skill_manage delete old-deploy-flow--force

17.总结

两篇文章下来，你应该已经掌握了Skills的全链路能力：

• 上篇：Skill的概念、创建、管理、结构分析、定位区分
• 下篇：社区生态、安装使用、适配修改、最佳实践、迭代更新

Skill是Hermes Agent中最具生产力的功能之一。一个精心打磨的Skill库，就是你作为开发者的"第二大脑"——你把脑力花在创造性的工作上，而重复性的最佳实践交给Agent去执行。

现在就去创建你的第一个Skill吧。从最简单的开始——比如把"创建新API接口"的流程固化下来，或者把"数据库备份检查"做成一个可复用的技能。你会发现，当Agent真正理解你的工作方式时，协作效率会有质的飞跃。

作者：挖AI金矿
系列：Hermes Agent 从小白到高级 — 第 10/18 篇
下一篇：记忆系统 — 让AI真正了解你