我一直在自托管的 Raspberry Pi 智能体设置上测试 Hermes 和 OpenClaw，简而言之：我更喜欢 Hermes。
这并不是因为 OpenClaw 不好。OpenClaw 令人印象深刻，特别是如果你想要的是一个广泛的个人 AI 助手，能够位于消息渠道背后，感觉像一个本地优先的助手。根据 OpenClaw 文档，它是围绕一个用于 WhatsApp、Telegram、Discord、iMessage 等渠道的 AI 智能体的全操作系统网关构建的。这是一个很强大的理念。
但在真实的本地环境中尝试两者之后，Hermes 的感觉更接近我实际运行智能体的方式：分离的角色、可重用的技能、成为操作上下文的记忆，以及可以在不变成一个巨大混乱助手的情况下持续工作的后台工作流。
这篇 Hermes 与 OpenClaw 的对比不是基准测试。这是在我自己的硬件上运行两者后的实用笔记。
通俗地说 Hermes 与 OpenClaw
在我看来，OpenClaw 作为以消息为先的个人 AI 助手最为强大。它为你提供了一个本地智能体网关、熟悉的工作区文件，以及围绕渠道、会话、技能、Web 界面、cron 任务和 Companion 应用不断增长的生态系统。如果你的主要问题是“如何与我 own 硬件上的 AI 智能体发消息？”，OpenClaw 会给你一个清晰的答案。
Hermes 则不同。根据 Hermes Agent GitHub 仓库，它是一个具有学习循环、技能、记忆、消息传递、MCP 集成、cron 调度、上下文文件以及从 OpenClaw 迁移支持的自我改进 AI 智能体。这种语言与其实际使用感受相符。Hermes 不仅仅关于与助手交谈，更是关于将重复性工作转化为可重用的行为。
这种差异比功能清单更重要。
使用 OpenClaw 时，我感觉自己是在配置一个强大的助手。而使用 Hermes 时，我感觉自己是在塑造一个小型的工作操作层。
我的设置不再只是一个演示
这很重要，因为 Raspberry Pi 智能体设置可以迅速从“有趣的实验”转变为“全天候运行的操作工具”。
一旦智能体开始帮助进行维护、研究、内容创作、行政任务或定期检查，问题就会发生变化。问题不再仅仅是模型能否回答，而是系统是否有清晰的边界。
这才是我关心的部分。我不想要一个拥有所有权限且个性模糊的单一智能体。我想要更小的操作身份：
Hermes 让这种结构感觉自然。我可以为每个角色塑造其自己的指令、记忆行为、工具和审批立场。高风险的工作流可以保守并在不确定时停止。内容工作流可以更具创造性。维护工作流可以直接且由清单驱动。
这比试图包罗万象的单一助手更接近真实操作。
配置文件边界即产品
我学到的最重要的一点是，智能体质量不仅关乎模型，还关乎模型周围的边界。
财务相关的助手不应表现得像内容助手。维护助手不应表现得像研究助手。记忆写入助手不应随意收集嘈杂的临时事实。每个角色都需要狭窄的工作范围、清晰的语气以及与风险相匹配的权限模型。
Hermes 让这种设计感觉平常。我可以在模型看到任务之前就分离工作。
这就是为什么 Hermes 与 OpenClaw 对我来说不仅仅是技术对比，而是工作流对比。
我喜欢 OpenClaw 的地方
OpenClaw 仍然拥有真正的优势。人们对其感到兴奋是有原因的。该项目围绕一个你可以从不同界面发消息的本地助手理念构建，其文档涵盖了会话、cron 任务、安全、Web 界面、技能、远程访问和移动 Companion 应用。
OpenClaw GitHub 仓库 也展示了生态系统的规模。这是一个以 TypeScript 为主的项目，拥有大量的社区动力。如果你的目标是实验一个通过消息应用交谈的个人助手，OpenClaw 是一个严肃的选择。
我也喜欢基于文件的个性模型。OpenClaw 工作区模式使用熟悉的文件来定义身份、指令、工具和用户上下文。这是一个很好的思维模型：助手有一个家、一个角色、本地笔记和记忆。
这很干净。它易于理解，易于解释，让助手感觉不那么一次性。
但对于我的用例，它仍然感觉更像是一个通用助手平台。我可以让它变得有用，但我必须更加努力才能获得那种分离的操作角色的感觉。
为什么 Hermes 更合适
Hermes 感觉更像是一个为那些希望不断改进工作流的人准备的智能体操作系统。
对我来说，最大的区别在于 Hermes 支持持久化、范围限定的工作的方式。
我不想要一个记住随机琐事的助手。我想要一个系统记住工作应该如何完成：使用什么风格、何时停止、什么需要验证、什么在未经批准的情况下绝不应发送到外部，以及哪些类型的任务属于哪个角色。
这种记忆是实用的。它不是为了让助手感觉更个性化，而是为了让重复性工作更不容易出错。
Hermes 还让配置文件分离感觉干净。敏感的工作流可以有严格的规则。研究工作流可以专注于证据。内容工作流可以专注于结构和清晰度。维护工作流可以专注于检查、日志和恢复。
对我来说，这就是 Hermes 胜出的地方：不在于功能清单，而在于操作纪律。
Raspberry Pi 的角度
在 Raspberry Pi 上运行这也改变了我对智能体框架的看法。
Pi 小巧、便宜、全天候运行，而且以最棒的方式显得“无聊”。这使其成为后台智能体的良好家园。但这也迫使人们保持纪律。你不能把它当作无限的云工作站。你需要清晰的流程、日志、配置文件和限制。
对我来说，Hermes 更容易映射到这种现实。我可以运行专注的后台工作流，保持记忆范围限定，使用例程调度，并将系统连接到有用的工作，而不仅仅是运行实验。
OpenClaw 也可以在本地运行，并具有强大的以消息为先的人体工学设计。但我个人的偏好是 Hermes，因为它感觉不像是一个聪明的助手，而更像是我可以不断塑造的基础设施。
这也是为什么我仍然会思考我在 构建真正有效的 AI 智能体→ 中写过的早期智能体工作。核心问题不是“智能体能否回答？”，真正的问题是系统是否能在监督、可追溯性和有用边界的情况下持续工作。
OpenClaw 可能仍是更好选择的情况
我不会告诉每个人都选择 Hermes。
如果你想要最快的路径来获得一个可以通过消息应用交谈的个人助手，OpenClaw 可能更适合。如果你想要依托更大的生态系统、测试社区集成，或者实验一个更具消费者感觉的助手层，它也可能更好。
这很有价值。很多人不想设计操作配置文件。他们想要一个住在盒子里并通过手机响应的单一助手。
为此，OpenClaw 是合理的。
当你的问题从“我能给我的智能体发消息吗？”变为“我能构建几个不断改进特定工作流的智能体吗？”时，Hermes 变得更有趣。
第二个问题是我的问题。
隐私要点
对于这两种工具，有一件事我不能忽视：本地智能体很强大。
一旦智能体可以读取文件、运行命令、使用浏览器、与 API 对话或与业务系统交互，它就不再只是一个聊天机器人。它是带有权限的基础设施。这意味着审批规则、范围限定的配置文件、记忆卫生和保守的默认设置很重要。
这也意味着你应该小心公开发布的内容。博客文章可以谈论架构和经验教训，而无需暴露主机名、确切路径、客户端名称、配置文件名称、令牌、私人工作流细节或任何可能帮助他人映射你真实系统的内容。
这是我倾向于 Hermes 的另一个原因。我当前的设置推动我走向分离：不同的角色、不同的工作、不同的记忆、不同的期望。这不会自动使其安全，但使安全性更易于推理。
草稿中的错误是一回事，敏感工作流中的错误则是另一回事。智能体设置应反映这一点。
这也是为什么我不断回到 AI 辅助开发的同一教训：只有系统保持可审查，速度才有意义。我在 AI 辅助开发： solo 开发者 7 天 102 次提交→ 中从编码角度写过这一点。同样的逻辑也适用于此。
我目前的结论
如果有人问我先尝试哪一个，我会根据他们的需求来回答。
如果他们想要一个具有大生态系统的广泛基于消息的个人助手，OpenClaw 值得测试。
如果他们想要一个更结构化的系统用于长期运行、自托管、特定工作的智能体，我会从 Hermes 开始。
对于我自己的 Raspberry Pi 设置，Hermes 更合适。它匹配我实际的构建方式：小型专注的角色、可重用的技能、持久化记忆、例程调度和清晰的操作边界。
OpenClaw 向我展示了本地 AI 助手的形态。Hermes 感觉像是我可以持续与之共存的那个。
这就是我在测试两者后关于 Hermes 与 OpenClaw 的结论：OpenClaw 令人兴奋，但 Hermes 更适合我实际的智能体工作。