Hermes Agent vs OpenClaw —— 一次架构重构的全景对比

一句话抓住重点

Hermes Agent 是 OpenClaw 的官方继任者（同出 Nous Research 体系），但不是升级版，而是一次架构重构。核心分野很清晰：OpenClaw 赢在生态宽度（25+ 消息通道、90+ 插件、接微信钉钉），Hermes 赢在能力深度与工程质量（闭环学习、6 种终端后端、5 万行 Python + 3000+ 测试）。"个人助手"场景 Hermes 全面更优，但要接国内 IM 平台，目前还得靠 OpenClaw。

01 · 定位

它们是什么关系？继任，不是平替

理解两者差异的前提，是先搞清它们的"血缘"。

OpenClaw

先行者 · TypeScript · ~10 万行 · 30 万+ GitHub Star

更早爆火的开源个人 AI Agent，曾靠"养虾"等玩法刷屏
核心卖点：极宽的接入生态——25+ 消息通道、90+ 插件
记忆靠 SOUL.md 等文件，人工归纳维护
后期迭代节奏放缓，从"热点"逐渐沉淀为"工具"

Hermes Agent

继任者 · Python · ~5 万行 · v0.8.0 (2026.4)

Nous Research 出品，定位"自我改进的 AI 助手"
核心理念：闭环学习——每次用完都比之前更好
Skills 由 Agent 自主积累 + 自我改进，非人工维护
提供 hermes claw migrate 一键从 OpenClaw 全量迁移

💡 我的看法

"重构而非升级"这句话是关键。两者代码语言、记忆范式、核心循环全变了，能共享的只有"个人 Agent"这个产品理念。所以别把 Hermes 当成 OpenClaw v2——它更像是同一拨人换了套地基重盖的房子，地段（理念）没变，但承重墙（架构）全是新的。

02 · 核心理念

最大的分水岭：Agent 该不该"每次从零开始"？

几乎所有 Agent 框架（LangChain、AutoGen…）的循环都是：输入 → 推理 → 工具调用 → 结束。对话一结束，能力清零。Hermes 把这定义为架构缺陷，而不是模型能力问题。

完成复杂任务→ 自动提炼经验→ 生成 skill.md→ 下次直接调用→ 用中发现问题
自动更新↺

维度	Hermes · 闭环学习	OpenClaw · 静态记忆
能力沉淀	任务后自动提炼可复用 Skill	无自动沉淀，靠人工写文件
Skill 演化	使用中发现问题 → 自动更新	SOUL.md 等手动维护
共享	发布到 agentskills.io 社区	插件生态，但非经验沉淀
本质	Agent 自主积累	人工归纳

🔥 关键工程细节：为什么 Skill 注入"用户消息"而非系统提示？

Hermes 把 Skill 作为 user message 注入，而不是塞进 system prompt。原因是 Anthropic 的 Prompt Cache 机制——缓存依赖 system prompt 全程不变。一旦中途改 system prompt，缓存失效，长对话（100+ 轮）成本暴涨。这个约束被硬写进项目的 AGENTS.md：禁止对话中途改上下文/工具集/重建系统提示。一个看似细节的决策，背后是真金白银的成本考量。

03 · 工程数字

用数据说话

Hermes v0.8.0 的工程质量，是它区别于"玩具 Agent"的硬指标。

~5万

行 Python 代码

3289

个测试用例

209

个 PR (单版本)

200+

模型热切换

个消息平台

种终端后端

轮最大迭代

70+

内置 Skills

💡 我的看法

"不到一个月一个大版本"的节奏，加上 3000+ 测试，说明这不是个人玩票。但要客观看：Hermes ~5 万行 Python vs OpenClaw ~10 万行 TS，并不代表 Hermes 功能少一半——TS 更冗长，实际逻辑量相当。代码行数从来不是能力的直接度量，测试覆盖率和架构清晰度才是。

04 · 架构

Hermes 的六层架构 & 单向依赖链

整个系统四个入口（CLI / Gateway / ACP 编辑器插件 / batch_runner）最终都汇入同一个 AIAgent 实例。

层级	核心模块	职责
接入层	CLI / Gateway / ACP / batch_runner	11 平台、编辑器插件、批量任务
Agent 核心	run_agent.py → AIAgent	同步对话循环，最大 90 轮，工具调度
工具层	tools/registry.py + 40+ 工具	统一注册中心，import 即注册，无外部依赖
终端后端	Local / Docker / SSH / Modal…	6 种执行环境，Modal 支持 Serverless 冬眠
记忆层	SQLite FTS5 + MEMORY.md + 插件	全文检索历史 + 长期记忆 + 用户画像
模型层	OpenAI 兼容接口	200+ 模型，无锁定，运行时热切换

🔥 为什么单向依赖链很重要？

依赖链是 registry.py（纯根节点，无任何外部依赖）← 各工具文件 ← model_tools ← run_agent ← cli/gateway。这意味着可以单独 import 任何一个工具来测试，不触发级联依赖——3000 个测试能跑通，很大程度靠这套设计。这是把"能跑"和"可维护"区分开的工程功底。

05 · 记忆 & 安全

Hermes 超出 OpenClaw 最多的地方

记忆系统是两者差距最大的模块，三层架构 + 安全隔离设计得相当克制。

三层记忆架构

MemoryManager 是唯一集成点

第一层：内置 Provider（不可移除）—— SQLite FTS5 会话检索 + MEMORY.md/USER.md
第二层：外部插件（最多一个，防冲突）—— Honcho / mem0 / Supermemory
第三层：Context Fencing —— <memory-context> 标签包裹注入

安全体系

相比 OpenClaw 显著提升

上下文文件注入威胁检测（防 Prompt Injection）
MCP 生态安全：OAuth 2.1 PKCE + OSV 漏洞扫描
多 Profile 隔离机制
FTS5 虚表靠 trigger 自动同步，检索延迟极低

💡 我的看法

"外部插件最多只能装一个"是个被低估的好设计——多个记忆系统并存会互相污染、产生冲突。Hermes 强制单一外部 provider，把复杂度挡在门外。很多框架反而以"支持 N 种记忆后端"为卖点，结果用户配出一堆互相打架的状态。克制有时候比堆功能更难。

06 · 终极对比

一张表看清谁强在哪

维度	Hermes Agent	OpenClaw
语言	Python (~5万行)	TypeScript (~10万行)
核心理念	闭环学习 / 自我进化	静态记忆 + 插件
消息平台	11 个	25+ 通道
插件/生态	70+ Skills + agentskills.io	90+ 插件
国内 IM(微信/QQ/企微)	暂不支持	支持 ✓
终端后端	6 种 (含 Serverless 冬眠)	较少
模型	200+ 热切换无锁定	支持但较少
记忆系统	三层 + FTS5 + 安全隔离	SOUL.md 文件
工程质量	3000+ 测试，工程级	偏应用导向
迁移	一键导入 OpenClaw	—
桌面客户端	Hermes Desktop (Mac/Win/Linux)	CLI 为主

07 · 选型建议

到底该用哪个？分场景给结论

你的场景	建议
个人助手 (Terminal/Telegram/Discord)	Hermes —— 可完全替代 OpenClaw，体验更优
要接国内平台 (微信/QQ/企业微信)	OpenClaw —— Hermes 目前不支持，这是它的优势区
工程开发 / 写代码	Hermes 超出 OpenClaw；但极致代码场景仍可能不如 Claude Code 专业
复杂企业工作流	Hermes 适用；超复杂编排可能需要 DeerFlow 等专用方案
看重"越用越聪明"	Hermes —— 闭环学习是它独有的护城河

🔥 联网补充：最新动态 (2026.6)

Nous Research 已推出 Hermes Desktop 公开预览版，支持 macOS / Windows / Linux，把 Hermes 从 CLI 升级为图形界面控制台，并支持一键接入本地大模型——记忆和配置默认存本地，不给云端厂商付一分钱 API 费即可挂机干活。同时业界观察到：OpenClaw 和 Hermes 都在"从热点变成工具"，GitHub Star 曲线不再是焦点，落地实用性成了新主线。

⚠️ 一个诚实的提醒

Hermes 的核心对话循环是全同步的——这是有意的设计（好调试、好追踪状态），但在高并发的 Gateway 多用户场景下确实是瓶颈，目前靠多线程绕开。如果你的诉求是"扛大量并发用户的服务端 Agent"，这点需要纳入评估。没有银弹。