OpenClaw 和 Hermes Agent 到底是什么？为什么会火？它们和 Codex、Claude Code 的分工是什么？

这两个月，如果你一直在关注 AI Agent 圈子，大概率会反复看到两个名字：OpenClaw 和 Hermes Agent。

很多人第一次看到它们时都会有一种困惑：

我已经在用 Codex、Claude Code 这种客户端了
我平时的核心需求就是写代码、改代码、跑命令
那为什么还会冒出来 OpenClaw、Hermes 这种看起来更“重”的东西？
它们到底解决了什么新问题？

这篇文章我想把这件事讲透，重点回答四个问题：

OpenClaw 和 Hermes Agent 分别是什么
它们为什么会在这个时间点突然变火
它们底层大概是怎么实现的
如果你已经在用 Codex、Claude Code，到底什么时候才需要它们

一、先说结论：它们不是“更强的 Claude Code”，而是另一类产品

先把最重要的一句话放前面：

OpenClaw 和 Hermes Agent，严格来说都不只是“写代码助手”。它们更接近“长期运行的、自带工具和记忆的个人/团队 Agent 基座”。

这和 Codex、Claude Code 的产品心智不太一样。

像 Codex、Claude Code 这类工具，核心体验通常是：

你人在终端或编辑器里
你有一个明确任务
你和模型高频来回交互
模型围绕当前项目上下文工作
任务完成后，这一轮会话就差不多结束了

而 OpenClaw、Hermes Agent 更像什么？

它们更像：

一个长期在线的 Agent
可以从 Telegram、Slack、WhatsApp、Discord、Web UI 等多个入口被你唤起
可以自己记住你、记住项目、记住长期任务
可以定时执行任务、调用工具、跨会话延续上下文
可以在服务器、VPS、容器、远程机器上持续运行，而不是只活在你当前这个终端窗口里

所以它们火起来，不是因为大家突然不需要 Codex、Claude Code 了，而是因为越来越多人开始需要另一层能力：

不是“让模型帮我写代码”，而是“让 Agent 长期替我盯事、跑事、接消息、调工具、跨场景工作”。

二、OpenClaw 是什么？

从官方文档看，OpenClaw 的定位非常明确：它是一个 self-hosted gateway，也就是“自托管的 Agent 网关”。

它的核心思路不是“做一个新的聊天框”，而是：

你在自己的机器或服务器上跑一个 Gateway 进程
这个 Gateway 连上 Telegram、Slack、Discord、WhatsApp、iMessage、WebChat 等渠道
它把这些渠道收到的消息，路由给背后的 Agent runtime
然后再把 Agent 的回复发回去

官方文档里强调了几个点：

它是 self-hosted 的，数据和运行权在你手里
它是 multi-channel 的，一个 Gateway 能接多个聊天入口
它是 agent-native 的，默认就围绕 session、memory、routing、tool use 设计
它支持 multi-agent routing，也就是一个网关下面跑多个隔离 Agent

换句话说，OpenClaw 更像一个“Agent 操作系统的网关层”。

你可以把 OpenClaw 想成什么？

如果一定要打个比方，OpenClaw 很像：

消息入口层
Agent 路由层
长期在线的控制平面

它最适合的不是“我今天要改一个函数”，而是这种需求：

我想在手机上随时给 AI 发消息，让它帮我处理事情
我想把 Telegram、Discord、Slack 全接进同一个 Agent 系统
我想让不同 Agent 负责不同角色，比如 coding、research、personal assistant
我想让一个 Agent 持续在远程环境里工作，而不是只在我当前电脑上开一会儿

OpenClaw 官方能力里最关键的部分

从官方站点和文档来看，OpenClaw 有几个特别关键的能力：

多渠道接入：一个 Gateway 同时服务多个聊天平台
多 Agent 路由：每个 Agent 有独立 workspace、session store、配置和 persona
浏览器、执行、搜索、媒体能力：不只是聊天，而是能动手做事
技能和插件系统：可以挂接 Skills、Plugins、外部集成
移动节点和 Control UI：不只是终端，还能从 Web 和移动端控制
和现有 coding runtime 集成：官方文档里明确提到可以把 Gateway 工具通过 MCP overlay 暴露给 codex-cli、claude-cli 等后端

这一点非常重要。

OpenClaw 本质上不是来替代 Codex/Claude 的模型能力，而是把它们包装进一个“长期在线、跨渠道、可路由、可编排”的 Agent 外壳里。

三、Hermes Agent 是什么？

如果说 OpenClaw 更偏“网关和控制平面”，那 Hermes Agent 更偏“Agent runtime 本体”。

根据 Nous Research 的官方介绍，Hermes Agent 的核心卖点不是“我能接多少聊天平台”，而是：

我是一个会持续学习、会积累记忆、会自我生成技能的长期运行 Agent。

官方首页反复强调了几个关键词：

self-improving
learning loop
persistent memory
skills
cron
delegation
MCP

这说明 Hermes 的重点不只是“能不能调用工具”，而是“这个 Agent 能不能随着时间推移变得更像一个持续工作的系统”。

Hermes 最有辨识度的地方是什么？

我觉得 Hermes 和其他 Agent 框架相比，最有辨识度的有三点。

1. 它非常强调长期记忆

Hermes 官方文档里把记忆分成两层：

MEMORY.md：环境事实、项目习惯、工作经验
USER.md：用户偏好、沟通方式、习惯与要求

而且这些记忆会跨会话持久化，不是一次聊天结束就全没了。

在此基础上，Hermes 还支持一个叫 Honcho 的 memory backend。官方文档的描述非常明确：它不是简单 key-value 存储，而是尝试去维护一个“用户模型”，包括偏好、风格、目标和行为模式。

这意味着 Hermes 的目标不是“记住几个设定”，而是想让 Agent 对你形成持续的工作画像。

2. 它非常强调学习闭环

Hermes 官方一直在讲的，不是普通意义上的 prompt memory，而是 closed learning loop。

简单理解，它希望做到：

每次任务不是做完就算了
有些经验会沉淀成 memory
有些流程会沉淀成 skill
skill 还可以在后续使用中继续改进

这个方向很像把“一个会话型助手”往“长期自增益的 Agent”推进。

3. 它非常强调自动化和并行工作

Hermes 文档里直接把这些能力放到了核心特性里：

cron 定时任务
delegate_task 子 Agent 委派
execute_code 程序化工具调用
MCP 接入外部工具
ACP 编辑器集成

所以 Hermes 不是只想做聊天 Agent，它明显在往更完整的“工作执行层”发展。

四、为什么它们会在这个时间点火起来？

这其实是最有意思的问题。

OpenClaw 和 Hermes 能火，并不是因为它们第一次让模型会用工具。真正的原因是：AI coding 客户端已经把“单次交互式生产力”做得足够好了，于是大家开始追问下一层需求。

这个“下一层需求”大概有五类。

1. 用户不再满足于“当前窗口里帮我一下”

Codex、Claude Code 这类工具最强的场景，还是“我现在就在这个项目里，跟你一起完成一个明确任务”。

但很多人很快会发现，自己还有另一类需求：

我不在电脑旁，但想让 Agent 继续跑事
我想在手机上给 Agent 发一句话，它就去远程机器上执行
我想让它每天固定时间做巡检、做汇总、做提醒
我想让它像一个长期助手，而不是一次性对话器

这类需求天然会把产品形态从“client”推向“agent runtime/gateway”。

2. 大家开始真正需要跨会话连续性

普通 coding client 当然也会保留一些 session，但它们的主设计中心往往还是当前项目、当前任务、当前上下文窗口。

而一旦你想让系统承担长期职责，就会马上碰到这些问题：

它记不记得我是谁
它记不记得这个项目的长期约定
它记不记得上周我们为什么这么设计
它能不能根据历史经验少走弯路

Hermes 之所以火，很大程度上就是因为它把“长期记忆”从附属能力提升成了产品主轴。

3. 大家开始需要“主动工作”，而不只是“被动应答”

会话式 coding 工具大多数时候都是被动的：你说一句，它做一步。

但很多真实工作更像：

每天巡检线上状态
跟进某个 PR 有没有新评论
定时抓取一个竞品页面
监控某个数据波动
到点自动发日报

这就是为什么 cron、消息渠道、always-on gateway、远程运行环境开始变得重要。

4. 大家开始需要多入口和多 Agent 结构

一个人对 AI 的需求，通常并不只有“写代码”这一种。

可能同时有：

一个 coding agent
一个 research agent
一个 personal assistant
一个 ops / monitoring agent

OpenClaw 的多 Agent 路由，就是在解决这个问题。它不是默认所有事情都塞给同一个大脑，而是支持每个 Agent 有独立 persona、workspace、session 和权限。

5. 大家开始在意主权和可组合性

随着工具越来越强，大家也越来越在意：

数据是不是在我手里
能不能自己选模型
能不能接自己的 MCP 工具
能不能跑在自己的机器、容器、VPS 上
能不能自己改技能、改路由、改权限

OpenClaw 和 Hermes 都明显踩中了这个趋势：它们都强调 self-hosted、开放技能系统、MCP、外部 provider、远程运行和可组合性。

五、它们底层大概是怎么实现的？

虽然两个项目的产品定位不完全一样，但从架构上看，它们都属于比较典型的“Agent 基座系统”。

如果你想理解它们的实现，可以把它们拆成 6 层。

1. 入口层：用户从哪里唤起 Agent

这层负责回答“消息从哪来”。

常见入口包括：

CLI
Web UI
Telegram
Slack
Discord
WhatsApp
Email
编辑器集成

OpenClaw 在这层特别强，因为它本质上就是一个多渠道 Gateway。Hermes 也支持很多平台，但它的叙事重心更偏 Agent runtime 本身。

2. 会话与路由层：这条消息该交给谁

一旦入口多了，问题就不是“能不能接到消息”，而是：

这条消息属于哪个 session
属于哪个 user
属于哪个 agent
是直接复用老上下文，还是新开一个任务

OpenClaw 官方文档里对这件事写得非常细：它会按 DM、群组、频道、cron、hook 等不同来源做路由，并支持多 Agent 隔离。

这一层是为什么它不像普通聊天脚本，而像一个小型 Agent 调度系统。

3. 记忆层：如何让 Agent 不只是“本轮聪明”

Hermes 在这里尤其突出。

它把记忆拆成：

用户画像
环境/项目事实
会话搜索与跨会话回忆
技能沉淀
更深层的 user modeling

这类设计的目标，不是把所有历史都塞回 prompt，而是做“有边界的、经过筛选的长期记忆”。

这是 Agent 能否长期稳定工作的关键。

4. 工具层：让模型真的能做事

这一层通常包括：

文件读写
shell/terminal
浏览器操作
搜索与网页提取
图片、音频、文档处理
MCP server 调用
消息发送
调度与系统操作

Hermes 的工具运行时文档里明确提到，它会把工具按 toolset 组织，并对某些 Agent 级工具做特殊处理，比如 memory、todo、delegate_task。

OpenClaw 则更强调 gateway tool、skills、plugins，以及如何把这些能力通过 MCP overlay 暴露给 CLI 后端。

5. 执行层：模型如何真正跑起来

这层负责回答“Agent 实际跑在哪里”。

Hermes 官方强调它可以跑在：

local
Docker
SSH
Daytona
Singularity
Modal

而且支持长期运行、空闲休眠、远程环境。

OpenClaw 这边则更强调 Gateway + runtime 的组合，尤其是它可以接不同 provider 和不同 CLI backend，包括 codex-cli、claude-cli 等。

这也解释了为什么它们看上去不像单纯的桌面工具，而更像“Agent 基础设施”。

6. 自动化层：让 Agent 不是只会聊天

一个真正会工作的 Agent，不能只有 message in / message out。

它还需要：

cron
子 Agent 并行
程序化工具调用
技能复用
失败恢复
provider fallback
权限和审批机制

Hermes 在这层特别完整，尤其是 cron、delegate_task、execute_code。OpenClaw 则更强调多入口、多会话、多 Agent 与控制 UI 的运维能力。

六、那它们和 Codex、Claude Code 到底是什么关系？

这是你最关心的，也是很多人最容易混淆的地方。

1. Codex / Claude Code 更像“交互式 coding worker”

它们最强的地方，是你已经在代码现场：

你在终端里
你在仓库里
你有明确改动目标
你要快速看代码、改代码、跑命令、修问题

这类任务里，Codex、Claude Code 的体验通常更直接、更轻、更顺手。

2. OpenClaw / Hermes 更像“长期运行的 Agent 基座”

它们更适合的不是每一次 coding loop，而是这些情况：

你想让 AI 常驻在线
你想从手机、IM、Web 随时唤起它
你想让它定时工作
你想让它跨会话记住你
你想让不同 Agent 承担不同职责
你想让它调度 coding agent，而不是替代 coding agent

所以更准确的理解不是“二选一”，而是：

Codex / Claude Code：面向当前任务、当前代码现场
OpenClaw / Hermes：面向长期运行、跨场景自动化、个人 Agent 系统

七、如果我现在主要直接用 Codex、Claude Code，什么时候才需要它们？

这部分最实际。

如果你现在的工作方式是：

打开项目
在终端里和 Agent 一起改代码
有问题就问，改完就结束

那你完全不必为了“跟风”去上 OpenClaw 或 Hermes。

对大多数纯 coding 用户来说，短期内最好的工具依然是 Codex、Claude Code 这类直接面向代码现场的客户端。

你会开始真正需要 OpenClaw 或 Hermes，通常是出现下面这些变化时。

1. 你希望 Agent 离开当前终端还能继续工作

比如：

帮你持续盯日志
定时巡检服务状态
定期抓网页、整理信息、发日报
晚上自动跑一轮检查，第二天给你总结

这时 cron + persistent agent 就很有意义。

2. 你希望从手机或聊天软件直接驱动 Agent

比如：

在 Telegram 上发一句“帮我看下 staging 挂了没有”
在 Slack 里让它总结某个 issue thread
在 WhatsApp 上让它去远程机器跑一段流程

这时 OpenClaw 这类 gateway 型系统会比单机 coding client 更合适。

3. 你希望 Agent 记住长期偏好和项目约定

比如：

你总是偏好某种代码风格
某个项目有长期约束
某些部署步骤和运行细节不想每次重讲

这时 Hermes 那种“把长期记忆当主能力”的系统会更有价值。

4. 你希望它不只是写代码，而是作为工作编排器

比如：

一边查资料，一边写周报
一边看 PR，一边盯线上状态
一个 Agent 研究，另一个 Agent 编码，第三个 Agent 通知结果

这类时候，多 Agent、delegation、multi-channel 价值就出来了。

八、怎么选：OpenClaw 还是 Hermes？

如果你只是想快速形成判断，可以先这么看。

更适合看 OpenClaw 的人

你特别看重 Telegram / Slack / WhatsApp / Discord 这些聊天入口
你想做一个长期在线、随时可 message 的个人 AI
你想把多个 Agent、多个渠道、多个 runtime 挂到同一个控制平面
你已经有 Codex / Claude 这类 coding agent，想把它们接进更大的系统里

一句话：OpenClaw 更像 Agent 网关和控制平面。

更适合看 Hermes Agent 的人

你更关心长期记忆、学习闭环、技能沉淀
你想让 Agent 具备定时任务、子 Agent 委派、程序化工具调用
你想让它既能做个人助手，也能做研究/自动化/工作流执行器
你需要一个“长期运行的 Agent runtime”，而不只是消息网关

一句话：Hermes 更像一个带记忆、调度和执行能力的长期运行 Agent 本体。

九、我自己的建议：别急着迁移，先确认你缺的到底是哪一层

如果你现在已经很习惯 Codex、Claude Code 这种工作方式，我的建议很简单：

不要一上来就问“我要不要迁移到 OpenClaw / Hermes”。

先问自己：

我缺的是 coding 能力，还是长期运行能力？
我缺的是更强的代码编辑体验，还是跨渠道触达？
我缺的是当前任务效率，还是长期记忆和自动化？
我缺的是一个更好的 client，还是一个 Agent 系统？

如果你缺的是：

代码现场协作效率
本地仓库理解能力
快速改代码、跑命令、修 bug

那继续用 Codex、Claude Code 就对了。