Skill 机器人 vs Hermes Agent:两种「AI 越用越聪明」的路径

1. 写在最前面

笔者最近一直在折腾一个基于企微的 AI 工作助手,核心功能是通过 Skill 来帮团队快速排查线上问题。用了几周下来,确实省了不少时间,但也踩了一些坑------最明显的就是 Skill 越加越多之后,AI 的决策速度肉眼可见地变慢了。

带着这个痛点,笔者去研究了一下 Hermes Agent,发现它的 Skill 系统有一套完全不同的设计思路:不仅支持人工编写 Skill,还能让 AI 自己从经验中创建 Skill,并且在后续使用中自动改进。更关键的是,它用了一种叫「渐进式加载」的机制来解决 Skill 多了之后的性能问题。

这篇文章就来对比一下这两种路径,顺便聊聊笔者在自研 Skill 机器人过程中的一些实践经验。

注:文中涉及的业务数据和 taskid 均已做脱敏处理,仅用于说明 Skill 的工作方式。

2. 笔者的企微 Skill 机器人:实战经验

2.1 它能做什么

笔者做的这个企微机器人,核心能力是通过 @全能工作助手 触发不同的 Skill,帮团队快速定位线上问题。每个 Skill 本质上是一段 Markdown 格式的指令,告诉 AI 在特定场景下应该怎么查、查什么、怎么分析。

一个典型的使用场景:

python 复制代码
@全能工作助手 分析一下为什么这个任务的语音识别报错了 <taskid>

AI 收到指令后,会按照对应 Skill 的流程去查 OTEL 链路、分析服务调用关系、定位报错时间点,最终给出一份结构化的分析报告。

实际输出效果(脱敏后):

css 复制代码
结论先说:这单更像不是语音识别服务自身报错,而是任务在后端已经不存在了,
后续相关的上报/更新请求打到服务端时,被直接返回 404 task not found。

关键信息:
· 当天该 taskid 的链路里只有 3 个服务有记录
· 没有看到独立的识别服务 span,失败点在按 taskid 查任务时就出现了
· 最后一批成功请求结束于 21:11,首次 404 出现在 22:00
· 两者间隔约 48 分钟

更准确的判断:
· 这不是「识别引擎返回异常」
· 而是「任务先被清理了,后续请求继续带着这个 taskid 过来,被服务端拒掉」

边界说明:
· 部分 worker 侧原始日志有权限限制,无法进一步确认是谁先清理了任务

这种分析如果纯靠人工去查 OTEL、翻日志、对时间线,少说也要 20 分钟。有了 Skill 之后,基本上一分钟内就能拿到结论。

2.2 Skill 的实现方式

每个 Skill 就是一份 Markdown 文件,定义了 AI 在特定场景下的分析流程:

markdown 复制代码
# 语音识别报错分析

## 触发条件
用户提问中包含「语音识别」「asr」「报错」等关键词,并提供了 taskid

## 分析流程
1. 根据 taskid 查询 OTEL 链路数据
2. 确认涉及的服务列表和调用关系
3. 按时间线梳理成功请求和失败请求的分界点
4. 分析失败原因(服务自身报错 vs 上游依赖问题 vs 任务状态异常)
5. 输出结论,明确说明边界和不确定的部分

## 输出格式
- 结论先行
- 关键信息列表
- 时序分析
- 边界说明

2.3 踩过的坑:Skill 越多越慢

这个机器人用了几周,Skill 从最初的 5 个涨到了 10 多个,覆盖了各种排查场景。但问题也来了:AI 的响应速度明显变慢了

原因很直观------每次用户提问,AI 都需要把所有 Skill 的内容加载进上下文,然后判断「这次应该用哪个 Skill」。Skill 越多,上下文越长,判断时间越久,token 消耗也越大。

复制代码
5 个 Skill 时:响应时间 ~3s,体验流畅
10 个 Skill 时:响应时间 ~5s,还能接受
20+ 个 Skill 时:响应时间 ~10s+,明显卡顿,偶尔还会选错 Skill

注:这个问题本质上是「全量加载」导致的。每次对话都把所有 Skill 塞进上下文,不管用不用得上,token 就这么白白消耗了。后面会看到 Hermes 是怎么解决这个问题的。

3. Hermes Agent 的 Skill 系统:深入拆解

3.1 Hermes 是什么

Hermes Agent 是 Nous Research 开发的一个开源 AI Agent,2026 年 2 月发布,MIT 协议。它不是一个 IDE 插件,而是一个独立运行的 Agent,可以跑在 CLI、Telegram、Discord、Slack 等平台上。

它最核心的卖点是「自我进化」------用得越多越聪明,这个能力主要靠 Skill 系统和 GAPA 机制来实现。

3.2 GAPA:每 15 次调用自我审视一次

GAPA(Generalized Action and Prompt Adaptation)是 Hermes 的核心进化引擎。它的工作方式是:

markdown 复制代码
每 15 次工具调用后,Hermes 会暂停当前任务,做一次「自我审视」:
1. 回顾刚才的执行过程
2. 分析哪些步骤是成功的,哪些是低效或失败的
3. 如果发现可复用的模式,自动生成一个 Skill 文件
4. 如果已有的 Skill 在这次执行中表现不佳,自动更新它

注意,GAPA 不会修改底层模型的权重,它只是优化 prompt 和 Skill 的内容。这意味着进化过程是稳定的,不会出现「改着改着模型行为突变」的风险。

举个具体的例子:

假设你让 Hermes 帮你做竞品分析,第一次它可能是这样执行的:

markdown 复制代码
第 1 次执行(没有 Skill):
1. 搜索竞品 A 的官网 → 提取定价信息 → 失败,官网改版了
2. 换用搜索引擎查竞品 A 定价 → 成功
3. 搜索竞品 B 的官网 → 提取定价信息 → 成功
4. 搜索竞品 C 的官网 → 提取定价信息 → 失败,又改版了
5. 换用搜索引擎查竞品 C 定价 → 成功
6. 整理对比表格
耗时:约 8 分钟,中间走了 2 次弯路

GAPA 审视后,Hermes 会自动生成一个 Skill:

markdown 复制代码
---
name: competitor-pricing-research
description: 竞品定价调研流程
version: 1.0.0
metadata:
  hermes:
    tags: [research, pricing]
    category: business
---
# 竞品定价调研

## 经验总结
直接访问官网提取定价信息成功率不高(约 50%),建议优先使用搜索引擎。

## 优化后的流程
1. 优先通过搜索引擎查询「{竞品名} pricing 2026」
2. 如果搜索结果不够准确,再尝试访问官网
3. 提取定价信息后,统一整理成对比表格

第二次执行同类任务时:

markdown 复制代码
第 2 次执行(有 Skill):
1. 加载 competitor-pricing-research Skill
2. 直接用搜索引擎查竞品 A 定价 → 成功
3. 直接用搜索引擎查竞品 B 定价 → 成功
4. 直接用搜索引擎查竞品 C 定价 → 成功
5. 整理对比表格
耗时:约 3 分钟,没有弯路

注:这就是「程序性记忆」的威力------Hermes 记住的不是「竞品 A 的价格是多少」(这是事实记忆),而是「查竞品定价应该先用搜索引擎而不是直接访问官网」(这是方法记忆)。

3.3 渐进式加载:解决「Skill 越多越慢」的问题

这是笔者最感兴趣的部分,因为它直接解决了笔者在企微机器人上遇到的痛点。

Hermes 的 Skill 加载分三级:

css 复制代码
Level 0: skills_list()
  → 只返回所有 Skill 的名称和描述(约 3k token)
  → AI 看一眼就知道有哪些 Skill 可用

Level 1: skill_view(name)
  → 按需加载某个 Skill 的完整内容
  → 只有 AI 判断「这个任务需要用到这个 Skill」时才加载

Level 2: skill_view(name, path)
  → 只加载 Skill 中的某个特定参考文件
  → 更精细的按需加载

对比一下两种加载方式的 token 消耗:

场景 企微机器人(全量加载) Hermes(渐进式加载)
20 个 Skill,每个约 500 token 每次对话消耗 10,000 token Level 0 只消耗 ~3,000 token
实际只用到 1 个 Skill 另外 19 个的 9,500 token 浪费了 只额外加载 1 个的 ~500 token
总消耗 ~10,000 token ~3,500 token
节省比例 - 节省约 65%

而且 Hermes 的文档里提到,它的内存架构是「缓存感知」的------系统 prompt 在会话初始化时会被冻结成快照,后续的高频模型调用可以复用缓存的上下文窗口,进一步减少 token 开销。

注:看到这个设计的时候,笔者第一反应是「这不就是编程里的懒加载吗」。确实,思路是一样的------不用的东西不加载,用到了再加载。简单但有效。如果笔者的企微机器人也能实现类似的机制,20 个 Skill 的场景应该就不会那么卡了。

3.4 四层记忆系统

Hermes 的记忆不只是 Skill,它有一套完整的四层记忆架构:

层级 存储方式 存什么 类比
持久存储 Markdown 文件(MEMORY.md 长期事实和偏好 笔记本
结构化存储 SQLite + FTS5 全文搜索 会话历史、跨会话检索 数据库
程序性记忆 Skill 文件 可复用的工作流程 肌肉记忆
用户建模 USER.md(Honcho 辩证建模) 对你的理解和偏好 了解你的老同事

其中「用户建模」是一个很有意思的设计------Hermes 会随着使用逐渐建立对你的理解模型,比如你喜欢什么样的输出格式、你的技术栈是什么、你通常在什么时间段工作。这些信息会影响 Hermes 的回答方式和工作节奏。

而笔者的企微机器人目前只有「程序性记忆」这一层(Skill 文件),没有跨会话记忆,也没有用户建模。每次对话都是从零开始,不会记住上次的分析结论或者你的偏好。

4. 正面对比

4.1 核心能力对比

对比维度 企微 Skill 机器人 Hermes Agent
Skill 创建 纯人工编写 人工编写 + AI 自动生成
Skill 进化 不会,写什么就是什么 会,GAPA 每 15 次调用自动优化
加载方式 全量加载,Skill 越多越慢 三级渐进式加载,按需加载
跨会话记忆 有,SQLite + FTS5 持久化
用户建模 有,Honcho 辩证建模
运行平台 企微 CLI / Telegram / Discord / Slack 等 15+ 平台
Skill 标准 自定义格式 兼容 agentskills.io 开放标准
部署成本 依赖企微生态 独立部署,$5 VPS 即可
上手难度 低,写 Markdown 就行 中等,需要配置 Provider 和环境

4.2 同一个场景下的表现差异

拿笔者最常用的「线上问题排查」场景来对比:

企微 Skill 机器人的方式:

复制代码
第 1 次排查:按 Skill 流程执行,输出分析报告 → 3 分钟
第 2 次排查(类似问题):按同一个 Skill 流程执行 → 还是 3 分钟
第 10 次排查(类似问题):按同一个 Skill 流程执行 → 还是 3 分钟

Skill 不会变,效率不会提升,除非人工去改 Skill

如果用 Hermes 的方式:

复制代码
第 1 次排查:没有 Skill,从零推理,可能走弯路 → 5 分钟
  → GAPA 自动生成 Skill:「排查 404 task not found 的标准流程」

第 2 次排查(类似问题):加载 Skill,跳过弯路 → 2 分钟
  → GAPA 发现「先查任务状态表比先查 OTEL 更高效」,更新 Skill

第 10 次排查(类似问题):Skill 已经被优化了好几轮 → 1 分钟
  → 流程已经非常精炼,直奔结论

注:当然,这个对比有点理想化。Hermes 的自学习效果取决于底层模型的能力和任务的复杂度,不是所有场景都能达到这种效果。但「越用越快」的趋势是确定的。

4.3 各自的优势场景

企微 Skill 机器人更适合:

  • 团队内部使用,需要跟企微生态深度集成
  • Skill 内容相对固定,不需要频繁更新
  • 对可控性要求高,不希望 AI 自己改 Skill
  • 快速上手,写个 Markdown 就能用

Hermes Agent 更适合:

  • 个人或小团队的长期使用,需要 AI 越用越聪明
  • 任务类型多变,需要 AI 自己积累经验
  • 跨平台使用(不只是企微,还有 Telegram、CLI 等)
  • 对 token 消耗敏感,需要精细的加载控制

5. 从 Hermes 身上能学到什么

虽然笔者暂时不打算把企微机器人迁移到 Hermes,但 Hermes 的一些设计思路是可以借鉴的:

5.1 渐进式加载

这是最值得借鉴的。笔者打算给企微机器人加一层「Skill 索引」------先让 AI 看一份精简的 Skill 列表(只有名称和描述),判断需要用哪个 Skill 后,再加载完整内容。这样 20 个 Skill 的场景应该能从 10s+ 降到 3-4s。

5.2 执行后复盘

Hermes 的 GAPA 机制本质上是「执行后复盘」。虽然让 AI 自动改 Skill 在企微场景下风险太高(万一改错了,影响整个团队),但可以折中一下------让 AI 在每次执行后输出一份「优化建议」,由人工审核后决定是否更新 Skill。

5.3 分层记忆

目前企微机器人没有跨会话记忆,每次都是从零开始。可以考虑加一层简单的记忆------比如记住「这个 taskid 上次已经分析过了,结论是 xxx」,避免重复分析。

6. 碎碎念

啦啦啦,终于把自研的企微机器人和 Hermes 的 Skill 系统做了一次深度对比。写完之后最大的感受是:自己做的东西虽然能用,但跟 Hermes 这种经过深度设计的系统比起来,确实还有不少可以优化的空间。

不过话说回来,适合的才是最好的。企微机器人胜在简单直接、跟团队工作流深度绑定;Hermes 胜在自学习能力和精细的资源管理。两者解决的问题不完全一样,没必要非此即彼。

最让笔者心动的还是 Hermes 的渐进式加载机制,准备找个周末把这个思路移植到企微机器人上,解决 Skill 多了之后变慢的问题。

  • 你永远不需要为做自己而道歉。

  • 人一生最重要的就是抵挡别人入侵自己的人生。

7. 参考资料

相关推荐
IT_陈寒3 小时前
SpringBoot自动配置把我都整不会了
前端·人工智能·后端
覆东流3 小时前
第1天:Python环境搭建 & 第一个程序
开发语言·后端·python
码事漫谈4 小时前
Token成本失控?两大开源方案如何重构AI编程成本结构
后端
橙露4 小时前
SpringBoot 全局异常处理:优雅封装统一返回格式
java·spring boot·后端
LiveWillChange4 小时前
第一阶段:基本功能实现
后端
朝阳5814 小时前
rust 交叉编译指南
开发语言·后端·rust
用户8356290780514 小时前
使用 Python 合并与拆分 Excel 单元格的实用方法
后端·python
thinkingandcoding4 小时前
BTrace实战:Arthas搞不定的那些场景
后端
王码码20355 小时前
Go语言中的配置管理:从Viper到环境变量
后端·golang·go·接口