Intelligence dossier · 20
Agent OS、OpenClaw 与 Hermes：运行时与产品层的职责边界
Agent Runtime 负责完成一次工作，OpenClaw 与 Hermes 一类产品则组织身份、渠道、记忆和主动性；两者是分层组合，而不是替代关系。
需要，但它们和我前面说的 Agent OS 不是同一层。更准确地说，OpenClaw、Hermes 这类工具往往是在 Agent Runtime 之上做“长期运行的个人/组织级 Agent 产品层”。
你可以把关系理解成：
所以答案不是“有了 Agent OS 就不需要 OpenClaw/Hermes”，而更像：
有了 Linux，是否还需要 Chrome、Kubernetes、VS Code？
需要，因为它们解决的是更上层的问题。
OpenClaw 实际上更像“Agent 的桌面环境 + Gateway”
OpenClaw 当前自己的定位就不是单纯 coding-agent runtime，而是一个长期运行的 AI assistant。它通过一个 Gateway 把 模型、工具、session、消息渠道、设备节点连接起来，CLI、TUI、Control UI 都只是 Gateway 的客户端。它还能接 WhatsApp、Telegram、Slack、Discord、Signal、iMessage 等渠道。
也就是说，假设你已经有一个很强的：
Agent OS能做到：
它依然没有回答：
OpenClaw 更像负责：
OpenClaw 最新 README 甚至已经明确把 Codex、Claude、本地模型/agent harness 看成可替换插件，而 OpenClaw 自己负责更上层的 assistant infrastructure。
所以从架构角度，我甚至不会把：
OpenClaw ≈ Codex而会认为：
OpenClaw ≈ Agent Gateway + Personal Agent Platform
Codex ≈ Agent Runtime / Coding AgentHermes 又稍微不一样
你说的应该是 Nous Research 的 Hermes Agent。
Hermes 当前非常强调几个东西：
官方项目描述里甚至直接强调：它会从经验生成 skill、持续改进 skill、检索过去 conversation，并逐渐构建关于用户的长期模型；同时能跑在 VPS、GPU cluster 或 serverless 上，而不局限在本机。
因此 Hermes 更像：
甚至可以画成：
所以 Hermes 和一个理想化 Agent OS 的重合度，会比 OpenClaw更高一些。
真正关键的问题：什么叫“Agent OS”？
这里得修正一下我们上一轮里的比喻。
如果你把 Agent OS 定义得很窄：
那么：
OpenClaw/Hermes 当然仍然有存在意义。
因为它们承担 application/platform 层。
但如果你把 Agent OS 定义成：
那 OpenClaw / Hermes 本身其实就在往“Agent OS”方向走。
所以这里容易产生一个概念问题：
Agent OS 并不是一个已经定义清楚的标准层。
现在行业里经常把不同东西都叫 Agent OS。
我更建议用 5 层模型
以后看这些东西，会比“都是 Agent OS”更清晰：
你会发现：
Codex / Pi主要覆盖：
L2 + L3而：
OpenClaw主要在：
L4 + L5但也自己实现不少 L2/L3。
Hermes：
L2 + L3 + L4 + L5覆盖得比较全。
因此这些项目现在大量“重复造轮子”其实很正常。
为什么未来可能发生“runtime 下沉”
我认为未来比较可能出现这样的趋势：
今天：
大量重复。
未来可能变成：
也就是：
类似 Web 世界：
但我觉得 OpenClaw 这种东西不会消失
因为有一类需求不是 Agent OS 能直接解决的：
“我想拥有一个 AI”
和：
“我想运行一个 Agent”
是两个完全不同的产品需求。
后者：
agent.run(task)前者要求：
这其实涉及：
所以 OpenClaw 的核心价值实际上不只是：
Agent而是：
Persistent Agent Identity你甚至可以把三者类比成 Linux 世界
这是我觉得最好理解的一种类比：
Linux Kernel
≈
Agent Runtime / Agent OS Core负责：
然后：
Ubuntu / macOS-like environment
≈
OpenClaw负责：
然后：
一个长期陪伴你的智能助手
≈
Hermes / personal-agent product当然这个类比不是一一对应，但架构思路很好理解。
更有意思的是：OpenClaw 已经开始成为“Agent Harness 的宿主”
现在 OpenClaw 的设计里，Agent harness 本身可以成为插件。官方当前 README 就直接提到 Claude、Codex/local harness 可以替换。
也就是说：
这其实特别值得关注。
因为未来很可能不是：
OpenClaw vs Codex而是：
OpenClaw
└── CodexHermes 更像另一条路线：把 Runtime 和 Personal Agent 合起来
Hermes 当前甚至提供 OpenClaw migration，可以迁移 OpenClaw 的 persona、memory、skills、approval patterns、messaging settings 等。
这说明两者实际上已经在争夺：
Personal Agent Platform这个层。
所以：
OpenClaw vs Hermes比较成立。
而：
Codex vs OpenClaw其实没有那么成立。
一个更准确的竞争关系
我会这么画：
当然现实里各项目层次会重叠。
未来真正可能被“Agent OS”吃掉的是哪些东西？
不是 OpenClaw 这个产品本身，而是它里面那些通用基础设施代码。
例如：
这些东西未来非常可能标准化、下沉。
OpenClaw 到时候就不用自己全部维护。
于是：
今天
OpenClaw = 80% infrastructure + 20% product未来可能变成：
OpenClaw = 20% infrastructure + 80% product它真正应该专注：
这和数据库的发展特别像
早期 Web App：
后来数据库成熟了：
Postgres
RedisApp 不消失。
只是：
基础能力下沉Agent 现在还处于非常早期阶段，所以每家都在写：
几年之后其中相当一部分大概率会变成标准 runtime 能力。
所以如果你准备自己做 Agent 产品
这里有一个很重要的架构判断。
不要把全部精力放在：
自己实现一个更好的 agent loop除非你就是研究 runtime。
如果你的目标是产品：
真正应该建立差异化的是：
Runtime 最终很可能 commoditize。
用一句话总结
Codex / Pi 更像“Agent 怎么运行”；OpenClaw 更像“Agent 怎么长期活在你的数字生活里”；Hermes则试图同时解决“怎么运行”和“怎么长期认识并服务用户”。
所以即使未来真的出现成熟的 Agent OS，OpenClaw/Hermes 这类产品依然会存在，只不过它们底层大量 runtime 能力可能会被 Agent OS 吸收。
而我觉得接下来最值得继续往下聊的其实是一个更关键的问题：
“如果现在让我从零设计一个真正的 Agent OS，它和 OpenClaw、Codex、MCP、Docker、Kubernetes 到底应该怎么分层？”
这个问题一旦讲清楚，你基本就能把整个 Agent Infra 技术栈串起来。