为什么我现在不安装 Hermes Agent

大家好,我是双越。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.mdCLAUDE.mdAGENTS.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 社区,大概半年内就能看出它是否到了值得切换的成熟度。

相关推荐
花千树-0102 小时前
MCP HTTP 传输详解:比 SSE 简单,但有一个意外的坑
java·agent·sse·function call·ai agent·mcp·harness
花千树-0102 小时前
三个 Agent 并行调研:用 concurrent 节点构建并发-汇聚式旅游规划助手
java·langchain·agent·function call·multi agent·mcp·harness
是小蟹呀^2 小时前
【整理】Agent中的ReAct架构
langchain·agent·react
小锋学长生活大爆炸5 小时前
【教程】在Docker中部署Hermes Agent
docker·容器·agent·教程·工具·openclaw·hermes
怕浪猫14 小时前
程序员越想转型AI,越不要只盯着技术
程序员
swipe14 小时前
用 Nest + LangChain 打造 OpenClaw 式 Agent 定时任务系统
人工智能·llm·agent
阿里云大数据AI技术16 小时前
让 AI 帮你写大数据AI开发代码:MaxFrame Coding Skill 正式发布
人工智能·agent
HOHO18 小时前
说起来你可能不信,我写了个跑在浏览器里的 ai agent 框架
aigc·agent
深念Y19 小时前
AI 写代码总跑偏?我逼它回到“函数级颗粒度”
ai·软件工程·agent·函数·coding·vibe coding·代码补全