三个 AI Agent,不是一条赛道:OpenClaw、Hermes Agent 与 OpenHuman 怎么选?

SuuJiKat 深研改写

结论先说：OpenClaw 适合“让 AI 住进聊天账号”；Hermes Agent 适合做组织级 agent 平台底座；OpenHuman 适合本地记忆、屏幕理解和隐私优先的桌面 AI。你如果只问“哪个更强”，选型就已经偏了。

图：基于 OpenClaw 官方小龙虾视觉、Hermes Agent 官方女孩视觉、OpenHuman 官方 mascot 做的重排图；仅做裁切、留白和中文标签，不再使用 PDF 文字截图。

先把一个误区拆掉

这份报告表面上在比较 OpenClaw、Hermes Agent 和 OpenHuman，真正有价值的地方却不是“功能列表 PK”，而是帮我们看清楚一件事：

AI Agent 产品正在分化成不同入口。

有的从聊天入口长出来，有的从平台编排长出来，有的从个人记忆和桌面上下文长出来。它们都能调用模型、接工具、跑任务，但第一优先级完全不同。

💡 Agent 可以先粗略理解为“能带着目标调用工具、读取上下文、连续执行任务的 AI 系统”。它不只是聊天机器人，重点在于它能进入流程并做动作。

报告给出的总判断很清楚：

OpenClaw
的第一公民是消息网关和设备通达性。
Hermes Agent
的第一公民是 agent 平台能力和可编排行为。
OpenHuman
的第一公民是长期个体记忆和本地用户体验。

💡 “第一公民”是工程里常用的说法，意思是某个能力不是附属功能，而是系统设计的核心对象。看一个产品的第一公民，往往比看 feature 数量更能判断它适合什么场景。

01｜OpenClaw：把 AI 放到你的聊天账号背后

OpenClaw 最像一个自托管的 personal assistant gateway。

它的重点不是做一个漂亮的桌面应用，也不是先搭一个研究平台，而是把 WhatsApp、Telegram、Slack、Discord、Signal、iMessage、WebChat 等聊天表面，接到一个长期在线的 Gateway 上，再把消息路由给后面的 agent runtime、skills、nodes 和工具。

💡 Gateway 可以理解为“总入口”或“中转站”。它负责接住外部消息、做身份和路由控制，再把请求分发给后面的 agent、工具或设备节点。

所以 OpenClaw 的典型画面是：你在常用聊天软件里发一句话，背后有一个常驻在 VPS、家用主机或小型服务器上的 AI 助理接住请求。它可以访问工作区、调用工具、连接设备节点、维护会话上下文，并通过聊天入口把结果返回给你。

这条路线适合

想把 AI 接进现有消息渠道。
想要一个长期在线的个人助理。
想用自托管方式掌控入口、账号和运行环境。
对聊天、设备节点、远程执行、轻量 VPS 部署有明确需求。

但 OpenClaw 也有一个必须正视的风险：安全治理责任很重。

报告里提到，OpenClaw 官方对安全的态度非常直接：你的 AI 有能力执行 shell 命令、读写文件、访问网络、发送消息，所以不存在“完美安全”。真正的边界来自 loopback bind、gateway auth、DM/group allowlists、node pairing、sandboxing 和安全审计。

换句话说，OpenClaw 很适合“可信单操作者”的长驻 AI 助理，但不适合带着默认配置直接外放到复杂多人环境。

02｜Hermes Agent：把 Agent 当成组织级操作系统

Hermes Agent 的气质完全不同。

它更像一个通用 agent 平台，面向的是研究、平台、复杂工具编排、跨 provider 调度、插件系统、轨迹数据和生产级部署。

报告里总结了几个关键能力：

平台无关的 AIAgent核心。
SQLite + FTS5 会话持久层。
70+ tools、约 28 个 toolsets。
20 个 platform adapters。
22 个 messaging platforms。
18+ 模型或推理 provider。
ACP、MCP、plugin、trajectory、memory provider、context engine 等扩展面。

💡 MCP/ACP 可以先理解为 agent 与外部工具、上下文或平台之间的协议层。它们的价值不在缩写本身，而在于让 agent 能通过稳定边界连接不同系统。

Hermes 的优势不只是“功能多”，而是抽象层次完整。它适合被当成组织级 agent platform 的底座：不同入口可以共用同一个 agent core，不同工具可以通过插件或 provider 进入系统，不同任务可以沉淀为轨迹、记忆和可复用能力。

这条路线适合

做内部 agent OS。
做复杂工具编排和自动化平台。
做 agent evaluation、训练数据沉淀、provider routing。
做 IDE/editor 集成、API server、batch runner、serverless 或 Nix/NixOS 部署。

它的问题也同样明显：功能面太宽，复杂度自然更高。

如果你的需求只是“给自己接一个聊天助理”，Hermes 可能显得过重。它的优势会在多入口、多工具、多 provider、多场景复用时才真正释放。

03｜OpenHuman：把长期记忆做成本地体验

OpenHuman 和前两者的出发点又不一样。

它的核心叙事不是“消息入口”，也不是“平台编排”，而是给 AI 模型补上长期记忆和个体化潜意识层。报告里提到的关键能力包括：

Neocortex 记忆引擎。
Screen Intelligence，约 5 秒周期分析屏幕。
Auto-complete，基于记忆上下文跨系统补全。
本地 Gemma 3 支持 chat、vision、STT、TTS。
118+ 第三方集成。
多源信息压缩为结构化知识图谱。
本地优先、raw data 不离设备、keys never leave the device。

这就是 OpenHuman 最鲜明的地方：它不是先问“agent 能接多少工具”，而是先问“AI 能不能理解这个人长期在做什么”。

图：由生图模型生成的三场景概念图。左侧对应消息入口，中间对应平台编排，右侧对应本地记忆与隐私。

这条路线适合

隐私敏感的个人知识工作流。
需要屏幕理解、跨应用上下文和长期个人记忆。
不想从终端或复杂配置开始，而是希望 UI-first。
愿意接受 Early Beta 带来的快速变化。

但 OpenHuman 也有两个硬边界：

它仍处在 Early Beta，接口和实现细节可能变化很快。
它是 GPL-3.0，商业分发或闭源深度嵌入前要做许可证审查。

💡 GPL-3.0 是一种强 copyleft 开源许可证。简单说，如果你分发修改版或把它深度嵌入闭源产品，可能需要承担开放相应源码的义务，商业团队不能只看“能免费用”。

一张表看懂差异

维度	OpenClaw	Hermes Agent	OpenHuman
核心定位	自托管消息网关 + 个人 AI 助理	通用 agent 平台，强调自学习、跨平台、研究/生产双用	本地优先记忆层 + 个体化潜意识 + 原生桌面 AI
主要运行面	聊天表面优先，Gateway 为中心	CLI、Gateway、ACP、Batch、API 并列	Desktop-first，同时覆盖移动/Web
核心抽象	Gateway、workspace、nodes、skills、plugin slots	AIAgent、provider resolution、tool dispatch、memory/context plugins	App layer、Neocortex、QuickJS skills runtime、MCP/Socket.io
部署偏好	常驻 Gateway 主机、Docker/Podman/VPS/WSL2	本机、Nix/NixOS、Docker/Podman、serverless、VPS	原生桌面/移动/Web，也可 headless 云部署
安全主线	自托管、allowlists、sandbox、gateway auth	七层 defense-in-depth、危险命令审批、容器隔离、credential filtering	零知识智能、本地处理、AES-256-GCM、OS keychain、skills sandbox
许可	MIT	MIT	GPL-3.0
最适合	聊天入口与常驻个人助理	平台底座、研究、复杂编排	本地记忆、隐私、桌面知识工作流

真正该问的不是“哪个最好”

更好的问题是：

你的 agent 要优先住在哪里？

如果它要住在聊天账号背后，优先看 OpenClaw。如果它要住在组织平台里，优先看 Hermes Agent。如果它要住在个人电脑、记忆和屏幕上下文里，优先看 OpenHuman。

报告最后给出的选型建议，我会进一步压缩成三句话：

研究平台、内部 agent OS、复杂工具编排、训练数据沉淀：选 Hermes Agent。它的平台抽象最完整，适合做底座。

生产中的个人助理、聊天入口、常驻在线 AI 代理：选 OpenClaw。它把“触达用户”放在第一位，消息渠道和 Gateway 路线清晰。

隐私敏感桌面应用、本地知识工作流、屏幕理解、长期个人记忆：选 OpenHuman。它把本地记忆和用户体验放在第一位，方向最鲜明。

还可以怎么组合？

如果不是单选题，可以按层组合，而不是硬迁全栈。

OpenClaw + OpenHuman

前者保留消息入口和常驻 Gateway，后者承担本地记忆、桌面感知和个人上下文。这条路线理念上最接近，因为 OpenHuman 官方叙事里也提到它和 OpenClaw 架构的关系。

Hermes Agent + OpenClaw

Hermes 负责 agent core、provider routing、工具编排和平台能力；OpenClaw 负责聊天渠道和个人设备网络。适合既需要复杂平台能力，又需要强消息触达的团队。

Hermes Agent + OpenHuman

Hermes 继续做研究、复杂编排和组织侧平台；OpenHuman 做个人工作站里的长期记忆前端。适合把“组织任务流”和“个人上下文”分层处理。

但这里要泼一点冷水：三者之间目前没有一个统一、官方冻结的互操作蓝图。真正落地时，最好优先选协议边界，比如 MCP、ACP、HTTP/代理、消息渠道，而不是深耦合内部状态。

今天的一个判断

AI Agent 的竞争，正在从“谁能回答更多问题”转向“谁能占住更关键的工作入口”。

OpenClaw 占的是消息入口。Hermes Agent 占的是平台编排入口。OpenHuman 占的是本地记忆和个人上下文入口。

这三种入口都会变重要，但它们解决的不是同一个问题。对团队来说，最危险的选型方式不是选错工具，而是还没想清楚自己要的是入口、底座，还是记忆层，就先被 feature list 带着跑。

来源与注记

本文基于本地 PDF《OpenClaw、Hermes Agent 与 OpenHuman 对比分析》改写，报告生成时间语境为 2026-05-20，主要依据官方文档、官方 GitHub 仓库和官方 release notes。文中星标数、release 数和性能主张均按原报告表述处理，适合看作该时间点的公开材料摘要，而不是持续更新的实时数据。

OpenClaw GitHub: https://github.com/openclaw/openclaw
OpenClaw Docs: https://docs.openclaw.ai/
OpenClaw Security: https://docs.openclaw.ai/gateway/security
Hermes Agent GitHub: https://github.com/NousResearch/hermes-agent
Hermes Agent Docs: https://hermes-agent.nousresearch.com/docs/
Hermes Agent Architecture: https://hermes-agent.nousresearch.com/docs/developer-guide/architecture
OpenHuman GitHub: https://github.com/tinyhumansai/openhuman
OpenHuman Docs: https://tinyhumans.gitbook.io/openhuman
OpenHuman Privacy and Security: https://tinyhumans.gitbook.io/openhuman/product/privacy-and-security
OpenClaw 官方视觉素材: https://openclaw.ai/og-image.png / https://openclaw.ai/favicon.svg
Hermes Agent 官方视觉素材: https://hermes-agent.nousresearch.com/docs/img/logo.png
OpenHuman 官方 mascot 素材: https://github.com/tinyhumansai/openhuman/tree/main/remotion/public