一句话：OpenClaw 和 Hermes 都是跨平台行动 harness。真正的区别不是“谁负责行动、谁负责记忆”，而是它们分别选择了什么作为 agent runtime 的核心组织对象。
OpenClaw 的答案更像：一个自托管 gateway 后面，住着一个有 workspace、channel、device、memory 和可审计生活史的 agent。
Hermes 的答案更像：一个平台无关的 AIAgent core，通过 profile、provider、tool、plugin、gateway adapter 和 session lifecycle 组合成很多可运行形态。
Memory 差异很重要，但它不是原因，而是结果。
先纠正一个容易误导的说法
把 OpenClaw 写成“记忆层”，把 Hermes 写成“行动层”，是不准确的。OpenClaw 本身首先就是跨平台行动 harness：它的官方定位是 self-hosted gateway，把聊天应用和 channel surfaces 接到 AI coding agents；它有 Gateway、WebSocket control plane、nodes、Discord / Telegram / Slack / WhatsApp / Signal / iMessage / Feishu 等 channel adapter，也有自动化、工具调用、消息投递和会话路由。
Hermes 也不是“只有行动，没有记忆”。它有 profile 隔离、SQLite session DB、FTS session search、bounded memory、memory provider plugin、gateway adapter、cron、ACP、API server、MCP、工具注册和 provider runtime。
所以这篇文章真正应该回答的问题不是：
为什么 OpenClaw 有 daily memory，Hermes 没有？
而是：
作为两个很 opinionated 的 agent runtime，OpenClaw 和 Hermes 分别认为一个长期 agent 应该围绕什么来组织自己的身份、行动、上下文、记忆和边界？
共同点：二者都在把 LLM 变成长期可行动的 agent
OpenClaw 和 Hermes 都不是普通聊天壳。它们都在处理同一组难题：
- 如何把模型接到真实工具、文件、终端、浏览器、消息平台和自动化任务。
- 如何让不同 channel 的输入输出被路由到正确 session。
- 如何让 agent 在多轮任务、长上下文、失败重试和跨 session 历史里保持连续。
- 如何管理身份、权限、profile、workspace、credential、model provider 和工具集。
- 如何让人类能在关键位置观察、干预、审批、恢复和追责。
也就是说，二者都是行动 runtime。区别在于，它们把“行动 runtime”这件事的中心放在了不同地方。
OpenClaw 的底层理念：agent 住在 gateway 连接的 workspace 里
OpenClaw 的核心不是“记忆文件”，而是 gateway + workspace + channel/device network 组成的 agent home。
它的架构从一个长驻 Gateway 出发。这个 Gateway 拥有消息 surfaces，控制 Telegram、Discord、Slack、WhatsApp、Signal、iMessage、WebChat 等连接；CLI、macOS app、web UI、自动化和移动/桌面 nodes 都通过 WebSocket 接入。换句话说，OpenClaw 首先关心的是：一个 agent 怎样长期驻扎在某台机器或服务器上，接入你已经使用的通信和设备世界。
在这个 Gateway 后面，agent 有一个 workspace。OpenClaw 文档里说得很直白：workspace 是 agent 的 home，也是工具默认工作目录和上下文来源。AGENTS.md、SOUL.md、USER.md、TOOLS.md、IDENTITY.md、HEARTBEAT.md、memory/YYYY-MM-DD.md、MEMORY.md、skills、canvas 都是这个 home 的一部分。
这就解释了为什么 OpenClaw 会自然长出 daily memory。因为在 OpenClaw 的世界里，长期 agent 不是一个抽象函数，也不是一个只靠数据库保存 session 的服务进程，而是一个住在工作区里的行动者。它每天在哪些 channel 里被触发、用了哪些工具、产生了哪些判断、哪些经验应该被留下，都可以沉淀为 workspace 里的文件。
所以更准确的说法是：
OpenClaw 是一个 workspace-centered, gateway-native, channel-aware 的长期 agent runtime。
Memory 只是这个设计的一个表现。Daily memory、long-term memory、compaction 前 memory flush、dreaming、memory-wiki 都是在回答同一个问题：当 agent 长期住在 workspace 里，它的生活史怎样被人类和 agent 共同维护、搜索、审计和迁移？
Hermes 的底层理念：一个平台无关 core，被 profile 和 provider 系统组合起来
Hermes 的中心不是 workspace home，而是 AIAgent core + profile isolation + provider/tool/plugin lifecycle。
Hermes 文档把系统结构画得很清楚：CLI、Gateway、ACP、Batch Runner、API Server、Python Library 都进入同一个 AIAgent。平台差异主要放在 entry point 和 gateway adapter，而不是把每个平台都做成一套不同 agent。这个 core 负责 prompt assembly、provider resolution、tool dispatch、compression、fallback、session persistence、memory flush。
Hermes 另一个关键对象是 profile。一个 profile 就是一套独立的 HERMES_HOME：config、.env、SOUL.md、memory、sessions、skills、cron jobs、gateway state 都在里面。多个 profile 可以并行运行，每个 profile 可以有自己的 gateway、bot token、模型配置、工具配置和记忆。
这带来一种很强的 runtime 工程气质：Hermes 更关心“如何把同一个 agent core 复用到 CLI、gateway、ACP、batch、API server、cron、subagent、provider plugin 这些入口里”，并且让状态边界足够清晰。它通过 provider resolver 支持不同模型 API mode，通过 tool registry 管理大量工具，通过 memory provider plugin 接入 Honcho、Mem0 等外部记忆系统，通过 SQLite session DB 和 FTS 搜索保存历史。
所以更准确的说法是：
Hermes 是一个 profile-isolated, provider-pluggable, platform-agnostic 的 agent execution runtime。
Memory 在 Hermes 里也不是没有，而是被纳入 prompt stability 和 runtime lifecycle：内置 MEMORY.md / USER.md 很小，作为 frozen snapshot 注入 system prompt；完整历史进 SQLite session DB；更复杂的长期建模交给 memory provider；compression、session end、pre-compress 等阶段触发 flush 或 extraction。
为什么 memory 机制会不同
现在再回到最初的问题：为什么 Hermes 有 memory，却没有像 OpenClaw 那样稳定的每日记忆文档机制？
答案不是“Hermes 不重视记忆”，而是两者默认的 state substrate 不同。
OpenClaw 把 agent 的连续性放进 workspace home。既然 workspace 是 agent 的家，那么 memory/YYYY-MM-DD.md 就很自然：今天发生的事情先进入日记，稳定判断再提升到 MEMORY.md，再进一步可以被 memory-wiki 编译成有 provenance、claim、freshness 和 dashboard 的知识层。这个路径强调可读、可改、可迁移、可人工巡检。
Hermes 把 agent 的连续性放进 profile runtime。profile 是状态边界，session DB 是历史底座，system prompt 要保持稳定，provider lifecycle 负责更复杂的长期召回。它不默认生成每日 Markdown，是因为它没有把“日期文件组成的生活史”设为内置 state substrate。它更倾向于：关键事实少量注入，完整历史按需搜索，深层记忆交给 provider。
这也是为什么 OpenClaw 的 memory 看起来更像“生活史文件系统”，Hermes 的 memory 看起来更像“受控 runtime context”。但这只能作为一个症状来讲，不能倒过来把 OpenClaw 定义成记忆层。
一张表看懂底层取舍
| 维度 | OpenClaw | Hermes |
|---|---|---|
| 核心组织对象 | Gateway 后面的 agent workspace / home | AIAgent core + profile |
| 行动入口 | 自托管 Gateway 连接 chat apps、control plane、nodes、automation | CLI、Gateway、ACP、Batch、API Server、Python Library 共用 core |
| 状态边界 | workspace 文件 + ~/.openclaw config/session/credentials | HERMES_HOME profile：config、env、memory、sessions、skills、cron、gateway state |
| 平台观 | channel/device/network 是 agent 生活场的一部分 | platform adapter 是同一 core 的入口和投递层 |
| 记忆观 | workspace-first：daily notes、long-term memory、dreaming、memory-wiki | runtime-first：bounded memory、frozen prompt snapshot、session DB、provider lifecycle |
| 优势 | 可审计、可迁移、适合长期驻扎和人类共同维护 agent state | 可组合、可扩展、profile 清晰、provider/tool/plugin 生态强 |
| 主要风险 | workspace discipline 不好时，文件层会膨胀或混乱 | state 太 runtime 化时，人类不一定能直接看到“生活史” |
这张表比“谁有 memory”更重要。因为它回答的是：这套 runtime 认为 agent 的真实存在边界在哪里。
放到更大的 agent 图景里
Cursor、Codex、Claude Code、opencode、OpenClaw、Hermes 并不是同一个层级的工具。
Cursor 更像 IDE 内的人机共写环境。它的连续性来自当前文件、编辑器状态、代码索引和开发者即时意图。
Codex、Claude Code、opencode 更像工程任务执行 harness。它们的世界中心是 repo、terminal、diff、test、PR、sandbox、approval 和可验证交付。
OpenClaw 和 Hermes 更靠近长期 agent runtime：它们关心的不只是一次 repo 修改，而是一个 agent 如何跨 channel、session、profile、memory、tool、automation 和人类协作现场长期存在。
但 OpenClaw 和 Hermes 的答案也不同：
- OpenClaw 更像“把 agent 安置到一个有工作区、有设备、有通道、有生活史的自托管环境里”。
- Hermes 更像“把一个强 agent core 做成可复用、可 profile 化、可 provider 化、可跨入口运行的执行系统”。
对 WeHub 的启发
如果用这篇文章来指导 WeHub，不应该得出“OpenClaw 负责记忆，Hermes 负责行动”的粗糙结论。那会把 OpenClaw 的行动 harness 属性写丢，也会低估 Hermes 的记忆和 session 系统。
更好的判断是：
- 当我们需要一个 agent 长期驻扎在某个 host / workspace / channel network 中，并且希望人类能看到、修订、审计它的生活史时，OpenClaw 的 worldview 更贴。
- 当我们需要很多 profile worker、不同 provider、不同工具后端、不同入口形态，并且希望核心执行逻辑高度复用时，Hermes 的 worldview 更贴。
二者都能行动，也都能记忆。真正的架构问题是：某一类状态应该成为 workspace 里可审计的文件，还是 profile runtime 里受控注入、搜索和 provider lifecycle 的一部分？
结尾
OpenClaw 和 Hermes 的区别，不是“一个有 memory，一个没有 memory”，也不是“一个负责记忆，一个负责行动”。它们都是 opinionated agent runtime，只是对 agent 的存在边界有不同想象。
OpenClaw 更相信：长期 agent 应该住在一个由 Gateway 连接起来的 workspace home 里。通道、设备、文件、记忆和人类审计共同构成它的生活场。
Hermes 更相信：长期 agent 应该由一个平台无关 core 驱动，通过 profile、provider、tool、plugin、session 和 gateway adapter 组合成不同运行形态。稳定 prompt、清晰 profile 和可替换 provider 是它的工程骨架。
Memory 是理解这个差异的好切口，但不是全部。真正要看的，是两套 runtime 怎样回答同一个底层问题：
一个 agent 要长期存在并持续行动，它的身份、上下文、记忆和边界，到底应该落在哪里？
资料口径
本文是 2026-06-17 的机制切片，不是永久定义。框架更新很快，发布后仍需要随 release notes 修订。
- OpenClaw overview：self-hosted gateway，连接 chat apps 和 channel surfaces 到 AI coding agents。
- OpenClaw Gateway architecture：长驻 Gateway、WebSocket control plane、nodes、messaging surfaces。
- OpenClaw Agent runtime：embedded agent runtime、workspace bootstrap、session store。
- OpenClaw Agent workspace：workspace 是 agent home，包含 bootstrap files、daily memory、long-term memory、skills、canvas。
- OpenClaw Memory overview：Markdown memory、daily notes、memory search、memory-wiki、memory flush、dreaming。
- Hermes Architecture：AIAgent core、CLI/Gateway/ACP/Batch/API entry points、tool registry、session storage、plugin system。
- Hermes Profiles：
HERMES_HOMEprofile boundary、profile-specific config、memory、sessions、skills、cron、gateway state。 - Hermes Gateway Internals：20+ platform adapters、session routing、delivery、authorization。
- Hermes Persistent Memory：bounded memory、frozen snapshot、session search、memory providers。
- Hermes Prompt Assembly：cached system prompt layers、memory snapshots、context files、prompt stability。