搜索 “Hermes skills” 的用户，通常已经不满足于让 Agent 临时完成一次任务。他想知道：一次成功经验能不能沉淀成长期能力？能不能从 Hub 安装别人的技能？如果 Hermes 自动调用 skill，怎么避免它变成不可控脚本？
Hermes Skills 的意义，是把稳定任务拆成可发现、可加载、可复用、可审查的能力资产。它不是“把所有脚本都丢进技能库”，而是让 Agent 在需要时按描述发现技能，再根据技能说明执行。
先抓住 4 个判断
- Skill 适合重复、稳定、可验证的任务，不适合一次性探索。
- Skill 被长期复用前，要审查命令、依赖、输入输出、外部 API 和权限。
- Memory 存事实，Skills 存动作；不要把流程塞进 memory。
- Gateway、cron 和 team profile 一旦能调用 skill，审查标准要高于个人临时脚本。
什么任务适合沉淀成 skill
| 任务特征 | 是否适合 | 例子 |
|---|---|---|
| 每周重复执行 | 适合 | 内容缺口报告、依赖检查、发布前清单 |
| 步骤稳定，有验收标准 | 适合 | 先 build，再 seo check，再 smoke check |
| 输入输出清楚 | 适合 | 输入教程目录，输出选题优先级表 |
| 权限边界清楚 | 适合 | 只读扫描、生成报告、创建草稿 |
| 一次性探索 | 不适合 | “帮我研究最近有什么新工具” |
| 依赖未确认外部接口 | 暂缓 | 临时爬取未稳定网页 |
| 涉及 secrets 或不可回滚变更 | 必须人工审查 | 自动发消息、提交代码、执行部署 |
一个好 skill 的标准不是“功能很强”，而是后来的人能读懂它为什么存在、什么时候该用、失败时如何停止。
建立 skill 候选池
先不要让 Hermes 把所有任务都变成 skill。建议你维护一个候选池：
- 任务名称。
- 触发频率。
- 输入是什么。
- 输出是什么。
- 成功标准是什么。
- 涉及哪些工具、目录和权限。
- 是否调用外部 API。
- 是否需要 secrets。
- 是否需要人工确认。
- 失败时是否能安全停止。
当一个任务连续完成 2 到 3 次，并且步骤没有大幅变化，再考虑沉淀。只跑过一次的任务，先保留为任务记录；能稳定复用后，再进入 skill。
官方技能发现与安装路径
官方 “Work with Skills” 文档给出的路径大致分为三类：
| 需求 | 推荐入口 | 适用场景 |
|---|---|---|
| 查看可用技能 | /skills 或技能列表 | 想知道当前会话能发现什么 |
| 从 Hub 搜索 | /skills search <term> | 想找已有技能而不是从零写 |
| 安装技能 | /skills install <skill-id> | 已确认技能来源与用途 |
| 启用可选技能 | /skills enable <skill-name> | 只在某些 profile 或项目启用 |
| 用 CLI 管理 | hermes skills | 需要终端式列表、更新或管理 |
| 通过工具管理 | skill_manage | 让 Hermes 在受控范围内管理技能 |
安装任何第三方 skill 前，都应该先看 SKILL.md、依赖、权限、会读取和写入哪些路径，以及是否会自动联网、发消息或改代码。来自 Hub 不等于可以无审查运行。
从一次任务到 skill 的标准路径
一个好 skill 通常不是凭空设计出来的，而是从真实任务里长出来的。推荐路径是：
- 第一次让 Hermes 完成任务，只保留对话、命令和结果。
- 第二次让它在相同场景下复用旧经验，观察步骤是否稳定。
- 第三次把输入、输出、失败条件和人工确认点写清楚。
- 再把它沉淀成 skill，并做权限审查。
- 在低风险 profile 里试跑，不要直接接 gateway 或 cron。
- 通过后再决定是否进入团队共享或自动触发。
例如“每周生成站点内容缺口报告”就适合进入候选池。它有固定输入：教程列表、搜索意图、现有页面长度、近期更新记录；有固定输出：缺口、优先级、下一批标题；也有明确边界：不自动发布、不自动修改商业披露、不强推。这样的任务比“帮我研究一下最近的 AI”更适合沉淀。
不要把 skill 写成黑盒
Skill 一旦开始被 cron、gateway 或团队成员调用，就不再只是个人脚本。它应该让后来的人看得懂：
- 为什么存在这个 skill。
- 适合在哪些项目、profile 或用户身份下使用。
- 触发前需要哪些输入。
- 会读取和写入哪些位置。
- 会调用哪些外部服务。
- 失败时会留下什么输出。
- 哪些动作需要人工确认。
- 如何禁用、更新或回滚。
如果一个 skill 只能靠创建者口头解释，就还没有达到长期复用标准。
安全审查清单
上线一个 skill 前，至少检查：
| 检查项 | 风险问题 | 通过标准 |
|---|---|---|
| 文件系统 | 会不会读写敏感目录 | 路径白名单清楚 |
| secrets | 是否需要 token、cookie、私钥 | 只从安全位置读取，不进入 memory 和日志 |
| 外部 API | 是否会联网或发消息 | endpoint、频率、身份都可追踪 |
| destructive 命令 | 是否会删除、覆盖、reset 或 force push | 默认禁止，必要时必须人工确认 |
| 输入验证 | 是否能处理空输入、错误路径、异常格式 | 有清晰失败输出 |
| 输出审计 | 是否能留下摘要和日志 | 人能复盘发生了什么 |
| 触发方式 | 是否会被 cron 或 gateway 自动调用 | 高风险动作需要确认门槛 |
如果 skill 会提交代码、推送仓库、部署服务或发送外部消息，建议把它当成生产自动化来审查，而不是当成提示词模板。
和 Memory、Cron、Gateway 的边界
| 能力 | 保存什么 | 常见误用 |
|---|---|---|
| Memory | 长期事实和偏好 | 把流程步骤、日志、secrets 塞进去 |
| Skills | 可复用动作和执行流程 | 把一次性探索沉淀成长期能力 |
| Cron | 定时触发 | 在没有审查的情况下周期性调用高权限 skill |
| Gateway | 外部消息入口 | 让任何群成员触发高风险技能 |
| Profiles | 环境和身份边界 | 多环境共享同一套高权限 skill |
Memory 可以告诉 Hermes “这个项目禁止 force push”；Skill 可以执行“发布前检查”；Cron 可以定时触发“生成只读报告”；Gateway 可以接收外部请求。把边界分清楚，长期系统才不会越用越危险。
适合第一批做成 skill 的任务
优先从低风险、可验收的任务开始：
- 发布前只读检查：读取文件、跑测试、输出摘要，不自动修复。
- 内容缺口报告：统计教程、搜索意图和页面长度，输出候选选题。
- 会议纪要整理：输入一段记录，输出行动项，不自动发消息。
- 依赖健康检查：读取 package 文件和 lockfile，输出风险，不自动升级。
- 文档链接检查：扫描内部链接，输出 broken links，不自动重写大段内容。
不建议第一批做成 skill 的任务：
- 自动删除文件。
- 自动部署生产。
- 自动改 Git 历史。
- 自动把消息发到群里。
- 自动把敏感内容写进 memory。
完成检查
- 你已经列出至少 3 个 skill 候选。
- 每个候选都有输入、输出和成功标准。
- 你能指出哪些技能需要人工确认。
- 你知道 skills 不是越多越好，而是越稳定、越可审查越好。
- 你能区分 memory、skill、cron、gateway 和 profile 的边界。
- 你已经知道第三方 skill 安装前要审查
SKILL.md、依赖、权限和外部调用。