摘要：Hermes Agent 和 OpenClaw 常被放在一起比，但网上流传的对比表格里有一半数据是错的。本文先把 Star、版本号、CVE 三类事实校准一遍，再按架构、记忆、技能、安全、部署、成本六个维度逐项对比，最后给六个典型场景的选型建议。结论不是"谁全面领先"，而是"它们解决的不是同一个问题"。
这是「Hermes Agent 深度剖析」系列的第 7 篇，也是最后一篇。全系列 7 篇：
01 总览：25 万 Star 的自改进 Agent 到底强在哪
02 三层记忆架构：会话记忆、持久记忆与用户模型怎么分工
03 技能学习闭环：Agent 怎么自己写技能文档
04 多平台网关：一个进程接住 16 个消息平台
05 安全架构：容器沙箱、技能扫描与人在回路
06 从零到生产：四种部署方式与成本账
07 vs OpenClaw：十二个维度的选型对比（本文）
一、先把事实校准：三个流传很广的错误说法
写对比文章最大的风险不是"观点不同"，而是"数据错了还不自知"。我先查了三件事。
1.1 Star 数：Hermes 并没有超过 OpenClaw
截至 2026 年 10 月 26 日（GitHub API 实时数据）：
| 项目 | Star | Fork | 最新版本 | 最近发版 |
|---|---|---|---|---|
| Hermes Agent | ~25.7 万 | ~5.6 万 | v0.22.5 | 2026-10-23 |
| OpenClaw | ~39.3 万 | ~8.3 万 | v2026.10.7 | 2026-10-24 |
网上不少对比文写着"OpenClaw 增长停滞、Hermes 反超"，这不成立。OpenClaw 规模依然更大，发版比 Hermes 还晚一天，两边都在高频迭代。
那"迁移潮"是真的吗？是真的——2026 年初 CVE 事件后确实有一批开发者和团队换了过去。但迁移潮不等于体量反超。Star 数在这里几乎不能作为选型依据：一个用户量更大的项目不代表它更适合你，只代表它被更多人看见过。
1.2 CVE：不是"0 比 1"，而是结构性差异
很多表格把两者简化成"Hermes 零 CVE、OpenClaw 一个漏洞"。实际情况是 2026 年 OpenClaw 连续披露了多个：
| 编号 | 评分 | 问题 |
|---|---|---|
| CVE-2026-25253 | 8.8 | 控制端信任 URL 里的 gatewayUrl，跨站 WebSocket 劫持窃取令牌 → 一键 RCE |
| CVE-2026-25157 | 8.1 | API 端点参数未过滤，可注入命令 |
| CVE-2026-32922 | 9.9 | 低权限令牌可提权到管理员 |
| CVE-2026-28363 | — | 白名单校验的语义盲区，授权绕过 |
| CVE-2026-44113 | 7.7 | 文件系统桥接 TOCTOU 竞态 |
Hermes 核心仓库截至目前没有公开 CVE 记录。但请注意措辞："暂无公开记录"和"没有漏洞"是两件事。前者是事实，后者是营销。第 5 篇详细拆过它的五层防护，也点明了它的一部分优势来自"后发"。
另外纠正一个流传很广的错误：CVE-2026-25253 不是"Prompt 注入导致命令执行"，修复版本是 2026.1.29（不是某些文章写的 v2.3.1），修复方式是给跨源连接加确认提示。
1.3 技能系统：OpenClaw 不是"没有技能"
"OpenClaw 社区技能数为 0"的说法也过时了。它有一个插件/技能市场（ClawHub），2026 年 2 月的 ClawHavoc 事件里被植入过上千个恶意技能——能被投毒，说明生态是存在的。
真正的差别在另外三点：
| 维度 | OpenClaw（ClawHub） | Hermes（agentskills.io） |
|---|---|---|
| 格式标准 | 自有格式 | 开放标准（Markdown + YAML Frontmatter） |
| 可移植性 | 绑定本框架 | 理论上可跨框架复用 |
| 自动生成 | 无（靠人工编写） | 有（复杂任务完成后自动生成） |
一句话：OpenClaw 有技能市场，Hermes 有技能标准 + 自动生成闭环。 前者是"有人写"，后者是"会自己写"。
二、设计哲学：消息驱动 vs 自进化
| OpenClaw | Hermes Agent | |
|---|---|---|
| 设计原点 | 智能消息路由系统 | 会成长的个人 Agent |
| 核心循环 | 意图识别 → 处理 → 回复 | 检索 → 推理 → 文档化 → 持久化 |
| 循环性质 | 消费型（结束即清零） | 积累型（产出知识资产） |
| 一句话定位 | 极其聪明但会失忆的顾问 | 会记笔记的长期搭档 |
OpenClaw = 一位顶级自由顾问
每次项目全力以赴
项目结束就清零，下次要重新交代背景
Hermes = 一位记笔记的终身搭档
项目结束自动写总结
下次遇到类似问题直接翻笔记
这个差别在单次任务上看不出来，在第一百次任务上会非常明显。
三、架构：一个容器 vs 一套基础设施
| 维度 | OpenClaw | Hermes Agent |
|---|---|---|
| 消息接入 | 消息总线 + 意图路由 | 统一网关 + 管道处理 |
| 会话存储 | Redis | 进程内 Session Memory |
| 持久存储 | MySQL | SQLite |
| 检索 | 向量数据库（Pinecone / Qdrant 等） | SQLite FTS5 全文索引 |
| 技能存储 | 插件目录 / 市场 | 文件系统（SKILL.md） |
| 外部依赖 | 3 个以上（缓存 + 数据库 + 向量库） | 0 |
| 备份 | 分别备份各数据库 | tar 一个 ~/.hermes/ 目录 |
两条链路摆在一起看最直观：
OpenClaw：
平台 → 消息总线 → 意图识别 → Agent 引擎 → 工具
↓ ↓
Redis 会话 MySQL 持久
↓ ↓
向量库检索（独立服务）
Hermes：
平台 → 适配器 → 标准化 → 会话路由 → 记忆检索（FTS5）
→ LLM 推理 → 工具 → 技能文档化 → 回复
（全部在一个进程、一个数据目录内）
我的看法：这不是"先进 vs 落后"，是两种规模假设。OpenClaw 假设你可能要跑多实例、要共享状态、要接企业监控——那 Redis + MySQL + 向量库就是合理投资。Hermes 假设你是一个人或者一个小团队——那零依赖、一个目录备份就是最优解。
第 4 篇讲过这个取舍的另一面：单进程架构在跨平台上下文同步上是天然优势，但在水平扩展上是天然瓶颈。
四、记忆：日记本 vs 教科书
这是两者差距最直观的一维。
| 维度 | OpenClaw | Hermes Agent |
|---|---|---|
| 会话上下文 | Redis 缓存，会话结束清理 | Session Memory + 阈值触发摘要 |
| 跨会话记忆 | MySQL + 向量库存储 | Persistent Memory（FTS5） |
| 用户画像 | 需自行建模 | User Model（自动推断 + 置信度） |
| 检索方式 | 向量语义搜索 | 全文搜索（关键词） |
| 检索延迟 | 通常 50–200ms | 本地约 10ms 量级 |
| 是否提炼知识 | 否（只存原始片段） | 是（摘要 + 技能文档） |
| 外部依赖 | 需要 embedding 模型 | 不需要 |
用一个示意场景感受差别（数字是假设，只用来说明趋势）：连续三天让 Agent 处理同一类 Python asyncio 并发问题。
| OpenClaw | Hermes | |
|---|---|---|
| Day 1 | 从零推理，找到 Semaphore 方案，约 15 轮 |
从零推理，任务复杂 → 自动生成技能文档 |
| Day 2 | 再次从零推理，路径可能不同，约 12 轮 | 检索到技能，直接套用，约 3 轮 |
| Day 3 | 依然从零推理，约 14 轮 | 技能已被补充修正，约 2 轮 |
差异的来源不是模型，是有没有把"这次怎么解决的"存成可复用的东西。
但我也要公平地指出：向量检索在语义层面确实更强。你说"查询很慢"，它能召回"SQL 性能优化"；FTS5 靠关键词，跨同义词的匹配会漏。第 2 篇详细讨论过这个天花板，以及混合检索（全文 + 向量）为什么可能是下一步。
五、技能：从"有人写"到"会自己写"
Hermes 的技能链路是三层：
社区技能市场（安装现成的）
→ 自动生成（复杂任务完成后自己写）
→ 共享分发（导出 / 发布 / 装别人的）
关键是第二层。触发条件是任务复杂度——工具调用达到 5 次以上，就把这次的成功路径写成一份结构化文档：
---
name: postgres-query-optimization
description: Patterns for optimizing slow PostgreSQL queries
version: 1.0.0
category: database
tags: [postgresql, sql, performance]
auto_generated: true
created_at: 2026-05-07T14:30:00Z
---
## Quick Summary
先用 EXPLAIN ANALYZE 定位瓶颈，再决定加索引还是改查询。
## Common Patterns
（按需展开）
## Edge Cases
（遇到边界情况时加载）
## When NOT to Use
（避免误用）
Quick Summary 先加载，详细内容按需展开——这就是第 3 篇讲的渐进式披露，能省 26%–60% 的 token。
我的判断：技能自动生成是 Hermes 最深的护城河，但它同时是最大的风险源。自动生成的技能质量取决于当时的推理质量，错了就会被固化。第 3 篇里提到的"回音室效应"就是这个问题的极端形态——Agent 只用自己那套老办法，永远不会尝试更优解。
六、安全：设计哲学的差异，不是补丁数量
第 5 篇已经把 CVE-2026-25253 拆得很细，这里只留结论性的差异：
| 维度 | OpenClaw | Hermes Agent |
|---|---|---|
| 安全思路 | 功能优先，出问题打补丁 | 设计阶段内建纵深防御 |
| 默认配置 | 需手动加固 | Docker 部署默认 --cap-drop=ALL |
| 代码执行隔离 | 可选沙箱 | 默认容器沙箱 |
| 注入防护 | 主要依赖模型自身 | 输入过滤 + 输出过滤 + 审计 |
| 技能安全 | 社区审核为主 | 四维自动扫描 |
| 本地模型 | 不支持 | Ollama 原生（敏感数据不出本机） |
我的看法：安全这一维上，OpenClaw 的问题是"信任边界画错了"，而不是"没做安全"。它把控制端 URL 参数当成可信输入，一个链接就能接管 Gateway——这类错误在任何框架里都可能重演。所以别把"Hermes 零 CVE"当成选它的主要理由，应该把"我能不能在被攻破时把损失控制住"当成主要问题。
七、部署与运维：四小时 vs 一分钟
| 维度 | OpenClaw | Hermes Agent |
|---|---|---|
| 最小部署 | 容器 + Redis + MySQL（+ 向量库） | 单容器或单二进制 |
| 首次安装 | 配置文件较多，通常以小时计 | 一行命令，分钟级 |
| 升级 | 多组件协同升级 | 换镜像 |
| 备份 | 分库备份 | 打包一个目录 |
| 多实例 | 天然支持 | 单实例为主 |
| 水平扩展 | 成熟 | 不是设计目标 |
这一维的差距很容易被低估。个人开发者最贵的资源不是服务器，是注意力——为一套私人助手维护三个中间件，性价比很低。反过来，如果你要在 Kubernetes 里跑 50 个租户实例，Hermes 的单进程设计会立刻变成障碍。
八、模型支持与成本
| 维度 | OpenClaw | Hermes Agent |
|---|---|---|
| 模型数量 | 少数几家主流云模型 | 200+（聚合平台 + 本地） |
| 本地模型 | 不支持 | Ollama 原生 |
| 离线运行 | 不支持 | 支持 |
| 多模型路由 | 单一模型为主 | primary / secondary / local 三级 |
成本估算（按公开单价：Claude Sonnet 约 $3/M 输入、$15/M 输出；轻量模型约 $0.5/M 输入、$2/M 输出。以每天 50 次交互、每次 4K 输入 + 1K 输出为例）：
| 方案 | OpenClaw | Hermes（智能路由） |
|---|---|---|
| 模型费 | 全走 Sonnet ≈ $40/月 | 40% 走 Sonnet + 50% 走轻量模型 ≈ $20/月 |
| 基础设施 | 4GB VPS 跑四个服务 ≈ $30/月 | 2GB VPS 单容器 ≈ $10/月 |
| 技能复用节省 | 无 | 约 −$6/月 |
| 合计 | ≈ $70/月 | ≈ $23/月 |
省下的钱来自三处，别搞混优先级：
| 来源 | 贡献 | 是否牺牲质量 |
|---|---|---|
| 多模型路由 | 大 | 轻微（简单任务不需要强模型） |
| 技能复用 | 中 | 不牺牲（反而提升一致性） |
| 零外部依赖 | 中 | 不牺牲（代价是失去水平扩展） |
我的看法：技能复用是唯一"既要又要"的优化项。所以如果只能做一件事，先把技能积累做起来，而不是先去换便宜模型。
九、六个场景，怎么选
| 场景 | 推荐 | 理由 |
|---|---|---|
| 个人开发者日常使用 | Hermes | 零运维、成本低、越用越顺手 |
| 小团队共享 Agent | Hermes（注意按用户隔离记忆） | 一个容器搞定，技能可团队共享 |
| 企业级多实例部署 | OpenClaw | Redis + MySQL 天然支持共享状态，监控体系成熟 |
| 安全敏感（金融/医疗/政务） | Hermes（或 OpenClaw 严格加固后） | 默认沙箱 + 本地模型可完全离线 |
| AI/LLM 研究与实验 | Hermes | 200+ 模型可横向对比，支持运行时切换 |
| 已深度使用 OpenClaw 的团队 | 渐进迁移 | 并行跑两周再切，别推倒重来 |
关于最后一类，多说一句：迁移成本常常被低估。自定义工具要重写、团队要重新适应交互方式、两套系统并行期间运维翻倍。先用两周做 A/B 对比，拿真实任务的数据说话，比读十篇对比文章都可靠。
十、我的判断：不是"更好"，是"不同"
10.1 结论
写完六个维度，我的结论和很多对比文章相反：
没有一方全面领先。
| 维度 | 谁更强 |
|---|---|
| 记忆与学习 | Hermes 明显 |
| 技能生态标准 | Hermes 明显 |
| 部署与运维简洁度 | Hermes 明显 |
| 默认安全配置 | Hermes 明显 |
| 生态规模与用户基数 | OpenClaw 明显 |
| 多实例与水平扩展 | OpenClaw 明显 |
| 企业级运维体系 | OpenClaw 更成熟 |
所以选型问题不是"哪个更强"，而是"你更需要经验积累，还是更需要横向扩展"。
打个比方：
OpenClaw = 汽车
把你从 A 送到 B，每次行程独立
性能取决于引擎（模型）
车队可以很大（多实例）
Hermes = 自动辅助驾驶 + 高精地图
不仅送到目的地，还记得每条路的路况
性能取决于引擎 + 地图精度（模型 + 技能积累）
但地图服务目前是单机的
给汽车换个更强的引擎，它依然不会记住路况——这就是"模型能力更强并不能弥补没有技能系统"的意思。
10.2 Hermes 的三个隐忧
隐忧一：技能库的熵增。 自动生成的技能质量参差不齐，低质量技能越积越多，检索会开始返回"看起来相关但实际误导"的内容。Wikipedia 有编辑审核，Hermes 的技能库目前缺少同级品控。一个可能的方向是技能质量评分（使用次数、成功率、社区投票、新鲜度加权），让检索优先返回高分技能。
隐忧二：FTS5 的边界。 一万条文档下很轻松，十万条以上呢？延迟或许还能撑，精度会先掉。语义检索在这里有天然优势。
隐忧三：大厂降维。 如果 Claude Code、Codex 内置类似的技能学习机制并与自家模型深度共建，独立框架的优势会被稀释。agentskills.io 的开放性也是双刃剑——它降低了用户迁移成本，同样降低了竞争对手的接入成本。
10.3 三个预测
预测一：技能会成为 Agent 的"源代码"。 未来两三年，技能会像代码一样进版本管理、做 Code Review、跑 CI。会出现 awesome-agent-skills 这样的仓库，技能市场会成为生态基础设施。
预测二：三层记忆会成为行业标配。 会话记忆 / 持久记忆 / 用户模型这个分层，会像数据库的关系模型一样成为共识抽象。
预测三：安全从"加分项"变成"准入项"。 CVE-2026-25253 是分水岭。以后不在架构层面内建安全的 Agent 框架，过不了企业的安全评审。
十一、总结
七篇文章走完，回到最初的问题：Hermes Agent 到底改变了什么？
它没有改变模型能力，也没有改变工具数量。它改变的是"Agent 怎么对待自己的经历"——从每次从零开始，变成每次留下一点东西。
| 篇目 | 一句话 |
|---|---|
| 01 总览 | 闭环技能学习是它的灵魂 |
| 02 记忆 | 三层记忆 + FTS5，把长期记忆做成基础设施 |
| 03 技能 | 工具调用 ≥ 5 次就写文档，用时间换能力 |
| 04 网关 | 多平台的核心是上下文管理，不是消息路由 |
| 05 安全 | 目标不是零漏洞，是零失控 |
| 06 部署 | 生产用 Docker，Primary 模型别省钱 |
| 07 对比 | 不是更好，是不同——按"积累 vs 扩展"来选 |
三条给中高级开发者的建议：
- 别用 Star 数做选型。 25.7 万 vs 39.3 万的差距，远不如"你要单机积累还是要分布式扩展"这个问题重要。
- 别把"零 CVE"当成主要理由。 它可能只是"还没被发现"。真正该问的是：被攻破时，损失能控制到多小。
- 先把积累做起来。 无论选哪个框架，让它开始记住你的项目、风格、常用套路。这部分资产会随时间增值，而且换框架时最舍不得丢。
Agent 的竞争，最后不是模型之争，是积累之争。
上一篇：从零到生产：四种部署方式与成本账
系列延伸阅读
「Hermes Agent 深度剖析」系列到这里就结束了，七篇都在这个账号下。如果你是从中间某篇点进来的，建议从第 1 篇开始看——后面的每一篇都建立在前面的概念上。也欢迎留言说说你的选型：你现在用的是哪个框架，最看重的是积累能力还是扩展能力？
