智能体skills大乱斗：OpenClaw的精确控制如何完胜Hermes的自改进狂欢？本文对比分析OpenClaw与Hermes两大AI代理框架的技能管理策略，揭示各自在自改进能力、控制精度和产品定位上的根本差异，帮助用户根据需求选择。
智能体中技能自生成机制的冗余问题与控制策略对比研究——以Hermes和OpenClaw为例
我花了九个小时并排研究OpenClaw和Hermes的源代码，发现两者在技能管理上走了完全相反的路线。Hermes通过让代理自己写技能来实现自改进，但很快会陷入技能爆炸和冗余的困境。OpenClaw则坚持精确控制和严格治理，技能必须由用户主导添加，虽然起步慢但长期运行更稳定。这场对比不仅是技术选择，更是产品定位的经典案例。
Hermes的自改进魔法从何而来
Hermes最吸引人的地方在于它让代理能够通过编写技能实现自我进化。系统提示里直接嵌入了一个隐形推动机制：每调用N次工具，代理就会考虑保存当前模式为技能。当任务完成后，后台会扫描整个过程，找出值得固化成技能的模式。甚至在上下文压缩启动之前，那些持久性的知识会被强制写入磁盘。这个提示非常直白——如果已有技能能覆盖当前需求，就直接在原技能上修补更新；只有当完全找不到匹配项时，才创建全新技能。
这种设计真的有效。我亲眼看到它自己创建了一个名为“提取社交证明”的技能，而且这个技能后来被证明非常实用。我在OpenClaw里也有一个通过提示触发的保存命令，但这种类型的技能我自己根本想不到要创建。第一次看到代理自我改进就像变魔术一样。
但问题也随之而来。在我的Hermes安装目录下，在代理自己写出任何一个技能之前，官方已经打包了123个技能文件。从GitHub PR工作流到Obsidian笔记，从Google Workspace到项目管理工具Linear，从内容发布工具Typefully到搜索工具Perplexity，甚至还包括Minecraft模组服务器——这个覆盖面大得惊人，意思是“别人已经替你解决了这个问题”。这就是所谓的有主见的默认配置。你不是拿到一个空白代理加一个框架，而是拿到一个第一天就知道怎么处理一百多件事的代理，再加上一个随着你使用会不断学习更多技能的自改进循环。
技能爆炸的真实案例与后果
这里有个没人讨论的实际问题：自编写的技能会快速膨胀导致爆炸。我在自己的Hermes技能目录里发现了一个真实例子。代理想读取我桌面上的一个图片，先尝试了浏览器读取技能，不行；又尝试了视觉识别技能，还是不行。于是它写了第三个技能叫“读取本地图片”，哈哈。这三个技能全部围绕着“图片加本地文件系统加模型能看见”这个相同需求。技能库会迅速膨胀，而且很快就变得互相重叠、互不排他。
这就是长尾失败模式。代理很擅长发现“我应该把这个模式封装起来”，但它非常不擅长发现“我隔壁三个文件夹已经封装过同样东西了”。最终你会得到一个增长速度远快于整合速度的技能库。长期影响就是你会积累大量技能，有些非常聪明，有些完全冗余，还有些跟其他三个没人记得存在的技能互相重叠。
我确信Hermes背后团队NousResearch的Teknium已经知道这个问题，目前只是产品优先级决策。随着更多普通用户变成高级用户，他们的技能不断积累，这个问题很快会被解决，解决方案可能是引入调用频率统计的整合清理机制，以及在创建技能时做更强的去重检查。
OpenClaw的精确控制如何避免技能爆炸
OpenClaw完全没有这个问题。部分原因是它不会以同样速度自动生成技能，所以从一开始需要去重的东西就少很多。另一个原因是它有更多机制从结构上解决这个问题。OpenClaw在技能方面采取了完全相反的立场。根据它的愿景文档：官方仍然会打包一些基础技能以保证基本体验，但新技能应该先发布到ClawHub仓库，而不是默认添加到核心代码库。核心技能的添加应该非常罕见，并且必须有强烈的产品或安全理由。这是一种通过策略来防止臃肿的方式，代码更干净，但编写技能的责任完全在你身上。
所以OpenClaw的技能是明确的工件，每一层都有治理规则。技能来源有五种，按优先级排序：工作空间技能、用户全局技能、托管技能、打包技能、额外技能。这样你永远知道加载了哪些技能。当凌晨三点出问题时，你可以通过一次搜索就追踪到问题根源，而不是猜测代理触发了哪个技能。技能发现机制在多个层面都有边界限制：字节数上限、候选技能数量上限、符号链接拒绝、验证过的文件打开操作。资格检查和发现机制是分开的，不同代理可以看到不同子集的技能——你的编程代理不需要在上下文中加载你的邮件技能。
OpenClaw的治理策略带来的实际好处
更小的技能覆盖面意味着更低的运行成本、更敏锐的响应速度、以及长时间任务中更少的偏离。治理部分明确写入了产品策略：打包技能只是基础，新技能必须先进入ClawHub，核心库的添加必须非常罕见。技能库不会腐烂，因为没有用户明确意图就不会添加任何东西——每个技能都必须靠自己赢得存在的位置。这就是所谓原语的实际含义。你不是拿到一堆默认配置，而是拿到一系列保证。OpenClaw只做你明确告诉它做的事，不多也不少。这是最无聊但也最好的方式。当你在生产环境中部署或者在团队内部运行这个系统时，无聊本身就是整个产品的价值所在。
我在OpenClaw上得到一个实用成果：我把它的工具文档和Vercel的代理优化模式结合了起来。在代理需要从大约五十个选项中选择正确的命令行或API的任务上，OpenClaw的工具激活正确率比Hermes更高。Vercel有一篇很好的文章解释了这一点，简单总结就是显式优于隐式。代理不需要判断“这个技能值不值得加载”，因为路由规则已经写在了系统提示里。
我的当前判断与选择建议
两个框架都能完成你想要的所有事情。选任何一个，你都不会错。但如果你要从头开始选，快速入门选Hermes。有主见的默认配置意味着你第一天就能高效工作，并且只需很少的维护就能保持高效。想要百分之百控制权的用户选OpenClaw。可读性和范围控制比自改进更重要。如果你是开发者，那就看情况了。有些事OpenClaw做得更好，有些事Hermes做得更好。诚实的做法是每天用其中一个，然后从另一个身上偷学模式。
但更有趣的问题不是选哪个，而是你能从每个框架身上学到什么。Steipete给世界带来了堆栈中的一个新层次，把爪子放到了每个人手里。这是基础性工作。你甚至不需要使用OpenClaw就能从OpenClaw受益——这些模式会在未来几年出现在下游所有项目中。另外他做代理工程的方式，现在每个写软件的人都应该认真学习。
NousResearch正在上演一场产品定位的大师课，这值得单独写一篇文章，但简单来说：OpenClaw曾经拥有整个受众，拥有思想份额，拥有GitHub星标，拥有那种“它基本上已经是标准了”的能量。
产品定位的经典案例
看看那些试图正面竞争的人都发生了什么。Nanoclaw、Nullclaw、Picoclaw、Zeroclaw，我能再列出十个。所有这些框架都想成为比OpenClaw更OpenClaw的东西——更小、更轻、更极简、更可组合、治理更好，随便什么。但没有一个达到了Hermes的吸引力。因为当你通过成为某个品类定义者的更便宜或更干净版本来竞争时，品类定义者只是默认获胜。你在他们的棋盘上玩他们的游戏。
Hermes创造了自己的游戏。自编写技能。默认打包一大堆功能。故意走最大主义路线。工具网关作为锁定机制。每一次发布都在强化同一个论点：我们不是极简原语公司，我们是内置电池、代理即产品的公司。
这是教科书级别的产品定位。每一次发布以及他们发布的方式，都应该被研究。这是给创始人的教训。给用户的教训更简单：随便选一个，从两个身上学习，然后去做点有用的东西。