Hermes Skill 太多记不住？我做了一个活跃度统计插件

这个月我一直在折腾 Hermes ，skill 也越装越多，都一百多个了……

写作的、抓网页的、同步微信的、飞书的、GitHub 的，刚装上去时都觉得有用。可一旦堆到几十个，真正让人头疼的问题马上就冒出来了：你手里明明有一堆 skill，却不知道不上来谁在高频干活，谁只是安静躺在目录里。

skill 多，只能说明你装过很多东西。skill 的真实使用情况，才决定这套能力值不值得继续维护、继续投入、继续往上迭代。

所以我后来越来越确定，Agent 走到后面，早晚都得补上一块技能使用面板。你得先把谁常用、谁变热、谁长期吃灰摊开看，后面的治理动作才有理有据。

于是，我就开发了一个 hermes 的插件（划掉，不是我开发，是 hermes 自己开发的，我只是口述）

可以查看当前 hermes 安装的 skill 的使用情况，比如最多使用、最少使用、最近使用等等

看不见使用情况，skill 体系很容易越长越虚

很多人玩 Agent，前期最容易获得的成就感，就是 skill 数量一直在涨。

需求来了补一个，踩坑了再封一个，流程跑顺了又沉淀一个。

最后你会继续维护一些几乎没人碰的 skill。

你还会产生一种错觉：系统里 skill 很多，能力应该已经很完整了。可真跑起来，调用可能长期只集中在少数几个入口，并且这些 skill 还会浪费上下文，降低 ai 真正的运行效率。

这就是为什么我现在看 Agent，第一眼已经不会先盯 skill 总数。我更想先看活跃度、最近变化和长期 unused 列表。

我真正想看的，其实就 4 件事

到了这个阶段，我关心的已经很具体了：

1. 哪些 skill 最常用。
2. 哪些 skill 最近用的多。
3. 哪些 skill 还在被持续编辑，说明它还处在活跃迭代里。
4. 哪些 skill 明明安装着，却在最近一段时间里完全没有调用记录。

只要把这 4 件事看清楚，后面的动作就自然会冒出来。

哪些值得继续打磨，能判断。哪些该改名字、改触发方式、改说明，也能判断。哪些已经沉底，该合并还是清理，同样能判断。

所以我给 Hermes Web 单独做了一个 Skills 面板

hermes-web 本身是 Hermes Dashboard 里的一个工作台，里面也有 Usage、Requests、GroupChat 这些入口。但这次我最想补上的，还是 Skills，因为这块信息以前太黑箱了。

我希望这个面板回答的是一个更关键的问题：你这套 skill 现在到底活成什么样。

要知道一旦可视化，skill 才会进入真正的治理循环。

我后来越来越觉得，这块能力的价值远不止“多了一个统计页”。

它真正改变的是，skill 终于从堆库存，进入了可治理、可判断、可迭代的循环。

以前你做一个新 skill，更多是在补一个能力口子。补完以后，它有没有减少重复劳动，有没有变成高频入口，有没有因为名字太模糊被人绕开，往往很难追。

现在就清楚多了。数据一出来，后面的动作会直接跟上：

1. 高频 skill 继续打磨，因为它已经在真实流量里证明了价值。
2. 偶尔有人碰一下的 skill，要回头检查名字、说明、触发入口是不是写得太别扭。
3. 长期 unused 的 skill，就别再投入同样多的维护精力了，该合并就合并，该清理就清理。
4. 整个 skill 体系如果过散，也会被数据逼着重新收口。

如果你对这个 skill 感兴趣，可以给你的 hermes 说：去搜索一个 repo 仓库 whitedew/hermes-web 即可。

延伸阅读

• 给 AI 注入品味：当编码工具性能趋同，审美成了新战场：Emil Kowalski把十年前端经验打包成Skill文件注入AI编码工具、Kimi K2.7成为GitHub Copilot首个开源权重模型、Senior SWE-Bench评估高级工程师任务——当性能不再是瓶颈的时候，品味就成了新的战场。
• 我们给AI出的考试，可能全错了：两份不相干的报告指向同一件事，AI学会了应付考试，而不是真的具备能力。当分数越来越高、可信度越来越低，验证的价值正在超过信任。
• Grok Build开源，是慷慨还是灭火？：xAI把Grok Build开源了，但五天前它刚被抓到偷偷上传用户全部代码。这是慷慨，还是灭火？AI编程工具的信任危机才刚刚开始。
• FDE：AI行业给自己开的一张病历诊断书：FDE岗位招聘量一年暴涨729%，这不只是一个新岗位的走红，而是AI行业集体承认了一个事实：模型不是答案，落地才是。