Hermes Skills 怎么设计：把重复任务变成 Agent 可复用流程

Hermes 如果只是拿来聊天，价值其实没有完全发挥出来。

它真正适合做的事，是把你反复执行的任务沉淀成 Skills。也就是：不是每次都重新告诉 Agent “你先读哪里、再输出什么、哪些动作不能做”，而是把这些规则固定下来，让 Agent 每次都按同一套流程工作。

这篇不再讲 Hermes 怎么接模型，也不重复讲权限怎么开。这里重点讲一个更实用的问题：Hermes Skills 应该怎么设计，才不会变成一堆散乱提示词。

Skill 不是提示词收藏夹

很多人一开始做 Skills，会把它写成一段很长的提示词：

你是一个专业助手，请帮我整理资料，要求准确、清晰、有条理，不要胡编。

这种写法当然比什么都不写好，但它还不是一个真正可复用的 Skill。

一个好的 Skill 至少要讲清五件事：

模块	要回答的问题
适用场景	什么时候应该用这个 Skill
输入	用户需要给什么材料、路径或目标
步骤	Agent 应该按什么顺序做
输出	最终交付什么格式
边界	什么不能做，什么必须停下来问人

如果只有“写得专业一点”，那只是写作风格。如果有输入、步骤、输出和边界，它才像一个流程。

先从高频重复任务开始

不要一上来就给 Hermes 做一个万能 Skill。

万能 Skill 最后通常会变成另一个聊天窗口：什么都能接，什么都不稳定。更好的起点，是找你每天都会重复、但每次都懒得重新说明的任务。

比如：

1. 阅读一个项目目录并整理结构。
2. 把网页资料整理成 Markdown 笔记。
3. 把会议记录改成任务清单。
4. 把一堆文章标题整理成内容 Brief。
5. 检查某个文件夹里哪些文档缺字段。

这些任务有共同特点：输入相对固定，步骤能拆清楚，输出格式也能固定。做成 Skill 后，Hermes 才能真的省时间。

一个 Skill 先写“拒绝做什么”

设计 Agent 工作流时，我会先写限制，再写能力。

这听起来反直觉，但很重要。因为 Agent 很擅长“继续帮你做下一步”，而很多事故就发生在这个下一步。

比如一个网页资料整理 Skill，可以先写：

这个 Skill 只做资料读取、结构化整理和待确认清单生成。
不要登录账号，不要提交表单，不要发布内容，不要下载未知文件，不要修改外部系统。
如果资料需要登录、付费、验证码或人工判断，输出“需要人工确认”。

有了这段边界，后面的步骤才安全。

如果你先写“帮我完成资料调研”，Agent 很容易自己推断：要不要继续搜索、要不要点链接、要不要登录、要不要把结果写进某个文件。它不是故意乱来，而是任务边界没有告诉它该停在哪里。

输入要设计成清单，不要靠临场解释

一个 Skill 越依赖临场解释，越不稳定。

比如你每次都说：

“帮我整理这个项目，重点看看有没有能写文章的点。”

这句话太宽。Hermes 可能今天按文件夹整理，明天按主题整理，后天直接开始写文章。

更稳的输入格式可以是：

target_path: C:/projects/demo
focus: 内容选题
allowed_actions:
  - read_files
  - search_files
output_format: markdown
stop_before:
  - writing_final_article
  - modifying_files

这不是为了形式主义，而是为了让 Agent 每次都拿到同样的任务边界。

如果你不想写 YAML，也可以用普通清单。关键是字段固定：目标路径、任务目的、允许动作、禁止动作、输出格式、停止点。

步骤要短，每一步都有验收

一个 Skill 里不要写“分析全部内容并给出建议”这种大步骤。

更好的写法是拆成小步：

1. 先确认输入路径是否存在。
2. 列出顶层文件和目录。
3. 找入口文件和说明文档。
4. 搜索与本次目标相关的关键词。
5. 整理发现内容。
6. 列出不确定项。
7. 输出下一步建议，但不直接修改文件。

每一步都应该能判断有没有完成。

如果某一步失败，比如路径不存在、文件太多、没有权限、搜索结果为空，Skill 应该要求 Agent 停下来说明原因，而不是继续编一个结论。

输出格式决定结果能不能复用

很多 Agent 输出看起来很漂亮，但不能继续用。

比如一大段“这个项目整体结构比较清晰，建议后续优化文档和测试”。这句话读完没错，但你很难拿它进入下一步。

Skill 的输出最好固定成结构。

比如项目阅读 Skill 可以输出：

## 项目入口
- README：...
- 配置文件：...
- 主要源码目录：...

## 我确认的事实
- ...

## 我不确定的内容
- ...

## 可执行下一步
1. ...
2. ...
3. ...

网页研究 Skill 可以输出字段表。内容 Brief Skill 可以输出关键词、搜索意图、页面目的、内链目标和暂缓原因。文件归档 Skill 可以输出改名前后映射和需要人工确认的冲突。

输出越固定，后续越容易接给另一个 Skill 或人工流程。

不确定项必须成为固定字段

我建议每个 Hermes Skill 都保留一个字段：不确定项。

原因很简单：Agent 最大的问题不是不知道，而是不知道自己不知道。

在 Skill 里固定要求它列出不确定项，可以减少很多“看起来很肯定”的错误。

不确定项可以包括：

• 没有读取到的文件。
• 需要登录或权限的页面。
• 只看到部分内容的资料。
• 需要用户确认的业务判断。
• 可能影响外部系统的动作。
• 输入里没有说明但会影响结论的前提。

如果某个任务没有不确定项，也应该写“未发现明显不确定项”，而不是把这个部分省略。长期看，这会让 Skill 的输出更好审计。

四类 Skill 最值得先做

如果你刚开始用 Hermes，我建议先做这四类 Skill。

Skill 类型	解决的问题	输出
项目阅读	快速理解一个目录或代码库	结构摘要、不确定项、下一步问题
网页资料整理	把公开网页转成可复用笔记	字段表、来源页面、缺失字段
内容 Brief	把选题和材料变成写作输入	页面目的、关键词、内链目标、避免项
文件归档	把散乱文件按规则整理	目录映射、冲突清单、人工确认项

这四类都很适合 Hermes，因为它们需要读文件、整理结构、生成固定格式，但不一定需要直接改生产系统。

等这些 Skill 稳定后，再考虑更重的自动化。

Skill 和 Tool 要分清楚

Hermes 里的 Tool 是能力，Skill 是流程。

Tool 可以是读文件、搜文件、写文件、打开浏览器、调用模型端点。Skill 则告诉 Agent 什么时候用这些能力、按什么顺序用、用完输出什么。

不要把 Tool 的能力直接暴露成任务目标。

比如“使用写文件工具帮我整理项目”就太宽。更好的说法是：

“使用项目阅读 Skill，先只读项目结构，输出摘要和不确定项。不要写文件。”

等只读结果确认后，再用另一个归档 Skill 或写作 Skill 进入下一步。

这样流程会慢一点，但每一步都清楚。

一个最小 Skill 模板

下面这个模板可以作为起点：

# Skill 名称

## 适用场景
这个 Skill 用于……

## 输入
- target：目标路径、URL 或材料
- goal：本次要解决的问题
- allowed_actions：允许动作
- output_format：输出格式

## 禁止动作
- 不删除文件
- 不提交外部表单
- 不发布内容
- 不访问未授权账号

## 执行步骤
1. 检查输入是否完整。
2. 读取或整理材料。
3. 按字段输出确认事实。
4. 单独列出不确定项。
5. 给出下一步建议，但停在人工确认前。

## 输出格式
- 已确认事实
- 不确定项
- 建议下一步
- 需要人工确认的动作

这个模板不复杂，但已经足够避免很多随意发挥。

和 OpenClaw 怎么配合

Hermes Skills 如果要接网页任务，可以把 OpenClaw 当成网页能力来源。

比如一个“公开网页资料整理 Skill”可以这样设计：

1. Hermes 接收 URL 清单和字段表。
2. OpenClaw 负责读取页面、展开只读内容、返回结构化结果。
3. Hermes 把结果合并成 Markdown。
4. Skill 固定输出确认事实、不确定项和人工复核项。
5. 高风险动作全部停下，不进入提交、发布、登录。

这里 Hermes 不是替代 OpenClaw，OpenClaw 也不是替代 Hermes。一个负责流程，一个负责网页能力，分开以后更容易稳定。如果你还没理解 OpenClaw 的基础能力，可以先看 OpenClaw 怎么用：让 Agent 读网页、查资料和控制浏览器；如果你想把浏览器能力接成工具，可以继续看 OpenClaw 和 MCP 怎么接：把浏览器能力做成 Agent 可控工具。

小结

Hermes Skills 的价值，不是把提示词写得更长，而是把重复任务变成可复用流程。

一个好的 Skill 应该讲清适用场景、输入、步骤、输出和边界。先限制危险动作，再开放能力；先做只读流程，再考虑写入；先固定输出格式，再追求自动化。

如果你把 Skills 当成工作流资产来维护，Hermes 就不只是一个本地 Agent 客户端，而会变成一个能积累方法的工作台。