OpenClaw vs Hermes：开源AI Agent框架深度对比与选型指南

引言：名字相似，方向迥异

在开源AI Agent框架领域，OpenClaw和Hermes是两个备受关注的项目。它们都采用MIT许可证，名字听起来像同类竞品，但实际上从设计哲学到架构定位完全不在一个方向上。

AI Agent框架是指为构建自主决策、能够调用工具并完成复杂任务的AI系统而设计的软件基础设施。与传统的聊天机器人不同，Agent具备规划能力、工具使用能力和记忆持久化能力，能够在多轮交互中保持上下文并自主推进任务。2024-2025年间，开源Agent框架经历了爆发式增长，从LangChain、AutoGPT到更专业化的垂直框架，开发者面临的选型难度急剧上升。在这样的背景下，理解每个框架的核心差异变得尤为重要。

本文从定位、架构、记忆系统、鉴权机制、插件生态、渠道分布等多个维度，深入拆解两者的核心差异，帮助开发者做出合理选择。

定位差异：向外连接 vs 向内生长

OpenClaw官方的自我介绍是："Your own personal AI assistant, any OS any platform, the lobster way"。它把自己定位为一个跨平台的个人AI助手网关，核心价值在于将Agent接入你日常使用的各种Messaging平台——Telegram、Slack、微信、iMessage等，让你在任何地方都能调起AI助手。

Hermes的官方定位则是："The self-improving AI agent built by Noose Research"。它强调的是自我学习和持续成长，会从使用过程中自动创建Skill、自我迭代、加深对用户的理解，实现跨Session的持续进化。

简单概括：一个向外连接万物，一个向内生长智慧。这是两种截然不同的产品哲学。

Runtime架构对比：调度器 vs 单循环

最有信息量的差异体现在Runtime架构上。Runtime在Agent框架语境下指的是实际执行模型推理和工具调用的运行时环境。理解这一层的设计差异，是判断两个框架适用场景的关键。

OpenClaw：多Runtime调度器

OpenClaw把Runtime当成一等公民，内置四个自家Runtime——Codex、Claude、CLI，以及通过ACP协议接入的外部Agent。ACP（Agent Communication Protocol）是一种用于Agent间通信的标准化协议，允许不同框架构建的Agent相互发现、协商能力并协作完成任务。它类似于微服务架构中的gRPC或REST API，但专门为AI Agent的异步、多轮、带状态的交互模式设计。通过ACP，OpenClaw可以将外部Agent视为本地Runtime来调度，实现跨框架的Agent编排。

每个模型都可以通过配置中的agent.runtime.id字段指定走哪个Runtime。比如选OpenAI模型加Codex，这一回合就交给Codex CLI的AppServer来跑；选Anthropic加Claude CLI，就走Claude CLI。它的失败模式是Fail Close——当系统无法确认安全状态时选择拒绝服务而非降级运行。你指定的Runtime找不到就直接报错，不会偷偷回退。这种策略在金融和安全领域是标准做法，OpenClaw将其引入Agent调度中确保行为完全可预测。

Hermes：单循环加可选扩展

Hermes完全不同，它只有一个原生的Sync Agent Loop跑所有模型。Codex AppServer是后加的可选Runtime，通过slash命令和全局开关控制。开启后，OpenAI模型的回合才会委托给Codex跑。

打个比方：OpenClaw像Window Manager，本身不跑Agent Loop，而是调度多个独立Process；Hermes像VS Code装了一个Codex扩展，自己能跑，Codex只是可选的Plan B。

这种架构差异直接影响了两者的扩展模式：OpenClaw天然支持多Agent协作（每个Runtime可以是独立Agent），而Hermes更适合单Agent深度运行的场景。

记忆系统：透明文件 vs 智能检索

OpenClaw：所见即所得的文件记忆

OpenClaw的记忆全是纯Markdown文件。长期记忆放Memory.md，每日工作记忆放按日期命名的MD文件。官方原话很直接："The model only remembers what gets saved to disk. There is no hidden state." 文件你能直接打开看、直接手编，完全透明可控。

这种设计的优势在于调试和审计极其简单——你随时可以打开文件查看Agent"记住了什么"，也可以直接编辑文件来修正Agent的认知。缺点是随着记忆量增长，纯文件方案在检索效率上会遇到瓶颈。

Hermes：多层记忆架构

Hermes的记忆系统复杂得多。基础层是Memory.md加User.md两个文件，外层套了一个SQLite加FTS5全文检索的Session数据库，再加上8个可选的外部Memory Provider（MEM、Hanqiu、SuperMemory、Hindsight等），每个Provider带自己的工具集，相当于给Agent接入第三方记忆云服务。

SQLite是一个嵌入式关系数据库，无需独立服务器进程，数据存储在单个文件中，非常适合本地应用。FTS5（Full-Text Search 5）是SQLite的全文检索扩展模块，支持对文本内容建立倒排索引，实现毫秒级的关键词和短语搜索。在Agent记忆系统中使用SQLite+FTS5意味着可以在不依赖外部服务的情况下，对历史对话和Session数据进行高效的语义检索，平衡了本地部署的轻量性和检索的高效性。

记忆升级机制的本质对立

这里最有意思的细节是两者处理"Agent观察如何升级为长期记忆"的方式：

OpenClaw采用Human in the Loop：它有个Dreams.md文件，后台Sweep进程把日常观察整理成候选写进去，但不会自动升级到长期记忆，而是等用户审核后才进入Memory.md。

Human in the Loop（HITL）是AI系统设计中的一种核心模式，指在自动化流程的关键决策节点保留人类审核和干预的能力。在Agent系统中，这意味着AI可以自主完成大部分工作，但在涉及不可逆操作、高风险决策或知识固化时，需要人类确认。OpenClaw在记忆升级这个环节引入HITL，本质上是认为"什么值得被长期记住"这个判断不应该完全交给机器。

Hermes采用全自动Curator：Curator Release版本中，后台自动跑一个Curator进程，给Agent自己的Skill打分、减值、归档，零用户参与。这种设计假设Agent自身有足够的判断力来管理自己的知识库，更接近人类大脑的遗忘曲线机制——不常用的记忆自然衰减，高频使用的记忆得到强化。

同一个问题——Agent积累的观察怎么处理？OpenClaw说"我不替你做决定，给你候选清单你来定"；Hermes说"我替你打分自动淘汰，你不用管"。这是设计哲学的本质分歧。

鉴权机制：集中管理 vs 委托分治

OpenClaw把所有鉴权集中存在一个authprofiles.json文件里（官方称为TokenSync），统一存、统一管、再分发给各个Runtime。一个文件里可以同时放ChatGPT订阅的OAuth Token、OpenAI的API Key、Anthropic的Key以及Claude CLI的本地Auth。这种集中式管理类似于密码管理器的思路——单点存储、统一加密、按需分发。

Hermes走的是Delegate路线：Hermes自己的hermes auth login命令管基础鉴权，但开了Codex Runtime之后，Codex部分的鉴权完全交给Codex CLI自己的auth.json，绕过Hermes。这种委托模式遵循最小权限原则——每个组件只管理自己需要的凭证，互不干扰。

两种思路各有道理：OpenClaw集中存方便管理和审计，但安全责任全在它身上，一旦authprofiles.json泄露则所有凭证暴露；Hermes委托给各CLI减少了攻击面（单点泄露不影响其他组件），但你得分别维护各自的登录态，在Token过期时需要逐个刷新。

插件生态：多格式兼容 vs 开放标准对齐

OpenClaw有官方注册中心CloudHub，分四种Artifact：Skills、Code Plugins、Bundle Plugins和Source角色包。除了CloudHub还可以直接装NPM包、Git仓库、本地Link。最值得一提的是它支持兼容Codex、Claude和Cursor的Bundle格式，相当于一份插件给多套客户端用。这种多格式兼容策略降低了插件开发者的维护成本，也让OpenClaw能快速借力已有生态。

Hermes走PIP Entry Points发现机制，也是四个子类：General、Memory、Context和Model Providers/Skills。PIP Entry Points是Python包管理系统中的一种插件发现机制——开发者在包的setup.cfg或pyproject.toml中声明entry_points，安装后框架可以通过importlib.metadata动态发现所有已注册的插件，无需硬编码导入路径。这种机制在pytest、Flask等项目中广泛使用，其优势在于插件的安装和发现完全解耦——用户只需pip install一个包，框架就能自动识别并加载其中的功能模块。

Hermes与AgentSkills.io开放标准对齐，不绑自家格式，能与其他兼容该标准的工具互通。此外，Hermes的Agent自己有个skills_manage工具，可以自己创建、修改、删除自己的Skills——这与其Self-Improving定位完全配套。Agent不仅使用Skills，还能在运行过程中根据新的需求自主生成新的Skills，形成正向的能力积累循环。

渠道分布：横向广度 vs 纵向深度

OpenClaw在渠道覆盖上完胜：支持27个以上Messaging平台，从Discord、Telegram、Slack这些主流平台，到微信、元宝、Faceu等国内平台，再到iMessage甚至通过Technics直接接电话。加上WebChat、Control UI面板、Mac/iOS/Android三端伴侣App，横向铺得极广。这种策略的核心逻辑是：用户不应该为了使用AI而改变自己的通讯习惯，AI应该出现在用户已经在的地方。

Hermes覆盖19个以上Messaging平台，包括Telegram、Discord、Slack、WhatsApp、Signal等常见平台。但Hermes在另一个维度做得更深：它有ACP协议接入，能把Agent接到VS Code、JetBrains等IDE里，还提供OpenAI兼容的API Server。OpenAI兼容API意味着任何支持OpenAI API格式的客户端（如Chatbox、TypingMind等）都可以直接对接Hermes，无需额外适配。

简单说：OpenClaw横向铺得更广，Hermes纵向接得更深，特别是开发者工作流这块。

选型建议：根据需求匹配框架

选OpenClaw的场景：

• 需要接入各种Messaging平台的统一AI入口
• 使用ChatGPT或Claude订阅鉴权
• 偏好本地透明可控，愿意手动维护配置文件
• 重视Human in the Loop的记忆管理
• 团队中有多人使用不同平台，需要统一的Agent接入层

选Hermes的场景：

• 需要一个会自我学习、长时间运行的Agent
• 重度IDE集成需求（VS Code/JetBrains）
• 希望系统自动管理Skill库，减少人工干预
• 需要复杂的记忆检索和外部Memory Provider
• 偏好Python生态，习惯pip install的工作流

两者并不互斥，你完全可以都装来对比使用。但主入口最好选定一个——毕竟Session数据库和记忆系统各管各的，混着用会导致两边都跑不起来。从长期演进来看，OpenClaw更可能向Agent编排平台方向发展（管理多个Agent的协作），而Hermes更可能向单Agent极致智能方向演进（一个Agent越来越聪明）。

核心要点

• OpenClaw定位为跨平台AI助手网关（向外连接），Hermes定位为自我学习型Agent（向内生长），设计哲学本质不同
• Runtime架构差异显著：OpenClaw像Window Manager调度多个独立Runtime，Hermes是单Agent Loop加可选Codex扩展
• 记忆系统哲学对立：OpenClaw采用Human in the Loop的透明文件方案，Hermes采用全自动Curator零用户参与的智能管理
• 渠道分布各有侧重：OpenClaw横向覆盖27+平台，Hermes纵向深耕开发者工作流和IDE集成
• 两者不互斥但不建议混用，应根据使用场景（多平台接入vs自学习Agent）选定主入口