逼到源码级的追问——OpenClaw vs Hermes到底在「成长」这件事上有什么根本区别
我和AI吵了一下午，关于怎么让Agent自己"活过来"
第三篇：逼到源码级的追问——"成长"到底是什么意思
> 这一篇是整场对话里信息密度最高的部分。我在OpenClaw和Hermes之间纠结，Claude给了三次结论，我打回去三次。最后一次追问，把问题逼到了架构哲学的层面——两个框架对"Agent应不应该自己改变自己"这个命题的回答是相反的。
纠结的开始
我跟Claude说了句大实话："我最近很纠结，到底是用OpenClaw好还是用Hermes好。"
背景：OpenClaw是2026年最火的开源Agent框架，5,400+社区技能、Dreaming记忆整理系统、庞大生态。Hermes Agent是Nous Research的开源框架，主打"自我改进的AI Agent"，有Profile系统和skill_manage工具。
两个都是顶级框架。社区里吵翻天了，各有拥趸。我不想凭直觉选，我想搞明白它们的本质区别。
第一轮：被我说"鲁莽"
Claude搜索了一圈，给了一个初步结论：Hermes适合"成长型"场景，OpenClaw适合"工具型"场景。核心论据是"Hermes会成长，OpenClaw需要人工维护"。
我说：你评价得可能过于鲁莽。
我的理由很具体：OpenClaw在2026年4月密集发了三个版本——4.9加了Dreaming系统、4.10加了Active Memory、4.11做了安全强化。你不能拿旧版信息来评新版产品。这跟拿iOS 15的体验去评价iOS 18一样荒谬。
Claude犯了什么错？ 它搜索时用的信息来源有滞后。更深层的问题是——它找到了支持"Hermes更好"这个结论的证据就停下了，没有主动去验证OpenClaw最新版本是否已经补上了差距。
这是AI搜索的典型陷阱：确认偏误（Confirmation Bias）。一旦有了初步假设，后续搜索就会不自觉地偏向支持假设的证据。
第二轮：被我说"逻辑不对"
Claude重新搜索了最新版本，调整了结论：两个框架的记忆系统在2026年4月已经非常接近。OpenClaw的Dreaming系统和Hermes的外部记忆提供商，在"记忆增长"维度上几乎打平。
听起来公允了。但我说：
> "你评估的逻辑不对。他们会成长，不能只看记忆，还有他们的核心机制。你要想为什么Hermes会成长OpenClaw不会成长——核心到底是什么？"
这句话是整场对话里技术含量最高的一次追问。
我在说什么？我在说：你在比较两个框架的"器官"（记忆系统），但你应该比较它们的"基因"（架构设计哲学）。 器官可以升级、可以移植，但基因决定了这个生命体能长成什么样。
Claude这次真的被逼到墙角了。它不能再做功能列表对比了，它必须去理解两个框架的底层架构逻辑。
四路并行搜索：找到了关键证据
Claude开了四个并行搜索任务，查两个框架的源码结构、GitHub Issues、技术博客、架构文档。
回来的结果，终于触碰到了核心。
OpenClaw的ReAct循环
七个阶段：normalize → route → assemble context → infer → ReAct → load skills → persist memory。
load skills：session启动时做一次静态快照。整个session期间，Agent用的技能列表不变。Agent自己不能在运行时创建、修改、删除任何skill。
persist memory：session结束后，Dreaming系统可以整理和更新记忆。
翻译成人话：OpenClaw的记忆是活的，但技能是死的。
Hermes的Agent Loop
内置一个叫skill_manage的工具。Agent在运行过程中可以：create（创建新技能）、update（更新已有技能）、delete（删除过时技能）。默认开启，不需要手动配置。每15个任务自动触发一次自我评估。
翻译成人话：Hermes的记忆和技能都是活的。
这意味着什么：两个厨师的故事
我们用了一个比喻来把这件事说透。
OpenClaw厨师有一本菜谱。他记忆力越来越好——记住了"上次客人说太咸"、"周三的鱼更新鲜"、"芹菜要提前焯水"。但菜谱本身他改不了。菜谱上写着盐15g，他就放15g。即使他记得"上次太咸了"，他还是会放15g——因为那是菜谱规定的步骤。除非老板来改菜谱。
Hermes厨师同样有菜谱，同样能记东西。但关键区别——他可以自己改菜谱。今天红烧肉太咸了，他不只是记住"下次少放盐"，而是直接把菜谱上的15g改成12g。明天他的助手来做这道菜，起点就已经是改进后的版本。
一个只能变博学，一个能变能干。
用学术语言说：OpenClaw只有陈述性记忆（Declarative Memory：知道什么），Hermes同时有陈述性记忆和程序性记忆（Procedural Memory：知道怎么做，以及能修改"怎么做"）。
第三轮追问：OpenClaw真的不行吗？
我没有满足于这个结论。我追了第三次：
> "关键在于那个Self-Improving Skill。你要基于这个环节深度调研，OpenClaw是否有很大的改进——不是靠第三方，而是自身。"
我要的是确定性。不能光看"默认不支持就说它不行"——万一最新版已经把自改进能力并入核心了呢？
Claude再次开了三路并行调研，查了OpenClaw 2026全年的changelog、GitHub releases、核心架构文档、社区讨论。
结论很清楚，也很残酷：
OpenClaw核心层面：完全不支持技能自修改。
- ReAct循环七个阶段没有任何一个包含技能修改能力
- 自带的skill-creator只是教学文档，不是自动化工具
- Dreaming系统只写MEMORY.md，从不触碰skill文件
- Active Memory只是记忆读取工具
- 2026全年changelog里没有任何技能自修改的PR或roadmap
OpenClaw社区层面：有Capability Evolver（35,000+安装量），但它是第三方插件。 需要手动安装、需要write权限、官方没有并入核心的计划。
还有MetaClaw（强化学习更新技能权重）和SkillClaw（集体技能进化），但都是论文级项目。
这不是技术做不到——而是架构哲学选择。 OpenClaw有意把skill定位为"人类控制的配置层"。技能由人类编写、审核、版本管理。好处是可预测性：你永远知道Agent会按什么逻辑执行。
Hermes把skill定位为"Agent自己的程序性记忆"。好处是自主进化，代价是可控性降低。
这不是好vs坏，是控制vs自主。两种哲学。
公平起见：Hermes也有问题
我从第四次被打脸学到了教训——不能鲁莽评价。所以Claude这次主动查了Hermes skill_manage的已知问题。
Issue #5563（严重）：重度使用（每天8小时+，连续3周）后，state.db损坏，69%的token浪费在session replay上，环境幻觉。这直接影响技能持久化的可靠性。
Issue #8293：symlink技能目录无法被发现。
没有回滚机制：Agent改坏了skill，没法回退。
没有创建前验证：写入磁盘前不检查格式，理论上能写出损坏的技能。
"默认开启"不等于"生产可靠"。 这句话值得用大号字体打出来。
三轮追问的收获
回头看这三轮：
第一轮——我打回"鲁莽"——逼Claude更新了信息源。
第二轮——我打回"逻辑不对"——逼Claude从功能对比深入到架构对比。
第三轮——我追问"原生到底行不行"——逼Claude用证据排除了可能性，给出了确定性结论。
如果我在第一轮就接受了"Hermes好OpenClaw不行"的结论？我会基于一个过时的、浅层的判断来选框架。
如果我在第二轮就接受了"记忆系统差不多"的结论？我会错过两个框架最核心的架构差异。
三次追问，三次逼近，最后才触碰到真相。 这不是AI不够好，是"看起来合理"和"确实如此"之间，永远隔着至少三层追问。
真正的对比矩阵
经过三轮追问后的对比，不再是功能列表的堆砌，而是一张有灵魂的图：
| 维度 | OpenClaw | Hermes |
|------|----------|--------|
| 对"技能"的定位 | 人类管控的配置 | Agent的程序性记忆 |
| 技能运行时可改 | 否（核心不支持） | 是（默认开启） |
| 记忆运行时可改 | 是（Dreaming很强） | 是（外部provider） |
| 成长方程式 | 记更多，做法不变 | 记更多 + 做法在变 |
| 可预测性 | 高 | 低 |
| 社区生态 | 5,400+技能 | 较小但快速增长 |
| 生产稳定性 | 成熟 | 有已知问题 |
| 适合谁 | 有团队维护skill的组织 | 需要Agent自我进化的场景 |
最后一行是关键。不是谁更好，是谁更适合你的场景。
我是一个人。我没有团队来维护14个Agent的技能文件。我需要Agent自己变强。
但我也没有天真到以为选了Hermes就万事大吉——state.db损坏、没有回滚、token浪费，这些都是真实的生产风险。
所以我问了下一个问题：有没有融合方案？
> *（未完待续）*
>
> *下一篇：苏格拉底不会让你轻易下结论——融合、反转、以及这场对话真正教会我的事*