为什么我现在不安装 Hermes Agent

344 阅读10分钟

大家好,我是双越。wangEditor 作者,前百度 滴滴 资深前端工程师,慕课网金牌讲师,PMP,前端面试派 作者。

我正致力于两个项目的开发和升级,感兴趣的可以私信我,加入项目小组。

  • 【划水AI】 Node 全栈 AIGC 知识库,包括 AI 写作、多人协同编辑。复杂业务,真实上线。
  • 【智语】 AI Agent 智能体项目。一个智能面试官,可以优化简历、模拟面试、解答题目等。

最近 Hermes Agent 在社区里火起来了。作为一个使用 OpenClaw 的用户,我花了一些时间认真研究了它的文档,和现有工具做了对比,最终决定:暂时不切换,继续观察

这篇文章记录我的思考过程,希望对同样在评估 Hermes Agent 的朋友有所参考。


Hermes Agent 核心功能介绍

Hermes Agent 是由 Nous Research(就是训练了 Hermes、Nomos、Psyche 系列模型的那个 AI 实验室)开源的自主 Agent 框架,MIT 协议,定位是"自我进化的 AI Agent"。

它的核心能力可以概括为以下几个方面:

闭合学习闭环(Closed Learning Loop) 这是 Hermes 最核心的设计理念。Agent 能从使用经历中自动创建技能文档、主动持久化知识、并随时间构建对用户越来越深入的模型。

持久记忆系统 维护两个关键文件:MEMORY.md(约 2200 字符)记录环境事实、项目约定、已完成工作;USER.md(约 1375 字符)记录用户偏好、沟通风格、技能水平。每个 session 开始时注入 system prompt。同时所有会话存储在 SQLite(FTS5 全文检索),支持跨 session 召回几周前的对话内容。

运行环境灵活 支持 6 种终端后端:本地、Docker、SSH、Daytona、Singularity、Modal。其中 Daytona 和 Modal 提供无服务器持久化,环境空闲时休眠,成本几乎为零。你可以把 Hermes 部署在一台 $5/月的 VPS 上,用 Telegram 远程指挥它在云端工作,完全不依赖本地笔记本。

多平台消息网关 支持 15+ 平台:Telegram、Discord、Slack、WhatsApp、Signal、Matrix、Mattermost、Email、SMS、DingTalk、Feishu、WeCom、BlueBubbles、Home Assistant 等,一个 gateway 统一管理。

Skills 生态系统 遵循 agentskills.io 开放标准,接入多个 Hub 来源:官方 Optional Skills、skills.sh(Vercel 技能目录)、GitHub 直接安装、ClawHub、LobeHub 等。技能采用渐进式披露加载,先拉摘要列表,需要时再加载全文,节省 token 消耗。

其他能力 47 个内置工具、19 个 toolset、MCP 支持、语音模式、浏览器自动化、图像生成、定时任务(Cron)、子 Agent 并行委托、IDE 集成(VS Code、Zed、JetBrains)、RL 训练轨迹导出……功能相当完整。


Hermes Agent 对比 OpenClaw

在我认真核查两份文档之前,我一度以为 OpenClaw 没有记忆功能,但实际上并非如此。两者在核心能力上的对比远比表面看起来更接近。

记忆系统 OpenClaw 同样有完整的记忆系统:MEMORY.md 长期记忆、每日笔记文件(memory/YYYY-MM-DD.md)、混合语义搜索(向量 + 关键词)、自动 memory flush(在上下文压缩前触发),以及实验性的 Dreaming 功能(后台整合短期记忆晋升为长期记忆)。两者都支持 Honcho 用户建模,都有外部记忆 Provider 可选。

消息平台 两者都覆盖主流平台,Hermes 略多(15+),OpenClaw 也有 10+ 个,并且有插件机制可扩展。

技术栈 OpenClaw 是 Node.js,Hermes 是 Python。

定位侧重 OpenClaw 更侧重"多 channel 消息网关",把各个 IM 接入 AI 是它的核心场景;Hermes 更侧重"自主 Agent 能力",消息网关是它的功能之一,而非核心。

最大的区别 经过仔细对比,两者真正不同的地方只有一个:技能自动创建。这也是下一节要重点讨论的。


Hermes Agent 最重要的特点:技能自动创建

功能介绍

Hermes 的 Skills 系统有两个层面:一是从社区 Hub 安装现成技能,二是 Agent 在使用过程中自动创建新技能

自动触发的条件包括:完成一个复杂任务(5+ 次工具调用)、遭遇错误并找到解决路径、被用户纠正了某个做法、或发现了一个非显而易见的工作流程。触发后,Agent 会通过 skill_manage 工具把这个"走通了的路"结构化为一个 Skill 文档,保存在 ~/.hermes/skills/ 下,供未来复用。

这本质上是把用户的使用经历转化为 Agent 能力的增量。普通 Agent 每次面对复杂任务都是从零开始推理,而 Hermes 积累的 Skill 库会让它下次遇到同类问题时直接加载经过验证的流程,而不是重新摸索。

优点

能力随时间增长。 使用越久,积累的 Skill 越多,Agent 处理特定领域任务的效率越高。这是一个正向飞轮。

知识可复用、可分享。 Skills 遵循开放标准,可以导出、分享给社区,也可以从 agentskills.io 等 Hub 安装他人沉淀的经验。

降低重复推理成本。 对于频繁出现的复杂操作,Skill 文档相当于给 Agent 装了一本操作手册,减少了无效的试错轮次。

缺点与潜在问题

数量膨胀。 长期重度使用后,自动创建的 Skill 可能积累到数百甚至更多。更麻烦的是,同类任务可能被反复创建成相似的 Skill,出现大量冗余,日后难以维护。

质量稀释。 自动创建的 Skill 未必都是高质量的——它可能记录了一个"当时恰好走通但并不通用"的路径,反而在未来误导 Agent。

系统提示膨胀。 Skills 通过系统提示注入,即便采用了渐进式披露(先只注入摘要列表),随着 Skill 数量增长,系统提示依然会越来越臃肿,影响 context 利用效率和推理质量。

用户感知不足。 创建过程在用户不知情的情况下自动发生,缺乏明确的审查机制,用户难以掌握 Skill 库的真实状态。

目前文档中提到的缓解措施主要是渐进式三级加载,并没有提到 LRU 淘汰或自动清理机制,这意味着 Skill 膨胀问题是真实存在的、尚未被完整解决的。


Agent 核心模块趋于稳定

评估一个新 Agent 工具时,有一个背景值得注意:主流 Agent 框架在核心模块层面已经高度趋同

如果你横向对比 Hermes、OpenClaw、Claude Code、Cursor、Aider 等工具,会发现它们几乎都覆盖了相同的核心能力矩阵:

  • LLM 接入:多 provider 支持,OpenAI 兼容接口,本地模型支持
  • Skills / 知识文档:SKILL.md、CLAUDE.md、AGENTS.md 等各种形式的上下文文件
  • Tools:文件读写、终端执行、Web 搜索、浏览器自动化
  • MCP:Model Context Protocol 已成事实标准,几乎所有主流 Agent 都支持
  • Memory:跨 session 持久记忆,语义搜索
  • Context Files:项目上下文注入,SOUL.md 人格定义
  • Cron:定时任务调度
  • Security:命令审批、沙箱隔离、allowlist
  • Config:灵活的配置文件系统
  • Channels:多平台消息网关

这个核心模块列表在过去一两年里已经基本稳定下来,成为"现代 Agent 框架"的标配。各家工具之间的差异,越来越体现在执行质量、稳定性、生态成熟度,以及少数几个差异化特性上,而不是模块的有无。

这也意味着,当你看到一个新 Agent 宣称拥有某项"独特能力"时,第一个问题应该是:这真的是结构性的差异,还是只是别人还没做但很快就会做的特性?


我不会立刻安装使用的原因

综合以上分析,我决定继续使用 OpenClaw,暂不切换 Hermes。原因有四:

1. 稳定性和安全性有待验证

Hermes 是一个相对较新的项目。作为由 Nous Research 团队构建的工具,工程背景值得信赖,但这不等于生产级稳定。任何新工具都需要经历大量真实用户的压力测试,才能暴露出边缘场景下的 bug、安全漏洞、或设计缺陷。

Agent 框架尤其如此——它运行在你的机器上、访问你的文件、执行终端命令,稳定性和安全性的门槛比普通工具更高。我倾向于等它在社区里跑过足够多的用户和时间之后再做评估。

2. 和现有 Agent 没有本质区别,差异点可以手动弥补

如前所述,Hermes 相对 OpenClaw 最大的差异是"技能自动创建"。但这个功能我可以用人工方式临时替代:当我完成一个复杂任务后,手动把工作流程整理成一个 Skill 文档,保存到 OpenClaw 的工作区。

这当然不如自动化便捷,但对于当前阶段来说足够用。我不需要为了一个可以人工弥补的功能,就冒着切换成本和稳定性风险迁移到一个新工具。

3. 技能自动创建本身存在尚未解决的问题

如前文所分析,Skill 膨胀、质量稀释、系统提示臃肿,这些都是自动创建机制带来的副作用。目前文档中并没有提到有效的自动清理或淘汰机制。

一个设计上有明显未解决问题的功能,在它被完善之前,我并不急于使用。

4. 其他 Agent 补齐这一差距的成本很低

这是最关键的一点。"技能自动创建"听起来是个独特功能,但从技术实现角度看,门槛并不高:检测复杂任务完成 → 触发一个结构化写文件的 prompt → 保存到磁盘。任何已经有文件读写工具的 Agent,今天就能实现这个逻辑。

社区 Skills 生态(agentskills.io)也是开放标准,不是 Hermes 私有的,其他 Agent 接入同样的生态完全没有障碍。

事实上,Claude Code 已经有 CLAUDE.md 机制,可以把项目约定和常用命令持久化复用,距离完整的 Skill 自动创建只差"自动触发创建"和"跨项目技能库"这两步。OpenClaw 同理。

这意味着 Hermes 在这个功能上的先发优势窗口期不会很长。我没有理由为了一个竞品很快会跟进的特性,现在就承担切换成本。


总结

Hermes Agent 是一个认真做的项目,来自有真实技术积累的团队,功能完整,方向正确。"技能自动创建"这个设计理念本身是值得肯定的——让 Agent 随使用积累能力,而不是每次都从零开始,这是 Agent 工具进化的正确方向。

但是,一个工具值得关注和一个工具值得立刻切换,是两件不同的事。

对我来说,当前的结论是:继续使用 OpenClaw,定期观察 Hermes 的社区反馈和版本迭代。等它的稳定性经过充分验证,技能膨胀等设计问题有了更完善的解法,或者它出现了真正让我无法在现有工具里替代的功能,再做切换决定。

Nous Research 的工程迭代速度应该不慢。如果你也在观望,建议关注他们的 GitHub releases 和 Discord 社区,大概半年内就能看出它是否到了值得切换的成熟度。