OpenClaw 和 Hermes Agent 到底是什么？为什么会火？它们和 Codex、Claude Code 的分工是什么？
读完了 · 8138 字 · 约 12 分钟
加载中...
这两个月，如果你一直在关注 AI Agent 圈子，大概率会反复看到两个名字：OpenClaw 和 Hermes Agent。
很多人第一次看到它们时都会有一种困惑：
Codex、Claude Code 这种客户端了OpenClaw、Hermes 这种看起来更“重”的东西？这篇文章我想把这件事讲透，重点回答四个问题：
OpenClaw 和 Hermes Agent 分别是什么Codex、Claude Code，到底什么时候才需要它们先把最重要的一句话放前面：
OpenClaw 和 Hermes Agent，严格来说都不只是“写代码助手”。它们更接近“长期运行的、自带工具和记忆的个人/团队 Agent 基座”。
这和 Codex、Claude Code 的产品心智不太一样。
像 Codex、Claude Code 这类工具，核心体验通常是：
而 OpenClaw、Hermes Agent 更像什么？
它们更像：
所以它们火起来，不是因为大家突然不需要 Codex、Claude Code 了，而是因为越来越多人开始需要另一层能力：
不是“让模型帮我写代码”，而是“让 Agent 长期替我盯事、跑事、接消息、调工具、跨场景工作”。
从官方文档看，OpenClaw 的定位非常明确：它是一个 self-hosted gateway，也就是“自托管的 Agent 网关”。
它的核心思路不是“做一个新的聊天框”，而是：
官方文档里强调了几个点：
self-hosted 的，数据和运行权在你手里multi-channel 的，一个 Gateway 能接多个聊天入口agent-native 的，默认就围绕 session、memory、routing、tool use 设计multi-agent routing，也就是一个网关下面跑多个隔离 Agent换句话说，OpenClaw 更像一个“Agent 操作系统的网关层”。
如果一定要打个比方，OpenClaw 很像：
消息入口层Agent 路由层长期在线的控制平面它最适合的不是“我今天要改一个函数”，而是这种需求：
从官方站点和文档来看，OpenClaw 有几个特别关键的能力：
codex-cli、claude-cli 等后端这一点非常重要。
OpenClaw 本质上不是来替代 Codex/Claude 的模型能力，而是把它们包装进一个“长期在线、跨渠道、可路由、可编排”的 Agent 外壳里。
如果说 OpenClaw 更偏“网关和控制平面”，那 Hermes Agent 更偏“Agent runtime 本体”。
根据 Nous Research 的官方介绍，Hermes Agent 的核心卖点不是“我能接多少聊天平台”，而是：
我是一个会持续学习、会积累记忆、会自我生成技能的长期运行 Agent。
官方首页反复强调了几个关键词：
self-improvinglearning looppersistent memoryskillscrondelegationMCP这说明 Hermes 的重点不只是“能不能调用工具”，而是“这个 Agent 能不能随着时间推移变得更像一个持续工作的系统”。
我觉得 Hermes 和其他 Agent 框架相比，最有辨识度的有三点。
Hermes 官方文档里把记忆分成两层：
MEMORY.md：环境事实、项目习惯、工作经验USER.md：用户偏好、沟通方式、习惯与要求而且这些记忆会跨会话持久化，不是一次聊天结束就全没了。
在此基础上，Hermes 还支持一个叫 Honcho 的 memory backend。官方文档的描述非常明确：它不是简单 key-value 存储，而是尝试去维护一个“用户模型”，包括偏好、风格、目标和行为模式。
这意味着 Hermes 的目标不是“记住几个设定”，而是想让 Agent 对你形成持续的工作画像。
Hermes 官方一直在讲的，不是普通意义上的 prompt memory，而是 closed learning loop。
简单理解，它希望做到：
这个方向很像把“一个会话型助手”往“长期自增益的 Agent”推进。
Hermes 文档里直接把这些能力放到了核心特性里：
cron 定时任务delegate_task 子 Agent 委派execute_code 程序化工具调用MCP 接入外部工具ACP 编辑器集成所以 Hermes 不是只想做聊天 Agent，它明显在往更完整的“工作执行层”发展。
这其实是最有意思的问题。
OpenClaw 和 Hermes 能火，并不是因为它们第一次让模型会用工具。真正的原因是：AI coding 客户端已经把“单次交互式生产力”做得足够好了，于是大家开始追问下一层需求。
这个“下一层需求”大概有五类。
Codex、Claude Code 这类工具最强的场景，还是“我现在就在这个项目里，跟你一起完成一个明确任务”。
但很多人很快会发现，自己还有另一类需求：
这类需求天然会把产品形态从“client”推向“agent runtime/gateway”。
普通 coding client 当然也会保留一些 session，但它们的主设计中心往往还是当前项目、当前任务、当前上下文窗口。
而一旦你想让系统承担长期职责，就会马上碰到这些问题：
Hermes 之所以火，很大程度上就是因为它把“长期记忆”从附属能力提升成了产品主轴。
会话式 coding 工具大多数时候都是被动的：你说一句，它做一步。
但很多真实工作更像：
这就是为什么 cron、消息渠道、always-on gateway、远程运行环境开始变得重要。
一个人对 AI 的需求，通常并不只有“写代码”这一种。
可能同时有：
OpenClaw 的多 Agent 路由，就是在解决这个问题。它不是默认所有事情都塞给同一个大脑，而是支持每个 Agent 有独立 persona、workspace、session 和权限。
随着工具越来越强，大家也越来越在意：
OpenClaw 和 Hermes 都明显踩中了这个趋势：它们都强调 self-hosted、开放技能系统、MCP、外部 provider、远程运行和可组合性。
虽然两个项目的产品定位不完全一样，但从架构上看，它们都属于比较典型的“Agent 基座系统”。
如果你想理解它们的实现，可以把它们拆成 6 层。
这层负责回答“消息从哪来”。
常见入口包括：
OpenClaw 在这层特别强，因为它本质上就是一个多渠道 Gateway。Hermes 也支持很多平台，但它的叙事重心更偏 Agent runtime 本身。
一旦入口多了，问题就不是“能不能接到消息”，而是：
OpenClaw 官方文档里对这件事写得非常细：它会按 DM、群组、频道、cron、hook 等不同来源做路由，并支持多 Agent 隔离。
这一层是为什么它不像普通聊天脚本，而像一个小型 Agent 调度系统。
Hermes 在这里尤其突出。
它把记忆拆成：
这类设计的目标，不是把所有历史都塞回 prompt，而是做“有边界的、经过筛选的长期记忆”。
这是 Agent 能否长期稳定工作的关键。
这一层通常包括：
Hermes 的工具运行时文档里明确提到，它会把工具按 toolset 组织，并对某些 Agent 级工具做特殊处理，比如 memory、todo、delegate_task。
OpenClaw 则更强调 gateway tool、skills、plugins，以及如何把这些能力通过 MCP overlay 暴露给 CLI 后端。
这层负责回答“Agent 实际跑在哪里”。
Hermes 官方强调它可以跑在：
而且支持长期运行、空闲休眠、远程环境。
OpenClaw 这边则更强调 Gateway + runtime 的组合，尤其是它可以接不同 provider 和不同 CLI backend，包括 codex-cli、claude-cli 等。
这也解释了为什么它们看上去不像单纯的桌面工具，而更像“Agent 基础设施”。
一个真正会工作的 Agent，不能只有 message in / message out。
它还需要：
Hermes 在这层特别完整，尤其是 cron、delegate_task、execute_code。OpenClaw 则更强调多入口、多会话、多 Agent 与控制 UI 的运维能力。
这是你最关心的，也是很多人最容易混淆的地方。
它们最强的地方，是你已经在代码现场：
这类任务里，Codex、Claude Code 的体验通常更直接、更轻、更顺手。
它们更适合的不是每一次 coding loop，而是这些情况：
所以更准确的理解不是“二选一”，而是：
Codex / Claude Code：面向当前任务、当前代码现场OpenClaw / Hermes：面向长期运行、跨场景自动化、个人 Agent 系统这部分最实际。
如果你现在的工作方式是：
那你完全不必为了“跟风”去上 OpenClaw 或 Hermes。
对大多数纯 coding 用户来说，短期内最好的工具依然是 Codex、Claude Code 这类直接面向代码现场的客户端。
你会开始真正需要 OpenClaw 或 Hermes，通常是出现下面这些变化时。
比如：
这时 cron + persistent agent 就很有意义。
比如：
这时 OpenClaw 这类 gateway 型系统会比单机 coding client 更合适。
比如：
这时 Hermes 那种“把长期记忆当主能力”的系统会更有价值。
比如：
这类时候，多 Agent、delegation、multi-channel 价值就出来了。
如果你只是想快速形成判断，可以先这么看。
一句话：OpenClaw 更像 Agent 网关和控制平面。
一句话：Hermes 更像一个带记忆、调度和执行能力的长期运行 Agent 本体。
如果你现在已经很习惯 Codex、Claude Code 这种工作方式，我的建议很简单：
不要一上来就问“我要不要迁移到 OpenClaw / Hermes”。
先问自己：
如果你缺的是：
那继续用 Codex、Claude Code 就对了。
如果你缺的是：
那再去看 OpenClaw、Hermes Agent，就会非常顺。
OpenClaw 和 Hermes Agent 会火，不是因为它们要取代所有 coding client，而是因为 AI Agent 正在从“当前窗口里的助手”，走向“长期运行的个人系统”。
Codex、Claude Code 代表的是一类能力：
而 OpenClaw、Hermes Agent 代表的是另一类能力：
所以最合理的理解从来不是“谁替代谁”，而是：
它们解决的是不同层级的问题。
如果你今天主要还是写代码，那 Codex、Claude Code 仍然是主力。
但如果你开始希望 AI 帮你长期盯事、主动跑事、从手机可达、跨会话记住你、甚至协调多个子 Agent，那你就会自然走到 OpenClaw 和 Hermes 这类系统面前。
到那时你会发现，它们不是“更花哨的客户端”，而是另一种完全不同的 Agent 基础设施。
如果你愿意，我下一篇还可以继续拆得更细：
OpenClaw vs Hermes vs Codex vs Claude Code 的场景对比表如何从纯 coding client 过渡到长期运行 Agent 系统 的实战指南