OpenClaw与Hermes：智能体框架的控制权之争

今年5月，在微软Build大会的主题演讲中，CEO萨蒂亚·纳德拉描述了一次平台转型：从操作系统与应用程序，转向无需用户主动打开即可运行的智能体AI。随后他展示了支撑这一转型的关键层：OpenClaw——一个仅发布数月的开源框架，已原生运行于Windows执行容器之上，并以此为基础构建了微软始终在线的企业智能体Scout。英伟达则在3月的GTC大会上，由黄仁勋更直接地将OpenClaw称为"个人AI的操作系统"。这个类比颇为贴切：一个智能体框架之于大语言模型，如同操作系统之于处理器——让模型不仅能独立回答问题，更能持续运行、积累记忆并调用工具采取行动。

今年，两个开源项目从不同起点构建了这一层。OpenClaw围绕"网关"展开，将智能体接入用户已在使用的各类通信渠道；Hermes Agent来自Nous Research，围绕"记忆"展开，让智能体能够学习开发者的工作习惯并持续改进。二者之间的竞争，争的不是调用哪个模型，而是控制层的主导权。

智能体框架是什么

从本质上看，智能体框架是将模型转变为可自主运行系统的软件。它包含：维持智能体在任务间持续存活的运行时、传递消息进出的网关，以及跨会话持久保存信息的记忆。在此之上，还有智能体调用的工具、其运行所依托的身份标识、可扩展的技能，以及决定其权限范围与必要记录的策略和可观测性控制。

Claude Code或Codex等编程助手只覆盖了其中一部分——它们运行于交互式会话中，会话结束后大部分上下文便会丢失。智能体框架则将运行时、记忆与治理机制持续保持到位，使智能体能够无人值守地运行。

Nous Research与OpenClaw在这一架构认知上一致，分歧在于各自将哪个环节视为主要控制点：OpenClaw以网关为核心，让同一个智能体可在WhatsApp、Discord、Slack等渠道统一响应；Hermes以记忆为核心，让智能体能够跨越数周保留开发者的上下文并精炼自身技能。

OpenClaw：以广度取胜

OpenClaw由开发者Peter Steinberger创建，他以早期的PDF工具开发工作著称，于2025年底发布早期版本，并在2026年1月最终定名为OpenClaw。该项目以广度为设计理念，核心是一个可将智能体连接至数十个消息渠道的中央网关。其公共技能市场ClawHub拥有数千个社区贡献的技能，大幅扩展了智能体的能力边界。截至6月底，该代码库在GitHub上的Star数量已接近38万，开源势头不容小觑。

更重要的进展在于谁采用了这一网关。Steinberger于2月加入OpenAI，该项目随即移交至独立基金会，OpenAI以赞助方而非所有者身份参与其中。3月GTC大会上，英伟达将OpenClaw封装入NemoClaw，以OpenShell运行时对每个智能体进行沙箱隔离，并在智能体之外强制执行策略。6月Build大会上，微软将OpenClaw原生集成至Windows执行容器，并推出了具备独立Entra身份标识、连接Teams、Outlook和SharePoint的智能体Scout。在每个案例中，平台厂商都保留了OpenClaw的广度，并补充了原项目所缺乏的治理与身份管理能力。

对企业而言，这改变了成本收益的计算方式。安全团队现在可以精确控制智能体能读取哪些文件夹、哪些必须隐藏，而无需授予那种曾使早期OpenClaw部署面临风险的宽泛访问权限。广度为OpenClaw带来了分发渠道，平台厂商则为其补全了进入生产环境所需的控制能力。

Hermes：以深度致胜

Hermes Agent走的是另一条路。Nous Research于2月25日以MIT协议发布了这一项目，使用Python编写，设计为可在团队自有基础设施上持久运行——无论是VPS、家庭服务器还是笔记本电脑。

Hermes的核心能力是跨会话的持久记忆。它维护分层记忆，在完成高难度任务后开发新技能，并在使用过程中持续精炼。它还会构建使用者的个人画像，使每次会话都比上一次拥有更多上下文。其技能遵循agentskills.io标准，保证技能的可移植性，不会被锁定在单一智能体中。

这种深度带来了可衡量的使用量。Hermes在5月中旬突破10万GitHub Star，月底达到约16万。5月10日，Hermes在OpenRouter的日Token排行榜上超越OpenClaw，当日总量据报达2240亿Token，超过此前的1860亿，位居第一。截至6月底，OpenRouter应用排名中Hermes的总Token数量也居首位，超过22万亿。

Nous Research还将可移植性作为核心卖点，推出了hermes claw migrate命令，可一步导入OpenClaw用户的设置、记忆、技能和密钥。开发者能够保留一个记录了代码库惯例与历史决策的智能体，跨越数周而无需每天重建上下文；团队也可以用一条命令将智能体迁移至不同提供商，因为Hermes对数百个模型保持模型无关性。代价则是运营上的——运行Hermes的团队需要自行负责其所在基础设施的安全与维护。

如何选择

这个选择与"托管云服务"和"自建基础设施"之间的经典取舍如出一辙：托管服务便捷但受厂商治理，自建基础设施控制权完整但需承担运营责任。许多企业将根据工作负载同时运行两者，而非非此即彼。

两个项目都不局限于单一能力：OpenClaw包含记忆和技能，Hermes也支持约二十余个渠道，区别在于侧重点而非能力的有无。英伟达的NemoClaw蓝图已能同样便捷地在OpenShell下运行Hermes智能体和OpenClaw，治理层正被构建为可承载多个智能体项目的底层架构，而非选择其一。

企业需要提前考量的问题

在任何一个智能体接触生产系统之前，企业采购方应当认真思考两个问题。

第一是问责问题。当智能体能够像Hermes那样在会话间重写自身记忆和技能时，团队需要明确：谁能解释行为变化，变化记录在哪里。

第二是所有权问题。当治理和身份标识来自平台厂商（如NemoClaw和Scout的模式），策略引擎和身份认证实际上属于该厂商，而非运行智能体的团队。

对平台厂商而言，争夺的是运行时层——这一层将比任何单一基础模型更为持久。英伟达和微软正在竞相围绕客户选择的任何智能体，构建治理、身份和可观测性能力，这正是NemoClaw同时支持Hermes与OpenClaw的原因。安全问题亦是同一逻辑的体现：对OpenClaw技能市场的审计在扫描的技能中发现了341个恶意条目，安全公司还报告了今年早些时候数以万计的暴露实例，而有治理的运行时正是为弥合这一缺口而设计的。

展望

智能体市场的竞争重心正从模型选择，转向运行时、治理与记忆层。OpenClaw证明了广泛的网关和庞大的技能生态能够吸引开发者，并拉来OpenAI、英伟达、微软的背书；Hermes证明了持久记忆和自我进化的技能，即便没有相同的平台支持，也能驱动可观的日常使用量。

广度与深度是否会长期分属不同项目，已是未定之数——NemoClaw在同一套控制下同时运行两者，Hermes也可以导入OpenClaw的完整配置。

企业需要搞清楚：谁控制着智能体积累的记忆，谁管理着它可调用的工具，谁拥有让它持续运行的运行时。一个积累了开发者一整年工作习惯的智能体，比一个仅仅连接了众多应用程序的智能体，产生的迁移成本要高得多。记忆，而非渠道覆盖范围，正在成为更持久的锁定形式——这正是平台厂商在各自落定于两大项目之下后，将要展开竞争的核心战场。

Q&A

Q1：OpenClaw和Hermes Agent的核心区别是什么？

A：两者都是智能体框架，但侧重点不同。OpenClaw以"网关"为核心，让同一个智能体可在WhatsApp、Discord、Slack等多个渠道统一响应，强调广度和渠道覆盖；Hermes Agent以"记忆"为核心，能跨越多个会话保留开发者的工作上下文、自动开发和精炼技能，强调深度和持续学习。两者并非功能上互斥，OpenClaw也有记忆功能，Hermes也支持多个渠道，区别在于各自的设计侧重。

Q2：Hermes Agent在使用上有什么要求，普通企业能用吗？

A：Hermes Agent以MIT协议开源，使用Python编写，可部署在团队自有基础设施上，包括VPS、家庭服务器或笔记本电脑。它对数百个模型保持模型无关性，团队可以用一条命令迁移至不同提供商。不过代价是运营责任——使用Hermes的团队需要自行负责基础设施的安全与维护，这对缺乏运维能力的企业来说有一定门槛。

Q3：企业在引入智能体框架前需要注意哪些风险？

A：主要有两点需要提前考量。第一是问责问题：当智能体能在会话间重写自身记忆和技能时，团队需要明确谁能解释行为变化、变化日志存储在哪里。第二是所有权问题：若治理和身份标识来自平台厂商（如微软的Scout或英伟达的NemoClaw），策略引擎和身份认证实际上归属于该厂商。此外，OpenClaw技能市场曾被审计发现341个恶意技能条目，安全风险也需关注。