Hermes Skills 安全审查清单：上线前必须检查的权限、命令和输入输出

Hermes 安全 进阶 进阶 预计 18 分钟 发布于 2026/6/1 核验于 2026/6/5

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 上线前，先写清：

如果你说不清输入输出，这个 skill 还没有资格长期复用。

触发入口审查

同一个 skill，被不同入口触发，风险完全不同。

一个 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 时，至少确认：

1. 使用环境变量或安全配置读取凭据。
2. 日志不打印 secrets。
3. 失败时不会把敏感响应原样发到消息入口。
4. API 调用有明确目的和最小权限。
5. 速率限制、重试和超时有边界。

涉及第三方 API 的 skill，最好先以只读模式试点。

输入输出审查

长期 skill 最容易被忽略的是输入输出。你需要明确：

• 用户输入是否会进入 shell、SQL、文件路径或 URL。
• 文件名、目录名和参数是否需要白名单。
• 输出是否可能包含 secrets、客户数据或内部路径。
• 是否会把模型生成内容直接发布到外部系统。
• 是否把失败日志原样回传给消息入口。

如果 skill 会把用户输入拼接进命令，至少需要转义、白名单或改用结构化 API。不要把“让模型自己小心”当作安全机制。

适合人工确认的动作

这些动作不建议直接自动执行：

• 修改生产配置。
• 推送代码或合并 PR。
• 发布文章、发送群消息或通知客户。
• 创建、删除或修改 cron job。
• 更改权限、策略、secrets。
• 执行付费操作或不可逆动作。

一个简单规则：如果结果会影响别人、花钱、上线或难以回滚，就先让人确认。

上线前试运行路线

不要直接把新 skill 接到生产入口。更稳的路线是：

1. 在临时目录或测试仓库里手动运行。
2. 用只读输入跑一遍，确认输出结构。
3. 人工模拟失败场景：缺文件、缺 token、网络超时、权限不足。
4. 检查日志是否泄露敏感信息。
5. 再接入一个低风险 profile。
6. 最后才考虑 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 长期运行。
• 你已经把触发入口、失败停止条件和回滚方式写清楚。