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. 参考资料
- Hermes Agent 官方文档
- Hermes Agent Developer Guide (Content was rephrased for compliance with licensing restrictions)
- How This Open-Source AI Agent Actually Learns from Its Own Mistakes (Content was rephrased for compliance with licensing restrictions)
- The Practitioner's Reference (Content was rephrased for compliance with licensing restrictions)
- agentskills.io - 开放 Skill 标准