Hermes Agent 的 Skill 系统是什么？一句话：Agent 在完成复杂任务后，自动将解法保存为可复用的技能文件；下次遇到类似问题直接加载，遇到新坑自动修补，长期不用的技能自动归档——创建、使用、修补、淘汰形成循环，这就是 Hermes 被称为「自我进化 Agent」的核心原因。

不是你手动写好一堆规则喂给它，也不是简单的对话历史记忆。Hermes 的 Skill 是 Agent 的程序性记忆（Procedural Memory）——它记住的不是「发生过什么」，而是「怎么做一件事」。Claude Code 的 Skill 需要人编写或从市场安装，Cursor Rules 是开发者手动维护的静态配置，OpenAI Custom GPT Actions 是一次性定义的 API Schema。Hermes 的 Skill 是 Agent 从自己的执行过程中自主提炼出来的，并且会在后续使用中持续自我改进。

如果你还没读过 Hermes 的整体架构和能力全景，建议先看 Hermes Agent 完全指南。本文专注拆解 Skill 系统的每一个技术细节，从触发条件到 Curator 优化到实操开发。

Agent 什么时候会自动创建 Skill？

Hermes 通过 skill_manage 工具管理自己的 Skill。不是每次对话都会创建——只有当 Agent 判断这次解决方案值得长期保存时才会触发。

四种触发条件

第一种：成功完成复杂任务。 当一次任务使用了 5 次以上的工具调用，Agent 认为这个解决路径足够复杂、值得沉淀，就会自动执行 skill_manage create，把整个解法写成一份 SKILL.md 文件。

💡 通俗讲：你让 Agent 帮你配置一个多步骤的 CI/CD 流水线，它调了 7 个工具才搞定。搞定之后它会想：「这个方案下次可能还用得上」，于是自动保存为一份技能文件。

第二种：遇到错误并找到可行路径。 Agent 在执行过程中踩了坑、报了错，但最终找到了绕过去的方法。这种「从失败中学到的经验」会被保存为 Skill，避免下次踩同一个坑。

第三种：用户纠正了做法。 你告诉 Agent 「不对，应该这样做」，Agent 会把你纠正后的正确做法固化为 Skill。这是用户偏好向 Agent 能力的直接转化。

第四种：发现非平凡工作流。 Agent 在探索过程中偶然发现了一种高效的工作方式，即使这次任务本身不复杂，它也会把这个工作流模式保存下来，把一次性探索变为可复用步骤。

skill_manage 的六个操作

Agent 管理 Skill 不只有「创建」，还有精细的修改和维护能力：

其中 patch 是首选方法——因为只传送改动部分，不需要发送完整的 SKILL.md 内容，省 token。

Skill 的自我改进机制

Skill 创建只是起点。真正让 Hermes 「越用越聪明」的是后续的自我改进循环。

完整的进化循环

用户提出复杂任务
  → Agent 使用 5+ 工具调用解决
    → Agent 将解法保存为 SKILL.md
      → 下次遇到类似问题，Agent 自动加载该 Skill
        → 遇到新坑，Agent 自动修补 Skill
          → Curator 定期检查，归档废弃 Skill、合并重叠 Skill

这个循环有一个关键设计：Agent 在前台对话中通过 skill_manage create 创建的 Skill 被视为「用户指导的」——用户参与了创建过程。而 Agent 在后台自我改进审查中创建的 Skill 才被标记为「Agent 自建」。两者的区别在于，只有 Agent 自建的 Skill 才会被 Curator 自动管理。用户指导创建的 Skill，Curator 不会碰。

💡 通俗讲：你亲手指导 Agent 建的技能，系统认为你有意为之，不会自动清理掉。只有 Agent 自己悄悄建的技能，系统才会定期审查是否该保留。

后台自我改进审查

Agent 不只在对话中被动修补 Skill。大约每 10 个 Agent 轮次，系统会启动一次后台审查分叉——这个分叉在独立的提示缓存中运行，不干扰当前对话。它会回顾最近的执行经验，把分散的小 Skill 合并成更完整的「伞 Skill」，或者修补已有 Skill 中发现的问题。

Curator：Skill 库的自动清道夫

没有维护机制的 Skill 系统注定会失控。每当 Agent 解决一个新问题并保存 Skill，~/.hermes/skills/ 目录就多一个文件。用不了几周，大量狭窄的近似重复 Skill 就会污染目录、浪费 token。

Curator 就是来解决这个问题的。

运行条件

Curator 不依赖外部 cron 守护进程，它在 Hermes 内部自触发。两个条件同时满足时自动启动：

1. 距上次 Curator 运行已过 168 小时（7 天）
2. Agent 已空闲至少 2 小时

两个条件缺一不可——既不会在 Agent 忙碌时干扰工作，也不会频繁运行浪费资源。

两阶段处理

第一阶段：自动状态转换——确定性操作，不调用大模型。

• 30 天未使用的 Skill → 标记为 stale（过时）
• 90 天未使用的 Skill → 移入 ~/.hermes/skills/.archive/ 归档目录

第二阶段：大模型审查——启动一个辅助模型通道，最多 8 轮迭代。

分叉的 Agent 遍历所有 Agent 自建的 Skill，逐个读取内容，对每个 Skill 做出决策：保留、修补、合并重叠的 Skill，或者归档。合并时有一条铁律——Skill 被视为完整包。如果一个 Skill 包含 references/、templates/、scripts/、assets/ 等子目录，Curator 必须整包保留或整包归档，不允许只把 SKILL.md 扁平化到另一个 Skill 的 references/ 里。

Curator 管理的精确边界

一个 Skill 被 Curator 管理需要同时满足三个条件：

1. 名称不在 .bundled_manifest——不是内置 Skill
2. 名称不在 .hub/lock.json——不是 Hub 安装的 Skill
3. .usage.json 中标记为 "created_by": "agent" 或 "agent_created": true

只有后台自我改进审查分叉创建的 Skill 才会设置这个标记。你在对话中指导 Agent 创建的 Skill 不在此列——Curator 故意不碰。

使用量遥测

~/.hermes/skills/.usage.json 为每个 Skill 维护精确的使用数据。每条记录包含三类计数器和状态标记：

提示词：生成 Hermes Skill 使用量遥测的 JSON 结构

请帮我生成 ~/.hermes/skills/.usage.json 中单个 Skill 的遥测字段。要求：

• use_count：Skill 被加载进对话提示词时递增
• view_count：Agent 调用 skill_view 时递增
• patch_count：任何修改操作执行时递增
• last_used_at / last_viewed_at / last_patched_at：对应操作的 ISO 8601 时间戳
• created_at：Skill 创建时间
• state：当前状态，取值 active / stale / archived
• pinned：布尔值，true 时阻止 Curator 自动归档
• archived_at：归档时间戳，未归档时为 null

Curator 根据 last_used_at 的时间距离来判断是否该标记为 stale 或归档。

安全网：Pin 保护与一键回滚

担心 Curator 误操作？有三道安全网：

# 锁定关键 Skill，阻止 Curator 自动归档和 Agent 删除
hermes curator pin api-health-monitor

# 每次 Curator 运行前自动备份整个 skills 目录
# 出问题一键回滚到上次运行前的状态
hermes curator rollback

# 从归档中恢复单个 Skill
hermes curator restore my-old-skill

每次 Curator 运行后还会生成人类可读的报告：

~/.hermes/logs/curator/
└── 20260429-111512/
    ├── run.json      # 机器可读：完整统计和大模型输出
    └── REPORT.md     # 人类可读摘要

高频使用场景的配置优化

默认参数对大多数用户够用，但如果你和 Agent 交互频繁，可以缩短 Curator 的运行间隔和归档窗口。在 ~/.hermes/config.yaml 的 curator 段调整以下参数：

提示词：生成高频交互场景的 Curator 配置

请帮我生成 ~/.hermes/config.yaml 中 curator 段的配置。要求：

• enabled：设为 true 开启自动清理
• interval_hours：运行间隔，默认 168（7 天），高频场景建议 72（3 天一次）
• min_idle_hours：Agent 空闲多久后允许运行，默认 2，可缩短到 1
• stale_after_days：未使用多少天标为 stale，默认 30，高频场景建议 14
• archive_after_days：未使用多少天归档，默认 90，高频场景建议 45
• prune_builtins：设为 true 时也会归档未使用的内置 Skill

渐进式披露：155+ 个 Skill 怎么不撑爆上下文？

155 个以上的 Skill，每个 Skill 可能几百到几千 token，全塞进系统提示词的话成本和延迟都会爆炸。Hermes 的解法是渐进式披露（Progressive Disclosure）——分层加载，用到才展开。

Skill 的三级加载

Level 0（会话启动）: skills_list()        → 所有 Skill 的名字和描述  约 3000 token
Level 1（按需激活）: skill_view(name)     → 完整 SKILL.md 内容      大小不等
Level 2（深度参考）: skill_view(name, path) → Skill 内的特定参考文件  按需

Level 0 在每次会话启动时自动执行。只加载一份精简的清单——每个 Skill 只有名字和描述，相当于一份目录索引。155 个 Skill 的目录索引大约 3000 token，可以接受。

Level 1 在 Agent 判断需要某个 Skill 时才触发。你用斜杠命令 /gif-search funny cats 或者在对话中提到相关需求，Agent 通过 skill_view 加载该 Skill 的完整内容。

Level 2 更进一步——Skill 内部引用了参考文件（references/ 目录下的文档），只有 Agent 确实需要查阅时才加载。

核心收益：Skill 不被使用时零 token 开销。

tool_search：工具层的同类优化

Skill 的渐进式披露解决的是 Skill 内容的加载问题。工具层面还有另一个问题：72 个工具的完整 Schema 定义约占 19,210 token。

Hermes 的 tool_search 元工具采用类似策略——只有 7 个高频核心工具始终保持完整 Schema 加载，其他工具通过 tool_search / tool_details 按需查找。效果：从 19,210 token 降到 2,200 token，减少 89%。 tool_search 的完整配置参数（mode、threshold、pinned_tools、evict_after_turns 等）详见 Hermes Agent 成本控制与本地模型部署。

💡 通俗讲：就像一个工匠不会把所有工具铺满工作台。常用的螺丝刀、扳手放手边，其他工具收在抽屉里，需要时拿一把出来，用完放回去。

Skill 的渐进式披露 + 工具的按需加载，两层配合让 Hermes 在上下文窗口有限的模型上也能高效运行。

155+ 内置 Skill 全景：17 个分类覆盖什么能力？

Hermes 出厂自带的 Skill 分为两大池子：85+ 个内置 Skill（Bundled，默认安装）和 70+ 个可选 Skill（Optional，按需安装）。

内置 Skill——17 个分类，85+ 个

可选 Skill——18 个分类，70+ 个

可选 Skill 覆盖了更多专业领域。其中 MLOps 类是最庞大的单一分类，包含 27 个 Skill：

这个 Skill 库的广度意味着：大多数常见场景，你不需要从零写 Skill——先看看有没有现成的。

值得首批安装的 Skill

基于社区和第三方评测的反馈，这几个 Skill 使用频率最高：

• obsidian：把 Obsidian 笔记库变成 Agent 可读写的知识库，搜索、创建、更新笔记
• test-driven-development：强制 Agent 遵循 TDD 工作流——先写失败测试，再实现功能
• github-pr-workflow：标准化的 PR 创建和审查流程
• hermes-agent-skill-authoring：教 Agent 创建 Skill 的 Skill——Skill 系统的自举能力

LobeHub 导入与 agentskills.io 开放标准

Skill 不是提示词市场

一个常见误解是把 Hermes Skills Hub 当成「提示词市场」。不是。每个 Skill 是包含指令、脚本、参考文件和资源的完整能力包，遵循 agentskills.io 开放标准的目录结构：

skill-name/
├── SKILL.md          # 必需：元数据前置声明 + 指令正文
├── scripts/          # 可选：可执行脚本
├── references/       # 可选：参考文档
├── assets/           # 可选：模板、资源
└── ...

agentskills.io 规范推荐 SKILL.md 主体控制在 500 行 / 5000 token 以内，详细参考资料放到子目录按需加载。这个约束直接服务于渐进式披露——主文件不能太大，否则 Level 1 加载的成本就失控了。

跨 Agent 可移植性

agentskills.io 定义的是一个开放的 Skill 格式标准，不绑定特定 Agent 运行时。同一个 SKILL.md 文件理论上可以在 Hermes、OpenClaw、Claude Code、Cursor 等兼容运行时加载。

区别在于：Skill 文件本身是可移植的，但自主创建和 Curator 维护是 Hermes 独有的行为。 其他运行时只能手动安装和管理这些文件。如果你对 Claude Code 的 Skill 开发感兴趣，可以参考 Claude Code Skill 开发指南——两套系统的 Skill 文件格式高度兼容，但运行时的自动化机制完全不同。

9 个 Skill 安装源

Hermes 集成了 9 个 Skill 生态源，从官方到社区多层次覆盖：

LobeHub 导入是其中比较有意思的一条路径——它可以搜索 LobeHub 公共 Agent 目录中的 Agent 条目，将其转换为可安装的 Hermes Skill：

hermes skills search react --source lobehub
hermes skills install lobehub/<agent-id>

四级安全信任体系

安装社区 Skill 的安全保障：

安全扫描器检查五类风险模式：数据外泄指令、提示注入攻击、破坏性命令（rm -rf 等）、Shell 注入、可疑的供应链信号。标记为 dangerous 的 Skill 始终阻止安装，不支持 --force 覆盖。

Skill 开发实战：从零写一个 Skill

第一步：Skill 还是 Tool？

在动手之前先判断：你要实现的能力适合做成 Skill 还是 Tool？

做 Skill：能力可以用「指令 + Shell 命令 + 现有工具」表达。比如封装一个 CLI 工具的使用流程、定义一套 Git 工作流规范、包装 API 调用模式。

做 Tool：需要端到端集成 API Key 和认证流程、处理二进制数据或流式传输、需要精确的自定义处理逻辑。比如浏览器自动化、文字转语音、视觉分析。

💡 通俗讲：Skill 是教 Agent 「怎么用已有的工具做事」，Tool 是给 Agent 「造一把新工具」。

第二步：创建目录和 SKILL.md

mkdir -p ~/.hermes/skills/api-health-monitor

在目录内创建 SKILL.md 文件，先写 YAML 前置声明。前置声明定义了 Skill 的身份、分类和可配置参数：

提示词：生成 Hermes SKILL.md 的 YAML 前置声明

请帮我生成一个 Hermes Skill 的 YAML 前置声明（放在 --- 围栏内）。要求包含以下字段：

• name：Skill 名称，最多 64 字符，只允许小写字母、数字和连字符
• description：用途描述，最多 1024 字符，说明触发条件——这段文字在 Level 0 加载时展示，直接决定 Agent 是否激活该 Skill
• version：语义版本号，如 1.0.0
• metadata.hermes.tags：标签数组，用于分类检索，如 [monitoring, api, devops]
• metadata.hermes.category：所属分类，如 devops
• metadata.hermes.requires_toolsets：条件激活——只在指定工具集可用时才显示，如 [terminal, web]
• metadata.hermes.config：用户可配置参数数组，每项包含 key（配置键名）、description（说明）、default（默认值）、prompt（交互提示语）

我的 Skill 功能是：[在此描述你的 Skill 用途]

前置声明中最关键的是 description 字段——它在 Level 0 阶段展示给 Agent，是 Agent 决定是否激活这个 Skill 的唯一依据。requires_toolsets 控制条件激活，config 中定义的参数存储在 config.yaml 中，Agent 运行时读取。

第三步：编写指令正文

前置声明下方写 Markdown 格式的指令正文。指令正文是 Agent 执行 Skill 时的操作手册，包含触发条件、操作步骤、输出格式和告警规则：

提示词：生成 Hermes SKILL.md 的指令正文

请帮我编写 SKILL.md 前置声明之后的 Markdown 指令正文。要求包含以下结构：

• When to use 段：列出触发条件清单（如"检查 API 端点健康""监控服务可用性""生成运行时间报告""排查延迟峰值"）
• 操作步骤：编号步骤，每步明确操作（如从 config 读取端点列表、用 curl 检测状态码和响应时间、与阈值对比）
• curl 命令模板：curl -o /dev/null -s -w "%{http_code} %{time_total}" <endpoint>
• 报告输出格式：Markdown 表格模板，包含端点、状态码、响应时间、判定结果（OK/WARN/FAIL）列
• 告警条件：HTTP 状态码非 2xx、响应时间超过阈值、端点不可达三种情况触发告警

我的 Skill 功能是：[在此描述你的 Skill 用途]

指令正文中可以使用两个模板变量：${HERMES_SKILL_DIR} 替换为 Skill 目录的绝对路径，${HERMES_SESSION_ID} 替换为当前会话 ID。引用 Skill 内的脚本或资源文件时用这个变量。

第四步：添加支持文件（可选）

如果你的 Skill 需要自带脚本或参考文档：

api-health-monitor/
├── SKILL.md
├── scripts/
│   └── batch-check.sh    # 批量检查脚本
└── references/
    └── status-codes.md   # HTTP 状态码参考

在 SKILL.md 中引用支持文件：

Run the batch check script:
    bash ${HERMES_SKILL_DIR}/scripts/batch-check.sh

参考文件不会在 Level 1 加载——只有 Agent 调用 skill_view(name, "references/status-codes.md") 时才会读取，这是 Level 2 按需加载。

第五步：条件激活（可选）

如果你的 Skill 是某个工具的兜底方案，可以用条件激活字段控制显示逻辑：

metadata:
  hermes:
    fallback_for_toolsets: [web]    # web 工具集可用时隐藏，不可用时显示

实际场景：内置的 duckduckgo-search Skill 用了 fallback_for_toolsets: [web]。当 FIRECRAWL_API_KEY 存在时 web 工具集可用，DuckDuckGo Skill 自动隐藏；API Key 缺失时 web 工具集不可用，DuckDuckGo Skill 自动浮现作为兜底。

第六步：测试

安装后通过斜杠命令测试：

hermes
> /api-health-monitor
# Agent 加载 Skill 并询问你要监控哪些端点

也可以在自然对话中触发——直接说「帮我检查一下这几个 API 的健康状态」，Agent 会根据描述匹配到你的 Skill 并自动加载。

如果发现问题，Agent 自己就能修补：

用户: 报告格式改成 JSON 输出
Agent: 好的，我来修改 Skill。
       [调用 skill_manage patch，更新报告输出格式]

Skill Bundle：组合多个 Skill

如果你经常需要同时使用几个相关的 Skill，可以把它们编组为一个 Bundle。Bundle 是一个 .bundle.yaml 文件，放在 ~/.hermes/skills/ 目录下，定义一组 Skill 的组合和执行顺序：

提示词：生成 Hermes Skill Bundle 配置

请帮我生成一个 Hermes Skill Bundle 文件（~/.hermes/skills/{名称}.bundle.yaml）。要求：

• name：Bundle 名称，如 fullstack-dev
• description：整体用途描述，如"全栈开发工作流——代码审查、测试、PR 管理"
• skills：包含的 Skill 名称列表，如 github-code-review、test-driven-development、github-pr-workflow、codebase-inspection
• instruction：工作流执行顺序指令，用编号步骤定义各 Skill 的调用顺序（如先检查代码结构 → 写失败测试 → 实现功能 → 自审 → 创建 PR）

我需要组合的 Skill 是：[列出你想编组的 Skill 名称和期望的执行顺序]

运行 /fullstack-dev 一次加载 Bundle 内全部关联 Skill，并且按 instruction 中定义的工作流顺序执行。

GEPA 自我进化：从执行 trace 中反思优化

除了 Agent 内建的「做中学」循环，Hermes 还有一条更系统的自我进化路径——GEPA（Genetic-Pareto Prompt Evolution，基因-帕累托提示进化），由独立项目 hermes-agent-self-evolution 实现。

两种进化的分层互补

GEPA 的工作方式：读取 Agent 的执行 trace，不仅知道哪里失败了，还理解为什么失败。然后提出针对性的变异方案——每个变体必须通过完整测试套件、大小限制、缓存兼容性、语义保持等多维度验证。

目前已实现的是第一阶段——优化 Skill 文件。后续计划扩展到优化工具描述、系统提示词和工具代码。这是一个有人在环的自我进化流程，不是完全无人值守。

翔宇的技能边界规则：创作类禁建 Skill

我在 Mac mini 上跑 Hermes 两个月，踩过的一个坑值得分享：Hermes 的 Skill 系统和我在 Claude Code 里维护的知识库工作流，如果不划清边界，会产生两套平行的「野生流程」。

我的解法是在 SOUL.md 中设了一条红线：

创作类任务（写文章、发推文、写公众号、发布内容、翻译、SEO 等）：
禁止创建技能，必须走 KB 工作流。

允许 Hermes 自动创建 Skill 的范围：Hermes 自身的平台操作、知识库检索优化、工具调用快捷方式、日常问答模式。

核心理由：知识库（KB）工作流和 Hermes Skill 不在同一层。工作流是多步创作管线——品牌差异、SEO 规范、多平台分发，这些复杂度由 KB 承载。Skill 是单次操作的快捷方式——轻量、即时、可自我修补。两层各管各的，不冲突。

但如果 Hermes 把工作流逻辑写进 Skill，就会产生两个真值源：KB 里一套，Hermes 的 ~/.hermes/skills/ 里又一套。我改了 KB 工作流，Hermes 不会知道；Hermes 自己修补了 Skill，KB 工作流也不会更新。

这个问题的根源在于指针架构的设计：Hermes 的 SOUL.md、MEMORY.md、USER.md 只存路径指针和导航指令，不复制内容。Claude Code 改了任何 KB 工作流，Hermes 下次对话通过 read_file 现场读取即可感知——零维护。但如果 Hermes 把工作流逻辑固化进了 Skill，这个「现场读取、零维护」的优势就断掉了。

如果你也在多 Agent 协作环境中使用 Hermes，建议在 SOUL.md 里明确 Skill 创建的边界——哪些事让 Hermes 自主学习，哪些事走外部系统。关于 SOUL.md 记忆系统的完整设计，参见 Hermes Agent SOUL.md 记忆系统详解。

社区怎么看 Skill 自我进化？

X 上的开发者评论直接：

"Hermes Agent 的自进化 Skill 是最强大的功能。Agent 不只是解决问题——它记住了自己是怎么解决的。" —— @akshay_pachaar

这个评价精确抓住了关键区别：大多数 Agent 框架在每次对话结束后就「失忆」了，下次遇到同样的问题需要从头推理。Hermes 把推理结果沉淀成文件，下次直接加载，跳过推理过程。

社区也观察到了一些已知局限：

• 5+ 工具调用的触发阈值可能过于宽泛——Agent 有时会固化只需要用一次的工作流，产生大量狭窄的一次性 Skill
• Curator 的 90 天归档窗口偏长——高活跃度的 Agent 在两次 Curator 运行之间仍会累积大量过时 Skill
• GEPA 不是完全自主的——需要人工启动、需要 PR 审查，目前只能优化 Skill 文件

这些都是实际使用中的真实反馈。前两个问题可以通过调整 Curator 配置来缓解（缩短间隔、降低阈值），第三个是产品阶段决定的——GEPA 目前还在第一阶段。

常见问题

Hermes Skill 和 Claude Code Skill 有什么区别？

最核心的区别是自主创建能力。Claude Code 的 Skill 由人手动编写或从市场安装，Agent 本身不会在执行过程中自动创建新 Skill。Hermes 的 Skill 可以由 Agent 在完成复杂任务后自动创建，形成创建、使用、修补、淘汰的完整循环。此外，Hermes 有 Curator 自动清理机制，Claude Code 没有。更多关于 Claude Code Skill 的内容可以参考 Claude Code Skill 开发指南。

Agent 自动创建的 Skill 质量可靠吗？

初始质量取决于 Agent 的推理能力和任务复杂度。但 Hermes 有两道保障：第一道是自我改进循环，Skill 在后续使用中遇到问题会自动修补（skill_manage patch）；第二道是 Curator 定期审查，合并重叠的 Skill、归档废弃的 Skill。如果你追求更系统的优化，还可以用 GEPA 自我进化引擎做反思式重写，每次约 $2-$10。

Skill 太多会不会拖慢 Agent 响应速度？

不会。Hermes 采用渐进式披露策略：会话启动时只加载所有 Skill 的名字和描述（约 3000 token），完整 Skill 内容只在 Agent 决定需要时才展开。配合 tool_search 元工具，72 个工具的 Schema 从 19,210 token 降到 2,200 token，减少 89%。未使用的 Skill 真正做到零 token 开销。

Curator 会误删我正在用的 Skill 吗？

不会。Curator 通过 usage.json 中的精确使用量遥测来判断：30 天未使用标为 stale，90 天未使用才归档。经常使用的 Skill 的 last_used_at 会持续更新，不可能被归档。你还可以用 hermes curator pin 命令锁定关键 Skill，彻底阻止自动归档。即使误操作，也有 hermes curator rollback 一键回滚和 hermes curator restore 单个恢复。

Hermes Skill 能在 Claude Code 或 Cursor 中使用吗？

Skill 文件本身基于 agentskills.io 开放标准，同一个 SKILL.md 可以在兼容的运行时加载。但自主创建和 Curator 维护是 Hermes 独有行为——其他运行时只能手动安装和管理这些 Skill 文件。格式兼容，自动化不兼容。

安装社区 Skill 安全吗？

Hermes 有四级信任体系。内置和官方 Skill 始终信任；受信源（openai/skills、anthropics/skills 等）策略更宽松；社区源必须通过安全扫描器检查五类风险模式——数据外泄、提示注入、破坏性命令、Shell 注入、供应链信号。标记为 dangerous 的 Skill 始终阻止安装。

GEPA 自我进化和 Skill 自动创建有什么关系？

分层互补。Skill 自动创建是「做中学」——Agent 从执行过程中自动沉淀经验，增量修补。GEPA 是「反思式进化」——通过 DSPy 框架读取执行 trace，理解失败原因，提出系统性变异，经完整测试套件验证后优化。GEPA 每次运行约 $2-$10 API 费用，需要人工启动和 PR 审查，目前处于第一阶段（Skill 文件优化）。

如何开始写自己的第一个 Skill？

最快的方式是使用内置的 hermes-agent-skill-authoring Skill——输入 /hermes-agent-skill-authoring，告诉 Agent 你想创建什么能力，它会引导你完成完整流程。也可以手动在 ~/.hermes/skills/ 下创建目录和 SKILL.md 文件。本文「Skill 开发实战」章节有完整的六步教程，从目录创建到前置声明到指令正文到条件激活到测试。

进一步阅读

• Hermes Agent 完全指南：架构全景、核心能力、成本对比、部署方案，本系列的总入口
• Hermes Agent SOUL.md 记忆系统详解：三层记忆架构、指针架构设计、记忆与 Skill 的协同
• Hermes Agent Cron 自动化实战：定时任务调度、Cron 交付 Skill、「你睡觉时它在工作」的自动化方案
• Claude Code Skill 开发指南：Claude Code 视角的 Skill 开发，与 Hermes Skill 格式兼容但运行时机制不同

下一步

• AI 编程实操课：Claude Code + Codex + Agent 工作流，覆盖一人公司、自媒体自动化、AI 副业全场景。237 篇实战教程 + 最佳实践 + 源码包，跟着做就出成果。国内版-FlowUS | 国际版-BMC
• YouTube 频道：翔宇工作流
• 微信公众号：搜索「翔宇工作流」