开源一些我自己会用的一些 Hermes 小工具

最近我把一个小仓库开源了，叫 橘猫的 Hermes 工具箱。

它不是一个很大的项目，也不是一个完整的框架。里面暂时只有一些我在使用 Hermes Agent 的过程中，真的会用到的小工具、Skill 和 Playbook。

仓库地址在这里：

https://github.com/jerryisacat/jumao-hermes-tools

我想写一篇文章介绍它，但不是为了说"我做了一个多厉害的工具箱"。恰恰相反，这个仓库最重要的地方可能就在于：它很小，很个人化，而且很多东西都是从实际使用里长出来的。

现在互联网上不缺 AI 用例。

每天都能看到很多演示：让 AI 做一个 App，让 AI 自动生成网页，让 AI 搭一个 Agent，让 AI 完成一个看起来很复杂的任务。它们当然有趣，也确实能让人看到 AI 的能力边界在往哪里推。

但看多了以后，我会有一点别的感受：很多 AI 用例是为了分享而分享。

场景是为了展示设计出来的，结果是为了截图或视频好看，流程跑完一次之后，大概率就不会再被第二次使用。它像一个很漂亮的烟花，能证明"AI 可以做到这件事"，但很难说明"AI 会怎样进入一个人的日常工作流"。

我不是说这种分享没有价值。只是对我来说，AI 真正有意思的地方，不在于一次性的演示，而在于它能不能被长期地养起来。

尤其是 Hermes。

我一直觉得 Hermes 不是那种装好以后就结束的工具。它更像一个需要慢慢相处、慢慢调教、慢慢养成的个人 Agent 系统。

每个人对 AI 的需求都不一样。

有人希望它帮忙写代码，有人希望它整理邮件，有人希望它管理知识库，有人希望它查航班、做简报、处理图片、写博客。哪怕都是"用 AI 提高效率"，落到每个人身上，真正需要的东西也完全不一样。

所以 Hermes 最有意思的地方，不是它一开始有多强，而是它可以被你慢慢养成你自己的样子。

你让它记住你的工作习惯，给它补工具，给它写 Skill，把一次次临时解决的问题变成下次可以复用的能力。时间久了，它就不再只是一个聊天窗口，而更像一个贴着你生活方式生长出来的操作系统。

这个仓库就是在这样的过程中出现的。

我在使用 Hermes 的时候，经常会遇到一些很小但具体的问题。

比如，我想让 Hermes 查询我的 Steam 游戏状态；我想让它用 aria2 更可靠地下载大文件；我想把某段反复使用的 Prompt 保存下来；我想在一个新仓库里初始化 Agent 协作规范，但又不希望 Agent 一上来就直接乱写文件。

这些事情都不大。

小到它们很难被包装成一个正式产品，也不值得单独开一个大型项目。但它们又确实会反复出现。如果只留在某一次对话里，很快就会消失。下次再遇到类似场景，还要重新解释、重新拼命令、重新让 Agent 摸索一遍。

于是我就想，不如把它们收起来。

这个仓库不是一个宏大的 AI 框架。它更像是我在使用 Hermes 时随手整理出来的一个工具抽屉：有些是脚本，有些是 Skill，有些只是 Prompt 或 Checklist。它们共同的标准只有一个：我自己真的会用。

目前仓库里主要有三类东西。

第一类是 tools/。

这里放真正可以运行的小工具。比如现在已经有的 steam-activity，可以读取 Steam 游戏库、最近游玩和当前正在玩的游戏；还有 aria2-download，用来通过 aria2 做大文件下载、批量下载、断点续传和 SHA-256 校验。

这些工具并不复杂，也没有试图做成"大而全"的通用系统。它们解决的都是很具体的问题：让 Hermes 在执行某个任务时，少一点临时拼命令，多一点可验证、可复用的路径。

第二类是 skills/。

如果说工具解决的是"能不能做"，那 Skill 解决的就是"下次 AI 能不能正确地做"。

一个工具放在那里，并不代表 Agent 就真的知道什么时候该用、怎么用、失败了怎么办、哪些边界不能碰。所以每个适合被 Agent 调用的工具旁边，我会配一个对应的 Skill。

Skill 里面会写清楚使用场景、命令、环境变量、失败处理、安全注意事项和验证方式。这样下次 Hermes 需要处理类似任务时，它不是从零开始猜，而是能按照已有说明去执行。

我越来越觉得，这可能是个人 Agent 工作流里很重要的一层。

因为 AI 不是只需要"工具"，它还需要"使用工具的上下文"。很多时候，一个小工具本身并不难写，真正决定它能不能长期进入工作流的，是 Agent 下次能不能稳定、正确、可验证地用起来。

第三类是 playbooks/。

这是我最近刚加进去的一类内容。它不是给 Hermes 自动加载的 Skill，而是给人阅读和复用的使用手册，里面可以放 Prompt、Workflow 或 Checklist。

比如现在有一个 initialize-agents-md.md，它的用途是在一个仓库还没有稳定 Agent 协作规范的时候，先让 Agent 调研项目现状，输出 AGENTS.md、AGENTS_CHANGELOGS.md 和 CODEGUIDE.md 的初始化讨论稿。

重点是：它会明确要求 Agent 先不要写文件。

这其实是我在真实使用里踩出来的经验。有些任务如果一上来就让 AI 动手，它很容易按照模板直接生成一堆东西。但更好的方式是先让它阅读项目，理解现有结构，整理方案，等人确认后再写入。

这种东西不一定需要写成程序。很多时候，一段足够清楚的 Prompt，本身就是一个很有用的工作流。

所以我把这类内容放进了 playbooks/。它面向的是人，而不是 Agent 自动执行系统。你可以复制、修改、迁移到自己的项目里，也可以把它当成一种使用 Hermes 的思路参考。

这也是我开源这个仓库的主要原因。

我不觉得这里面的每个工具都适合别人直接拿去用。事实上，它们很多都很个人化，甚至带着我自己的使用习惯。比如 Steam 活动查询这种东西，本来就不是每个人都会需要；某些 Prompt 也和我自己的开发流程、仓库治理习惯有关。

但我觉得它们仍然值得开源。

因为我真正想分享的不是这些脚本本身，而是背后的 ideas。

你看到这个仓库以后，可能不会直接复制我的工具，但也许会想到：原来可以给 Hermes 写一个查询自己 Steam 状态的小工具；原来下载任务可以封装成一个可校验的 wrapper；原来 Prompt 也可以像 Playbook 一样管理；原来每个工具旁边可以配一个 Agent Skill；原来个人 Agent 不是靠一次性的 Prompt，而是靠长期积累出来的。

这对我来说比"这个工具有多少功能"更重要。

我越来越相信，每个人都应该有一点自己的 AI 基础设施。它不一定要复杂，也不一定要开源，更不一定要做成产品。它可以只是一些脚本、一些约定、一些 Prompt、一些你自己经常用的小技巧。

但这些东西积累起来，就会变成你和 AI 之间的共同语言。

你不用每次都从头解释自己想怎么做。
你不用每次都让 Agent 重新猜你的偏好。
你不用把一个已经验证过的流程，一遍又一遍地临时重建。

这就是"养" Hermes 的意义。

不是把它当成一个随时可替换的聊天机器人，而是把它当成一个会随着你一起生长的工作伙伴。你给它工具，它就多一种能力；你给它 Skill，它就多一点判断；你给它 Playbook，它就多一段可以复用的方法。

当然，这个仓库现在还很早期。

它不会突然变成一个庞大的平台，也不会追求覆盖所有场景。我更希望它保持轻量，保持个人工具箱的状态。只有当某个东西是我真的用过、真的验证过、真的可能下次还会用的时候，它才适合被放进来。

这也是我喜欢的开源方式。

不是为了流量，不是为了包装一个产品，也不是为了证明自己做了什么很大的事情。只是因为某个东西对我有用，而它也许能给别人一点启发，所以就把它放出来。

早期互联网最打动我的地方，就是这种很朴素的分享：有人把自己写的小工具、小脚本、小经验放到网上。它不一定完整，不一定宏大，但真实、有用，而且带着一点个人气味。

我希望这个仓库也是这样。

如果你也在用 Hermes，我觉得最好的打开方式，不是手动复制某个脚本，也不是一页页读完所有 README。

你可以直接把这个仓库丢给你的 Hermes，让它自己读，让它自己学，然后问它：

这个仓库里有什么我可以借鉴的？
哪些工具适合迁移到我的 Hermes？
能不能参考这个结构，帮我整理自己的工具箱？
能不能把某个 Playbook 改写成适合我项目的版本？

这可能才是它最适合的使用方式。

因为真正值得开源的，也许不是这些小工具本身，而是背后那种思路：

AI 不是一次性的演示对象，而是可以被你慢慢养起来的工作伙伴。