Hermes Agent Skills 实战教程：5 个 Skill 从搭建到联动，附踩坑记录
从 Skills 系统核心概念到 5 个实用 Skill 的完整搭建过程，包含组合联动和最佳实践
AinoCode 编辑部
Hermes Agent Skills 实战教程：5 个 Skill 从搭建到联动，附踩坑记录
Hermes Agent 的 Skills 系统可能是它最被低估的功能。
很多人第一次接触 Hermes，以为它就是个”能聊天的 AI”。聊几次后发现它能搜网页、能跑代码、能读文件，但也就这样了。直到你开始写自己的 Skill，才发现这玩意能做的事情远超想象。
这篇是我用 Hermes Skills 一个月下来的实战总结。5 个真实可用的 Skill，从简单到复杂，最后把它们串成一个自动化工作流。不是概念介绍，是你跟着做就能跑通的教程。
一、Skills 系统的核心概念
先搞懂一个关键区别：Hermes 的 Skill 不是”插件”，是”能力定义”。
插件是往系统里加新功能（比如加个天气查询）。Skill 是给 Agent 定义”我擅长做什么”。一个 Skill 包含三样东西：
- SKILL.md：告诉 Agent 这个 Skill 是什么、什么时候用、怎么用。这是 Agent 理解 Skill 的唯一途径。
- 触发条件：什么情况下激活这个 Skill。可以是关键词匹配、cron 定时、或者 Agent 自主判断。
- 执行逻辑：激活后做什么。可以是直接让 Agent 执行 prompt 里描述的任务，也可以调用外部脚本。
SKILL.md 是核心。Agent 通过读取 SKILL.md 来决定什么时候使用这个 Skill。所以 SKILL.md 写得好不好，直接决定了 Skill 能不能被正确使用。
一个标准 SKILL.md 长这样：
---
name: skill-name
description: 一句话描述这个 Skill 做什么
---
# Skill Name
## 什么时候用
- 条件 1
- 条件 2
## 怎么做
1. 步骤一
2. 步骤二
3. 步骤三
## 注意事项
- 注意一
- 注意二
看着简单，但写好 SKILL.md 有讲究。后面每个 Skill 我都会展开讲。
Skill 1：每日新闻摘要（Cron 触发）
这是最简单的 Skill，适合入门。
需求：每天凌晨 7 点，自动抓取科技新闻，生成摘要，推送到飞书。
SKILL.md：
---
name: daily-tech-news
description: 每天早上抓取科技新闻并生成摘要推送
triggers: ["cron:0 7 * * *"]
---
# 每日科技新闻摘要
## 执行步骤
1. 使用 web 搜索查询今天最新的科技新闻（关键词："AI 科技 最新 2026"）
2. 从搜索结果中提取 5 条最重要的新闻
3. 对每条新闻生成一句话摘要
4. 用中文输出格式化报告，格式如下：
📰 每日科技新闻速报 - YYYY-MM-DD
- [标题] - [一句话摘要]
- …
🔥 今日热点：[最值得关注的一条]
5. 通过飞书 webhook 推送报告
踩坑记录：
- 时区问题：cron 表达式默认用 UTC。我设了
0 7 * * *以为是早上 7 点，结果发现是 UTC 7 点，北京时间 15 点。解决方案：用0 23 * * *（UTC 23 点 = 北京时 7 点），或者在 Hermes 配置里设TZ=Asia/Shanghai。 - 搜索质量：直接搜”科技新闻”返回的很多是旧闻。后来改成搜带日期关键词的，比如”2026年5月 AI 科技”，结果准了很多。
- 飞书推送格式：飞书 webhook 支持 Markdown 格式，但有些语法不兼容。比如
**加粗**可以，但~~删除线~~不行。建议先手动发一条测试，确认格式再固化到 Skill 里。
Skill 2：代码审查助手（关键词触发）
这个 Skill 是响应式的——你让 Agent 审查代码时才触发。
需求：把代码片段发给 Agent，它自动做代码审查，给出改进建议。
SKILL.md：
---
name: code-reviewer
description: 对用户提交的代码片段进行审查，给出改进建议
---
# 代码审查助手
## 什么时候用
- 用户说"审查这段代码"、"code review"、"帮我看看这段代码"
- 用户发送了一段包含代码块（```）的消息
## 怎么做
1. 识别用户发送的代码语言和主要功能
2. 从以下维度审查：
- **正确性**：是否有明显的 bug 或逻辑错误
- **安全性**：是否有 SQL 注入、XSS、敏感信息泄露等风险
- **性能**：是否有明显的性能问题（N+1 查询、不必要的循环等）
- **可读性**：变量命名、函数拆分、注释是否合理
3. 输出结构化审查报告，格式：
🔍 代码审查报告
语言：[识别出的语言] 功能：[一句话描述代码做什么]
⚠️ 发现的问题：
- [严重] 问题描述 + 建议修改
- [中等] …
- [建议] …
✅ 做得好的地方：
- …
实战效果：
这个 Skill 用了一周后我发现一个有趣的模式：Agent 对 Python 和 JavaScript 代码的审查质量明显高于其他语言。不是因为 Agent 能力有偏向，是因为 SKILL.md 里的审查维度（SQL 注入、N+1 查询）在 Python/JS 场景下更容易被 Agent 理解。
对于 Go 或 Rust 代码，建议单独写一个 SKILL.md，把审查维度换成 Go/Rust 特有的问题（goroutine 泄漏、生命周期、borrow checker 等）。
Skill 3：会议记录整理器（关键词 + 上下文触发）
这个比前两个复杂一点，需要 Agent 理解上下文。
需求：把会议记录（可能是语音转文字后的粗糙文本）整理成结构化纪要。
SKILL.md：
---
name: meeting-notes
description: 将原始会议记录整理成结构化会议纪要
---
# 会议记录整理器
## 什么时候用
- 用户说"整理会议记录"、"生成会议纪要"
- 用户发送了一段包含多人对话的文本
## 怎么做
1. 从文本中提取以下信息：
- 会议主题（从对话内容推断）
- 参会人员
- 讨论议题（按话题分组）
- 每个议题的结论
- Action Items（谁、做什么、什么时候完成）
2. 输出格式化纪要：
📋 会议纪要
主题：[推断的会议主题] 参会人员：[列出]
一、[议题一]
- 讨论内容摘要
- 结论：[明确结论]
二、[议题二] …
📌 Action Items：
- @张三 完成 XXX（截止：YYYY-MM-DD）
- @李四 …
3. 如果原始文本中没有明确的 Action Item，用"⚠️ 建议确认以下 Action Items"标注
踩坑记录：
- 语音转文字的噪声：真实的语音转文字文本质量很差——错别字、说话人识别错误、口语化表达。Agent 在处理这类文本时，有时会”过度修正”，把发言人的真实意思改掉了。我的做法是在 SKILL.md 里加了一条规则：“保留发言人的原始态度，不要替发言人下结论。”
- 多人对话解析：如果会议记录没有标注说话人，Agent 很难区分谁说了什么。建议在 SKILL.md 里加一条前置条件：“请用户提供带说话人标注的文本，或说明无法区分发言人。“
Skill 4：数据库查询助手（工具调用）
这个 Skill 开始用外部工具了。
需求：让 Agent 能安全地执行数据库查询，返回结果并做分析。
SKILL.md：
---
name: db-query
description: 安全地执行数据库查询并分析结果
requires: ["scripts/db_query.sh"]
---
# 数据库查询助手
## 什么时候用
- 用户问关于数据库数据的问题
- 用户说"查一下"、"统计"、"帮我看看数据库"
## 怎么做
1. 根据用户问题生成 SQL 查询
2. 在执行前，确认 SQL 是 SELECT 语句（不允 INSERT/UPDATE/DELETE）
3. 执行 `./scripts/db_query.sh "SQL语句"` 获取结果
4. 分析查询结果，用自然语言回答用户问题
5. 如果结果集超过 20 行，只做趋势分析，不逐行展示
## 安全约束
- 只允许 SELECT 语句
- 必须带 LIMIT（如果用户没有指定，默认 LIMIT 100）
- 不允许 DROP/TRUNCATE/ALTER 等 DDL 语句
配套的 scripts/db_query.sh：
#!/bin/bash
SQL="$1"
# 安全检查：只允许 SELECT
if [[ ! "$SQL" =~ ^[[:space:]]*SELECT ]]; then
echo "ERROR: 只允许 SELECT 语句"
exit 1
fi
# 执行查询
psql -h $DB_HOST -U $DB_USER -d $DB_NAME -c "$SQL" --csv
实战经验：
这个 Skill 的核心是安全约束。一开始我没写 db_query.sh 脚本，直接让 Agent 生成 SQL 然后通过 MCP Server 执行。结果有一次 Agent 生成了一个 DELETE FROM logs WHERE created_at < '2026-01-01'——它”好心”想清理旧数据。幸好我设置了只读权限，没出事故。
后来我强制加了 shell 脚本层做 SQL 类型校验，这才放心。对于生产环境，建议再加一层：SQL 执行前需要人工确认（可以在脚本里加一个 read -p "确认执行? (y/n)" 的交互）。
Skill 5：周报生成器（多 Skill 联动）
这是最复杂的一个，需要和其他 Skill 联动。
需求：每周五下午 5 点，自动汇总本周的工作数据，生成周报。
SKILL.md：
---
name: weekly-report
description: 汇总本周工作数据生成周报
triggers: ["cron:0 9 * * 5"]
requires: ["db-query", "daily-tech-news"]
---
# 周报生成器
## 执行步骤
1. 使用 db-query Skill 查询本周数据：
- 本周提交代码次数
- 本周处理的工单数量
- 本周修复的 bug 数量
2. 回顾本周 daily-tech-news 的输出，提取与工作相关的新闻
3. 使用 code-reviewer 的逻辑，总结本周代码质量趋势
4. 生成周报：
📊 周报 - YYYY-MM-DD
一、本周工作数据
- 代码提交：XX 次
- 工单处理：XX 个
- Bug 修复：XX 个
二、本周重要进展
- [项目 A] …
- [项目 B] …
三、行业动态
- [新闻 1]
- [新闻 2]
四、下周计划
- [待办 1]
- [待办 2]
5. 保存到 `~/weekly-reports/` 目录，文件名格式 `YYYY-MM-DD.md`
联动机制：
这个 Skill 的 requires 字段声明了对其他 Skill 的依赖。Hermes Agent 在执行这个 Skill 时，会先检查依赖的 Skill 是否可用，然后按顺序调用它们。
具体来说：
- 先查数据库（调用 db-query）
- 再回顾新闻（读取 daily-tech-news 的历史输出）
- 最后整合生成周报
这种联动能力是 Hermes Skills 系统最有价值的部分。单个 Skill 做的事情有限，但串起来就是一个完整的自动化工作流。
四、Skill 之间的组合和联动
上面 5 个 Skill 单独看各有用处，但组合起来威力更大。
场景 1：Daily Standup（每日站会自动化）
把 Skill 1（新闻摘要）和 Skill 4（数据库查询）组合，每天早上自动生成：
- 昨天系统运行数据（查询数据库）
- 行业相关新闻（新闻摘要）
- 待处理工单（查询数据库）
场景 2：Sprint Review（迭代回顾）
把 Skill 4（数据库查询）和 Skill 5（周报生成）组合，每周五生成迭代报告：
- 本周代码提交统计
- Bug 修复趋势
- 代码质量变化（基于 code-reviewer 的历史数据）
场景 3：Onboarding Guide（新人引导）
新同事入职时，用 Skill 2（代码审查）和 Skill 3（会议记录）组合：
- 自动审查新人提交的 PR
- 自动整理新人参加的第一次会议记录
- 生成新人周报（Skill 5）
五、最佳实践和踩坑记录
最佳实践
1. SKILL.md 要写得像给实习生看的手册
Agent 理解 SKILL.md 的方式和新人看手册差不多。你写得越模糊，Agent 发挥的空间越大——但发挥不等于准确。我的经验是，SKILL.md 里的每个步骤都要具体到”如果 A 出现，做 B”的程度。
2. 先用手动触发，再改自动触发
新 Skill 写好之后，先用手动方式触发测试几次，确认执行逻辑没问题再改成 cron 自动触发。不然自动触发出了 bug，你可能第二天才发现，到时候一堆错误输出不好排查。
3. 给每个 Skill 加”失败处理”说明
在 SKILL.md 的末尾加一个”如果出错了怎么办”的部分。比如 db-query Skill：
## 如果出错了
- 如果数据库连接失败：告知用户"数据库暂时无法连接，请稍后重试"
- 如果 SQL 执行超时：告知用户"查询超时，可能数据量过大，建议缩小查询范围"
- 如果返回空结果：告知用户"没有找到匹配的数据，请检查查询条件"
这样 Agent 在遇到异常时能给出有意义的提示，而不是沉默或者输出乱码。
踩坑记录
坑 1：Skill 命名冲突
一开始我给新闻摘要 Skill 起名 news，后来又想写一个”新闻搜索”Skill，也起名 news。结果两个 Skill 互相覆盖，行为不可预测。
解决方案：Skill 名字用 kebab-case，加前缀区分领域。比如 tech-news-daily、news-search、news-summarizer。
坑 2：cron 表达式重复
Skill 1 和 Skill 5 我都设了 cron 触发，但时间设得很接近（一个 7:00，一个 9:00）。后来发现 Hermes 的 cron 精度是分钟级的，如果两个 Skill 在同一分钟触发，可能出现资源竞争。
解决方案：错开触发时间，或者在 SKILL.md 里加优先级声明。
坑 3：Skill 之间的数据传递
一开始我以为 Skill A 的输出会自动传给 Skill B。实际上不是的。Hermes Agent 在执行多 Skill 联动时，是通过 Agent 自己的记忆来传递信息的。所以如果 Skill A 的输出很重要（比如数据库查询结果），要在 SKILL.md 里明确要求 Agent “记住这些数据，后续步骤要用”。
总结
Hermes Skills 系统的核心优势不是”能做什么”，是”能组合做什么”。单个 Skill 的能力有限，但当你能把代码审查、数据库查询、新闻摘要、会议整理串成一个工作流时，Hermes Agent 就从”聊天工具”变成了”自动化工作平台”。
我的建议是，从最简单的 Skill 开始写（比如每日新闻摘要），跑通之后再逐步复杂化。不要一上来就写联动 Skill——先把单个 Skill 调试好，再考虑组合。
毕竟，每个复杂的自动化工作流，都是从一行 SKILL.md 开始的。