OpenClaw vs Hermes Agent

1.概述

如果你是刚开始接触 AI Agent 的开发者，最容易踩进一个坑：把“会聊天的大模型”误当成“能持续工作的代理系统”。

这两者不是一回事。

大模型更像一个会推理、会生成文本的“大脑”；而一个真正能落地的 Agent，至少还需要下面几层东西：

1. 工具系统：让模型不只是“会说”，还要“会做”，比如读文件、跑命令、搜网页、发消息、调用浏览器。
2. 会话系统：让代理知道当前任务进行到哪一步，而不是每次都像第一次见你。
3. 记忆系统：让代理把长期偏好、项目背景、历史决策存下来。
4. 权限系统：让代理在执行高风险动作前有边界，避免“会做事”变成“乱做事”。
5. 运行时与入口：让代理能在 CLI、网页、Telegram、WhatsApp、Discord 等不同入口稳定工作。

OpenClaw 和 Hermes Agent，正是这类“真正能跑起来”的开源 Agent 系统里，近阶段很值得比较的两个项目。

它们的相似之处很多：

• 都是自托管、开源、强调可控性。
• 都支持多模型接入，而不是把自己绑死在单一厂商上。
• 都不满足于“问答”，而是强调工具调用、上下文、会话、长期使用。
• 都支持技能（skills）扩展，并且都和 AgentSkills 生态兼容。
• 都在朝“常驻型、长期在线、可跨端访问”的代理形态演进。

但它们的设计重心并不一样。

用一句最通俗的话概括：

• OpenClaw 更像“把所有聊天入口接到一个 AI 助理上的网关平台”。
• Hermes Agent 更像“一个会持续成长、会自我积累经验的常驻型代理运行时”。

这篇文章的目标，不是简单下结论说谁强谁弱，而是帮你把下面几个问题真正想清楚：

• 它们各自解决的核心问题是什么？
• 它们的架构为什么长成现在这个样子？
• 初学者到底该先上哪一个？
• 做个人助理、开发自动化、长期知识代理、消息机器人时，哪个更顺手？
• 从未来 1 到 2 年的趋势看，它们分别可能走向哪里？

2.内容

简要介绍：为什么 OpenClaw 和 Hermes Agent 会被放在一起比较？

原因很简单：它们面向的是一批高度重叠的用户。

这批用户通常有下面几类需求：

• 我想要一个随时能从手机上联系到的 AI 助手。
• 我不只想让它回答问题，还想让它帮我执行任务。
• 我希望它记住我的习惯、项目、工作流。
• 我不想被某一家模型厂商锁死。
• 我希望它能长期跑在我的机器、服务器或 VPS 上。

从官方文档能看出，两者虽然切入点不同，但正在覆盖同一片版图。更有意思的是，Hermes 官方甚至直接提供了从 OpenClaw 迁移的命令 hermes claw migrate，这本身就说明：两者并不是毫无交集的两个世界，而是同一赛道上的两种设计哲学。

下面先分别看它们各自是什么，再进入真正有价值的对比。

2.1 OpenClaw 是什么？

按照 OpenClaw 官方仓库与官方文档的描述，它是一个运行在你自己设备上的个人 AI 助理，同时也是一个把多种消息渠道连接到代理运行时的自托管 Gateway。

OpenClaw 的官方文档里，有几个关键词非常关键：

• 它强调自己是 self-hosted gateway。
• 它强调你可以继续在现有聊天渠道里和代理对话，而不必重新学习一个新界面。
• 它强调 Gateway 是“控制平面”，真正的产品是那个始终在线、可跨渠道访问的个人助理。

如果把 OpenClaw 用非常白话的话来解释，它更像下面这个模型：

你不是在“打开一个 AI App”；你是在“把 社交软件、Web 控制台、移动节点等入口，全部接到同一个 AI 助理上”。这个 AI 助理后面有工作区、技能、会话、记忆和工具，而 Gateway 负责把这些入口统一起来。

这带来几个非常鲜明的特点：

1. 它是“消息入口优先”的。
   你可以把它理解成一个 AI 总机。不同聊天入口、不同账号、不同设备，都可以通过 Gateway 汇到同一套系统里。

2. 它是“个人助理优先”的。
   OpenClaw 的安全模型官方就明确写了，它默认假设一个 Gateway 对应一个可信的个人边界，而不是拿来做 hostile multi-tenant 的多租户对抗式平台。

3. 它非常强调“可见、可编辑、可控”。
   比如记忆不是藏在黑盒数据库里，而是直接写成 Markdown 文件；技能也是 SKILL.md；很多配置都能直接在工作区和本地目录里看到。

4. 它天然适合“手机里能随时找到的助手”。
   你不一定总在终端里，也不一定总在 IDE 里，但你一定经常在消息应用里。OpenClaw 选择先占住这个入口。

对初学者来说，OpenClaw 最好理解的一点是：它首先是一个把 Agent 带进日常通信渠道的系统，然后才是一个可扩展的代理框架。

2.2 Hermes Agent 是什么？

Hermes Agent 的官方定位则明显不同。官方主页第一句话就很直接：它是 Nous Research 构建的 self-improving AI agent，也就是“会自我改进的 AI 代理”。

Hermes 最有辨识度的几个关键词是：

• built-in learning loop：内建学习闭环
• persistent memory：持久记忆
• session search：跨会话检索
• cron：定时任务
• subagent delegation：子代理委派
• MCP integration：MCP 工具生态接入

如果也用一句白话来解释 Hermes：

它不像“一个多消息入口的 AI 助手”，而更像“一个常驻在你机器或服务器上的智能工作体”。你给它任务，它不仅能做，还会逐渐把经验、偏好、上下文和技能沉淀下来，让自己在长期使用中变得更像一个成熟的助手，而不是每次都重新开始。

Hermes 的几个明显特征是：

1. 它是“运行时优先”的。
   也就是说，它更关心代理本身如何工作、如何记忆、如何委派、如何自动化、如何跨环境运行。

2. 它是“长期在线优先”的。
   官方文档反复强调它不需要绑在你的笔记本上，可以运行在 $5 VPS、GPU 集群、Daytona、Modal 等环境里。

3. 它是“闭环学习优先”的。
   不是只有工具调用，而是强调：做过的事情能不能积累为技能？长期偏好能不能沉淀成记忆？过去会话能不能检索回来？

4. 它是“自动化优先”的。
   Cron、委派、并行子代理、MCP、外部记忆提供器、上下文文件自动加载，这些都说明它的目标不只是聊天，而是构建一个长期运行的智能工作流系统。

对于初学者，Hermes 最重要的一句话理解是：它不是先解决“怎么联系到代理”，而是先解决“代理如何长期稳定地成长和工作”。

2.3 它们为什么值得比较？

因为很多人第一次做 Agent 时，真正纠结的不是“能不能装上”，而是“应该先围绕哪种心智模型去搭系统”。

这两种心智模型分别是：

• 入口优先：先把消息渠道、交互触点、设备接入做对，让代理能随时被叫到。
• 运行时优先：先把记忆、工具、自动化、委派、长期运行做对，让代理真能持续完成复杂工作。

OpenClaw 明显更偏前者，Hermes 明显更偏后者。

为了让这个差异更直观，可以先看一张总表：

维度	OpenClaw	Hermes Agent	对初学者意味着什么
设计中心	Gateway 与多渠道接入	AIAgent 运行时与学习闭环	前者更像“入口平台”，后者更像“智能执行内核”
主要使用姿势	从消息应用、Control UI、节点访问	从 CLI/TUI、Gateway、Cron、子代理访问	OpenClaw 更贴近日常通信，Hermes 更贴近长期自动化
记忆模型	工作区 Markdown 记忆为主，透明可编辑	MEMORY.md + USER.md + Session Search + 外部记忆提供器	OpenClaw 更直观，Hermes 更系统化
技能模型	AgentSkills 兼容，支持多层目录加载	AgentSkills 兼容，集中在 ~/.hermes/skills/，可自动创建和改进	Hermes 在“技能闭环”上更激进
自动化能力	有路由、多代理、节点、工具体系	有 Cron、子代理、并行委派、代码执行、MCP	Hermes 更像自动化工作平台
安全思路	单人可信边界、配对白名单、Exec 审批	七层防御、命令审批、容器隔离、MCP 过滤	Hermes 的安全分层更系统化
最适合的人	想先把 AI 助理接进日常消息入口的人	想搭长期运行、可学习、可自动化代理的人	选错入口，后续维护成本会明显变高

---

3.原理、架构与核心机制对比

3.1 OpenClaw：为什么它会长成一个 Gateway 中心架构？

OpenClaw 的官方文档里，有一条几乎可以当成“设计宣言”的描述：Gateway 是 sessions、routing 和 channel connections 的 single source of truth。

这句话非常关键，因为它决定了 OpenClaw 的整体长相。

3.1.1 OpenClaw 的核心原理

OpenClaw 的思路不是“让每个入口各自跑一份代理”，而是“让所有入口都连接到同一个长期运行的 Gateway，再由 Gateway 统一维护会话、路由和连接状态”。

这样做的好处非常现实：

1. 多渠道不会各玩各的。
   你可以从 Telegram 找它，也可以从 Web 控制台找它，甚至通过节点设备找它，但对底层系统来说，这些都是同一个总入口体系。

2. 统一会话与身份边界。
   一旦 Gateway 成为状态中心，谁在和代理说话、消息来自哪个渠道、应该路由给哪个 agent、要不要配对、是否允许执行某类操作，都能在一个中枢做决策。

3. 更适合个人助理场景。
   个人助理的典型特征不是“单次推理很强”，而是“我随时能找到它，而且它能在多个入口保持一致”。OpenClaw 的架构正是为这个需求定制的。

3.1.2 OpenClaw 的组件关系

用图来看会更直观：

flowchart LRU1[用户: Telegram / WhatsApp / Discord]U2[用户: Web Control UI / CLI]N[节点: iOS / Android / macOS]G[OpenClaw Gateway]A[Agent Runtime]W[Workspace\nAGENTS.md / MEMORY.md / skills]T[Tools / Plugins]M[模型提供商]U1 --> GU2 --> GN --> GG --> AA --> WA --> TA --> M

这个图的重点不是“它也有模型、也有工具”，而是：所有外部入口先汇入 Gateway，再由 Gateway 组织后面的代理能力。

从官方 Gateway 架构文档可以提炼出几条重要事实：

• 单个长期运行的 Gateway 负责所有消息表面。
• Control-plane 客户端（macOS app、CLI、Web UI、自动化程序）通过 WebSocket 连到 Gateway。
• 节点设备也通过 WebSocket 接入，但会带上自己的 role: node 与能力声明。
• 默认绑定地址是 127.0.0.1:18789。

对初学者来说，这意味着一个非常重要的认知：

OpenClaw 的“主语”不是某个聊天窗口，而是 Gateway 这个长期运行的中枢。

3.1.3 OpenClaw 的多代理与工作区隔离

很多人一看到“个人助理”会误以为它只能单体使用，但 OpenClaw 官方文档明确支持 Multi-Agent Routing。

它的多代理设计不是在一个上下文里塞很多 persona，而是：

• 每个 agent 有自己的 workspace。
• 每个 agent 有自己的 agentDir。
• 每个 agent 有自己的 sessions 存储。
• 不同渠道、账号、发送者可以通过 bindings 路由到不同 agent。

这点很值得肯定，因为它符合工程上的一个基本原则：隔离比提示词伪装更可靠。

也就是说，OpenClaw 不是靠“你现在假装自己是 A，现在又假装自己是 B”来扮演多个助理，而是给每个 agent 单独的工作区、技能、会话与认证边界。

对初学者的启发是：

• 如果你只想要一个自己的随身助理，默认单 agent 就够了。
• 如果你想把“生活助理”“工作助理”“内容助理”拆开，OpenClaw 已经提供了比较干净的隔离思路。

3.1.4 OpenClaw 的记忆模型为什么对新手友好？

OpenClaw 的记忆设计很“朴素”，但这恰恰是它好理解的地方。

官方文档说明它的记忆直接写在工作区的 Markdown 文件里，核心包括：

• MEMORY.md：长期记忆
• memory/YYYY-MM-DD.md：每日上下文
• DREAMS.md：可选的 Dream Diary / 总结层

这有两个非常大的优点：

1. 可审计。
   你能直接打开文件看代理到底记了什么，而不是只能猜。

2. 可修正。
   如果代理记错了，或者你想重新整理长期背景，直接改 Markdown 即可。

这类设计特别适合刚上手 Agent 的人，因为你能把“记忆”当成真实文件系统来理解，而不是抽象的 embedding 魔法。

当然，它不是没有代价。代价是：

• 需要你更主动地维护工作区质量。
• 当规模继续扩大时，单纯文件记忆可能不如更系统的检索/外部记忆架构灵活。

但对于“先把个人助理跑起来”这件事，它非常实用。

3.1.5 OpenClaw 的工具、技能、插件三层模型

OpenClaw 官方文档把能力拆成三层，这个拆法非常清晰：

1. Tools：代理真正调用的能力，比如 exec、browser、web_search、message。
2. Skills：通过 SKILL.md 教代理“什么时候、如何用工具”。
3. Plugins：把渠道、工具、技能、搜索、媒体理解等能力打包起来。

这个拆分很重要，因为很多初学者会把“工具”和“技能”混成一回事。

实际上：

• 工具决定“能不能做”。
• 技能决定“知不知道什么时候该这样做”。
• 插件决定“怎么把多种能力装配成一个可扩展系统”。

从工程角度讲，OpenClaw 的这个分层相当健康。它让你可以：

• 不改核心代码，只加技能。
• 不改技能，只换工具策略。
• 不改主程序，只通过插件扩渠道或扩能力。

3.1.6 OpenClaw 的安全模型：为什么它强调“个人可信边界”？

OpenClaw 官方安全文档写得很直白：它默认假设一个 Gateway 对应一个 trusted operator boundary，也就是一个可信的个人边界，而不是面向互相敌对用户的共享多租户安全边界。

这句话很多人会忽略，但它其实是在帮你避免严重误用。

它的意思是：

• 用它给自己搭个人助理，很合适。
• 用它给一个小团队中彼此信任的人搭工具，也可能可以。
• 但如果你想让互不信任的多个用户共用同一套代理与凭据，那就超出它的默认安全假设了。

OpenClaw 在保护措施上也不是没有动作。它至少有几层关键保护：

• DM pairing：陌生发送者需要显式配对。
• Node pairing：新节点接入需要审批。
• Exec approvals：代理要在真实宿主机执行命令时，需要策略、白名单与用户审批共同允许。
• Sandboxing：可以把代理运行在隔离的 sandbox runtime 中。

这里最值得初学者记住的一点是：

OpenClaw 的安全思路，不是把风险假装不存在，而是承认“个人助理天然高权限”，所以要通过 pairing、审批和沙箱把风险关进笼子里。

3.1.7 一句话总结 OpenClaw 的架构气质

如果非要给 OpenClaw 的架构气质下一个定义，我会这样说：

它不是先发明一个最“聪明”的代理大脑，而是先搭一个最适合“让助理真正进入你生活和工作入口”的基础设施。

这也是为什么它对“消息入口”“节点接入”“会话路由”“工作区可见性”如此上心。

---

3.2 Hermes Agent：为什么它会长成一个“自学习运行时”？

如果说 OpenClaw 的设计起点是“入口与中枢”，那 Hermes Agent 的设计起点几乎相反：它关心的是代理长期运行时，内部到底如何积累、调用、自动化与扩展。

3.2.1 Hermes 的核心原理

Hermes 的设计核心，可以概括为一句话：

代理不是一次性的聊天回合，而是一个会不断沉淀能力、维持状态并自主运行的长期系统。

从 Hermes 官方文档里能看到它非常强调几个能力闭环：

• 长期记忆闭环
• 技能生成与复用闭环
• 会话检索闭环
• 定时任务闭环
• 子代理委派闭环
• MCP 扩展闭环

换句话说，Hermes 把 Agent 看成一个长期演化的“软件主体”，而不是简单的消息机器人。

3.2.2 Hermes 的系统骨架

Hermes 的官方架构文档给出的核心非常明确：一个统一的 AIAgent 类服务于 CLI、Gateway、ACP、Batch、API Server 等多个入口。

这意味着 Hermes 的重心不是入口本身，而是把不同入口都接到同一个运行时核心。

可以用下面这张图来理解：

flowchart LRU[用户: CLI / TUI / Telegram / Discord]GW[Hermes Gateway]AI[AIAgent 核心循环]PT[Prompt System]TS[Tool Registry\n47 tools / 19 toolsets]ENV[Terminal Backends\nlocal / Docker / SSH / Modal / Daytona / Singularity]MEM[Memory\nMEMORY.md / USER.md / Session Search]SK[Skills / Plugins / MCP]CR[ Cron / Delegation ]M[模型提供商]U --> GWU --> AIGW --> AIAI --> PTAI --> TSTS --> ENVAI --> MEMAI --> SKGW --> CRCR --> AIAI --> M

这张图里最关键的不是模块多，而是模块之间的职责边界更“运行时化”：

• Prompt system 负责系统提示构建。
• Tool registry 负责工具发现、调度和可用性判定。
• Session persistence 负责会话与历史检索。
• Gateway 只是一个入口，不是唯一主角。
• Cron 与 delegation 都是一等公民，而不是外挂脚本。

3.2.3 Hermes 为什么更像“代理操作系统”？

Hermes 官方架构文档里，有几个设计原则特别能说明问题：

• Prompt stability：系统提示在会话中途不随意变化，避免破坏缓存与稳定性。
• Observable execution：每一次工具调用尽量可观察。
• Interruptible：执行过程可中断。
• Platform-agnostic core：同一个 AIAgent 核心服务多个平台入口。
• Profile isolation：不同 profile 拥有独立的配置、记忆、会话和 gateway PID。

这类原则其实已经很接近“操作系统级运行时”的思路了。

一个成熟的 Agent 系统，最终都得面对这些问题：

• 执行中能不能打断？
• 同一套核心能不能服务多个入口？
• 多个工作身份能不能隔离？
• 记忆写入后会不会破坏当前会话稳定性？
• 工具注册是不是足够规范？

Hermes 没有回避这些问题，而是把它们提升成一等设计对象。

这也是为什么很多开发者第一次用 Hermes，会感觉它不像“一个 bot”，而像“一个给 Agent 设计的操作环境”。

3.2.4 Hermes 的工具系统为什么更适合重自动化？

官方架构文档里明确提到，Hermes 有 47 个注册工具、19 个 toolsets，并且支持 6 种终端后端：

• local
• Docker
• SSH
• Daytona
• Singularity
• Modal

这个数字本身不是重点，重点是它背后的工程含义：

1. 工具不是临时拼接的。
   它们通过统一注册表进行发现、调度和错误包装。

2. 执行环境是可切换的。
   你今天在本地跑，明天切到 Docker，后天切到远端 SSH 或 Modal，不需要重写代理概念层。

3. 工具集合可以按场景收缩。
   这对安全尤其重要。不是所有场景都该把所有工具开满。

对于初学者，这里要理解的重点不是“47 比 20 更强”，而是：

Hermes 把“代理能做什么”这件事，做成了一个结构化的系统，而不是一堆散装命令。

3.2.5 Hermes 的记忆系统为什么更“分层”？

Hermes 的官方文档把记忆明确拆成了几层：

1. MEMORY.md
   记录环境事实、项目约定、经验教训。

2. USER.md
   记录用户偏好、沟通习惯、身份信息。

3. Session Search
   所有 CLI 与消息会话进入 SQLite，并支持 FTS5 全文搜索与总结。

4. External Memory Providers
   还可以外挂额外的记忆提供器。

这说明 Hermes 的记忆观不是“只要长期记一点东西就够了”，而是：

• 有些信息必须始终在 prompt 里，属于高价值小体积记忆。
• 有些信息不该常驻，但应当可检索。
• 有些信息需要交给更外部化、更结构化的记忆系统处理。

同时，Hermes 特别强调一个点：memory 是 frozen snapshot。

也就是说：

• 会话开始时，记忆会被注入系统提示。
• 会话中如果新写入记忆，会马上落盘。
• 但这段新记忆不会立刻重写当前系统提示，而是留到下一个会话再生效。

这背后的目的，是保持 prompt 稳定和缓存收益。

对初学者来说，这种设计虽然比 OpenClaw 的文件记忆更复杂，但它更接近一个成熟代理系统在长期使用中的真实需求：不是只要“记住”，还要“记得稳”“记得省”“记得可搜索”。

3.2.6 Hermes 的技能系统为什么更像“过程知识库”？

Hermes 官方主页和技能文档都反复强调一件事：技能不是装饰，而是代理的procedural memory，也就是“过程型记忆”。

什么意思？

举个最简单的例子：

• 记忆告诉代理：这个项目用的是 Rust。
• 技能告诉代理：在这个项目里，排查构建失败时先跑什么，再看哪里，再如何报告。

Hermes 进一步强调：

• 技能按需加载，减少 token 开销。
• 所有技能集中在 ~/.hermes/skills/。
• 每个技能都可以作为 slash command 使用。
• 代理可以在解决复杂任务后生成新的技能，后续复用。

这就是 Hermes 最有辨识度的地方之一：它想把“今天学到的做事方法”固化下来，而不只是把“今天聊过的内容”存下来。

3.2.7 Hermes 的 Cron 与 Delegation：为什么它更适合长期自动化？

Hermes 的官方 Cron 文档很清楚地说明了两点：

1. Cron 是一等功能，不是外部拼接脚本。
2. 每个 Cron 任务都运行在 fresh agent session 里。

这个设计非常成熟。

它避免了很多自动化系统的典型问题：

• 上一次任务残留上下文污染下一次任务。
• 多次调度叠加成难以解释的行为。
• 脚本和代理逻辑割裂，维护体验差。

Hermes 的 delegation 也同样体现了运行时思维：

• 子代理拿到的是隔离上下文。
• 子代理有自己的终端会话。
• 父代理只接收最终摘要，而不是把所有中间过程都塞回主上下文。
• 最多并行 3 个子代理，控制复杂度。

这意味着 Hermes 很适合做这类任务：

• 并行调研多个主题
• 把大任务拆成多个独立分析流
• 用新上下文重新审视问题，避免主上下文偏见
• 把重复性复杂操作变成 Cron + Skills 组合

如果你要搭的是“长期跑、持续产出、可调度、可拆分”的代理，Hermes 天生更占优势。

3.2.8 Hermes 的安全模型为什么更“企业化”

Hermes 官方安全页把安全分成了七层：

1. 用户授权
2. 危险命令审批
3. 容器隔离
4. MCP 凭据过滤
5. 上下文文件扫描
6. 跨会话隔离
7. 输入净化

这是一种非常明显的 defense-in-depth 思路。

它不是假设某一道防线永远不会失败，而是假设：

• 用户可能配错
• 工具可能被滥用
• MCP 可能暴露过宽
• 工作目录和上下文文件都可能被注入

所以需要多层叠加。

对于初学者，这里最重要的启示是：

当一个代理越来越像“自动运行的数字员工”，安全就不再是附加项，而是架构本体。

3.2.9 一句话总结 Hermes 的架构气质

如果也给 Hermes 下一个定义，我会这样说：

它不是先考虑“你怎么找到代理”，而是先考虑“代理长期活着以后，如何记忆、调度、扩展、委派、复盘和成长”。

这就是为什么 Hermes 看起来更像一个“代理操作系统”。

---

3.3 记忆、技能、工具与扩展：两者最关键的机制差异

为了避免“看起来都支持，所以差不多”的误判，这里把最关键的机制差异拆开说。

3.3.1 入口层差异

OpenClaw 的入口层更强。

它天然以消息渠道、Control UI、节点设备为第一优先级。对很多人来说，真正的价值不是“这个 Agent 理论上可以做什么”，而是“我能不能在手机上 10 秒内找到它”。OpenClaw 抢的就是这 10 秒体验。

Hermes 的入口层也不弱，官方文档显示它支持 CLI、Telegram、Discord、Slack、WhatsApp、Signal、Email 等多个平台，但它的文档气质明显更偏“先把代理运行时跑稳，再扩入口”。

所以：

• 如果你是交互触点优先，OpenClaw 更顺手。
• 如果你是运行闭环优先，Hermes 更顺手。

3.3.2 记忆层差异

OpenClaw 的记忆更透明、可手改、工作区导向。

Hermes 的记忆更分层、带容量控制、带会话搜索、还可外挂外部 provider。

这没有绝对优劣，关键看需求：

• 想快速理解、手工修正、直接看文件：OpenClaw 更友好。
• 想长期积累、可检索、可扩展、可控 token 成本：Hermes 更成熟。

3.3.3 技能层差异

两者都支持 AgentSkills，这是一个很大的共同点。

但 OpenClaw 更像“技能是工作区的一部分”；Hermes 更像“技能是代理成长机制的一部分”。

OpenClaw 在技能加载层次上更细，支持：

• 额外目录
• bundled skills
• ~/.openclaw/skills
• ~/.agents/skills
• 项目级 .agents/skills
• 工作区 skills/

Hermes 则更集中，默认以 ~/.hermes/skills/ 为主源，并强调按需加载与 slash command 直达。

3.3.4 自动化层差异

OpenClaw 擅长把代理变成一个随时可联系、可路由、可多入口访问的个人助理。

Hermes 更擅长把代理变成一个：

• 会定时运行
• 会并行拆任务
• 会检索历史
• 会通过 MCP 扩展外部系统
• 会从经验中形成技能

的长期自动化系统。

对很多工程团队来说，真正影响效率的不是“能不能回答一个问题”，而是“这个系统能不能自己稳定地做掉 30% 的重复工作”。在这一点上，Hermes 的答案更完整。

3.3.5 工程心智差异

我建议你把它们分别记成两种比喻：

• OpenClaw = AI 助理总机
• Hermes Agent = AI 代理运行时

一旦这样记，很多选择就会变得清晰：

• 我要的是“随时能联系到它”还是“长期能自己干活”？
• 我要的是“对话入口管理”还是“任务生命周期管理”？
• 我要的是“先上手跑起来”还是“先把长期系统打稳”？

---

3.4 安全、权限与风险控制：选型时最容易被忽视的一环

很多比较文章喜欢谈模型、速度、功能，却不谈安全。实际上，对 Agent 系统来说，安全不是附属功能，而是决定它能否长期可用的基础设施。

3.4.1 OpenClaw 的安全哲学

OpenClaw 的安全哲学很清楚：

• 它假设你在做个人助理，而不是公有多租户平台。
• 它通过 pairing、allowlist、exec approvals、sandboxing 来控制风险。

这种哲学的好处是非常务实：

• 新手容易理解。
• 配置路径清晰。
• 安全措施和使用场景高度匹配。

它的风险点在于：

• 如果你忽略官方信任边界假设，强行把它拿去做复杂多租户共享，就会超出设计预期。
• 如果你把 Gateway 暴露出去，却没有做好白名单、pairing 和执行审批，风险会上升得很快。

3.4.2 Hermes 的安全哲学

Hermes 的安全哲学更偏“多层防御”和“长期运行风险控制”。

它关心的不只是：

• 谁能发消息给代理

还关心：

• 这个命令是不是危险命令
• 这个 MCP 子进程能看到哪些环境变量
• 这个上下文文件是否存在注入问题
• 这个 cron 任务是否会递归制造更多 cron
• 这个会话的数据边界有没有被破坏

这种设计更适合长期自动化系统，因为代理一旦开始：

• 定时运行
• 访问外部系统
• 使用更多工具
• 和更多平台打通

风险面就会迅速变宽。

3.4.3 初学者应该如何理解“安全成本”？

一句话：代理越有行动能力，安全边界就越重要。

所以别只看“能不能自动发消息”“能不能自动跑命令”，还要看：

• 谁批准？
• 在哪执行？
• 能访问哪些目录？
• 会不会误发？
• 失败了怎么停下来？

从这个角度看：

• OpenClaw 更适合“先在个人边界内把事情跑顺”。
• Hermes 更适合“从一开始就按长期自动化系统来治理”。

---

4.用途、实践与前景

4.1 OpenClaw 实战：把聊天入口变成真正可用的随身 AI 助理

这一节我们不搞空泛概念，直接给一个适合初学者的最小可行方案。

目标很简单：

在自己的机器上启动 OpenClaw，打开 Control UI，并给它一套最基础的安全限制和博客写作技能。

4.1.1 安装与初始化

根据 OpenClaw 官方文档，推荐前提是 Node 24，Node 22.14+ 也支持。

你可以按下面的方式安装并初始化：

# 方式一：使用官方安装脚本，适合大多数新手
curl -fsSL https://openclaw.ai/install.sh | bash# 运行引导流程，自动配置模型提供商、Gateway 和基础环境
openclaw onboard --install-daemon# 检查 Gateway 是否已经启动
openclaw gateway status# 打开浏览器控制台，默认是本机 18789 端口
openclaw dashboard

如果你更习惯 npm 方式，也可以使用：

# 这种方式适合你已经有稳定的 Node 环境
npm install -g openclaw@latest# 初始化并安装后台服务
openclaw onboard --install-daemon

这一阶段你应该得到什么结果？

• 本地有一个长期运行的 Gateway。
• 浏览器能打开 Control UI。
• 你已经配置好至少一个模型提供商。
• 你可以先在 Web 控制台里对话，再决定是否接 Telegram、WhatsApp 等渠道。

4.1.2 一份新手足够用的 OpenClaw 配置示例

下面给一份面向“个人助理”场景的最小配置示例：

{// 这个工作区会存放 AGENTS.md、MEMORY.md、skills 等文件agents: {defaults: {workspace: "~/.openclaw/workspace"}},// 这里用飞书举例：私聊只允许白名单用户，群聊只允许指定群并要求 @ 提及channels: {feishu: {// 私聊只允许白名单用户访问dmPolicy: "allowlist",allowFrom: ["ou_1234567890abcdef"],// 群聊只允许白名单群接入groupPolicy: "allowlist",groupAllowFrom: ["oc_group_chat:topic:om_topic_root"],// 群聊默认要求先 @ 机器人，减少误触发requireMention: true,// 也可以针对具体群单独覆写策略groups: {"oc_group_chat:topic:om_topic_root": {requireMention: true}}}},// 群聊里只有命中这些提及模式时才响应messages: {groupChat: {// 这里保留统一群聊策略，便于后续扩展其他渠道mentionPatterns: ["@openclaw"]}}
}

这份配置体现了 OpenClaw 的一条最佳实践：先缩小可触达范围，再逐步放开能力。

很多人第一次玩 Agent，就急着把它接进所有渠道、所有群、所有联系人，最后不是误触发，就是风险不可控。正确做法正好相反：

1. 先只给自己用。
2. 先只开一个渠道。
3. 先只用白名单。
4. 先只在明确提及时响应。

4.1.3 给 OpenClaw 加一个博客写作技能

OpenClaw 支持 AgentSkills 兼容技能。对内容创作者或技术博主来说，最有价值的不是“让代理自由发挥写文章”，而是把写作流程固化成技能。

你可以在工作区下创建：

~/.openclaw/workspace/skills/tech-blog-writer/SKILL.md

---
name: tech-blog-writer
description: 面向初学者整理技术博客，先讲结论，再讲原理，再给代码示例。
---<!-- 这个技能用于规范技术博客的输出流程 -->
# Tech Blog Writer## 何时使用
- 当用户给出一个技术主题，希望生成完整博客草稿时
- 当主题涉及多个方案对比，需要表格、示例和选型建议时## 工作步骤
1. 先识别读者是谁：初学者、普通工程师，还是架构师
2. 先给结论，再讲原理，避免一上来堆背景知识
3. 如果涉及对比，必须输出对比表
4. 如果涉及工具或框架，至少给一个可运行示例
5. 结尾给出“适用场景、限制、风险”## 输出约束
- 关键术语第一次出现时，用一句白话解释
- 避免空话和营销化表达
- 代码示例尽量短，并带必要注释

这个技能的价值不是“让模型更会写”，而是让代理知道：写一篇合格的技术博客，应该按什么流程输出。

这也是 Agent 和普通聊天机器人的一个核心差异：

• 普通聊天更像临场发挥。
• Agent 技能更像把经验沉淀成可重复执行的方法。

4.1.4 给 OpenClaw 准备一份长期记忆

既然 OpenClaw 的记忆是工作区文件，那就要善用它的透明性。

你可以在 ~/.openclaw/workspace/MEMORY.md 里先写入：

# 长期偏好- 用户写技术博客时，默认读者是初学者和 1 到 3 年经验工程师。
- 代码示例优先使用 bash、yaml、python。
- 对比类文章必须包含“适用场景”和“不适用场景”。
- 发布前需要检查标题是否足够具体，避免空泛词汇。

这类内容特别适合放进 OpenClaw 的长期记忆里，因为它们：

• 经常复用
• 体积不大
• 对输出风格影响非常稳定

4.1.5 OpenClaw 的典型实践场景

如果你按上面的方法搭好一个最小系统，OpenClaw 特别适合下面几类用法：

1. 随身内容助理
   你在手机上把灵感、语音、链接发给它，让它回到工作区里整理。

2. 多入口统一助理
   在电脑上用 Control UI，在外面用 Telegram 或 WhatsApp，对的是同一个助理体系。

3. 项目入口分流
   不同 agent 对应不同工作区和人格，把生活、工作、内容创作分开。

4. 个人知识工作台
   用工作区文件、技能与记忆，把“你自己的工作方法”外化出来。

4.1.6 OpenClaw 对新手最常见的三个误区

误区一：把工作区当成默认沙箱。

官方文档明确提醒，工作区默认是代理的 cwd，但不是强制安全沙箱。你要真正限制访问范围，需要结合 sandbox 配置。

误区二：还没做好 allowlist 就把渠道全接进来。

这类配置在演示里看起来很酷，实际是风险放大器。

误区三：技能写得像宣传文案，不像操作说明。

技能不是“写给人看的广告”，而是“写给代理看的做事说明书”。越具体，越有执行价值。

---

4.2 Hermes Agent 实战：搭一个会记忆、会定时、会扩展的常驻型代理

下面换到 Hermes Agent。

这一节的目标是：

启动一个适合长期使用的 Hermes 基础环境，让它具备模型配置、持久记忆、MCP 文件系统接入，以及博客巡检类定时任务。

4.2.1 安装与初始化

Hermes 官方 Quickstart 给出的建议非常直接：

• 用一键安装脚本安装
• 先用 hermes model 或 hermes setup 把模型配置跑通
• 再去叠加 gateway、cron、skills、voice、routing

基础安装命令如下：

# 官方一键安装方式，适合 Linux / macOS / WSL2 / Termux
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash# 重新加载 shell，让 hermes 命令生效
source ~/.zshrc# 先走交互式模型配置，这是最关键的一步
hermes model# 如果你想让 Hermes 一次性帮你完成基础设置
hermes setup

Hermes 官方文档还特别提醒了一点：模型上下文至少需要 64K tokens。

这条提醒非常重要，因为很多新手会直接拿一个小上下文模型来跑，然后得出“Agent 不稳定”“经常忘事”的结论。实际上，这并不一定是系统问题，而是模型窗口根本不够支撑多步工具调用。

4.2.2 一份适合长期使用的 Hermes 配置示例

Hermes 会把 secrets 存在 ~/.hermes/.env，把非敏感配置放在 ~/.hermes/config.yaml。这比把一切都塞进一个文件里更工程化。

下面给一份偏“博客与项目工作流”场景的示例：

# 选择默认模型；这里用 OpenAI 风格命名举例
model: openai/gpt-5.4terminal:# 用 Docker 后端跑终端工具，降低直接碰宿主机的风险backend: dockermemory:# 开启代理自己的长期记忆memory_enabled: true# 开启用户画像，让代理记住你的写作和沟通偏好user_profile_enabled: true# 这里沿用官方默认量级，保持记忆紧凑memory_char_limit: 2200user_char_limit: 1375cron:# 关闭包裹输出，让定时报告更像正常正文wrap_response: falsemcp_servers:project_fs:# 用 MCP 文件系统服务器，把博客项目目录暴露给 Hermescommand: npxargs:- -y- "@modelcontextprotocol/server-filesystem"- /Users/yourname/projects/blog

这份配置其实体现了 Hermes 的四个关键思想：

1. 模型配置是系统级入口。
2. 执行环境要可替换、可隔离。
3. 记忆要有上限，不要无限膨胀。
4. 外部工具生态最好通过 MCP 以标准方式接入。

4.2.3 先验证一个真实对话，再做复杂自动化

Hermes 官方文档给的建议非常工程化：先确认普通对话能正常工作，再叠加高级功能。

你可以先在项目目录里启动：

# 经典 CLI 入口
hermes# 如果你更喜欢现代 TUI，可以这样启动
hermes --tui

然后直接给一个容易验证的提示词：

请用 5 个要点概括当前仓库的作用，并告诉我最可能的入口文件是什么。

这一步的意义非常大，因为它能帮助你快速分辨问题到底出在哪一层：

• 如果连普通对话都跑不稳，先不要急着上 Cron 和 MCP。
• 如果普通对话稳、文件读写稳，再继续叠加自动化才是正确顺序。

4.2.4 给 Hermes 增加一个博客巡检定时任务

Hermes 的 Cron 是它最实用的亮点之一。

假设你的博客仓库里经常会出现这些问题：

• 新文章没写摘要
• 没加标签
• 标题不具体
• 没有配图占位

你可以直接创建一个每日巡检任务：

# 每天上午 9 点巡检博客目录，并把结果保存在本地 cron 输出目录
hermes cron create --schedule "every 1d at 09:00" \--workdir /Users/yourname/projects/blog \--prompt "检查当前博客项目中的 Markdown 文章，找出缺少摘要、缺少标签、标题过于空泛、没有封面占位的文章。请按文件名输出问题列表，并给出最短修复建议。"

这个例子非常能体现 Hermes 的运行时思路：

• 任务不是 shell cron + Python 脚本拼出来的。
• 它是一个真正的 agent session。
• 这个 session 继承工具体系，但会在 fresh context 里运行。
• 输出默认可落到本地，也可以再接消息平台分发。

如果你已经接好了 Telegram 或其他消息平台，也可以通过对话方式直接说：

每天早上 9 点检查我的博客仓库，把缺少摘要和标签的文章汇总后发给我。

Hermes 会在内部使用统一的 cronjob 工具去完成这件事。

4.2.5 用子代理并行做技术调研

Hermes 的另一个实用点，是子代理委派。

假设你要写一篇“不同 AI Agent 框架的比较文章”，你完全可以让 Hermes 并行跑几个独立调研流。

官方文档里的 delegate_task 用法大致如下：

# 这个示例展示 Hermes 内部的委派思路：把多个主题分给独立子代理并行处理
delegate_task(tasks=[{"goal": "调研 OpenClaw 的官方定位与架构特点","context": "重点关注 Gateway、多渠道接入、工作区与安全模型","toolsets": ["web"]},{"goal": "调研 Hermes Agent 的官方定位与架构特点","context": "重点关注 learning loop、memory、cron、delegation、MCP","toolsets": ["web"]},{"goal": "整理两个项目的共同点和差异点","context": "重点关注初学者选型、长期自动化和消息入口差异","toolsets": ["web"]}
])

这段示例不是让你手动去调这个 API，而是帮助你理解 Hermes 的做事方式：

• 子代理不是共享同一份上下文。
• 每个子代理都要得到明确 goal 和 context。
• 只把最后总结回传给主代理，避免主上下文被调研噪音淹没。

这对于复杂写作、并行调研、代码审查、方案评估都非常有用。

4.2.6 给 Hermes 放一个可复用技能

Hermes 的技能默认在 ~/.hermes/skills/ 下。下面给一个适合博客场景的技能示例：

~/.hermes/skills/blog-quality-check/SKILL.md

---
name: blog-quality-check
description: 审查技术博客草稿，重点检查结构、术语解释、示例完整性和结论明确度。
---<!-- 这个技能用于统一博客质检流程 -->
# Blog Quality Check## 何时使用
- 当用户已经有博客草稿，希望快速做结构化审查时## 检查清单
1. 标题是否具体，而不是只有大词
2. 开头是否在 3 段内说明“这篇文章解决什么问题”
3. 术语第一次出现时，是否有白话解释
4. 代码示例是否能说明核心逻辑，而不是堆无关细节
5. 结尾是否给出适用场景、限制和风险## 输出格式
- 先列出严重问题
- 再列出可优化问题
- 最后给一版建议大纲

和 OpenClaw 很像，技能本身仍然是 Markdown。但 Hermes 对技能的理解更进一步：它把技能当成长期过程知识，未来还可能由代理自己迭代。

4.2.7 Hermes 对新手最常见的四个误区

误区一：还没把基础对话跑通，就急着上 MCP、Cron、子代理。

这会让你不知道故障到底出在哪一层。

误区二：用上下文窗口太小的模型。

官方已经明确要求至少 64K，不要忽视。

误区三：Cron 提示词写得过于模糊。

Hermes 官方文档也强调了：Cron 是 fresh session，提示词必须自包含。像“检查那个问题”这种提示，几乎肯定会导致结果不稳定。

误区四：把所有 toolsets 都开满。

工具越多，风险面越大，也越容易让代理分散注意力。先收紧，再按需放开。

---

4.3 一个很实用的交叉点：同一份 Skill，如何同时服务 OpenClaw 与 Hermes？

这是我认为很多比较文章没讲透，但实际很有价值的点。

OpenClaw 与 Hermes 虽然设计重心不同，但它们都兼容 AgentSkills。也就是说，你的“方法论资产”并不会因为换了运行时就完全作废。

下面给一个可同时在两边复用的技能模板：

---
name: compare-tech-options
description: 对多个技术方案做面对初学者的结构化对比，输出结论、差异、适用场景和风险。
---<!-- 这个技能可以同时放进 OpenClaw 或 Hermes 的技能目录 -->
# Compare Tech Options## 目标
把“多个技术方案的零散信息”整理成读者容易理解的对比结果。## 工作步骤
1. 先说明比较对象分别是什么
2. 先给一句话总结，再展开细节
3. 必须输出表格，至少包含定位、优点、限制、适用场景
4. 对初学者必须补一句白话解释
5. 如果有实践建议，要给最小可执行步骤## 输出约束
- 不要只说“看场景”，要明确举例
- 不要只有优点，没有限制
- 不要只比功能，要比心智成本和维护成本

在 OpenClaw 里，你可以把它放进：

• <workspace>/skills/compare-tech-options/SKILL.md

在 Hermes 里，你可以把它放进：

• ~/.hermes/skills/compare-tech-options/SKILL.md

这意味着什么？

意味着你未来真正值钱的部分，不只是“你选了哪个 Agent 框架”，而是：

• 你积累了哪些高质量技能
• 你把哪些工作流结构化了
• 你把哪些偏好、边界与审查标准沉淀下来了

从长期价值看，方法论资产往往比某一个具体框架本身更稳定。

---

4.4 典型用途、选型建议与实践路线

说了这么多，最后还是要落回一个现实问题：到底怎么选？

我给你一个尽量直接的判断表。

场景	更推荐 OpenClaw	更推荐 Hermes Agent	原因
想把 AI 接进 社交软件 / Web 控制台，形成随身助理	是	也可，但不是第一优先	OpenClaw 天然是 Gateway 心智
想让代理长期跑在 VPS 上，做自动化、定时任务、并行调研	可做，但不是最强项	是	Hermes 的 Cron、Delegation、运行时更强
想要透明可编辑的工作区记忆	是	也支持，但更分层	OpenClaw 的 Markdown 记忆最直观
想要跨会话搜索、外部记忆 provider、结构化长期沉淀	一般	是	Hermes 的记忆体系更完整
想做一个“先能联系到，再慢慢增强”的个人助理	是	也可以	OpenClaw 更适合从入口切入
想做一个“先把自动化闭环跑稳，再扩消息平台”的智能工作体	一般	是	Hermes 更像长期运行时
想做多代理、不同 persona、不同工作区隔离	是	是	两者都支持，但侧重点不同
想把技能当成长期方法资产积累	是	是，且更激进	两者都兼容 AgentSkills

如果你希望一句话判断：

• 你要的是“随时在消息入口找到 AI 助理”，优先选 OpenClaw。
• 你要的是“让 AI 长期跑任务、积累能力、做自动化”，优先选 Hermes。

如果你还是拿不准，我建议按下面路线做：

1. 你是第一次接触 Agent：
   先选更符合你日常使用入口的那个，不要一开始追求全能。

2. 你主要是内容创作、生活助理、消息触达：
   先上 OpenClaw。

3. 你主要是开发、运维、研究、长期自动化：
   先上 Hermes。

4. 你后续一定会做复杂工作流：
   就算先上 OpenClaw，也要尽早理解 Hermes 这类“运行时优先”的设计。

---

4.5 前景：从 2026 年看，这两条路线会怎么演进？

这一部分带一点判断性质，我会明确告诉你：以下内容不是官方原话，而是基于当前官方架构、功能布局和生态方向做出的推断。

4.5.1 OpenClaw 的前景

从当前文档与产品形态看，OpenClaw 很可能会继续强化下面几条路线：

1. 更多聊天与设备入口整合
   也就是让 AI 助理真正进入“你已经在用的沟通网络”。

2. 更成熟的多代理路由
   包括不同身份、不同工作区、不同渠道账号的隔离与治理。

3. 更强的工作区与节点协同
   比如移动端节点、Canvas、设备能力和实时消息交互结合。

4. 更个人化的长期助手形态
   不是“给所有人一个统一 AI 产品”，而是“给每个人一套自己的 AI 基础设施”。

如果这条路线走通，OpenClaw 会越来越像：

一个围绕“个人 AI 助理可达性”构建的操作中枢。

4.5.2 Hermes Agent 的前景

Hermes 的发展路线看起来更偏向下面几个方向：

1. 更强的学习闭环
   技能生成、自我改进、长期记忆、用户建模会继续成为核心。

2. 更成熟的自动化运行时
   Cron、delegation、execute_code、MCP、profiles 这些会越来越像完整平台，而不是功能拼盘。

3. 更强的代理工程化
   包括安全分层、执行观察、上下文治理、环境后端、性能与缓存策略。

4. 更靠近研究与生产之间的中间层
   既能做开发自动化，也能服务 RL/trajectory/data generation 这类研究工作。

如果这条路线继续向前走，Hermes 很可能会越来越像：

一个面向长期运行、自主执行与经验沉淀的 Agent OS。

4.5.3 两者共同的趋势

尽管侧重点不同，但我认为它们最终会在几个大方向上汇合：

1. 标准化工具生态
   MCP 会越来越重要。

2. 可移植技能生态
   AgentSkills 这类标准会越来越值钱。

3. 记忆分层化
   “长期常驻记忆 + 可检索历史 + 外部知识层”会成为主流组合。

4. 更强的安全与审计
   真正能进生产的 Agent，必须能解释自己做了什么、为什么能做、谁批准了它做。

5. 从“聊天产品”走向“长期工作体”
   未来最有价值的代理，不是最会对话的那个，而是最能在长期上下文中稳定完成任务的那个。

---

5.总结

如果你把这篇文章读到这里，其实已经能把 OpenClaw 和 Hermes Agent 的本质差异说清楚了：

OpenClaw 的强项，在于它把 AI 助理真正带进了多渠道、可触达、可路由、可工作区化的个人使用场景里。它更像一个以 Gateway 为核心的“AI 助理中枢”，非常适合先从消息入口和个人助理体验切入。

Hermes Agent 的强项，在于它把 Agent 当成一个长期运行、会积累经验、会定时执行、会委派子任务、会接入外部工具生态的运行时系统来设计。它更像一个“会成长的代理操作环境”，非常适合开发自动化、研究助手、长期任务代理和生产级工作流。

所以，问题不是“谁更强”，而是“你的第一性需求是什么”：

• 如果你的第一需求是“我想在手机和聊天工具里随时叫到我的 AI 助理”，选 OpenClaw。
• 如果你的第一需求是“我想要一个能长期在线、会记忆、会自动跑任务的代理系统”，选 Hermes Agent。
• 如果你真正想做的是长期 AI 工作流，那么无论你从哪边起步，最终都要理解：入口、记忆、工具、自动化、安全，这五件事缺一不可。

从工程角度看，这两个项目都很有代表性。OpenClaw 代表了“AI 助理入口基础设施”这条路线，Hermes Agent 代表了“AI 代理长期运行时”这条路线。理解它们的差异，不只是为了选一个工具，更是为了帮助你理解：下一代 AI 软件，究竟会以什么方式进入真实世界。

---

6.结束语

这篇博客就和大家分享到这里，如果大家在研究学习的过程当中有什么问题，可以加群进行讨论或发送邮件给我，我会尽我所能为您解答，与君共勉！

另外，博主出新书了《Hadoop与Spark大数据全景解析》、同时已出版的《深入理解Hive》、《Kafka并不难学》和《Hadoop大数据挖掘从入门到进阶实战》也可以和新书配套使用，喜欢的朋友或同学， 可以在公告栏那里点击购买链接购买博主的书进行学习，在此感谢大家的支持。关注下面公众号，根据提示，可免费获取书籍的教学视频。