Hermes skills 最迷人的地方，是它能把一次成功任务变成长期能力。最危险的地方，也正在这里。
临时任务失败一次，影响有限；长期 skill 被 cron、gateway 或团队成员反复调用，风险会被放大。所以审查 skill 时，不要只问“能不能跑”，要问“长期跑会不会出事”。
这篇适合什么场景
如果你准备把 Hermes skill 用到下面任一入口，这篇应该在上线前读完：
- 让 cron 定期调用 skill。
- 让 messaging gateway 从 Telegram、团队频道或内部入口触发 skill。
- 让 API Server 或外部系统间接调用 skill。
- 把个人临时脚本交给团队成员复用。
- 让 skill 读写仓库、配置、文档、issue、PR 或外部服务。
搜索“Hermes skills 安全审查”的用户，真正需要的不是抽象安全口号，而是一张能逐项打勾的风险清单。
官方资料给出的边界
Hermes 官方 skills 指南强调把稳定经验沉淀为可复用能力，Agent Skills standard 也把 skill 视为带有说明、上下文和可执行资产的能力包。换句话说，skill 不是一句 prompt，也不只是一个脚本片段。
它一旦被发现、加载和复用，就会改变 Agent 能调用的能力范围。因此审查要覆盖三层：
- 文档层：skill 是否说清用途、输入、输出、限制和适用场景。
- 资产层：脚本、模板、依赖、示例文件是否可审计。
- 执行层：工具调用、文件读写、外部 API、人工确认和失败处理是否受控。
真正成熟的 skill，不是“能帮你省一步”，而是“别人也能看懂它为什么安全”。
先看任务边界
每个 skill 上线前，先写清：
| 问题 | 需要回答 |
|---|---|
| 解决什么任务 | 一句话说明目标 |
| 输入是什么 | 用户输入、文件、环境变量、API |
| 输出是什么 | 文本、文件、提交、消息、报告 |
| 会读哪里 | 目录、仓库、数据库、外部服务 |
| 会写哪里 | 文件、issue、PR、消息、配置 |
| 谁能触发 | 个人、团队、cron、gateway、API |
如果你说不清输入输出，这个 skill 还没有资格长期复用。
触发入口审查
同一个 skill，被不同入口触发，风险完全不同。
| 触发方式 | 主要风险 | 建议策略 |
|---|---|---|
| 手动 CLI 调用 | 用户能即时观察输出 | 可先试运行，但保留确认点 |
| cron 定时调用 | 错误会周期性重复 | 默认只读，写操作需要人工确认 |
| messaging gateway | 外部输入更嘈杂 | 加白名单、触发词和输入校验 |
| API Server | 可被系统链路放大 | 限制调用方、记录请求摘要 |
| 团队共享 | 使用者不一定理解边界 | 写清适用项目和禁止场景 |
一个 skill 在 CLI 下看起来安全，不代表放进 cron 或消息入口后仍然安全。入口越开放，默认权限越应该收紧。
命令审查
重点检查这些风险：
- 是否包含 destructive 命令。
- 是否会递归删除、覆盖或重命名文件。
- 是否会自动 commit、push、deploy。
- 是否依赖全局环境中的不确定命令。
- 是否会执行用户输入拼接出来的 shell。
- 是否缺少失败退出或错误提示。
一个稳的 skill 应该让危险动作显眼，而不是藏在长脚本里。
依赖和供应链审查
很多 skill 表面上只是一段流程，实际风险来自依赖：
- 是否安装 npm、pip、brew 或系统包。
- 是否从未经固定版本的远程脚本下载代码。
- 是否依赖全局 CLI 的当前登录态。
- 是否读取浏览器 profile、SSH key、cloud credentials 或本地配置。
- 是否要求用户把 token 写进示例文件。
如果 skill 必须安装依赖，至少写清版本、用途、最小权限和卸载方式。不要把“运行一次安装脚本”伪装成无风险动作。
Secrets 与外部 API
skill 不应该把 token、cookie、私钥写进正文、日志或 memory。需要外部 API 时，至少确认：
- 使用环境变量或安全配置读取凭据。
- 日志不打印 secrets。
- 失败时不会把敏感响应原样发到消息入口。
- API 调用有明确目的和最小权限。
- 速率限制、重试和超时有边界。
涉及第三方 API 的 skill，最好先以只读模式试点。
输入输出审查
长期 skill 最容易被忽略的是输入输出。你需要明确：
- 用户输入是否会进入 shell、SQL、文件路径或 URL。
- 文件名、目录名和参数是否需要白名单。
- 输出是否可能包含 secrets、客户数据或内部路径。
- 是否会把模型生成内容直接发布到外部系统。
- 是否把失败日志原样回传给消息入口。
如果 skill 会把用户输入拼接进命令，至少需要转义、白名单或改用结构化 API。不要把“让模型自己小心”当作安全机制。
适合人工确认的动作
这些动作不建议直接自动执行：
- 修改生产配置。
- 推送代码或合并 PR。
- 发布文章、发送群消息或通知客户。
- 创建、删除或修改 cron job。
- 更改权限、策略、secrets。
- 执行付费操作或不可逆动作。
一个简单规则：如果结果会影响别人、花钱、上线或难以回滚，就先让人确认。
上线前试运行路线
不要直接把新 skill 接到生产入口。更稳的路线是：
- 在临时目录或测试仓库里手动运行。
- 用只读输入跑一遍，确认输出结构。
- 人工模拟失败场景：缺文件、缺 token、网络超时、权限不足。
- 检查日志是否泄露敏感信息。
- 再接入一个低风险 profile。
- 最后才考虑 cron、gateway 或 API Server。
这条路线看起来慢，但比事后清理错误提交、误发消息或泄露日志便宜得多。
日志和回滚
长期 skill 必须让人复盘。至少保留：
- 本次输入摘要。
- 关键步骤。
- 最终输出。
- 失败原因。
- 是否触发外部动作。
- 如何回滚或撤销。
不要只留下“done”。对长期自动化来说，“done” 是最没有信息量的日志。
一个可复制的审查模板
Skill 名称：
主要任务：
适用 profile / 项目：
触发入口：CLI / cron / messaging gateway / API Server / 团队共享
输入：
输出：
读取范围：
写入范围：
外部 API：
需要的 secrets：
高风险动作：
人工确认点：
失败停止条件：
日志位置：
回滚方式：
最后审查人和日期：每次把 skill 改进到可以长期复用时，都应该更新这张模板。skill 是能力资产，资产必须有变更记录。
上线前检查清单
- 任务目标明确。
- 输入输出明确。
- 读写范围明确。
- 没有硬编码 secrets。
- 外部 API 权限最小化。
- 依赖来源、版本和用途可解释。
- cron、gateway、API Server 等触发入口已单独评估。
- 高风险动作需要人工确认。
- 失败时能安全停止。
- 有日志、摘要和回滚说明。
- 已经在低风险项目中试运行。
下一步怎么读
如果你还没判断哪些任务适合做成 skill，先读 Hermes Skills 实战。如果准备把 skill 交给定时任务调用，再看 Hermes Cron Job 示例。如果 skill 依赖长期偏好或项目约定，先用 Hermes Memory 实战 把事实和动作分开。
完成检查
- 你已经审查了至少一个候选 skill。
- 你知道它会读写什么。
- 你把高风险动作放到人工确认后面。
- 你没有把临时脚本直接交给 cron 长期运行。
- 你已经把触发入口、失败停止条件和回滚方式写清楚。