如果你今天还在用一张“支持多少平台、接了多少模型、会不会写代码”的功能表，去给 Agent 基础设施打分，那你其实已经错过了真正的战场。

2024 年和 2025 年，行业里最流行的误解，是把一切带 tool call 的产品都叫作 Agent；2026 年，这种误解正在变得更加昂贵。因为真正决定 Agent 上限的，早就不再是它能不能调一个 Shell、会不会写一段 CRUD，也不是它能否把 Telegram 和 Discord 接起来。真正决定上限的，是四件更深的事情：入口由谁掌控、记忆如何沉淀、执行环境能否迁移、经验能否转化为长期能力。

截至 今日，当我重新核对 OpenClaw 官方文档 与 Hermes Agent 官方文档 之后，我越来越确信：OpenClaw 和 Hermes 之所以值得被放在一起写，不是因为它们“长得像”，而是因为它们代表了两条已经清晰分叉的基础设施路线。

OpenClaw 更像一套以 消息入口、网关控制、本地主权、多平台代理接入与工作空间编排 为中心的 Agent 操作底座。它首先回答的是：消息从哪里进来，命令如何路由，哪些设备能力可以开放，哪些物理边界必须锁死。

而 Hermes 则把更大的赌注押在 学习闭环、持久记忆、技能生成、运行时迁移与长期能力演化 上。它首先回答的是：这个 Agent 如何越用越懂你，如何把一次次会话沉淀成可复用技能，如何在不同环境中继续工作，而不是每次都从零开始。

所以，这篇文章不是测评，不是安装指南，也不是“谁更强”的饭圈式站队。它真正要辨析的，是一个更根本的问题：

在 Agent 时代，你究竟需要一个可控的网关，还是一个会成长的系统？你争取的到底是入口主权，还是学习主权？

一、Agent 时代真正开始分叉了

今天很多人一提到 Agent，脑子里浮现的依然是一个聊天框，再外加几个工具按钮。这个认知并不完全错，但它只覆盖了最浅的一层。那一层的重点是“会不会执行”；而基础设施真正关心的，是“执行发生在什么边界内、由什么历史驱动、能否被持续治理”。

为什么我说 2026 年以后，Agent 工具链的竞争已经不再是“会不会调工具”，而是“谁来掌控入口、记忆、执行环境与长期演化”？原因很简单。工具调用这件事，已经越来越像云时代的 HTTP 请求能力，迟早会变成标配。真正稀缺的，不是一个 Agent 能不能把命令发出去，而是：

• 它从哪里接收到任务；
• 它能记住多久；
• 它的经验能否在下一次调用时继续生效；
• 它能不能离开你的这台笔记本，在更稳定、更隔离、更适合长期运行的环境里持续工作；
• 它的“人格”“规则”“技能”“上下文资产”是否可迁移、可审计、可治理。

事情已经变了。我们讨论的重点，已经从“让模型动起来”，转向“让系统长出来”。

这也是为什么我越来越反感一种极其偷懒的比较方式：把不同层级的产品全部塞进同一个表格里，左边写“支持 Telegram/Discord”，右边写“支持记忆/自动化/子代理”，最后得出一个“功能更多所以更强”的结论。这样的比较，和拿 NAS、Kubernetes、消息中间件与协同办公软件做横向评分没有本质区别，表面上都沾边，实际上根本不在同一个战略层面。

OpenClaw 和 Hermes 的真正价值，不在于它们都能接平台、调模型、写文件，而在于它们分别选择了不同的“中心”。一个把中心建在 Gateway 上，一个把中心建在 Learning Loop 上。一个更关心系统如何接住现实世界的消息流与设备边界，一个更关心系统如何在时间中形成自我连续性。

这不是小差异。这是系统人格的分水岭。

如果一个产品从诞生之初就把“消息入口与平台治理”放在第一位，那么它后续的一切设计，包括工作空间隔离、节点能力声明、配对机制、权限裁剪、命令队列，都会围绕“控制平面”展开。

如果一个产品从诞生之初就把“记忆、技能、长期成长”放在第一位，那么它后续的一切设计，包括 bounded memory、session search、skill improvement、subagent delegation、remote backends、scheduled automation，都会围绕“持续性”展开。

你看，分叉其实不是从“支持什么功能”开始的，而是从“系统首先害怕失去什么”开始的。

OpenClaw 害怕失去的是入口、边界与主权。

Hermes 害怕失去的是连续性、经验与成长。

这就是我们后面所有分析的底盘。

二、为什么 Hermes 和 OpenClaw 值得被放在一起比较

有些比较从一开始就不成立。比如把一个 IDE 内补全插件，和一个自托管消息网关放在一起打分，通常只会得出空洞结论。但 Hermes 与 OpenClaw 不一样，它们之间不仅有可比性，甚至还带着一丝明确的“谱系关系”。

先看 OpenClaw。截至 4 月 22 日，我核对的 OpenClaw Gateway Architecture 文档非常明确：它的核心是一个单一、长期运行的 Gateway。所有消息 surface 都归 Gateway 所有，Gateway 通过 WebSocket 与 clients、nodes 建立连接，默认控制平面监听在 127.0.0.1:18789。文档甚至强调，每台主机只应有一个 Gateway，它不仅是控制平面的枢纽，也是某些平台会话唯一的持有者。

这说明什么？说明 OpenClaw 从来就不是一个“会聊天的壳子”。它是把 Agent 放进可治理的消息与执行基础设施里来理解的。平台入口、身份绑定、工作区路由、节点能力声明、配对审批、队列调度，这些不是旁枝末节，而是主干。

再看 Hermes。截至同一天，我核对的 Hermes Agent 文档首页 与 Features Overview 的表述相当明确：Hermes 把自己定义成一个“会自我改进的 agent”，重点落在闭环学习、技能生成、长期记忆、子代理协作、远程终端后端、自动化调度与多平台接入。它不是一个只靠“当下上下文”过日子的聊天机器人，而是试图让每次成功与失败都在后续行为中留下痕迹。

如果只是这样，二者还可以被理解为“同赛道里的不同风格”。但真正让我确认这篇文章值得写下去的，是 Hermes 官方提供的 Migrate from OpenClaw 指南。

这件事的意义非常大。

一个项目愿意专门提供另一个项目的迁移路径，通常说明三件事：

1. 它认为对方用户与自己目标用户高度重叠；
2. 它认为对方沉淀下来的资产值得继承，而不是必须抛弃；
3. 它不只是想做“新工具”，而是想接管一段既有工作流和心智模型。

而 Hermes 的迁移指南，恰恰就暴露了这种野心。它不仅尝试接住 SOUL.md、AGENTS.md、MEMORY.md、skills、providers、approval mode、gateway tokens、MCP servers，甚至连 session reset 策略、消息平台配置、环境变量映射都要一起带走。它并不是只想把你“拉新”，而是想把你在 OpenClaw 里已经形成的行为资产一起吞进来。

所以，Hermes 与 OpenClaw 不是两个毫无关系的并列名词，它们更像是同一问题上的两种答案：

• 如果你首先把 Agent 当作一个需要严控入口和边界的控制系统，你会更容易走向 OpenClaw；
• 如果你首先把 Agent 当作一个需要持续积累与进化的长期系统，你会更容易走向 Hermes。

它们之所以值得比较，不是因为功能重叠，而是因为它们都在争夺“Agent 基础设施”的定义权。

三、先拆 OpenClaw：它本质上是一台 Agent 网关，而不是单纯聊天壳子

我在之前的两篇 OpenClaw 文章里，已经用过比较重的措辞去形容它：数字领地、代理操作系统、物理隔离、多平台代理枢纽。今天重新回头看，我依然认为这种判断大体成立，但我更愿意把它说得再精准一点：

OpenClaw 首先是一台 Gateway-first 的 Agent 控制平面。

很多人一看到它能接 Telegram、Discord、Slack、Signal、WhatsApp，以及 Matrix、Feishu、Microsoft Teams 这类扩展渠道，就会本能地把它归类成“高级聊天桥接器”。这其实低估了它。平台接入只是你肉眼最容易看到的一层，真正有分量的，是它围绕 Gateway 建立起来的那整套治理逻辑。

根据 Gateway Architecture 与 Agent Runtime 的设计，OpenClaw 把系统拆成了几个非常鲜明的角色：

• Gateway：长期运行的中心进程，持有消息 surface、会话状态、路由能力与部分平台专属连接；
• Clients：通过 WebSocket 连入 Gateway 的界面或交互端；
• Nodes：也通过 WebSocket 接入 Gateway，但它们不是 UI，而是带着显式能力声明的执行节点；
• Workspace / Session / Agent 配置：决定消息如何落到不同上下文、不同规则与不同运行边界。

这意味着，在 OpenClaw 的世界观里，“Agent”从来不是一个抽象人格，而是一套被放进消息入口、工作空间、权限声明、节点能力与路由规则中的可执行实体。

更具体一点说，OpenClaw 的运行时并不是一团漂浮的“多代理幻觉”。文档里写得很明白：它有一个嵌入式 agent runtime，而 channels、sessions、routing、nodes、bootstrap files 与 tools 决定了这个 runtime 在什么边界内工作。也正因为如此，它给人的感觉才更像控制平面，而不是一串随手堆起来的 prompt。

这很重要。因为一旦你把问题定义成“控制平面”，很多原本会被聊天产品忽视的东西，就会一下子变成头等大事。

1. 入口统一不是锦上添花，而是系统的第一性原则

OpenClaw 的官方设计把“统一消息入口”放在极高的位置。你可以把 Telegram、Discord、Slack、WhatsApp、Signal 这类外部平台理解成不同国家的港口，而 Gateway 就像一个中央海关。所有船都可以来，但不是直接闯进仓库，而是先经过主权边界、身份验证、路由判断、会话归属、节点能力裁剪，最后再进入具体工作空间。

这就是为什么 OpenClaw 的很多“繁琐配置”其实不是负担，而是这种世界观的自然结果。比如：

• 某些平台需要配对审批，而不是 token 一贴就自动放行；
• 某些账号需要群组白名单或明确 mention 才能触发；
• 某些设备能力必须在节点层做 deny commands；
• 某些工作区必须物理隔离，避免上下文污染；
• 某些自动回复需要进队列，不能并发乱闯。

如果你只是把 Agent 当作一个“更聪明的聊天机器人”，这些设计会显得很重；但如果你把它当作一个真实连接多平台、多设备、多工作空间、多模型提供商的执行中枢，这些设计才像它该有的样子。

2. 127.0.0.1:18789 背后的，不只是一个端口

我一直很喜欢 OpenClaw 文档对默认控制平面的处理方式。它把核心监听收敛到 127.0.0.1:18789，强调 loopback、本地优先、必要时通过 Tailscale 或 SSH tunnel 暴露。这并不花哨，却极其说明问题。

因为这意味着它默认把 Agent 视作需要先守住本机边界的系统，而不是天然开放在公网的服务。

这背后的思想其实很朴素：如果一个系统可以执行命令、读写文件、连接设备、代你回应外部消息，那它首先应该被看作“高权限基础设施”，而不是“会话产品”。一旦这样理解，端口绑定、令牌认证、节点 capability 声明、命令黑名单、会话范围隔离，就都不是次要细节，而是主权设计的一部分。

3. 节点能力声明，让“执行”从黑箱变成了协商

很多所谓 Agent 工具，表面上也能执行 Shell、读写文件、操作浏览器，但这些能力往往是隐式的，甚至有点“工具一开，听天由命”的味道。OpenClaw 对 nodes 的处理更接近工程世界里的资源协商：节点通过 WebSocket 连入 Gateway，并带着自己的能力、命令支持范围、执行环境特征参与系统。

这件事有两个意义。

第一，它让执行权从“模型想干什么”退回到“节点允许什么”。这看似保守，实则成熟。

第二，它把多机、多环境、多能力层级的调度问题，从“提示词技巧”变成了显式架构问题。你的某个节点可以只负责安全地执行 Shell，另一个节点可以负责受限的浏览器访问，再一个节点可以挂在更高算力机器上提供重推理。这样一来，Agent 不再只是一个人格，它背后是一张可编排的能力网络。

4. SOUL、Workspace 与会话边界，构成了 OpenClaw 的性格骨架

我之前写 OpenClaw 的时候，尤其强调过 SOUL.md 的价值。今天回头看，我依然觉得这是 OpenClaw 最容易被忽视、却非常关键的一点。

在很多工具里，“人格设定”只是 system prompt 的另一种包装；而在 OpenClaw 体系里，SOUL.md、AGENTS.md、USER.md、工作区规则、会话边界、memory 文件与 skills 之间，形成了一个更接近操作约束 + 性格约束 + 项目约束的组合体。官方 system prompt 文档甚至把这些文件明确列成 bootstrap context 的一部分，这就意味着它们不是边角配置，而是行为面的骨架。

这套设计的妙处在于，它默认承认了一件事实：Agent 的“个性”不是一句 prompt 能讲完的，它需要和工作空间、权限边界、长期记忆共同构成一个稳定的行为面。

这也是为什么我会把 OpenClaw 视作“数字领地底座”而不是玩具 bot。它的重点从来不是一句话生成得多漂亮，而是你能否在一个统一入口上，把多个平台、多个工作区、多个角色、多个能力节点收编进同一治理框架。

5. OpenClaw 的内核焦虑，是失去控制

理解一个系统最好的方式，不是看它宣传什么，而是看它最怕什么。

OpenClaw 最怕什么？

它最怕的是：

• 入口失控；
• 平台混乱；
• 会话串线；
• 节点越权；
• 设备能力被提示词注入滥用；
• 多代理互相污染；
• 外部消息直接顶到执行层。

所以它做出来的一切都带着一种鲜明的“控制平面气质”。哪怕是在 memory、skills、agent teams 这些更像“聪明层”的地方，你也能感觉到它始终不愿意失去对边界与归属的把控。

这就是 OpenClaw 的底色。

它不是先问“Agent 能不能更像人”，它先问“Agent 能不能先像一套可靠的系统”。

6. OpenClaw 的系统图像

你会发现，这张图里最粗的那根骨头不是模型，而是 Gateway。模型当然重要，但在 OpenClaw 的叙事里，它更像可替换算力，而不是文明中心。

这就是 OpenClaw 的强项，也是它的宿命。

四、再拆 Hermes：它真正想解决的是 Agent 如何越用越像一个人

如果说 OpenClaw 的世界观，是先造一座边界清晰、路由明确、可接万渠的港口城市，那么 Hermes 的野心更像另一种东西：它想造的不是港口，而是神经系统。

这句话听上去像夸张修辞，但当你把 Hermes 的官方文档从头到尾读一遍，会发现它几乎所有主轴都在围绕同一个问题打转：

一个 Agent，怎样才能不是每次都像第一次见你？

Hermes 文档把自己的身份定义得非常鲜明：它不是一个绑在 IDE 里的代码补全器，也不是一个只能靠单轮上下文撑场面的聊天机器人。它试图成为一个会积累、会迁移、会委派、会自我修正的长期系统。

1. 闭环学习，不是一个营销词，而是产品中心

在 Hermes 的叙事里，最关键的不是“有记忆”，而是记忆能否形成闭环。这和很多产品嘴上说“我们也有 memory”完全不是一回事。

Hermes 不是把记忆当作一个辅助模块，而是把它当作系统的方向盘之一。它关心的不只是“保存过什么”，更关心：

• 哪些经验值得进入始终加载的短记忆；
• 哪些历史应该进入可搜索的长记忆；
• 哪些成功模式可以被提炼成 skills；
• 哪些失败应当被总结为行为修正；
• 用户的偏好、习惯、语气和禁忌，能否在后续任务里自然生效。

这就是官方文档不断强调 closed learning loop 的原因。真正稀缺的，不是“保存聊天记录”，而是让聊天记录、项目经验、执行反馈和技能资产互相转化。

2. bounded persistent memory，说明 Hermes 不是在幻想“无限记忆”

我很欣赏 Hermes 对 memory 的一个处理：它没有天真地承诺“无限上下文”或者“什么都记住”，而是做了一套分层结构。

根据 Hermes Persistent Memory 与 Sessions 文档，Hermes 的核心长期记忆至少分成了几层：

• 一个始终在上下文中的 MEMORY.md，默认预算约为 2200 字符；
• 一个面向用户建模的 USER.md，默认预算约为 1375 字符；
• 基于 SQLite FTS5 的 session_search，可以在 state.db 与 JSONL transcript 所构成的会话历史里检索再总结；
• 外部 memory provider 插件，可以接入更专业的长期记忆存储。

这意味着 Hermes 不是在搞“无限装载”的幻觉，而是在做一种更像认知系统的分层：

• 有些东西必须时刻记得；
• 有些东西不必常驻，但要能在需要时想起来；
• 有些东西不该只是记住，而该被提炼成技能；
• 有些东西则应该被沉淀为稳定的用户模型。

这比“把所有历史都硬塞进上下文”成熟得多。因为真实的成长，从来不是信息越多越好，而是筛选、压缩、召回与抽象的质量越高越好。

3. Skills 在 Hermes 里，不是插件边角，而是程序性记忆

Hermes 的 skills 体系之所以重要，并不是因为“它也支持技能”，而是因为它把技能放在一个近乎核心资产的位置上。

在 Hermes 的设计里，skills 不是单纯的 prompt 模板，也不是给用户显摆花样的小工具包。它更接近一种程序性记忆：把一次次完成任务的稳定方法，提炼成可以复用、共享、迁移、组合的行为单元。

更有意思的是，Hermes 还把 skills 视作开放标准的一部分，和 agentskills.io 这样的生态产生关系。这说明它不只是想让你“本地多几个技能包”，而是试图把技能当成跨项目、跨环境、跨人群都可以流动的资产。

这和 OpenClaw 的 skills 叙事很不一样。OpenClaw 当然也有 skills、plugins、工作区技能与管理技能，但在它的产品神话里，skills 更多像是可编排能力的一部分；而在 Hermes 的叙事里，skills 更像成长之后留下来的能力结晶。

4. 六种 terminal backends，暴露了 Hermes 的另一个核心欲望：脱离单机束缚

Hermes 的另一个非常关键的信号，是它对运行时后端的抽象。

按我核对的文档，Hermes 当前列出的终端后端包括 local、docker、ssh、Daytona、Singularity、Modal。这个列表本身，比一百句宣传语都更能说明问题。

因为它告诉你：Hermes 想解决的不是“在你的笔记本上跑一个 agent”，而是“让 agent 可以在不同安全等级、不同持续时长、不同隔离强度、不同成本模型的环境里继续活着”。

这和 OpenClaw 的思路差别很大。

OpenClaw 当然也能通过 nodes 把执行能力拉到不同机器上，但它的重心依然是Gateway 如何统御这些节点；Hermes 则更像是在说：Agent 本身不该被困在你当前这台机器上，它应该能够迁移到更适合它工作的环境里。

这会直接带来几个现实优势：

• 长时间任务不再必须占着你的本机；
• 更高风险的执行可以放入容器或远端隔离环境；
• 更高算力需求的任务可以迁到 SSH/Modal/Daytona 等后端；
• 你的聊天入口与实际执行环境可以物理分离。

这就是为什么我说 Hermes 的野心已经不仅是“让 agent 接入 Telegram/Discord”，而是“让 agent 在时间和空间上都具备持续性”。

5. Delegation 让 Hermes 更像一个会分工的系统，而不是一张万能嘴

Hermes 的 subagent delegation 同样不是一个边缘彩蛋，而是核心能力的一部分。官方文档对 child agent、并发上限、上下文隔离、深度限制、delegation patterns 都给了明确说明。以当前文档为准，默认最多并发 3 个子代理；默认 max_spawn_depth=1，也就是平面委派，子代理不能继续递归派生。只有显式启用 role="orchestrator" 并把 max_spawn_depth 提高到 2 或 3，才会出现孙代理层级。父代理收到的也不是原样上下文回灌，而是子代理的结构化总结。这意味着 Hermes 不是简单支持“多开几个任务”，而是在认真把任务分工做成一等公民。

这件事的意义，远不只是性能或方便。

它意味着 Hermes 默认承认：一个足够复杂的 Agent，不应该永远靠单一上下文、单一人格、单一执行路径去硬扛所有任务。复杂工作要拆、要分工、要隔离上下文、要限制深度、要控制并发、要让 orchestrator 和 worker 的责任分开。

这个思路非常像现代工程体系里的微服务和任务编排，但 Hermes 试图把它下沉进“个体 agent”的日常运行里。一个 agent 不再只是一个输出接口，而更像一个会调度自己分身的工作系统。

6. Messaging gateway 在 Hermes 里也重要，但不再是唯一神

有人可能会说：Hermes 也有 messaging gateway，也能接十几个平台，为什么还要强调它和 OpenClaw 不一样？

答案是：重要性排序不同。

Hermes 的 gateway 的确很强。按 sessions 文档列出的来源，它覆盖了 CLI、本地 TUI、Telegram、Discord、Slack、WhatsApp、Signal、Matrix、email、cron、webhook 等会话入口。但 Hermes 的整个产品叙事，并没有像 OpenClaw 一样把 Gateway 塑造成宇宙中心。

在 Hermes 的世界里，messaging gateway 更像一条非常重要的输入输出神经，而不是整个神经系统本身。真正的中心，仍然是 memory、skills、delegation、backends 与 automations 共同构成的持续工作能力。

7. Hermes 的系统图像

这张图和 OpenClaw 那张图最大的区别，不在于有没有 gateway，而在于哪根线最粗。在 Hermes 里，最粗的线不再是入口，而是持续性。

它要的不是一座把船接进来的港口，而是一个会长出经验、技能和分工机制的工作大脑。

五、第一轮正面对决：两者在设计哲学上到底差了什么

如果前面两章还只是拆解，那么从这里开始，我们就该把刀口直接对准核心差异了。

很多文章喜欢在这个时候开始列表，说谁支持 Telegram，谁支持 SSH，谁支持自动化，谁支持 memory。那种比较当然也能做，但它很容易把真正重要的问题稀释掉。

我更愿意先给出一句可能会得罪一部分人的判断：

OpenClaw 和 Hermes 的差异，本质上不是功能差异，而是“系统人格差异”。

一个系统的功能可以补，一个系统的插件可以装，一个系统的模型提供商可以换；但一个系统最初把什么当成文明中心，这个东西通常非常难改。它会决定默认配置、文档叙事、治理逻辑、扩展方向、用户群体，甚至决定它遇到矛盾时优先保护什么。

1. OpenClaw：通道优先、控制平面优先、主权先行

OpenClaw 的哲学可以浓缩成一句话：

先把入口和边界守住，再谈智能如何生长。

所以你会看到它天然偏好：

• 单一长期运行的 Gateway；
• 统一消息 surface；
• 明确的节点能力声明；
• 会话与工作区隔离；
• 平台配对与审批；
• 物理级权限裁剪；
• 通过 routing 和 policy 来控制“谁能被什么触发”。

这是一种很工程化、很像“控制系统”的思维。它先把交通秩序、安保系统、港口调度和仓库归属建好，再来讨论仓库里放什么货。

这也解释了为什么 OpenClaw 的魅力，往往会最先打动那类特别在意边界的人：极客、自托管爱好者、多平台代理重度使用者、本地优先主义者、对设备权限和网络暴露有明确警惕的人。

2. Hermes：学习优先、能力积累优先、运行环境抽象优先

Hermes 的哲学则是另一句话：

先让 Agent 拥有时间维度，再谈它如何接住更多入口。

所以你会看到它天然偏好：

• bounded persistent memory；
• session search 与长期召回；
• user modeling；
• skills 的沉淀与开放标准化；
• subagent delegation；
• remote terminal backends；
• scheduled automations；
• 把经验转化为下一次能力的闭环。

这是一种更像“认知系统”的思维。它关心的不是先建一个巨大的港口，而是先让大脑学会记住、学会检索、学会归纳、学会把成功模式固化成技能，然后再让这些能力进入更多输入输出通道。

这也解释了为什么 Hermes 会更吸引另一类人：长期与 agent 协作的人、希望 agent 越用越懂自己的人、需要 remote execution 的人、需要分工与自动化的人、把 agent 当作长期生产系统而不是消息机器人来使用的人。

3. 它们真正分叉的地方，是“先保护什么”

如果要我用一句极端凝练的话来总结两者差异，我会说：

OpenClaw 首先保护的是系统的边界；Hermes 首先保护的是系统的连续性。

这句话很重要。

因为边界与连续性，恰恰是 Agent 基础设施最容易互相拉扯的两端。

• 你越强调边界，系统往往越保守、越审慎、越依赖显式规则；
• 你越强调连续性，系统往往越想积累、越想召回、越想迁移、越想从历史中长出新的能力。

一个产品的默认姿态，本质上就是它对这组张力的取舍。

4. 一张总对照表

看明白这张表之后，你其实已经能理解后面大半篇文章的结论了。

OpenClaw 更像“通道优先、控制平面优先、主权先行”的系统。

Hermes 更像“学习优先、能力积累优先、运行环境抽象优先”的系统。

这一章不讨论输赢，只讨论气质。因为很多时候，用户选错工具，不是功能不够，而是气质不合。

六、第二轮正面对决：入口、记忆、技能、执行环境、协作模型逐项拆开

现在我们进入更硬的一层。既然系统人格已经定性，那就必须把关键模块逐项拆开，看看这种人格到底是怎么落到技术结构里的。

1. 入口层：OpenClaw 把入口当疆域，Hermes 把入口当神经末梢

OpenClaw 的入口观非常强硬。Gateway 持有所有消息 surface，这不仅是实现问题，更是政治问题。它相当于在说：所有来自外部世界的触发，都必须先经过我这个中央关口。

这就是为什么 OpenClaw 的平台适配、工作区匹配、配对审批、群组 allowlist、mention policy、account 绑定、channel scope 都那么显眼。它不允许入口绕过控制面，直接撞到执行层。

从工程角度看，这种设计有三个明显好处：

• 入口统一，利于治理；
• 平台差异被 Gateway 吃掉，利于抽象；
• 安全策略、路由策略、工作区归属都可集中管理。

但代价也存在：入口一旦成为一切的中心，你的复杂度也会在这里堆积。平台兼容性、会话奇怪行为、token 轮换、bot 权限、平台 API 漂移，都更容易在 Gateway 层持续吞噬维护精力。

Hermes 当然也不缺入口。官方文档里的会话来源覆盖得很广，从 CLI 到消息平台，再到 email、cron 与 webhook 都算入口。但 Hermes 对入口的态度更像是：它必须强，但它不是文明中心。

这就像一个人拥有嘴巴、耳朵、眼睛，但文明中心不是感官，而是大脑与神经系统。Hermes 的消息入口很强，却更像服务于长期系统的 I/O 层，而不是唯一主轴。

如果你最看重的是“把各种现实世界入口统一收编”，OpenClaw 会天然更打你；如果你更看重“入口只是任务进入系统的一种方式”，Hermes 的视角会更顺。

2. 记忆层：OpenClaw 更像可审计笔记本，Hermes 更像分层认知架构

这可能是二者最容易被说成“都差不多”的地方，但其实恰恰相反：它们在记忆上的差异，非常能暴露路线分叉。

根据 OpenClaw Memory Overview，OpenClaw 的 memory 体系围绕文件化与工作区可见性展开。官方直接强调：模型只会记住写进磁盘的东西，没有隐藏状态。MEMORY.md 是常规长期记忆入口，memory/YYYY-MM-DD.md 承担 daily notes 的角色，而且今天与昨天的日记会被自动加载；DREAMS.md 则承担更像“后台整理”或灵感沉淀的角色。除此之外，它还有 memory_get、memory_search 之类工具，并通过 SQLite / 向量 / 混合搜索来完成召回。

这套体系的优点非常鲜明：

• 可审计；
• 可编辑；
• 与工作区绑定清晰；
• 记忆是一种你能摸得着、改得了、提交得出的资产；
• 对于本地优先和项目导向的使用方式非常友好。

你甚至可以把它理解成一种“工程师式记忆”：它不追求像人脑那样暧昧而流动，而是尽量把长期经验落成结构清晰、归属明确、文件可见的存档。

而 Hermes 的记忆观则明显更“认知化”。

它一方面给出严格的 bounded memory：MEMORY.md 与 USER.md 都有明确的上下文预算，不鼓励失控膨胀；另一方面又通过 session_search 和 FTS5 把历史检索能力做成一等公民，还允许接入外部 memory provider。也就是说，Hermes 把“记住”拆成了至少三层：

• 常驻短记忆；
• 可搜索的长记忆；
• 可结构化沉淀的技能与用户模型。

这套思路更接近人的认知系统：不是所有东西都要一直背着，但该想起来的时候要能想起来；不是所有历史都值得常驻，但有些模式应该被抽象成能力，而不是变成堆积的聊天记录。

所以，如果要一句话总结二者记忆差异，我会说：

OpenClaw 的记忆像一本可审计、可归档、可控边界的工程日志。

Hermes 的记忆像一个会筛选、召回、压缩并继续长出技能的认知分层系统。

3. 技能层：OpenClaw 的技能更像扩展能力，Hermes 的技能更像经验结晶

OpenClaw 的 skills、plugins、bundled channels、workflow pipelines 当然不弱。它有足够强的扩展性，也允许工作区技能和管理技能共存。这一套更接近“把 Agent 的手脚装齐”：让它可以处理更多动作、更多平台、更多外部连接。

但 Hermes 的 skills 叙事更像是在说：技能不是外挂，而是经验的硬化形态。

这带来两个很大的差异。

第一，Hermes 的 skill 更强调 portable、standardized、shareable。它希望技能不仅能在你当前任务里用，还能成为你未来所有任务的资产。

第二，Hermes 的 skill 更紧密地连接 memory 与 learning loop。也就是说，skills 并不只是“提前写好的技巧包”，它们还承担了一部分“把长期经验固化成可复用方法”的功能。

这就是为什么我会说，OpenClaw 的 skills 更像扩展能力，Hermes 的 skills 更像程序性记忆。

4. 执行层：OpenClaw 强在控制，Hermes 强在迁移

执行层的差异同样非常深。

OpenClaw 的执行世界，是 Gateway 统御下的 nodes 世界。你可以把它理解成：所有执行都必须纳入一个中心控制面里，被工作区归属、节点能力、命令权限与平台路由共同约束。它非常适合处理“这台机器能干什么、那台机器能干什么、哪些命令必须拉黑、哪些设备能力绝不开放”这类问题。

这种设计对于强调物理边界的人极具吸引力。因为你清楚知道：

• 哪个节点提供了什么能力；
• 哪些命令会被拦截；
• 哪些工作区能访问哪些文件；
• 哪个平台来的消息最终会进入哪个执行环境。

而 Hermes 的执行层，则明显更偏向“运行时抽象”。它把 local、docker、ssh、Daytona、Singularity、Modal 这些后端放到同一个终端抽象之下，本质上是在回答一个更大的问题：

Agent 该不该永远绑定在用户眼前这台机器上？

Hermes 的答案显然是否定的。

这种思路的优点，在今天越来越明显：

• 远程任务不再依赖本地机器持续在线；
• 隔离环境变成常态，而非额外补丁；
• 迁移工作负载到更合适的环境更自然；
• 你可以把聊天入口留在日常平台，把高风险执行丢给更强、更远、更隔离的后端。

所以，OpenClaw 强在可控执行，Hermes 强在可迁移执行。这两个词看起来只差一个字，背后其实是两套完全不同的工程取向。

5. 协作层：OpenClaw 像调度中枢，Hermes 像任务分形

多代理协作这件事，也是二者差异非常有戏的一层。

OpenClaw 的多代理思路，很容易让人想到调度中心与特种工种。你可以通过 workspace 隔离、SOUL 角色定义、routing、agent teams、handoff 机制，把不同代理塑造成不同功能角色。它强调的是：让不同角色在同一控制平面下，按边界和规则被调度起来。

我之前写“北斗七星”式流水线，其实就是把这种思路写得更戏剧化了一点：天枢感知、玉衡设计、天玑执行，本质上依然是 Gateway-first 的编排世界。

Hermes 的 delegation 则更像另一种东西：任务分形。

它允许你在当前 Agent 中继续派生子代理，让每个子代理拥有隔离上下文、独立终端会话、受限工具集，并根据 delegation patterns 处理不同子问题。这里的重点不再是“有几个角色被 central router 叫醒”，而是“当前系统能否自发地把复杂任务分裂成可并行的局部工作单元”。

从协作哲学看：

• OpenClaw 更像一个总调度台，强调角色清晰、入口统一、边界明确；
• Hermes 更像一个可自我裂变的工作系统，强调任务拆分、并发推进、局部隔离。

6. 自动化层：OpenClaw 重通道连续性，Hermes 重工作连续性

自动化能力是很多人喜欢一笔带过的部分，但我认为它恰恰能揭示二者对“持续性”的不同理解。

OpenClaw 的自动化，天然容易和消息通道、会话入口、平台推送绑在一起。它非常适合做“某个平台来的事件应该触发什么工作流”“某个 Bot 在特定频道如何响应”“某个 gateway 内的周期任务如何回到某个消息 surface”。

Hermes 的 scheduled automations 则更强调“这个 Agent 自己有哪些应该持续做的工作”。定时任务在它那里不是仅仅服务于消息平台，而是整个长期工作系统的一部分。你可以把它理解成：OpenClaw 更像在维持通道的连续性，Hermes 更像在维持工作的连续性。

7. 这一轮对决的结论

如果把这一整章压缩成一句话，那就是：

OpenClaw 把 Agent 放进一个可治理的基础设施框架里；Hermes 则试图让基础设施本身长出时间维度。

这两者都很高级，也都很难。真正可怕的不是它们谁做不到，而是用户自己根本没分清自己在买哪一套逻辑。

七、为什么说 OpenClaw 更像“入口主权”，而 Hermes 更像“学习主权”

这是我整篇文章最想讲清楚的一章。因为如果不把这个概念讲透，后面所有对比都会滑回“功能表比较”。

1. 什么叫入口主权

所谓入口主权，不是一个空洞的政治大词。落到 Agent 基础设施上，它至少意味着：

• 你知道消息从哪里进来；
• 你知道什么消息可以触发系统；
• 你知道不同平台、不同账号、不同群组、不同私聊该落到哪个工作区；
• 你知道执行权是通过哪些节点、哪些命令、哪些权限边界被授予的；
• 你知道哪些设备能力被永远封死；
• 你知道控制平面是否暴露公网，还是被 loopback、tunnel、allowlist 保护。

本质上，入口主权首先是一种控制消息流、命令流与权限流的能力。

OpenClaw 在这方面非常强，甚至可以说，这是它存在的根本理由。它让你把平台入口、工作区归属、节点能力、命令权限、会话范围都纳入可见、可配、可审计的体系里。它提醒你：不要把高权限 Agent 当成一个单纯的聊天玩具，它首先是一套要守住边界的执行基础设施。

这就是我为什么一直认为，OpenClaw 对“数字主权”的理解带有非常强的基础设施味道。它不是在卖你一个更聪明的助手，而是在帮你收回入口控制权。

2. 什么叫学习主权

而学习主权，则是另一个层级的东西。

它意味着：

• 你知道 Agent 记住了什么；
• 你知道它如何把短记忆、长历史、用户偏好与技能资产区分开；
• 你知道它的技能不是云厂商黑箱里的一串不可见 embedding，而是你可审视、可导出、可迁移的资产；
• 你知道它能把成功与失败沉淀成稳定改进，而不是每次都靠临场发挥；
• 你知道这个系统即便换了后端、换了机器、换了项目，也能保留核心人格与经验结构。

本质上，学习主权首先是一种控制 Agent 如何成长、成长成什么样、成长资产归谁所有的能力。

Hermes 在这方面明显走得更远。bounded memory、user model、session search、skills、delegation、backends、migration，这一整套组合起来，构成的就是一种学习主权框架。真正昂贵的，不只是入口 token 和平台绑定，而是 Agent 长时间与你合作之后形成的那套“会做事的方法”。

如果这些东西只存在于某个 SaaS 黑箱中，你就始终在租用它的记忆和成长；如果这些东西能够落地为 MEMORY.md、USER.md、state DB、skills、context files、可迁移配置，那你才真正开始拥有 Agent 的“持续人格”。

3. 从数据主权到认知主权

过去几年，很多人一谈“主权”，主要还是在谈数据不出境、本地部署、私有 API key、loopback 端口、不依赖云厂商。这些都重要，而且一点都不过时。

但到了今天，如果我们还把主权理解停留在“数据在哪台机器上”，那就太浅了。

因为对于 Agent 来说，更深一层的主权其实是：

这个系统怎么理解你、怎么记住你、怎么学会一套工作方法、怎么把经验传到下一个任务里。

这就是我为什么说，Hermes 把“数字主权”从本地部署推进到了另一层：从数据主权，进一步逼近认知主权。

而 OpenClaw 则恰恰守住了更早但同样不可或缺的一层：入口主权。

4. 两种主权不是互斥，但顺序会改变一切

这里我要特别提醒一点：入口主权和学习主权不是互斥的。任何足够成熟的 Agent 基础设施，最终都应该兼顾这两者。

问题在于，系统最先构建哪一层，会深刻影响后续一切。

如果你先构建入口主权，你的世界会长得更像 OpenClaw：先统一消息入口，先立边界，先管执行，再去谈记忆与成长。

如果你先构建学习主权，你的世界会长得更像 Hermes：先让 Agent 形成连续性，先把经验沉淀成技能，先把运行环境抽象出来，再去扩张更多入口。

顺序为什么重要？因为基础设施不是搭乐高。先打什么地基，会决定你未来哪里补得动、哪里永远别扭。

5. 我的判断：2026 年之后，真正昂贵的是“成长权”

如果一定要让我给出一个带锋芒的判断，我会说：

在 2026 年之后，入口依然重要，但真正越来越昂贵的，将是 Agent 的成长权。

为什么？因为平台入口这件事，随着协议成熟、插件生态扩张、桥接能力增强，会越来越像“可以通过工程投入补齐的能力”；但一个 Agent 的持续人格、技能资产、用户模型、远程运行能力、跨项目经验复用，这些东西一旦沉淀下来，就会变成更难替代的壁垒。

说得再直白一点：

• 入口是可以被重新接入的；
• 记忆与成长却往往更难被重新培养。

这不是说 OpenClaw 过时，恰恰相反。没有入口主权，学习主权很容易变成空中楼阁。但这意味着我们不能再只满足于“Agent 在我本地跑起来了”，而必须继续追问：它留下了什么，未来还能带走什么。

八、迁移指南背后的真实信号：Hermes 为什么要主动吃掉 OpenClaw 的历史资产

如果说前面七章还主要是架构与哲学分析，那么从这里开始，我们终于要进入最有现实味道的一层：迁移。

一个项目提供另一个项目的迁移指南，这件事本身就很有信息量；而 Hermes 的 OpenClaw 迁移指南之所以格外值得研究，是因为它迁移的不是表面配置，而是一整套“行为资产”。

根据我核对的 迁移文档，Hermes 在真正执行写入前会先给出 preview，且支持 --dry-run。它试图映射和吸收的，至少包括这些对象：

• SOUL.md
• AGENTS.md
• MEMORY.md
• USER.md
• daily memories
• workspace / managed skills
• providers
• approval mode
• messaging tokens
• MESSAGING_CWD
• session reset policies
• MCP servers
• 部分环境变量与密钥映射

你仔细看这份清单，就会明白一个非常重要的事实：

Hermes 不是只想把你“导过去”，而是想把你在 OpenClaw 里已经形成的世界一起接过去。

1. 迁移的对象，不只是文件，而是人格与习惯

先看 SOUL.md 与 AGENTS.md。

这两个文件代表的不是简单配置，而是 Agent 的角色、操作习惯、项目边界、人格口吻与执行规则。Hermes 迁移它们，说明它非常清楚：一个长期使用者最宝贵的资产，不只是 token 和模型提供商，而是他已经把系统调教成什么样了。

再看 MEMORY.md、USER.md 与 daily memories。

这部分更直接。它们是长期协作关系的沉淀物，是“这个 Agent 对我知道什么、记住什么、怎么叫我、什么偏好别碰、哪些习惯该保留”的核心材料。Hermes 不只是复制它们，而是尝试把这些东西归并到自己的 memory 结构中去。这说明它并不是只想接一个“静态配置集”，而是想吸收一段协作历史。

2. 迁移映射本身，就是架构意图的证据

下面这张映射表，比很多宣传文案都更能解释 Hermes 的野心：

注意，这不是“复制粘贴”。它更像一种翻译。

而且这种翻译不是无损搬箱子。迁移文档里写得很细：MEMORY.md 和 USER.md 会被解析成条目，与现有内容合并、去重，并使用 § 分隔；导入到 ~/.hermes/skills/openclaw-imports/ 的 skills 也不是立刻在当前会话生效，而是要从新 session 开始接管行为。迁移工具要做的，不只是把文件放到新目录，而是要判断：旧体系里的资产，在新体系里应该变成什么角色。这背后的本质，是 Hermes 在说：

OpenClaw 用户真正拥有的，不是一个配置文件，而是一套已经被打磨出来的工作文明。

3. 哪些东西不能自动迁移，恰恰更有信息量

一个成熟的迁移系统，最值得信任的地方，往往不是“它能迁多少”，而是“它清楚说出哪些不能迁”。

Hermes 的迁移文档里，至少有几个地方值得注意：

• 某些 SecretRef 来源如果是 source:file 或 exec，无法完全自动解析；
• WhatsApp 等平台可能需要重新配对，而不是单纯迁 token；
• skills 如有冲突，需要人工决定 skip、overwrite 或 rename；
• AGENTS.md 的迁移需要你显式提供 --workspace-target；
• 部分 OpenClaw 特有概念会被归档，而非直接变成 Hermes 的一等结构；
• session reset 策略需要核对，不是所有行为都能 1:1 语义等价。

这其实更能证明 Hermes 不是在做表面文章。因为它非常清楚：迁移不是导入 JSON，而是把一套工作方式搬进另一套文明里。

4. 为什么这件事会让我高看 Hermes 一眼

我不是因为“能迁移”就高看一个产品。我高看它，是因为它知道用户真正舍不得丢的东西是什么。

普通产品经理以为用户最怕重输 token。

稍微懂一点工程的人知道，用户更怕重配 providers。

真正理解长期协作价值的人才知道，用户最怕丢的其实是：

• 已经磨出来的行为规则；
• 已经沉淀下来的记忆；
• 已经复用起来的技能；
• 已经适应的审批与安全习惯；
• 已经绑定好的上下文文件与工作流。

Hermes 愿意花力气去接这些东西，说明它想竞争的不是“新鲜感”，而是长期系统的接班权。

5. 这也暴露了 Hermes 对 OpenClaw 的真正判断

一个项目是否提供另一个项目的迁移，背后其实也藏着它对对方的评估。

Hermes 愿意接 OpenClaw，等于默认承认了三件事：

1. OpenClaw 用户是高价值用户；
2. OpenClaw 沉淀下来的资产具有高度可继承性；
3. OpenClaw 并不是“低端旧工具”，而是一套值得被升级吸纳的基础设施前史。

从这个角度看，Hermes 并没有把 OpenClaw 当成需要否定的过去，而是把它视作一个值得承接的文明阶段。

这件事本身，就非常说明问题。

九、工程现实：两套系统分别会给谁带来红利，给谁制造负担

到这里为止，如果你还只想问“那到底选哪个”，说明你还是没有摆脱消费电子测评思维。真正负责任的回答，从来不是一个单选按钮，而是要看你到底在解决什么问题、你愿意承担什么成本、你未来六到十二个月最看重的是什么。

1. 什么人更适合 OpenClaw

如果你属于下面这类人，OpenClaw 往往会更对味：

• 你是重度多平台消息用户，希望把 Telegram、Discord、Slack、WhatsApp、Signal、Feishu、Matrix 等入口统一收编；
• 你对本地优先、loopback、配对审批、物理权限边界这类事情极度敏感；
• 你把 Agent 首先视作一个“可控执行中枢”，而不是陪聊系统；
• 你需要一套能够把不同工作区、不同角色、不同节点能力明确分隔开的控制平面；
• 你愿意为入口治理付出配置代价；
• 你对“系统能否被严格定义边界”看得比“它会不会自我成长”更重。

这种用户通常有一个共同特点：他们很讨厌黑箱，尤其讨厌一个高权限系统在自己不知道的前提下越界行动。他们宁愿多写点配置、多调点路由、多做点权限裁剪，也不愿接受“它大概会自己处理好吧”的含糊感。

对这类人来说，OpenClaw 的价值，不是让系统更像人，而是让系统先像一套受管控的基础设施。

2. 什么人更适合 Hermes

如果你属于下面这类人，Hermes 往往会更有未来感：

• 你和 Agent 的协作不是偶发的，而是长期关系；
• 你希望它记住你的偏好、项目脉络、做事方法，最好还能越来越会做；
• 你不满足于单次执行，而是需要 skills、memory、automations、delegation 形成闭环；
• 你需要 Agent 离开本机，在 Docker、SSH、Modal、Daytona 等环境里持续工作；
• 你关心跨项目、跨环境、跨时间的能力延续；
• 你相信最贵的不是入口，而是成长出来的行为资产。

这类用户通常也有共同特征：他们不是把 Agent 当“机器”，而更像把它当“长期合作对象”。他们接受系统有更多层次，也愿意投入时间治理 memory、skills、delegation 和 remote runtime，因为他们想得到的是复利，而不是一次性的执行便利。

3. 什么人其实两者都不太适合

还有第三类人，值得被直接点出来。

如果你只是：

• 想在 IDE 里补补代码；
• 偶尔问几句技术问题；
• 不打算自托管；
• 不想维护配置；
• 不需要多平台接入；
• 不需要长期记忆；
• 不想管远程后端；
• 不会持续使用 agent。

那无论是 OpenClaw 还是 Hermes，都很可能是火力过剩。

这不是看不起需求，而是很多人真正需要的，可能只是一个轻量 copilot、一个云端对话工具、或者一个更稳定的编码助手，而不是一整套需要你自己治理的智能基础设施。

工具选型里最常见的浪费，就是拿一艘巡洋舰去送外卖。

4. 三种典型人物画像

为了说得更直白一点，我给三个典型画像。

画像一：多平台数字指挥官

你有 Telegram、Discord、Slack、Feishu、Matrix 甚至 WhatsApp 的重度使用需求，希望所有消息入口统一归口，Agent 可以在不同平台之间承担协同、监听、转发、执行与汇报角色。你还非常在意本机权限、节点命令、设备隔离。

这类人，大概率先从 OpenClaw 获得最大收益。

画像二：长期协作型独立开发者

你希望 Agent 帮你写代码、查资料、跑任务、记偏好、沉淀技能，而且这些事情最好别总占着你的本机。你需要远程执行、记忆复利、子代理并发和定时任务。

这类人，更容易在 Hermes 身上看到未来。

画像三：小团队里的流程编排者

你既在意入口，也在意成长，既想统一平台，又不想让经验白白流失。你不是想买一个“能聊”的产品，而是在试图搭一层长期工作底座。

这类人很可能既不会彻底放弃 OpenClaw，也不会忽视 Hermes。他们真正要做的，是判断自己的第一性约束在哪：是入口治理，还是成长治理。

5. 一个非常现实的判断：大多数人会先被 OpenClaw 打动，再被 Hermes 说服

如果让我凭直觉做一个行业判断，我会说很多工程用户的路线大概率会是这样：

1. 先因为 OpenClaw 的入口统一、多平台联动、本地主权、物理边界而被打动；
2. 在实际长期使用中，开始意识到“入口收回来了，但成长资产还没有真正沉淀下来”；
3. 然后被 Hermes 这种 learning-first 体系吸引，开始重新思考什么才是最值钱的部分。

这条路径很正常。因为入口主权通常比学习主权更容易被感知。你一旦把 Telegram、Discord、Feishu 这些入口全都打进一个 gateway，那种“控制权终于回到自己手里”的感受非常强烈；而成长主权则是慢变量，它需要时间累积，直到有一天你忽然意识到：一个会持续记住、持续提炼、持续迁移的 Agent，比多接几个入口更值钱。

这也是为什么我认为两者不是简单替代关系，而更像两个阶段的重心转移。

十、风险与代价：别把“开源主权”误读成“零成本自由”

这里我必须泼一盆冷水。

无论是 OpenClaw 还是 Hermes，只要你开始认真使用它们，你就会很快发现一件事：

开源主权不是免费午餐，它只是把成本从订阅费，转移成了配置费、治理费、维护费和认知负担。

很多人对“主权工具”的浪漫想象，停留在“我终于不受 SaaS 绑架了”；但真实工程世界更接近另一句话：

你不再向平台交租，但你开始给自己的复杂度交租。

1. OpenClaw 的代价：你拥有了港口，也就拥有了海关、码头和巡逻队

OpenClaw 最迷人的地方，恰恰也是它最累人的地方。你一旦真的把它当成统一入口，就意味着你也要开始承担统一入口的责任。

它的典型隐性成本包括：

• 各平台 API、权限模型、token 生命周期与 webhook / 长连接细节持续变化；
• 配对、allowlist、mention policy、群组范围、账号映射这些东西需要持续打磨；
• Gateway 作为中心控制面，会自然变成复杂度集散地；
• 节点能力与命令黑名单要长期维护，不是一劳永逸；
• 多代理、多工作区、多平台并发下的会话污染与路由异常，需要你有足够清晰的治理策略；
• 一旦你让它真的接触文件系统、设备、Shell，它的任何失误都不再是“聊天胡说八道”，而可能是真实物理层面的副作用。

很多人喜欢把这种成本说成“配置比较多”。这话太轻了。更准确的说法应该是：

你接管的不只是入口，你还接管了入口背后的全部秩序维护。

2. Hermes 的代价：成长从来不是白给的，尤其是可治理的成长

Hermes 则有另一类成本，而且在我看来，它并不比 OpenClaw 轻松。

它的典型隐性成本包括：

• memory 如何压缩、何时更新、是否污染、是否过时，本身就是一门治理学；
• skills 会不会越长越乱、越积越碎、命名失控、质量参差，需要系统性整理；
• delegation 一旦滥用，子代理会带来额外 token、调度、追踪和责任归因成本；
• remote backends 虽然解放了本机，但也引入了容器安全、SSH 密钥、云费用、持久化、审计等问题；
• 自动化任务一旦持续运行，就意味着你要真正考虑“它在无人值守时出错怎么办”；
• 认知资产一旦变多，如何迁移、如何去重、如何防止幻觉写入“伪记忆”，会成为长期问题。

很多人对 learning-first 系统的误解，在于他们以为“系统越会学越好”。不是的。

一个会学习的系统，如果没有良好的记忆治理、技能治理、审批治理、环境治理，它很容易从“越来越懂你”滑向“越来越难控制”。所以 Hermes 的难点不是功能不够，而是它逼着你面对一个更成熟、也更沉重的问题：

你真的准备好治理一个会成长的系统了吗？

3. 最容易被忽略的成本：认知负担

我认为无论 OpenClaw 还是 Hermes，用户最容易低估的成本都不是钱，而是认知负担。

因为当你从普通工具升级到基础设施时，你不再只是“会用某个软件”，你是在管理一套系统的：

• 边界；
• 习惯；
• 规则；
• 记忆；
• 技能；
• 环境；
• 自动化；
• 审批策略；
• 故障模式。

这不是小白鼠玩具，而是一种新的工作方式。你越认真使用，就越需要从“消费者心态”切到“运维者心态”甚至“架构师心态”。

4. 一个残酷但必要的结论

如果一定要说得更难听一点，我会说：

很多人不是不需要 OpenClaw 或 Hermes，而是不具备长期治理它们的纪律。

他们喜欢的是那种“我掌控了一切”的感觉，却不愿意承担“掌控一切之后的维护义务”。这种心态下，任何基础设施都会在三个月后长成垃圾场。

所以，别再把“开源主权”理解成“零成本自由”。真正的自由，不是你能不能跑起来，而是你有没有能力长期维护自己夺回来的那部分世界。

十一、未来趋势：Agent 工具的下一轮竞争不再是“更会写代码”，而是“谁拥有持续性”

未来几年，如果还有人拿“写代码更快”“支持模型更多”“平台接得更全”当作 Agent 工具链的主要比较维度，我会越来越觉得那是旧时代的回声。

因为下一轮竞争，正在从“即时能力”迁移到“持续能力”。

我认为至少有四个维度，会决定下一代 Agent 基础设施谁更有生命力。

1. 记忆质量，而不是记忆数量

不是谁存得多谁赢，而是谁更能：

• 过滤噪音；
• 保留关键；
• 让召回发生在正确时机；
• 把重复经验转化成长期优势；
• 避免系统被自己过往的垃圾拖死。

OpenClaw 在记忆可审计与工作区归属上有优势，Hermes 在分层记忆与长期召回闭环上更激进。未来谁能把“可控”与“高质量召回”同时做深，谁就更接近下一阶段的答案。

2. 技能资产，而不是提示词技巧

提示词再花哨，也很难形成真正的长期资产。真正值钱的，是你能否把一套稳定方法沉淀为可迁移、可共享、可演进的 skill。

在这一点上，Hermes 明显已经把技能资产当成文明中心之一；OpenClaw 则更像把技能放在可扩展能力框架里。未来如果行业继续成熟，我几乎可以确定：skills 将会像源码仓库、基础镜像、IaC 模板一样，成为真正可复利的基础资产。

3. 环境迁移能力，而不是单机炫技

一个 Agent 是否只能活在你眼前这台机器上，这个问题会越来越重要。

因为长期工作、夜间自动化、高风险执行、高并发任务、跨地域协作，都要求 Agent 有更强的运行时迁移能力。Hermes 已经在这条线上押注明显；OpenClaw 则通过 nodes 和 gateway 管理路径给出另一种答案。未来行业不可能一直停留在“我本地开个 terminal 让它跑”的阶段。

4. 治理与安全边界，而不是功能炫技

越强的 Agent，越需要成熟的治理。审批模式、权限模型、节点能力、技能来源、记忆污染、远端后端隔离、会话归属、自动化审计，这些问题最终会把所有“玩具级 Agent”筛出去。

在这件事上，我反而觉得 OpenClaw 和 Hermes 其实代表了两种很互补的未来方向：

• OpenClaw 提醒行业：别忘了边界、入口、平台治理、物理世界风险；
• Hermes 提醒行业：别忘了连续性、成长、技能资产、运行时迁移。

未来真正成熟的系统，很可能必须把这两套意识都装进去。

5. 它们会继续靠拢，还是会彻底分家？

这是一个很有意思的问题。

我认为未来有两种可能。

第一种可能：继续靠拢。

OpenClaw 进一步强化长期记忆、技能资产、更多自动化治理，慢慢向 learning-first 靠近；Hermes 则继续补强 gateway、平台治理、权限控制与设备边界，慢慢向 control-plane-first 靠近。最终二者会在中间地带相遇，形成一类“既懂入口主权，也懂学习主权”的复合型 Agent OS。

第二种可能：彻底分家。

OpenClaw 继续成为消息入口与执行控制的主权中枢，做成最强的 gateway / agent routing plane；Hermes 则继续朝长期认知系统、生长型 agent runtime、远程执行编排平台的方向狂奔。

如果是我个人判断，我认为短期内二者会局部靠拢，长期却未必会收敛成同一种东西。因为它们的第一性焦虑不同，而第一性焦虑，往往会在关键决策上反复暴露出来。

6. 我最确定的一点

无论未来哪条路径胜出，我最确定的一点都是：

下一轮 Agent 基础设施的竞争，不再是“谁更会写代码”，而是“谁更能让智能持续存在”。

这里的持续，不只是 uptime，而是：

• 经验持续；
• 规则持续；
• 技能持续；
• 运行持续；
• 人格持续；
• 可迁移性持续。

谁抓住了这件事，谁就抓住了真正的未来。

十二、结语：我们真正争夺的不是一个 Agent，而是一套可继承的智能基础设施

写到这里，其实已经可以把整篇文章压缩成最后一句话了。

如果说 OpenClaw 的历史使命，是帮助开发者从平台与 SaaS 手里夺回消息入口与本地控制权，那么 Hermes 正在尝试推进下一步：从“我能控制它做什么”，走向“我能控制它如何成长、如何记住、如何延续”。

前者争夺的是港口。

后者争夺的是文明。

这话听上去很重，但我一点都不觉得夸张。因为我们今天面对的，已经不是一个会不会聊天的机器人，而是一类越来越接近“长期工作系统”的东西。你给它入口，它就会形成流量；你给它记忆，它就会形成历史；你给它技能，它就会形成方法；你给它后端与自动化，它就会形成生产关系。

到了这个层面，讨论“哪个更好”已经太浅了。真正的问题是：你到底想先掌控哪一层世界。

如果你首先害怕的是外部平台、执行边界、设备能力、权限失控，那 OpenClaw 这条路会非常有说服力。它告诉你，别把高权限系统当玩具，先把边界建起来，先把入口收回来，先把控制平面立住。

如果你首先害怕的是经验蒸发、记忆丢失、方法无法复用、系统每次都像第一次见你，那 Hermes 这条路会更有未来感。它告诉你，真正值钱的不是一次次短暂输出，而是那个会随着时间越来越像“你的系统”的长期 Agent。

所以，这场对比真正给我的结论，不是 Hermes 取代 OpenClaw，也不是 OpenClaw 注定被 Hermes 吞掉，而是：

Agent 基础设施正在从“入口主权时代”，迈向“学习主权时代”。

前一个时代的英雄，是把消息入口、平台触角和执行边界收回到自己手里的系统；后一个时代的英雄，则是能把成长权、记忆权、技能权和迁移权一起收回来的系统。

而我们真正争夺的，终究不只是一个会说话、会执行、会写代码的 Agent。

我们争夺的是：

• 谁定义它的边界；
• 谁保管它的记忆；
• 谁拥有它的技能；
• 谁决定它在哪个环境继续活下去；
• 谁继承它在时间中长出来的那部分“人格”。

如果这些东西仍然掌握在别人手里，那么你拥有的只是一个租来的幻觉。

如果这些东西开始回到你自己的文件、你自己的 gateway、你自己的 memory、你自己的 skills、你自己的 backends、你自己的自动化与审批规则里，那么你才真正开始拥有一套可继承的智能基础设施。

这，就是我理解的下一代数字主权。

延伸阅读

• OpenClaw 官网
• OpenClaw Gateway Architecture
• OpenClaw Features
• OpenClaw Memory Overview
• OpenClaw SOUL.md Personality Guide
• Hermes Agent 文档首页
• Hermes Features Overview
• Hermes Persistent Memory
• Hermes Sessions
• Hermes Subagent Delegation
• Hermes Delegation Patterns
• Migrate from OpenClaw