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. 参考资料

相关推荐
llz_1126 分钟前
web-第二次课后作业
前端·后端·web
红尘散仙6 小时前
我把终端小说阅读器接上了 AI Agent:TRNovel 现在能用 skill 生成书源了
人工智能·后端·rust
卷毛的技术笔记7 小时前
告别硬编码!Spring AI Alibaba 实现 AI Agent 智能工具调用(Tool Calling)
java·人工智能·后端·python·spring·ai编程
会编程的土豆8 小时前
Go 语言反射(Reflection)详解
开发语言·后端·golang
喵个咪8 小时前
GoWind Toolkit Go后端代码生成 完整全流程实战
后端·go·orm
basketball6168 小时前
Go 语言从入门到进阶:4. 数组和MAP使用方法总结
开发语言·后端·golang
qq_2518364578 小时前
SpringBoot+Vue 共享电池柜管理系统 完整实现 前后端分离项目实战 完整代码
vue.js·spring boot·后端
zhangxingchao9 小时前
AI 大模型核心六:量化、Workflow 与 Agent、多轮 RAG
前端·人工智能·后端
IT_陈寒10 小时前
Vite打包时遇到的坑,原来问题出在这里
前端·人工智能·后端
ayqy贾杰11 小时前
基层管理的三板斧,在AI时代行不通了
前端·后端·团队管理