本文属于「Hermes Agent自进化智能体深度解析」系列 | 模块四 · 第1篇

 

每次都从零开始，是一种浪费

你有没有这样的经历？

 

上个月，你花了半小时精心构造了一个prompt，让AI帮你完成了一个复杂的数据库迁移任务。效果很好，你很满意。

 

这个月，你需要做一个类似的迁移。但你发现——上次的prompt找不到了。于是你重新花半小时构造，反复调整，终于又跑通了。

 

下个月呢？如果再来一次，大概率还是要重新来过。

 

这就是临时交互的困境——每一次有价值的AI协作经验，都随着对话结束而消散。没有沉淀，没有复用，没有积累。

 

Hermes Agent的Skills系统，就是为了彻底解决这个问题。

 

Skills as Power Layer：从临时交互到能力资产

什么是Skill？

在Hermes的世界里，Skill是一组可复用、可组合、可演进的过程化能力资产。它将一次性的提示交互，封装为标准化的、可重复调用的能力单元。

 

用软件工程的概念来类比：

 

概念

类比

临时Prompt

脚本（一次性执行）

Skill

函数/模块（可复用调用）

Skill组合

库/框架（能力集合）

当你把一个常用的任务封装为Skill后，下次调用只需要一行指令，而不是重新构造完整的prompt。

 

Skill的七个必定义要素

每个Skill都必须定义以下七个要素：

 

1. Trigger（触发条件）

 

什么情况下应该调用这个Skill？

可以是关键词匹配、模式识别、或上下文判断

trigger: "当任务涉及数据库迁移时"

2. Inputs（输入规格）

 

这个Skill需要什么输入？

每个输入的类型、格式和约束

inputs:

  - source_db: 数据库连接字符串（必填）

  - target_db: 目标数据库连接字符串（必填）

  - tables: 需要迁移的表列表（可选，默认全部）

  - batch_size: 批量大小（可选，默认1000）

3. Tools（所需工具）

 

这个Skill需要调用哪些工具？

文件操作、数据库操作、CLI命令等

tools: [database_connector, file_write, terminal, progress_tracker]

4. Steps（执行步骤）

 

按什么顺序执行？

每一步的具体操作和预期输出

steps:

  - 1. 连接源数据库，读取表结构

  - 2. 在目标数据库创建对应的表结构

  - 3. 按批次读取源数据

  - 4. 转换数据格式（如果需要）

  - 5. 写入目标数据库

  - 6. 验证数据完整性

  - 7. 生成迁移报告

5. Failure Handling（失败处理）

 

每一步可能出什么错？

出错后如何处理？

failure_handling:

  - step: 3（批量读取）

    error: 连接超时

    action: 重试3次，间隔递增（1s, 2s, 4s）

    fallback: 记录失败的批次，继续处理后续数据

  - step: 5（批量写入）

    error: 唯一约束冲突

    action: 跳过冲突记录，记录到错误日志

    fallback: 将冲突记录写入待处理队列

6. Logs（日志记录）

 

记录哪些关键信息？

日志的格式和级别

logs:

  - level: INFO

    content: "开始迁移表 {table_name}，预计 {row_count} 条记录"

  - level: INFO

    content: "表 {table_name} 迁移完成，成功 {success_count}，失败 {fail_count}"

  - level: ERROR

    content: "表 {table_name} 批次 {batch_id} 迁移失败：{error_message}"

7. Verification（验证标准）

 

如何判断Skill执行成功？

验证的步骤和标准

verification:

  - 源数据库和目标数据库的表数量一致

  - 每张表的行数差异 < 0.1%

  - 抽样100条记录比对，一致率 100%

  - 无未处理的错误记录

  - 迁移报告已生成

Custom Skill Design：设计你自己的Skill

从临时prompt到Skill的转化过程

假设你经常需要做代码审查。之前每次都要写很长的prompt告诉AI怎么审查：

 

"请审查这段代码，注意以下方面：1. 是否有安全漏洞 2. 是否有性能问题

 3. 代码风格是否符合规范 4. 是否有边界条件未处理

 5. 是否有异常处理缺失 6. 是否与现有架构一致..."

把这个过程转化为Skill：

 

skill: code_review

trigger: "当需要审查代码变更时"

inputs:

  - files: 需要审查的文件列表

  - context: 相关的设计文档和Spec

  - standards: 项目编码规范

tools: [file_read, git_diff, linter_runner, test_runner]

steps:

  - 1. 读取变更文件的diff

  - 2. 运行静态代码分析

  - 3. 按六个维度逐一审查

  - 4. 标注问题严重级别

  - 5. 生成审查报告

failure_handling:

  - linter运行失败 → 跳过自动检查，仅做人工审查

  - 文件读取失败 → 记录错误，跳过该文件

logs:

  - 记录审查的文件数、发现的问题数、各级别的分布

verification:

  - 所有变更文件都已审查

  - 每个问题都有明确的级别和修复建议

  - 审查报告格式正确

一次定义，终身复用。下次审查代码，只需要：

 

/skill code_review --files src/api/matching.py,src/services/engine.py

Skill的组合能力

单个Skill解决单个任务，但Skill真正的威力在于组合：

 

数据库迁移Skill + 数据验证Skill + 性能测试Skill = 数据库升级工作流

代码审查Skill + 安全扫描Skill + 依赖检查Skill = 发布前检查工作流

需求分析Skill + 代码生成Skill + 测试生成Skill = 功能开发工作流

通过Skill组合，你可以构建出覆盖完整工作流的自动化能力链。

 

为什么Skills是AI原生的核心？

Skills系统代表了AI使用方式的根本转变：

 

从"临时交互"到"能力资产"：每次有价值的协作不再是临时的，而是沉淀为可复用的资产。

 

从"个人知识"到"组织能力"：一个工程师积累的Skill可以被整个团队复用，甚至跨项目迁移。

 

从"静态工具"到"进化能力"：Skill不是写完就固定了，它可以根据执行反馈持续优化（这将在第11篇中深入探讨）。

 

这正是模块四的核心内容——系统掌握Skills、MCP、Plugins、Hooks等应用组合，实现从单次Prompt调用，升级为可复用、可治理、可迭代的智能体能力资产搭建。

 

延伸阅读与交流

ccia-666