Hermes 是个值得研究的项目，但它的"自进化"有明显边界，别被营销号带偏了。
2026年年后，GitHub上突然冒出来一个叫 Hermes Agent 的项目，Nous Research出的。2月底发布，到我写稿的时候已经4万多Star了，更新速度快得离谱。
我刷到的时候第一反应是：这才火多久，怎么就有人开始说"不用学OpenClaw了，直接上Hermes"？作为一个在这个领域跟踪了一段时间的人，我决定认真看一下它的源码，不能光看营销吹牛。
看完之后，有些地方确实比OpenClaw做得深，但也有一些地方被夸大了。这篇文章把我的判断写清楚。
Self-Evolving：两条路，一条靠谱一条存疑
Hermes 最核心的宣传点就是"自进化"，号称能"越用越强"。实现路径有两条：
第一条是动态 Skill 生成——每次完成任务后自动复盘，把踩过的坑、有效的纠错方式沉淀成一个Skill文件。下次遇到类似任务直接复用，不用从零摸索。
这个设计是合理的，本质上就是把"试错经验"从口头记变成了系统化存储。OpenClaw 也可以做这件事，但需要用户主动要求；Hermes 把这个过程自动化了。效果好不好取决于沉淀质量，但机制本身没毛病。
第二条是 RL 训练闭环——把轨迹数据拿来训练模型权重，号称能从根本上提升模型能力。
这一条我得多说几句。
Hermes 的 RL 训练流程确实是完整的：轨迹捕获 → 数据清洗 → 格式转换 → GRPO训练 → 评估。用的也是 DeepSeek R1 论文里的 GRPO 算法，不依赖单独的 Reward Model，简化了以前训练 Reward Model 的痛苦。
但问题在于：它的训练数据是从哪来的？
是合成数据——用 Claude Opus 4.6 作为 Teacher Model 来生成示范数据，不是直接用用户对话。官方文档里也明确说了，不建议拿用户对话直接训练，因为质量不可控，容易把模型训废。
这就产生了一个关键问题：它的"进化"是受限的。Skill 沉淀是真实有效的，但 RL 训练这一环本质上是"用强模型的知识蒸馏到小模型"，不是真正意义上的"越用越强"。你用它越多，它不会自动变聪明——除非官方自己拿新数据重新训一版模型发出来。
所以我的判断是：Skill 动态生成这部分是真实增量，RL 训练闭环是"一次性定向优化"。两者结合确实比纯静态的 Agent 强，但别指望它变成一个会自己进化的数字生命。
自进化的技术细节：Skill生成怎么做的？
如果你对具体机制感兴趣，这段讲一下技术实现。
触发机制在run_agent.py里有一个计数器_skill_nudge_interval = 10：如果 Agent 连续10轮对话都没创建/修改技能，系统就会提醒它"你是不是该整理一下经验了"。这个阈值可以调，但默认10轮。
复盘过程是异步进行的。主 Agent 回复用户之后，后台会 fork 一个轻量级审查 Agent，从三个维度分析刚结束的对话：记忆有没有值得留的、任务路径有没有值得固化的、执行过程有没有可以改进的。
这个设计有点像"双进程"——前台快速响应，后台慢慢整理。用户体验不受影响，经验也在积累。
但问题在于：审查 Agent 的质量完全不可控。它沉淀出来的 Skill 到底好不好，没有人工验证环节，也没有任何质量评分机制。如果审查 Agent 自己判断错了，把错的经验当成对的沉淀下来，那下次就会重复犯错。这是一个隐患，官方目前没有解决。
Prompt Engineering：兼容牌打得不错，但不算创新
Hermes 在 Prompt 层面的核心思路是兼容——尽量减少用户从其他框架迁移过来的成本。
它能直接读取 OpenClaw 的 AGENT.md、SOUL.md、USER.md，也能读 Cursor 的.cursorrules、Claude Code 的CLAUDE.md。如果你已经在用 OpenClaw，迁移到 Hermes 确实可以复用大部分配置。
另外，针对不同模型工具调用意愿不同的问题，Hermes 做了动态指令补丁：GPT系需要提醒"不要只说不做"，Gemini系需要提醒"使用绝对路径、先读后改"。这个设计合理，但也不算创新，本质上是把经验沉淀成了配置。
Context Engineering：比例阈值压缩思路有意思
上下文压缩这块，Hermes 用的是相对比例而不是绝对Token数。窗口50%满了就触发压缩，而不是等具体某个数值。
这个思路比 OpenClaw 的绝对阈值更合理。不同模型窗口大小差异很大，32K和200K的模型用同一套绝对阈值肯定有问题，按比例来更灵活。
压缩策略和 OpenClaw 类似：头部任务定义保护，尾部最后几轮保护，中间冗余部分用LLM生成摘要。中间压缩区如果 token 太多，会触发多次摘要。
Harness Engineering：14种错误分类是亮点
长程任务最怕的就是报错后 Agent 陷入死循环。Hermes 把错误分成了14类：认证失败、账单问题、限流、超时、上下文溢出、格式错误……每类都有预设的恢复策略。
这个分类体系比 OpenClaw 细致很多。OpenClaw 的错误处理相对粗糙，Hermes 至少让你能知道"报的是什么错"，而不是看到一个笼统的Error。
子 Agent 隔离也做了限制：最多3个并行子Agent，最多2层嵌套，子Agent不能创建新的子Agent，不能访问主Agent的记忆库。这个约束是必要的，防止递归调用把系统拖垮。
我的判断：值得研究，但别神化
说几个我的核心观点：
好的地方：
- Skill 动态沉淀机制真实有效，是对现有Agent框架的真实改进
- 错误分类体系是工程上实用的积累
- 相对比例压缩思路值得借鉴
- 兼容 OpenClaw 生态降低了迁移成本
被高估的地方：
- "自进化"这个说法有误导性，RL训练是定向的，不是持续自发的
- 审查 Agent 的质量没有保障机制
- RL 训练的数据合成依赖强模型，普通人没有能力复现这个流程
- 更新速度快不等于做得好，4万Star有相当部分是追热点追来的
如果你是OpenClaw用户：迁移成本不高，但建议先想清楚你要解决的核心问题是什么。Hermes 能解决的我认为主要是"减少重复踩坑"这一件事。
如果你是新人：建议先了解 OpenClaw ，把 Agent 的基础概念打扎实再看 Hermes，否则容易只看到"哇好牛逼"但不知道牛逼在哪。
