OpenClaw、OpenHuman 与 Hermes Agent：开源智能体栈的三种架构

挑错开源智能体，你将从零重建。OpenClaw、OpenHuman、Hermes Agent 并非同一物种——一个把机器封进沙箱，一个先把你读个透，一个从自己的失败里持续进化。下面是它们的架构，并排比一比。

速览

三个项目，对同一个问题给出了三种不同的答案：一个真正有用的自主智能体，究竟需要什么？下表先列基本信息，紧接的柱状图与矩阵则呈现各自的发力方向。

项目	发布时间	主打场景	部署形态
OpenClaw	2026.3.31（Task Brain 版本）	本地优先运行时 / 系统自动化	本地常驻守护进程
OpenHuman	2026 年 5 月 13 日	个人上下文 / 知你如己的助理	原生桌面应用（Tauri）
Hermes Agent	2026 年 2 月 26 日	常驻自主研究 / 任务智能体	自托管常驻服务

撰文时的 GitHub Star 数——OpenClaw 的领先达到两个数量级。

谁在哪条轴上最有发力。深色格子标出每个项目的强项。

三款项目，60 秒读完

OpenClaw 是迄今为止 Star 数最多的开源智能体项目，撰写本文时约有 347,000 个 GitHub Star。它的核心主张是：本地优先的运行时可以把一个静态 LLM 转化为一个主动出击的数字工作者——给它文件系统、Shell、浏览器、邮件、日历，以及九个消息平台的访问权，然后让它在无需人工逐步审批的情况下持续运转。2026.3.31 版本引入了 Task Brain 任务台账，这是一个由 SQLite 支撑的统一管理层，将所有任务、子智能体、定时任务与后台进程整合进单一的可查询存储。OpenClaw 不显眼的一面：eBPF 沙箱层意味着各技能仅以完成任务所需的最小内核权限运行——智能体主动，但并不是拿着空白授权单在操作。

OpenHuman 由 TinyHumans 于 2026 年 5 月 13 日发布，发布数日内便积累了约 7,800 个 GitHub Star——而且攀升势头持续加速，约两周内便突破 29,000。该项目的主张是一种反转：不是让智能体在对话过程中边聊边了解你，而是在你敲下第一个提示词之前，就从 Gmail、Notion、GitHub、Slack、Stripe、Linear、Jira 以及 110+ 个其他连接器中，提前构建好你生活的压缩模型。这棵记忆树存储在本地 SQLite 中，成为每次交互的初始上下文。不显眼的一面：20 分钟的轮询间隔意味着智能体对你的认知会在你毫无感知的情况下持续刷新——记忆不是静止的，它会自己朝着当下漂移。

Hermes Agent 由 Nous Research 于 2026 年 2 月 26 日发布——该团队正是 Hermes 系列微调模型的幕后团队——三个月内突破 140,000 个 GitHub Star，遥测数据显示其是 OpenRouter 上使用最多的智能体。它的主张是持久性与自我进化：智能体以自托管常驻服务的形式运行，每次任务完成后写入一条结构化的事件型记录（尝试了什么、什么成功、什么失败），并在面对类似的未来任务前检索这些记录。不显眼的一面：事件型记忆循环是跨会话可量化的自我提升机制，而不是聊天机器人式的对话历史——每个新任务都以检索到的历史先例为起点，而非白板。

OpenClaw — 架构详解

OpenClaw 的控制循环外裹一层 SQLite 任务台账，技能进程经由 eBPF 隔离运行。

控制循环

OpenClaw 的运行时采用持续执行模型。智能体接收目标、将其分解为步骤、为每个步骤调用对应的技能、评估结果，再决定下一步——全程无需暂停等待人工确认。这与简单的流水线不同：模型是每个节点的决策者，而非固定脚本。

Task Brain 充当这个循环的编排层。每一步的状态在技能执行前就被记录进台账，因此若进程在任务中途崩溃，循环可以从最后一次已提交的状态恢复，而不必从头再来。为处理并行分支而派生的子智能体会在父任务的命名空间下向同一台账写入数据，使多智能体协调可以通过单条查询完整审计。

Task Brain 台账

2026.3.31 版本引入的 Task Brain SQLite 存储，是智能体内所有移动部件的统一管理层：任务、子智能体、定时任务和后台进程。此版本之前，这些内容各自独立追踪；某个子系统崩溃时，其他子系统无从得知究竟哪些步骤已经完成。台账将它们整合在统一的 schema 之下。

台账中每行记录携带任务标识符、父任务（如有）、分配的技能、当前状态、工具调用参数以及原始结果。智能体读取这张表——而非内存结构——作为下一步该做什么的真实来源。这意味着循环在进程重启后依然可以存活：重连后智能体查询台账，识别待处理步骤，继续执行。

子智能体协调也通过同一张表实现。父任务派生出子记录；子任务的状态在台账内从 pending 转变为 running，再到 complete 或 failed。父任务通过轮询台账来检测完成情况，而非依赖内存通道。这使得整个执行图可以用标准 SQLite 查看器一览无余。

沙箱模型

技能以沙箱化进程运行，其内核权限由 eBPF 钩子在运行时强制执行。一个需要读取特定目录文件的技能，只会获得刚好这个权限——没有写权限、没有网络访问权限、没有 Shell 执行权限——除非该技能的声明清单明确申请并获批每项能力。这是最小权限执行：权限集默认收窄，仅在明确声明后才放开。

OpenClaw 针对的威胁模型是来自环境的提示注入——恶意文档或网页试图把智能体引向用户意图之外的行为。由于技能在 eBPF 约束的进程中运行，即使提示注入成功，也无法将权限提升至该技能从未被授予的能力范围。攻击者的攻击面由技能的声明清单划定，而非宿主操作系统所允许的全部权限。

集成面

OpenClaw 的集成面涵盖文件系统、Shell、浏览器（通过 Playwright）、邮件与日历。消息平台方面，截至 2026 年 4 月，直接集成包括 WhatsApp、Telegram、Discord、Signal、Slack、iMessage、Matrix、LINE、QQ Bot 以及 Microsoft Teams——共十个平台。广度背后是一种设计哲学：智能体应住在用户所在的地方，而非一个需要单独打开的工具。

这份集成列表揭示出 OpenClaw 并非一个面向开发者的专用工具。消息平台集成——尤其是 iMessage 和 WhatsApp——表明从未打开过终端的用户也是预期的目标用户群。智能体应当在他们已经常开着的那个通信频道中触达他们。

OpenHuman — 架构详解

OpenHuman 把 118 个连接器压缩进 Markdown 记忆树——智能体读你的数据，而不是读你的提示词。

连接器模型

OpenHuman 内置 118+ 个第三方连接器，涵盖 Gmail、Notion、GitHub、Slack、Stripe、日历、Drive、Linear、Jira 以及同类产品中的数十个。每个连接器声明自己能拉取什么：邮件、日历事件、工单、PR、交易记录、文档。授权后，OpenHuman 自动开始遍历这些连接——每个连接器无需额外配置。

自动取数器每 20 分钟对所有活跃连接执行一次——只拉取增量，而非全量重同步——并将新数据压缩成 Markdown 块追加到记忆树的对应分支。结果是一个持续刷新的用户工作生活模型，完全不需要用户手动发起同步。智能体的上下文始终在 20 分钟以内保持最新。

记忆树压缩

记忆树是一个层次化结构——而非扁平日志——它按领域组织压缩后的 Markdown 块：通信、任务、代码活动、财务、日历等。每个分支对应一个连接器类别。取数器拉取新数据时，将增量压缩成 Markdown 块追加到对应分支，并在分支超出大小阈值时裁剪旧块。树形结构的意义在于：它让智能体可以按需加载与查询相关的分支，而不必扫描完整历史。

压缩是刻意为之的。连接器原始输出——一个完整邮件线程、一个完整的 GitHub PR——很快就会耗尽上下文窗口。压缩步骤提炼出信号：谁说了什么、什么发生了变化、当前状态如何。生成的 Markdown 块信息密集但人类可读，这在智能体引用了错误上下文时便于调试。

记忆树存储在本地 SQLite 中，而非云端数据库。这意味着记忆在断网时依然完整，且永远不会离开用户的机器——对于那些连接器涉及敏感财务或法律数据的用户而言，这是一个重要特性。

用户上下文优先的提示策略

大多数智能体将用户视为交互的目标：用户输入目标，智能体追求它。OpenHuman 将这个关系倒置了。在读取提示词之前，用户的记忆树已被加载为初始上下文。智能体在开始时就已知晓用户当前的项目状态、待处理任务、近期通信以及日历安排。用户的提示词是被投入一个已经充满用户专属信息的上下文窗口中。

这改变了用户需要说什么。用户不再需要在每次会话开始时向智能体汇报自己的情况，而是可以发出简短指令——"起草一封周二那次 Stripe 对话的跟进邮件"——并期待智能体无需进一步解释就能调取相关背景。用户不是系统提示词；用户是预加载的世界状态。提示词是叠加在这个状态之上的增量指令。

桌面运行时

OpenHuman 基于 Rust 和 Tauri 构建，在 macOS、Windows 和 Linux 上以原生桌面应用形式交付。选择 Tauri 的好处是：相比 Electron 方案，二进制体积更小；具备原生操作系统集成能力，可访问文件系统和 IPC；进程模型将 Web 视图约束在沙箱内，无需为智能体核心逻辑赋予 Chromium 级别的权限。撰写本文时版本为 v0.53.43（Early Beta），应用仍在积极开发中，但已完全可用于日常任务。

本地优先的数据存储不是一种局限，而是一种刻意的信任模型。由于记忆树永远不会离开本机，拥有敏感连接器数据（法律、财务、医疗）的用户可以把这些数据保留在设备上，而不必存入厂商的服务器。不过，这一信任模型比"完全本地"更微妙：默认情况下，账号登录、模型路由、网页搜索以及连接器 OAuth 仍会经过 OpenHuman 的托管后端——留在本地的是你的数据，而非每一项服务。可选的本地 AI 支持可缩小这一范围：配置本地模型后，查询数据也同样留在设备上。

Hermes Agent — 架构详解

Hermes Agent 的规划器在动手前先检索过去任务的事件型记忆。

规划循环

Hermes Agent 将每个任务结构化为四阶段循环：将目标分解为子任务、为每个子任务选择合适的工具、执行工具调用、然后对照目标评估结果。若评估失败或返回部分结果，循环携带更新后的观察结论重新进入分解阶段。模型主导这一循环——它不是固定流水线——这意味着智能体可以在执行过程中根据发现来修正计划。

Hermes Agent 的"常驻"意味着服务以持久后台进程运行，而非每次对话启动一个会话。任务可以由外部入队、由定时规则触发，或由其他服务发起。规划循环独立处理每个到来的任务。没有"开始一段对话"的概念——只有"向队列提交一个任务"。这使得 Hermes Agent 可以作为后端服务进行组合，而不仅仅是面向用户的助理。

工具库

Hermes Agent 内置 40+ 个工具，涵盖网页搜索、网页抓取、代码执行、文件操作、API 调用和数据处理。每个工具都是带有类型化 schema 的可调用注册项。规划器通过将 schema 的声明能力与子任务描述进行匹配来选择工具。注册新工具只需提供名称、供规划器用于选择的描述以及类型化的输入/输出 schema——没有与此注册契约分离的插件 API。

这与 OpenClaw 的 Skill 模型有实质区别。在 OpenClaw 中，一个 Skill 是带有 eBPF 强制内核权限的沙箱进程——添加 Skill 需要声明能力清单并接受内核的强制执行。在 Hermes Agent 中，工具作为智能体进程空间内的可注册调用项运行，以进程边界而非内核强制的能力约束进行隔离。权衡在于扩展速度：添加 Hermes 工具更快，但恶意或有缺陷的工具的爆炸半径更大。

事件型记忆

每次任务完成后——无论成功与否——Hermes Agent 都会向其记忆存储写入一条结构化的事件型记录。每条记录包含任务描述、所采用的方法（选择了哪些工具、以何种顺序、带什么参数）、结果（成功、失败、部分完成），以及执行过程中的任何值得注意的观察。这不是对话日志；它是一个为检索建立索引的结构化案例库。

新任务开始前，规划器查询事件型存储，查找具有相似特征的记录。若存在历史记录，它们会被预置到规划器的上下文中。规划器在决定如何分解当前任务之前，会先阅读以往的方法——包括失败的那些。一个用某种特定工具顺序失败了三次的任务，会在检索到的记录中显示这些失败；规划器可以在重蹈同样的错误之前调整方案。

自我提升可以跨会话量化。如果同一类任务最初需要四次工具调用和两次重试，而经过十轮事件型检索后只需两次工具调用和零次重试，这个差距在执行日志中清晰可见。记忆不是装饰性的——它与任务性能之间有着随时间复利的因果关系。

模型无关后端

Hermes Agent 与任何特定 LLM 解耦。运营者配置规划器使用哪个模型后端——通过 Ollama 的本地模型、云端 API，或任何兼容 OpenRouter 的端点。更换模型不需要修改智能体的工具库、任务队列配置或事件型记忆 schema。智能体的行为由模型的能力塑造，但其架构不对任何模型硬编码。

OpenRouter 遥测数据——Hermes Agent 是该平台上使用最多的智能体——印证了模型无关设计在实践中奏效。用户在不同部署中选择不同的模型，智能体在这个范围内均可正常运转。对于希望今天跑一个有能力的模型、将来升级时不重写智能体逻辑的运营者来说，这种解耦是相对于那些将模型专属提示模式深埋在规划器中的架构而言的核心部署优势。

横向对比

记忆模型

三种持久化形态，对应三种不同的工作目标。

OpenClaw 的记忆是事务性的：SQLite 任务台账记录智能体在当前执行上下文中正在做什么、已经做了什么。它并非为了跨周积累用户知识而设计——而是为了让当前任务可恢复、可审计。任务完成后，台账条目关闭；它不会反哺未来的任务规划。

OpenHuman 选择的是生活上下文树：一个层次化、持续更新的 Markdown 结构，对用户的世界建模，而非对智能体当前的工作建模。记忆树在任何任务提交之前就已存在，无论智能体是否活跃都持续保留。OpenClaw 的台账是会话范围的；OpenHuman 的树是永久累积的。Hermes Agent 介于两者之间，以事件型案例库折中——记忆像 OpenClaw 那样以任务为范围，但像 OpenHuman 那样跨会话积累。

事件型案例库存储结果，而非状态。OpenHuman 的树回答的是"这个用户是谁，他们当前的上下文是什么"；Hermes Agent 的记录回答的是"上次我们尝试这类任务时发生了什么，我们应该有什么不同"。三种形态服务于三种截然不同的检索目的：可恢复性、用户上下文饱和，以及跨会话方案改进。

工具 / 技能模型

智能体伸手要什么，又有什么伸进了智能体。

OpenClaw 使用 Skill 抽象：每个 Skill 是一个带有声明能力清单的沙箱进程，由 eBPF 钩子强制执行。智能体调用 Skill；Skill 以其声明的特定内核权限执行。这使得 OpenClaw 的工具模型是三者中最安全的，但扩展起来也是最重的——添加一个 Skill 需要编写清单并针对 eBPF 强制执行进行测试。

OpenHuman 的模型是混合型的。在输入侧，连接器将外部服务的数据拉入记忆树——这些是只读的数据集成，而非执行动作的工具。在动作侧，OpenHuman 内置原生工具：网页搜索、网页抓取、文件系统访问、git 工作流、代码检查、测试、类似 grep 的代码搜索、语音转文字和文字转语音。这些原生工具与桌面运行时紧密集成，而非在进程层面沙箱化。

Hermes Agent 选择了注册可调用项模型：40+ 个内置工具配备类型化 schema，可通过相同契约注册新的可调用项来扩展。相比 OpenClaw 的 Skill SDK，注册更快，所需基础设施更少；相比 OpenHuman 的原生工具，作为远程服务的组合性更强，但没有内核级隔离。可扩展速度的优势以爆炸半径控制为代价。

安全与沙箱

各家运行时的"爆炸半径"故事。

OpenClaw 的 eBPF 沙箱是三者中隔离能力最强的。内核强制的最小权限意味着一个被入侵或遭受提示注入的技能，无论尝试什么，都无法访问其声明清单之外的资源。攻击面由能力声明划定，而非由智能体或用户对技能理论上能访问什么的了解程度决定。对于一个拥有广泛系统访问权限——文件系统、Shell、九个消息平台——的智能体而言，这是正确的模型：没有隔离时，潜在的爆炸半径极大。

OpenHuman 在操作系统级桌面信任下运行。原生桌面应用以用户级进程权限运行，而非每个工具都有内核强制的能力约束。对于一个主要工作是读取和汇总连接器数据的桌面助理而言，这是可接受的权衡：威胁模型是通过连接器误用导致的数据泄露，而非权限提升。本地数据存储降低了攻击的爆炸半径——入侵 OpenHuman 的攻击者不会获得云端凭证或远程数据库访问权；他们得到的只是已经在这台机器上的内容。

Hermes Agent 使用进程隔离：每次工具调用在独立进程中执行，将有缺陷工具的损害限制在该进程的范围内。这是一个有意义的边界——一个崩溃或行为异常的工具不会拖垮整个智能体——但与 OpenClaw 的内核强制能力约束相去甚远。对于部署在月租 5 美元的 VPS 上、处理自动化研究任务的自托管服务而言，进程隔离是与威胁模型务实匹配的选择：攻击面是 VPS 环境，运营者控制着哪些工具被注册。

部署拓扑

智能体住在哪里，决定了它能做什么。

OpenClaw 以常驻本地守护进程运行。它持续驻留在机器上，而不仅仅是在用户打开窗口时才存在。这使得定时任务、事件触发的工作流以及无需用户在场就能运行的后台进程成为可能。守护进程是整个消息平台栈——WhatsApp、Telegram、Discord 等——的集成点，这些平台需要持久连接才能向智能体传递入站消息。基于会话的部署无法满足这一需求。

OpenHuman 是一个原生桌面应用：用户打开时运行，通过 SQLite 在会话之间持久化记忆树，但应用关闭后不运行后台进程。这在很大程度上塑造了助理模型——OpenHuman 是用户调用的工具，而非用户无限期委托的服务。Hermes Agent 处于另一个极端：一个自托管的常驻服务，无论有没有人在看都在运行。任务通过 API 或定时规则到达；智能体在后台处理并存储结果。运营者的界面是日志，而非聊天窗口。

部署拓扑的选择决定了托管成本曲线。OpenClaw 和 OpenHuman 在用户现有硬件上运行，无额外增量成本。Hermes Agent 需要一台自托管服务器——但 Nous Research 明确以月租 5 美元的 VPS 作为基准部署目标，使其对无云端预算的个人开发者也可触达。这个成本点与通过托管智能体服务运行相同任务的 API 费用相当。

可扩展性

系统如何超越发布日的那张功能图。

OpenClaw 通过 Skill SDK 扩展：编写一个技能、声明能力清单、向运行时注册，智能体便获得该能力——附带 eBPF 强制约束。SDK 是主要的扩展面；消息集成和直连集成都建立在相同的 Skill 原语之上。后果是每个扩展都继承了安全模型——强隔离、明确能力声明——但也继承了这个模型的工程开销。

OpenHuman 在数据摄入侧通过连接器插件扩展，在动作侧通过添加原生工具扩展。添加一个连接器意味着编写一个实现取数器接口的插件；新连接器的输出自动进入记忆树压缩管道。OpenHuman 的可扩展性主要关于丰富用户的上下文模型，而非添加新的动作能力。Hermes Agent 通过工具注册和模型替换来扩展：向注册表添加新的可调用项，规划器立即获得访问权；替换 LLM 后端，整个智能体的推理方式随之改变，无需触碰任何工具代码。双重扩展面——同时作用于工具库和模型——是 Hermes Agent 独特的可扩展性优势。这次对比中没有任何其他项目允许独立替换"大脑"而不影响"双手"。

该选哪一个

使用场景	选 OpenClaw，当……	选 OpenHuman，当……	选 Hermes Agent，当……
DevOps 自动化 / 常驻本地系统管理	你需要一个持久的本地守护进程，能执行 Shell 命令、监控服务，并以 eBPF 沙箱化的技能隔离响应定时触发。	不太合适——OpenHuman 是基于会话的，关闭后不运行后台进程。	你希望将自动化逻辑远程自托管，并通过 API 调用，而非在目标机器本身上运行。
个人助理 / 收件箱 + 日历 + 笔记	你主要通过支持的消息平台通信，希望智能体在无需单独打开应用的情况下处理回复和日程安排。	你希望智能体在你开口之前就已知晓你的上下文——待处理任务、近期邮件、日历冲突——数据来自 118+ 个连接器。	你习惯运行自托管服务，并希望智能体通过事件型记忆，随时间推移不断改进对你日常个人任务的处理能力。
自主研究 / 长周期多步骤任务	你需要一个本地运行时，能执行扩展的多步骤工作流，具备完整的崩溃恢复能力，且无需每步人工审批。	你的研究任务需要深度个人上下文——了解你的已有笔记、当前项目或历史工作——作为每次研究会话的起点。	你需要一个面向服务的智能体，能将研究任务入队、调动 40+ 个工具库运行，并在数周内对循环出现的研究模式变得可量化地更快。
受监管数据工作流（离线、审计追踪）	你需要内核强制的按技能能力约束，以及每个任务和工具调用的完整 SQLite 审计追踪，且在进程重启后依然保留。	你希望抓取到的连接器数据保留在设备上——它们会落入本地 SQLite，可选的本地 AI 也能让查询保留在本机（账号登录与连接器 OAuth 默认仍走托管后端）。	你在自己控制的基础设施上自托管，接受进程级隔离作为安全边界，并以事件型记录作为审计追踪。
多模型实验 / 避免 LLM 锁定	你愿意接受 OpenClaw 配置 LLM 的模型约束，以换取集成的本地运行时和沙箱故事。	你希望对隐私敏感的查询使用可选本地 AI，但对复杂任务接受云端路由——在那些场景下本地模型力有不逮。	你需要自由切换 LLM 后端——从本地 Ollama 到 GPT-4o，再到微调的 Hermes 模型——而无需修改任何智能体逻辑、工具注册或记忆 schema。

常见问题

Star 数最多的是哪个？

OpenClaw 以绝对优势领先，截至 2026 年 5 月约有 347,000 个 GitHub Star——迄今为止 Star 数最多的开源智能体项目。Hermes Agent 在 2026 年 2 月 26 日发布后三个月内突破 140,000 Star。OpenHuman 于 2026 年 5 月 13 日发布，是三者中最新的——发布头几天约 7,800 Star，约两周内便快速攀升至 29,000 以上。

树莓派或小型 VPS 上能跑起来吗？

Hermes Agent 明确以月租 5 美元的 VPS 作为基准部署目标，是最轻量的服务端选项——无需桌面环境，配合小型 LLM 或远程 API 后端即可运行。OpenHuman 需要桌面操作系统（macOS、Windows 或带显示器的 Linux），因此无显示设备的树莓派并不适合。OpenClaw 作为本地守护进程运行，可在任何支持 eBPF 的机器上运行，这要求 Linux 内核 4.15 及以上、x86-64 或 ARM64 架构；运行现代 64 位树莓派系统的树莓派 4 在范围之内，但 LLM 推理的硬件预算仍需考量。

生产环境下哪个最安全？

OpenClaw 提供最强的技术隔离：eBPF 钩子在内核层面对每个技能强制执行最小权限，无论遭受提示注入的技能尝试什么，都无法超越其声明的能力清单。OpenHuman 的操作系统级桌面信任模型适合个人助理，但不提供每个工具粒度的内核强制能力约束。Hermes Agent 使用进程隔离——对崩溃遏制有意义，但与内核强制的能力边界不在同一层级。对于智能体输入中的恶意载荷可能尝试权限提升的生产工作流，OpenClaw 的沙箱模型是最具防御性的选择。

做个人助理哪个最合适？

OpenHuman 专为这一场景而生：118+ 个连接器从 Gmail、日历、Notion、Slack、GitHub 等来源拉取数据到本地记忆树，在你输入提示词之前就预加载好你的上下文。你无需花时间向智能体介绍自己的情况。OpenClaw 在消息平台层面表现出色——WhatsApp、iMessage、Slack 以及其他八个平台——擅长在这些频道中代表你采取行动，但其记忆模型是任务范围的，而非生活上下文范围的。Hermes Agent 也可作为个人助理，但需要自托管，且最适合那些有反复出现的任务模式、事件型记忆能随时间提升性能的场景。

三者之间能互通吗？

原生不支持。OpenClaw 的 Skill 格式、OpenHuman 的连接器与记忆树 schema，以及 Hermes Agent 的工具注册契约是各自独立的接口——没有共享协议，没有跨项目的插件格式，也没有在它们之间交换记忆的标准。想要将 OpenHuman 的记忆树与 Hermes Agent 的规划器结合起来的团队，需要自己构建一个定制适配器。这三个项目在架构上的差异足够大，使得浅层互操作（共享工具或共享记忆）需要非平凡的集成工作，而不是一个配置开关。

它们各自支持哪些模型后端？

Hermes Agent 最为灵活：它在设计上模型无关，支持运营者配置的任意 LLM 后端——通过 Ollama 的本地模型、OpenRouter 端点、直连云端 API，或任何兼容 OpenAI 接口的服务。OpenClaw 支持可配置的 LLM 后端，涵盖本地和云端选项，但集成与运行时结合更紧，并非其主要差异化卖点。OpenHuman 默认路由至云端 LLM，但为希望查询完全留在设备上的用户提供可选的本地 AI 支持；模型路由层根据任务复杂度在本地与云端之间进行选择。

速览