Hermes Agent 深度架构剖析与 OpenClaw 工程化对比

引言

2025 年以来，AI Agent 从概念验证走向工程化落地，开源社区涌现出大量框架级项目。其中，Nous Research 推出的 Hermes Agent 和社区驱动的 OpenClaw 是两个值得深入研究的标杆：前者以”会自我成长的 Agent”为核心定位，35.7k Star，3,496 次提交，317 位贡献者；后者是当前 GitHub 上最受欢迎的个人 AI 助手项目之一，352k Star，29,172 次提交，已发展为一个覆盖全平台的成熟产品。

两个项目在技术栈、架构理念和产品定位上走了截然不同的路径。本文将以 Hermes Agent 的源码为主线进行深度剖析，然后从八个工程化维度与 OpenClaw 进行结构化对比。全文面向工程师、架构师和研究者混合受众，侧重讲清架构意图与设计取舍，而非逐行贴代码。

第一部分：Hermes Agent 深度架构剖析

一、项目定位与设计哲学

Hermes Agent 的 Slogan 是 “The agent that grows with you”——一个会随使用而成长的 AI Agent。这个定位暗含了几个关键的架构约束：

闭环学习：Agent 能从经验中创建技能（Skill）、在使用中改进它们、主动持久化知识、搜索自己的历史会话，并建立对用户的渐进理解模型。
模型无关：支持 Nous Portal、OpenRouter（200+ 模型）、OpenAI、Anthropic 等任意 LLM 端点，通过 hermes model 一键切换，无代码改动，无锁定。
运行环境灵活：可以运行在 5 美元的 VPS 上，也可以运行在 GPU 集群或无服务器基础设施上，空闲时几乎零成本。
多平台触达：不绑定笔记本电脑——通过 Telegram/Discord/Slack/WhatsApp/Signal 等平台与它对话，同时它在云端 VM 上工作。
研究就绪：支持批量轨迹生成、Atropos RL 环境、轨迹压缩，为训练下一代工具调用模型服务。

这些约束决定了 Hermes Agent 不是一个”轻量 SDK”式的框架，而是一个垂直整合度很高的、从推理到执行到学习到调度的完整系统。

二、整体架构概览

从源码目录结构和模块依赖链来看，Hermes Agent 的架构可以抽象为五个层次：

第一层：入口与编排层

cli.py（HermesCLI 类）：交互式终端编排器，基于 prompt_toolkit 实现 TUI
gateway/run.py（GatewayRunner 类）：消息平台网关入口，管理所有平台适配器的生命周期
hermes_cli/main.py：全局入口点，所有 hermes 子命令的调度中心

第二层：Agent 核心层

run_agent.py（AIAgent 类）：核心对话循环，约 3,600 行的”大脑”
agent/prompt_builder.py：系统提示组装——身份、平台提示、技能索引、上下文文件
agent/context_compressor.py：自动上下文窗口压缩
agent/prompt_caching.py：Anthropic 提示缓存支持
agent/auxiliary_client.py：辅助 LLM 客户端（用于视觉分析、摘要等低成本任务）

第三层：工具与注册层

tools/registry.py：中央工具注册表——模式定义、处理器、派发
model_tools.py：工具编排薄层——触发发现、提供公共 API
toolsets.py：工具集定义——灵活的工具分组与组合系统
tools/*.py：每个工具一个文件，自注册

第四层：状态与持久化层

hermes_state.py（SessionDB 类）：SQLite 会话存储，支持 FTS5 全文搜索
tools/memory_tool.py（MemoryStore 类）：有界策展式记忆，文件持久化
cron/scheduler.py + cron/jobs.py：定时任务调度与执行

第五层：平台适配层

gateway/platforms/：Telegram、Discord、Slack、WhatsApp、Signal 等平台适配器
acp_adapter/：ACP 服务器（VS Code / Zed / JetBrains 编辑器集成）
environments/：终端后端——local、Docker、SSH、Modal、Daytona、Singularity

这五层的依赖关系是单向的、自下而上的，工具注册层是整个系统的”脊柱”。

三、核心抽象与关键设计

3.1 AIAgent：同步循环的核心

flowchart TD
    A["User Input"] --> B["AIAgent.chat()"]
    B --> C["_build_system_prompt()"]
    C --> D{"Main Loop\nbudget > 0?"}
    D -->|Yes| E["Call LLM API"]
    E --> F{"Has tool_calls?"}
    F -->|Yes| G["coerce_tool_args()"]
    G --> H["registry.dispatch()"]
    H --> I["Append tool_result"]
    I --> J{"Need compression?"}
    J -->|Yes| K["ContextCompressor\n4-phase"]
    K --> D
    J -->|No| D
    F -->|No| L["Return response"]
    D -->|No| M["Budget exhausted"]

    style A fill:#4A90D9,color:#fff
    style E fill:#7B68EE,color:#fff
    style H fill:#E8833A,color:#fff
    style K fill:#D94A7A,color:#fff
    style L fill:#50C878,color:#fff

AIAgent 类是整个系统最核心的抽象。它的 run_conversation() 方法实现了一个完全同步的对话循环：

循环逻辑可以概括为：当 API 调用次数未超限且迭代预算有剩余时，调用 LLM 获取响应。如果响应包含工具调用，则逐一执行每个工具调用，将结果追加到消息列表，递增调用计数；如果没有工具调用，则返回响应内容。

这个设计的几个关键取舍值得注意：

为什么是同步而非异步？ Hermes Agent 选择同步循环是一个深思熟虑的决定。AI Agent 的核心瓶颈是 LLM API 调用的延迟，而不是 I/O 并发。同步循环让代码更容易推理、调试和维护。当需要并行时（如子 Agent 批量执行），它通过 ThreadPoolExecutor 显式并行，而非引入全局异步运行时。model_tools.py 中的 _run_async() 函数提供了一个精心设计的同步-异步桥接，处理了三种场景：无运行中事件循环时使用持久化循环、在异步上下文中开辟新线程、在工作线程中使用线程局部持久化循环。

消息格式遵循 OpenAI 标准：所有消息使用 {"role": "system/user/assistant/tool", ...} 格式。推理内容存储在 assistant_msg["reasoning"] 中。这种对 OpenAI 格式的贴合让多模型切换几乎无摩擦。对于需要 developer 角色的模型（如 GPT-5、Codex），在 API 边界处进行角色映射，内部表示保持一致。

迭代预算（Iteration Budget）机制：AIAgent 不仅有全局 max_iterations 限制，还有细粒度的迭代预算管理。子 Agent 获得独立预算，不会消耗父 Agent 的配额。这在委托任务场景中尤为重要——总迭代次数可以超过父 Agent 的上限，但每个子 Agent 的执行是受控的。

3.2 工具注册表：去中心化注册，中心化派发

graph BT
    subgraph L0["Layer 0: Registry"]
        TR["ToolRegistry Singleton"]
    end

    subgraph L1["Layer 1: Tool Files"]
        MT["memory_tool"]
        DT["delegate_tool"]
        WT["web_tool"]
        CT["code_tool"]
        BT["browser_tool"]
    end

    subgraph L2["Layer 2: Orchestration"]
        MO["model_tools.py"]
        TS["toolsets.py"]
    end

    subgraph L3["Layer 3: Agent Core"]
        AG["AIAgent"]
        PB["prompt_builder"]
        CC["context_compressor"]
    end

    MT -->|register| TR
    DT -->|register| TR
    WT -->|register| TR
    CT -->|register| TR
    BT -->|register| TR

    MO -->|dispatch| TR
    MO -.->|import| MT
    MO -.->|import| DT
    TS --> MO

    AG -->|get_tool_definitions| MO
    AG --> PB
    AG --> CC

Hermes Agent 的工具系统设计是整个项目最优雅的部分之一。其核心是 tools/registry.py 中的 ToolRegistry 单例。

注册流程：每个工具文件在模块导入时调用 registry.register() 声明自己的模式（Schema）、处理器（Handler）、工具集归属、可用性检查函数和环境变量依赖。这种”自注册”模式意味着添加新工具只需三步：创建工具文件并调用 registry.register()、在 model_tools.py 的发现列表中添加导入、在 toolsets.py 中将工具加入适当的工具集。

依赖链的精心设计：tools/registry.py 不依赖任何工具文件或 model_tools.py，保证了无循环导入。工具文件导入 registry 并注册自己。model_tools.py 导入 registry 并触发所有工具模块的发现。上层的 run_agent.py、cli.py 等消费 model_tools.py 的公共 API。

运行时可用性检查：每个工具可以注册一个 check_fn，在获取工具定义时会检查该函数。例如，需要 API Key 的工具会在 Key 未配置时自动隐藏。这个设计让工具系统天然支持”优雅降级”——缺少某些依赖时，Agent 仍然可以运行，只是少了某些能力。

ToolEntry** 的元数据丰富度**：每个注册的工具除了 Schema 和 Handler 外，还携带 max_result_size_chars（输出截断阈值）、emoji（UI 展示）、is_async（是否需要异步桥接）等元数据。max_result_size_chars 特别值得一提——它让不同工具可以有不同的输出预算，避免单个工具的大量输出淹没上下文窗口。

3.3 工具集系统：组合式能力管理

toolsets.py 定义了一个灵活的工具集系统。工具集支持两种组合方式：直接包含具体工具名、引用其他工具集（支持递归解析和环检测）。

核心设计亮点包括：

平台统一的核心工具列表：_HERMES_CORE_TOOLS 是一个共享列表，CLI 和所有消息平台的工具集都从这个列表派生。这意味着编辑一次就能同时更新所有平台，避免了工具集在不同入口点之间”漂移”的问题。

门控工具：某些工具（如 send_message、Home Assistant 工具）通过 check_fn 门控——只有当 Gateway 运行中或特定 Token 配置后才会出现在工具列表中。这种”按条件显现”的设计比静态启用/禁用更加灵活。

动态 Schema 重建：model_tools.py 的 get_tool_definitions() 函数在返回工具定义后，会根据实际可用工具动态重建某些工具的 Schema。例如，execute_code 工具的描述会列出”沙箱中可用的工具”——如果 web_search 的 API Key 未配置，它就不会出现在 execute_code 的描述中。类似地，当 web_search/web_extract 不可用时，browser_navigate 的描述中”优先使用 web_search”的引用会被动态移除。这种反模型幻觉的设计非常精巧。

3.4 提示工程：分层组装与缓存友好

agent/prompt_builder.py 揭示了 Hermes Agent 的系统提示组装策略——一个精心设计的分层结构：

身份层：默认的 Agent 身份描述，或用户自定义的 SOUL.md
平台提示层：根据运行平台（WhatsApp/Telegram/Discord/CLI 等）注入特定的格式指导
行为指导层：记忆指导、会话搜索指导、技能指导、工具使用强制指导
模型特定指导层：针对不同模型家族的执行纪律补丁（OpenAI 模型的 OPENAI_MODEL_EXECUTION_GUIDANCE、Google 模型的 GOOGLE_MODEL_OPERATIONAL_GUIDANCE）
记忆快照层：从 MEMORY.md 和 USER.md 加载的冻结快照
技能索引层：所有已安装技能的紧凑索引
上下文文件层：AGENTS.md、.hermes.md 等项目上下文文件

缓存友好是硬性约束：AGENTS.md 中明确警告——“不要实现任何会在对话中途改变过去上下文的变更”。记忆的”冻结快照”模式正是这个约束的产物：MemoryStore 在 load_from_disk() 时捕获快照用于系统提示注入，之后的写入立即持久化到磁盘但不改变当前会话的系统提示。这保证了 Anthropic 的前缀缓存在整个会话期间有效，大幅降低成本。

注入安全扫描：所有外部注入的内容（记忆文件、上下文文件）在进入系统提示前都会经过威胁模式扫描，检查 prompt 注入、角色劫持、数据窃取等模式，以及不可见 Unicode 字符。这是一个非常实用的安全防线。

3.5 记忆系统：有界策展式记忆

Hermes Agent 的记忆系统是其”自我成长”能力的核心支撑之一，设计上做了几个有趣的取舍。

两个记忆存储：MEMORY.md 存储 Agent 的个人笔记（环境事实、项目惯例、工具特性、学到的东西），USER.md 存储对用户的了解（偏好、沟通风格、期望、工作流习惯）。这种分离让 Agent 可以独立管理”关于世界的知识”和”关于人的知识”。

有界设计：记忆有字符数上限（MEMORY.md 2200 字符，USER.md 1375 字符）。这不是 token 限制而是字符限制，因为字符计数是模型无关的。当接近上限时，Agent 必须先替换或删除旧条目才能添加新条目。这种”有限资源”的约束迫使 Agent 学会优先级管理——什么值得记住，什么可以遗忘。

子字符串匹配的操作界面：replace 和 remove 操作使用子字符串匹配而非全文或 ID。这个设计让 LLM 可以用简短的描述性片段来定位要修改的条目，比精确匹配更适合 LLM 的使用模式。

主动写入指导：记忆工具的 Schema 描述中包含了详细的”何时保存”指导——用户纠正时、用户分享偏好时、发现环境信息时。同时明确排除了不应保存的内容——任务进度、会话结果、临时 TODO 状态。这些指导直接嵌入工具 Schema 而非系统提示中，让记忆行为在不同平台间保持一致。

Honcho 辩证用户建模：除了内置记忆外，Hermes Agent 还集成了 Honcho 作为记忆提供者插件，提供更丰富的辩证式用户建模能力。

3.6 上下文压缩：结构化摘要与迭代更新

agent/context_compressor.py 实现了一个多阶段的上下文压缩算法，当对话接近模型上下文窗口限制时自动触发。

四阶段压缩流程：

廉价预通过——工具输出修剪：首先替换旧的工具结果为占位符，这是零 LLM 调用的操作
边界确定：保护头部消息（系统提示 + 首次交互）和尾部消息（基于 token 预算，约 20K token 的最近上下文）
结构化摘要：使用辅助 LLM（廉价/快速模型）对中间轮次进行结构化摘要，模板包含目标、约束与偏好、进度（已完成/进行中/阻塞）、关键决策、相关文件、下一步、关键上下文七个部分
工具调用对完整性修复：压缩后修复孤立的 tool_call/tool_result 对

迭代更新机制：当进行第二次及后续压缩时，系统不是从头摘要，而是在前一次摘要的基础上进行增量更新。这保证了跨多次压缩的信息保留。

按比例缩放的摘要预算：摘要的 token 预算是压缩内容量的 20%，但有上限（模型上下文窗口的 5% 或 12,000 token 取较小值）。大上下文窗口的模型会得到更丰富的摘要。

尾部保护的 token 预算方法：不使用固定消息数来保护尾部，而是使用 token 预算。这意味着包含大量工具输出的消息会被分配更多的保护空间，而短消息则不会浪费配额。

3.7 子 Agent 委托：隔离执行与上下文零泄漏

tools/delegate_tool.py 实现了一个精心设计的子 Agent 系统。

隔离原则：每个子 Agent 获得全新的对话（不继承父上下文）、自己的 task_id（独立的终端会话和文件操作缓存）、受限的工具集（可配置，但被阻止的工具如 delegate_task、clarify、memory 总是被剥离）、聚焦的系统提示（从委托的目标和上下文构建）。

深度限制：最大委托深度为 2（父 -> 子 -> 孙辈被拒绝），防止递归委托导致的资源失控。

并行执行：批量模式下最多 3 个子 Agent 并行运行（MAX_CONCURRENT_CHILDREN = 3），使用 ThreadPoolExecutor。每个子 Agent 的进度通过回调实时传递给父 Agent 的 UI（CLI 显示树形视图，Gateway 批量转发工具名称）。

凭证继承与覆盖：子 Agent 可以继承父 Agent 的凭证，也可以通过委托配置使用不同的 provider:model 对。凭证池可以在父子之间共享，让子 Agent 在遇到速率限制时可以轮换凭证。

进程全局状态的保护：model_tools._last_resolved_tool_names 是一个进程全局变量。委托系统在构建子 Agent 前保存父 Agent 的工具名列表，在子 Agent 执行完毕后恢复。这防止了子 Agent 的工具集”污染”父 Agent 的全局状态。

3.8 会话管理与跨会话搜索

hermes_state.py 中的 SessionDB 类提供了基于 SQLite 的会话持久化，几个设计亮点值得关注。

WAL 模式：使用 SQLite 的 Write-Ahead Logging 模式，支持并发读者和单写者。这对 Gateway 的多平台场景非常重要。

FTS5 全文搜索：为所有会话消息建立 FTS5 虚拟表，支持跨会话的快速文本搜索。Agent 可以通过 session_search 工具搜索自己的历史对话，配合 LLM 摘要实现跨会话回忆。

会话链：通过 parent_session_id 字段支持会话链——压缩触发的会话分裂会创建新会话并链接到父会话。这让会话的完整历史可以被追溯。

来源标记：每个会话标记来源（cli、telegram、discord 等），支持按来源过滤。

3.9 定时调度系统

cron/scheduler.py 和 cron/jobs.py 实现了一个功能完备的定时任务系统。

自然语言定义任务：用户可以用自然语言描述任务（“每天早上 8 点总结昨天的 GitHub 活动”），由 Agent 本身来执行任务。

多平台交付：任务结果可以自动投递到配置的平台（Telegram、Discord、Slack 等）。支持 local（仅保存）、origin（返回到创建任务的平台）、特定平台三种交付模式。

技能注入：定时任务可以配置预加载一个或多个技能，这些技能内容会被注入到任务提示中。

数据收集脚本：任务可以配置预执行的 Python 脚本，脚本输出作为上下文注入到 Agent 提示中。脚本必须位于 HERMES_HOME/scripts/ 目录下（有路径遍历防护），执行有超时限制。

不活跃超时而非硬超时：任务使用不活跃超时而非固定时间超时。只要 Agent 在积极调用工具或接收流式 token，任务就可以运行数小时；但如果出现 API 挂起或工具卡死，超过配置的不活跃时间（默认 10 分钟）就会被终止。

静默标记：当 Agent 判断没有新内容需要报告时，可以返回 [SILENT] 标记来抑制投递。输出仍然保存在本地用于审计。

四、执行链路全景

sequenceDiagram
    participant U as User
    participant CLI as HermesCLI
    participant AG as AIAgent
    participant PB as PromptBuilder
    participant LLM as LLM API
    participant TR as ToolRegistry
    participant CC as Compressor
    participant DB as SessionDB

    U->>CLI: Input message
    CLI->>AG: chat()
    AG->>PB: build_system_prompt()
    PB-->>AG: Identity+Memory+Skills

    loop Main Loop
        AG->>LLM: messages + tools
        LLM-->>AG: response
        alt Has tool_calls
            AG->>TR: dispatch(tool, args)
            TR-->>AG: tool_result
            opt Token threshold
                AG->>CC: compress()
                CC-->>AG: compressed
            end
        else No tool_calls
            AG-->>CLI: Final response
        end
    end

    AG->>DB: Persist session
    CLI-->>U: Display

以一次 CLI 交互为例，完整的执行链路如下：

用户在终端输入消息
HermesCLI.process_input() 检查是否是斜杠命令，若否则传入 Agent
AIAgent.chat() 或 AIAgent.run_conversation() 被调用
_build_system_prompt() 组装系统提示：身份 + 平台提示 + 行为指导 + 模型特定指导 + 记忆快照 + 技能索引 + 上下文文件
进入主循环：调用 OpenAI 兼容 API
如果响应包含工具调用：
a. 对每个工具调用，handle_function_call() 进行参数类型强转
b. 检查是否是 Agent 级工具（todo, memory, session_search, delegate_task），若是则在 Agent 层拦截处理
c. 否则通过 registry.dispatch() 派发到工具 Handler
d. 工具结果追加到消息列表
触发 pre_tool_call / post_tool_call 插件钩子
检查是否需要上下文压缩（should_compress_preflight）
如需压缩，执行四阶段压缩流程
循环继续，直到 LLM 返回无工具调用的响应或达到迭代上限
会话元数据和消息历史持久化到 SessionDB
如果在 Gateway 模式下，响应通过相应平台适配器发送

Gateway 模式下的链路类似，但入口从 GatewayRunner 开始，经过平台适配器的消息标准化后进入同一个 AIAgent.run_conversation() 循环。

五、可扩展点

Hermes Agent 提供了多个清晰的扩展维度：

新工具：三步流程——创建工具文件、添加导入、加入工具集。工具注册表的自注册模式让扩展非常低摩擦。

新平台：在 gateway/platforms/ 下实现平台适配器，遵循 BasePlatformAdapter 接口。

新终端后端：在 tools/environments/ 下添加新的终端后端实现（当前支持 local、Docker、SSH、Modal、Daytona、Singularity）。

MCP 服务器集成：通过 tools/mcp_tool.py 连接外部 MCP 服务器，自动发现并注册工具。

插件系统：通过 hermes_cli/plugins.py 支持用户/项目/pip 插件，插件可以注册新工具和工具集。

技能系统：技能是 Agent 可以创建、安装和改进的 Markdown 文档，存储在 ~/.hermes/skills/ 下。技能可以通过 Skills Hub 发现和共享，兼容 agentskills.io 开放标准。

自定义 Skin：皮肤引擎提供纯数据驱动的 CLI 视觉定制，用户可以通过 YAML 文件定义自定义皮肤。

六、适用场景与局限

适用场景：

需要长期记忆和用户建模的个人 AI 助手
跨平台消息网关（统一管理多个通信渠道）
自动化定时任务（报告生成、监控告警）
AI Agent 研究（批量轨迹生成、RL 训练数据）
需要终端/代码执行能力的开发辅助
需要无服务器持久化的轻量部署

局限：

Python 单体架构：93.6% Python 代码，不适合对前端体验有极致要求的产品场景
不原生支持 Windows：需要 WSL2
同步核心循环：虽然简化了代码，但在高并发网关场景下可能成为瓶颈
无原生多租户：设计为”一个用户一个实例”，企业级多租户需要额外架构
记忆容量有限：有界记忆设计是特性也是限制，复杂长期项目可能需要更大的知识存储

七、RL 训练集成与轨迹生成

Hermes Agent 最独特的设计之一是其研究就绪的架构。这不仅仅是一个可用的 Agent——它同时也是一个 AI 训练数据工厂。

批量轨迹生成：batch_runner.py 支持并行批量处理——给定一组任务描述，批量运行 Agent 并收集完整的交互轨迹（包括系统提示、用户消息、模型推理、工具调用及其结果）。这些轨迹以 JSONL 格式保存，可以直接用于监督微调或强化学习。

轨迹压缩：trajectory_compressor.py 提供了一个专门的后处理工具，将完成的 Agent 轨迹压缩到目标 token 预算内，同时保留训练信号质量。压缩策略遵循一个精心设计的优先级：保护首轮次（系统提示、人类消息、首个 GPT 响应、首个工具调用），保护最后 N 轮次（最终行动和结论），仅压缩中间轮次，且只压缩达到预算目标所需的最少轮次。被压缩的区域替换为单个人类摘要消息，保留未压缩的工具调用完整性。这个设计的巧妙之处在于——压缩后的轨迹仍然是一个有效的、可训练的对话记录，模型可以从摘要处继续理解之前的工作。

Atropos RL 环境：environments/ 目录包含与 Tinker-Atropos（Nous Research 的 RL 训练框架）的集成环境。这些环境将 Agent 的工具调用行为封装为 RL 交互，支持在 Agent 的策略空间上进行强化学习训练。

工具集分布：toolset_distributions.py 为批量生成提供工具集分布配置，可以控制不同工具组合的采样概率。这确保训练数据覆盖多样化的工具使用场景，而不仅仅是最常见的路径。

这个研究基础设施的存在，意味着 Hermes Agent 不仅仅是消费 LLM 能力的系统，还是生产训练数据、反哺 LLM 改进的闭环系统。这在当前开源 Agent 项目中是独一无二的定位。

八、Gateway 架构与平台适配

Gateway 是 Hermes Agent 的多平台接入层，其设计体现了几个重要的工程取舍。

单进程多平台：GatewayRunner 在一个进程内管理所有平台适配器的生命周期。每个平台适配器独立连接和断开，但共享同一个事件循环。这简化了部署（一个进程搞定所有平台），但也意味着单个平台的崩溃可能影响整体稳定性。

消息标准化：每个平台适配器负责将平台特定的消息格式（Telegram 的 Update、Discord 的 Message 等）标准化为统一的内部格式。这包括文本提取、媒体处理（图片、音频、视频的下载和转换）、语音备忘录转录等。

斜杠命令共享：hermes_cli/commands.py 中的 COMMAND_REGISTRY 定义了所有斜杠命令。CLI、Gateway、Telegram 菜单、Slack 子命令路由、自动补全等所有下游消费者都从这个注册表自动派生。添加一个新的斜杠命令只需要在注册表中添加一个 CommandDef 条目，所有平台自动获得支持。这种单一真相源的设计大大降低了维护成本。

背景进程通知：当使用 terminal(background=true) 时，Gateway 运行一个观察者，将状态更新推送到用户的聊天中。通知详细程度可配置为 all（运行中输出 + 最终消息）、result（仅最终完成消息）、error（仅错误时的最终消息）或 off（完全禁用）。

Token 锁与 Profile 隔离：Gateway 平台适配器使用 token 锁——同一个 bot token 不能同时被多个 Profile 使用。这防止了不同 Hermes 实例之间的 bot 冲突。

第二部分：Hermes Agent 与 OpenClaw 的工程化对比

对比背景

维度	Hermes Agent	OpenClaw
首次发布	2025 年中	2024 年底
Star 数	35.7k	352k
贡献者	317	3,000+
主语言	Python 93.6%	TypeScript 90.3%
版本	v0.8.0	2026.4.8 (84 releases)
定位	自进化研究型 Agent	个人 AI 助手产品

一、运行时形态：本地/云/多平台

Hermes Agent 提供六种终端后端——local、Docker、SSH、Daytona、Singularity 和 Modal。Daytona 和 Modal 提供无服务器持久化——Agent 的环境在空闲时休眠，按需唤醒，空闲时几乎零成本。部署形态是”一个 Python 进程 + SQLite”，通过 hermes gateway 启动消息网关。支持 Nix 构建。入口分为两个：CLI 模式（hermes）和 Gateway 模式（hermes gateway），前者用于终端交互，后者用于消息平台集成。

OpenClaw 走的是更重的产品化路线。核心是一个 Node.js Gateway 进程作为 WebSocket 控制平面，管理会话、存在感、配置、Cron、Webhooks、Control UI 和 Canvas。配套有完整的 macOS 菜单栏应用（Voice Wake + PTT、Talk Mode overlay、WebChat、调试工具、远程 Gateway 控制）、iOS Node（Canvas、Voice Wake、Talk Mode、相机、屏幕录制、Bonjour + 设备配对）和 Android Node（连接标签、聊天会话、语音标签、Canvas、相机/屏幕录制、Android 设备命令）。支持 Tailscale Serve/Funnel 暴露 Gateway、Docker 部署和 Nix 声明式配置。

差异本质：Hermes Agent 是”轻量后端 + 重 Agent 循环”，OpenClaw 是”重 Gateway 平台 + 分布式 Node 架构”。前者更适合开发者和研究者，后者更像一个完整的消费级产品。

二、工具系统与权限边界

Hermes Agent 的工具系统以 ToolRegistry 单例为核心，支持自注册、工具集组合、运行时可用性检查和动态 Schema 重建。权限模型相对简单——tools/approval.py 提供危险命令检测，用户通过命令审批白名单控制。子 Agent 通过 DELEGATE_BLOCKED_TOOLS 显式剥离危险工具。工具执行在主机上进行，由用户自行管理安全边界。

OpenClaw 的工具系统更加精细。agents.defaults.sandbox.mode 支持三种模式：off（默认，主机直接执行）、non-main（非主会话在 Docker 沙箱中运行）、all（所有会话沙箱化）。沙箱有专用的允许/拒绝列表——默认允许 bash、process、read、write、edit、sessions_*；默认拒绝 browser、canvas、nodes、cron、discord、gateway。此外还有 tools.exec.applyPatch.workspaceOnly 和 tools.fs.workspaceOnly 等文件系统硬化选项，以及 sessions_spawn 的子 Agent 委托硬化。

OpenClaw 还有完整的 ACP（Agent Communication Protocol）支持和插件信任模型——“安装或启用一个插件就授予它与 Gateway 主机上本地代码相同的信任级别”。

差异本质：Hermes Agent 信任用户自己管理安全边界，适合技术用户的自托管场景。OpenClaw 则提供了更丰富的沙箱和权限层次，适合面向更广泛用户的产品部署。

三、长期记忆与数据持久化

Hermes Agent 的记忆系统由三个组件构成：

策展式记忆（MEMORY.md / USER.md）：有界、文件持久化、冻结快照注入系统提示
会话搜索（SessionDB + FTS5）：全文搜索所有历史会话，配合 LLM 摘要实现跨会话回忆
技能（Skills）：Agent 从经验中创建的可复用程序记忆

记忆采用 Markdown 文件格式，使用 § 分隔符分割条目。写入使用原子临时文件 + 重命名（os.replace()），读取不需要文件锁（因为原子重命名保证了读取一致性）。并发写入通过文件级独占锁（fcntl.flock）保护。

OpenClaw 的记忆系统更加模块化。记忆是一个”特殊插件槽”——同一时间只能有一个记忆插件活跃。当前已有多个记忆选项，长期计划收敛到一个推荐的默认路径。此外还有 MEMORY.md / memory/*.md 作为工作区级记忆文件。会话数据存储在本地配置目录中。OpenClaw 还集成了 Honcho 进行辩证用户建模（Hermes Agent 同样支持 Honcho 集成）。

差异本质：Hermes Agent 的记忆设计更紧凑、更”有机”——有界约束迫使 Agent 学会信息管理。OpenClaw 的记忆更模块化、可替换，但缺少 Hermes Agent 那种”从经验中创建技能”的闭环学习机制。

四、任务编排与调度

Hermes Agent 的任务编排包含三个层次：

工具循环：核心的”调用 LLM -> 执行工具 -> 追加结果 -> 重复”循环
子 Agent 委托：通过 delegate_task 工具生成隔离的子 Agent，支持单任务和批量并行模式（最多 3 个并行）
定时调度：基于文件锁的 Cron 调度器，支持自然语言任务定义、多平台交付、技能注入和数据收集脚本

OpenClaw 的任务编排更加丰富：

多 Agent 路由：入站渠道/账户/对等方可以路由到隔离的 Agent（工作区 + 每 Agent 会话）
Agent-to-Agent 会话工具：sessions_list、sessions_history、sessions_send、sessions_spawn 提供完整的跨会话协调能力
Cron + 唤醒：支持定时任务和 Webhooks
队列模式：控制消息处理的排队行为
Pi Agent 运行时：RPC 模式下的 Agent 运行时，支持工具流和块流

差异本质：Hermes Agent 的编排更简洁——单 Agent 循环 + 委托。OpenClaw 提供了更完整的多 Agent 拓扑——发现、消息传递、委托生成，更接近一个 Agent 操作系统。

五、可插拔性

Hermes Agent 的可插拔性体现在多个维度：

模型提供者：通过 hermes model 一键切换，支持 OpenRouter、Nous Portal、OpenAI、Anthropic 等
工具：自注册模式，三步添加新工具
终端后端：六种后端可选
MCP 集成：连接外部 MCP 服务器自动发现工具
插件：支持用户/项目/pip 插件
皮肤：数据驱动的 CLI 主题定制

OpenClaw 的可插拔性更加系统化：

插件 API：完整的 npm 包分发 + 本地扩展加载
渠道插件：26+ 消息渠道作为插件实现
记忆插件：记忆系统作为可替换插件槽
MCP 集成：通过 mcporter 桥接，保持核心精简
技能平台：内置/托管/工作区技能 + ClawHub 技能注册表
A2UI：Agent 驱动的视觉工作区（Canvas）

差异本质：Hermes Agent 的可插拔性偏向”开发者友好的扩展点”，OpenClaw 偏向”产品级的插件生态”。

六、可观测性与调试体验

Hermes Agent 的可观测性工具包括：

KawaiiSpinner：动画 spinner + 工具结果活动馈送（┊ 前缀的实时输出）
/usage 和 /insights 命令：token 使用和会话洞察
子 Agent 进度回调：父 Agent 实时显示子 Agent 的工具调用
会话搜索：/search 命令搜索历史会话
hermes doctor：诊断工具，检查配置和依赖状态
日志系统：标准 Python logging，支持 --verbose 模式
约 3,000 个测试：Pytest 测试套件

OpenClaw 的可观测性更加全面：

Control UI + Dashboard：Gateway 直接服务的 Web 控制界面
存在感 + 打字指示器：实时状态同步
健康检查：/status 命令和健康检查端点
Gateway 锁：防止多实例冲突
日志系统：完整的结构化日志
openclaw doctor：诊断工具 + openclaw security audit --deep
调试工具：macOS 应用内置调试工具
无障碍树：用于 Web 自动化的无障碍树暴露

差异本质：Hermes Agent 的调试体验是”开发者级”的（日志 + CLI + 测试），OpenClaw 是”运维级”的（Dashboard + 健康检查 + 安全审计）。

七、安全模型

Hermes Agent 的安全模型相对简洁：

命令审批：通过 tools/approval.py 检测危险命令，支持白名单
DM 配对：Gateway 支持 DM 配对码机制
容器隔离：可选的 Docker 终端后端
记忆注入扫描：检测 prompt 注入和数据窃取模式
上下文文件扫描：AGENTS.md 等文件的威胁模式扫描
Cron 脚本路径验证：防止路径遍历和任意脚本执行

OpenClaw 的安全模型是一个深思熟虑的信任模型体系：

“个人助手”信任模型：一个受信操作者，可能多个 Agent。不是”共享多租户总线”
DM 策略：dmPolicy 支持 pairing（默认）和 open 两种模式
沙箱系统：基于 Docker 的每会话沙箱，支持 off/non-main/all 三级
工具文件系统硬化：workspaceOnly 选项限制文件操作范围
Gateway + Node 信任：明确的 Gateway 作为控制平面、Node 作为执行扩展的信任模型
临时文件夹边界：专用的临时文件根目录，防止路径逃逸
安全审计：openclaw security audit --deep 扫描 + --fix 自动修复
完整的 SECURITY.md：详尽的漏洞报告流程、超出范围定义和信任边界文档

差异本质：Hermes Agent 的安全模型是”默认信任 + 选择性防护”，适合技术用户。OpenClaw 的安全模型是”默认安全 + 选择性开放”，有完整的威胁模型和信任边界文档，适合更广泛的部署场景。

八、社区生态

Hermes Agent 背靠 Nous Research（知名 AI 研究组织），社区生态侧重于：

Skills Hub：技能的发现和共享平台
Atropos RL 集成：与 RL 训练流水线的原生集成
轨迹压缩：为训练数据生成提供工具
OpenClaw 迁移工具：hermes claw migrate 提供从 OpenClaw 的迁移路径
Discord 社区

OpenClaw 是目前最大的开源 AI 助手社区之一：

ClawHub：技能注册表和发现平台
多平台伴侣应用：macOS/iOS/Android 原生应用
丰富的文档：架构概览、运维手册、安全指南、平台指南等
mcporter：独立的 MCP 桥接工具
WeChat 官方插件：腾讯官方提供的微信集成
Discord 社区 + 赞助计划

差异本质：Hermes Agent 的社区偏向研究和技术探索，OpenClaw 的社区偏向产品使用和生态建设。

第三部分：总结与展望

对比全景表

维度	Hermes Agent	OpenClaw
运行时	Python 进程 + SQLite，六种终端后端，无服务器支持	Node.js Gateway + WebSocket，原生多平台应用
工具系统	自注册表 + 工具集组合 + 动态 Schema 重建	插件 API + npm 分发 + 沙箱 + 权限层次
记忆	有界策展式 + 冻结快照 + FTS5 跨会话搜索 + 技能	可替换记忆插件 + 工作区文件
编排	同步循环 + 子 Agent 委托 + Cron	多 Agent 路由 + 会话工具 + Cron + 队列
可插拔性	工具/后端/MCP/插件/皮肤	插件 API/渠道/记忆/MCP/技能/Canvas
可观测性	CLI spinner + 日志 + doctor + 3000 测试	Dashboard + 健康检查 + 安全审计 + 调试工具
安全	命令审批 + DM 配对 + 注入扫描	完整信任模型 + 分级沙箱 + 安全审计
社区	研究导向，Skills Hub，RL 集成	产品导向，ClawHub，原生应用，352k Star

架构哲学的差异

Hermes Agent 和 OpenClaw 代表了 AI Agent 工程化的两条路径：

Hermes Agent 走的是”深度学习循环”路线——核心创新在于 Agent 的自我改进能力。技能系统让 Agent 从经验中学习，有界记忆迫使它管理知识优先级，轨迹压缩和 RL 集成让它可以训练自己的下一代。它的架构服务于这个目标：同步循环让推理链路可控，工具注册表让扩展低摩擦，多终端后端让研究者可以在各种环境中实验。

OpenClaw 走的是”全平台产品化”路线——核心创新在于将 AI 助手做成一个真正的消费级产品。26+ 消息渠道、原生 macOS/iOS/Android 应用、Voice Wake、Canvas、完整的安全模型和运维工具链，所有这些都服务于”让非技术用户也能拥有一个强大的个人 AI 助手”的目标。

对于不同的读者，我的建议是：

如果你是 AI Agent 研究者：Hermes Agent 的闭环学习设计、轨迹生成和 RL 集成是独一无二的研究基础设施。
如果你需要一个日常使用的个人 AI 助手：OpenClaw 的产品完成度和多平台覆盖更适合日常场景。
如果你是 Agent 框架的架构师：两个项目都有值得借鉴的设计模式——Hermes Agent 的工具注册表和冻结快照记忆，OpenClaw 的信任模型和沙箱分级。
如果你想从 OpenClaw 迁移：Hermes Agent 提供了一键迁移工具（hermes claw migrate），可以导入设置、记忆、技能和 API 密钥。

AI Agent 的工程化仍处于早期。这两个项目展示了不同方向的可能性——一个追求 Agent 的自主进化，一个追求助手的全面产品化。两者都在用自己的方式回答同一个问题：如何让 AI 成为真正有用的、持久的、值得信赖的工作伙伴？

启示与建议

在深入分析了这两个项目的源码后，我总结了几条对 Agent 架构设计者可能有价值的启示：

关于工具系统设计：Hermes Agent 的”自注册 + 运行时可用性检查 + 动态 Schema 重建”三连击是一个值得复制的模式。太多 Agent 框架在工具 Schema 中硬编码了对其他工具的引用，导致当某些工具不可用时模型产生幻觉。动态移除不存在的跨工具引用，是一个看似微小但影响深远的设计决策。

关于记忆设计：有界记忆不是退而求其次，而是一种设计哲学。无限记忆看似更强大，但实际上会导致系统提示膨胀、检索噪声增大、缓存失效等问题。Hermes Agent 的冻结快照模式——记忆在会话开始时冻结，中间写入仅持久化但不改变系统提示——是在 LLM 推理成本（前缀缓存）和信息新鲜度之间找到的一个精妙平衡点。

关于安全模型：OpenClaw 的 SECURITY.md 是我见过的开源 AI Agent 项目中最完善的安全文档之一。它不仅定义了信任边界，还明确列出了”不属于安全漏洞”的场景——这对于减少噪声安全报告非常有价值。任何计划向公众开放的 Agent 系统都应该有类似的威胁模型文档。

关于多平台架构：两个项目都选择了”消息标准化 + 平台适配器”的模式，但实现路径不同。Hermes Agent 的单 Python 进程更简单，OpenClaw 的 Gateway + WebSocket 控制平面更灵活。如果你的目标是轻量部署和快速迭代，前者更合适；如果你需要支持设备端 Node（相机、屏幕录制、位置等原生能力），后者的分布式架构是必要的。

关于闭环学习：Hermes Agent 的”使用 -> 创建技能 -> 改进技能 -> 压缩轨迹 -> RL 训练”闭环是 AI Agent 领域一个令人兴奋的方向。当前大多数 Agent 框架只是 LLM 能力的消费者，而 Hermes Agent 试图成为 LLM 能力的共同生产者。这可能代表了 Agent 框架发展的下一个阶段。

关于参数类型强转：一个经常被忽视的工程细节——LLM 经常将数字作为字符串返回（“42” 而不是 42），将布尔值作为字符串返回（“true” 而不是 true）。Hermes Agent 的 model_tools.py 中的 coerce_tool_args() 函数将每个参数值与工具注册的 JSON Schema 进行比对，在值是字符串但 Schema 期望不同类型时尝试安全强转。这种防御性编程在实际生产中能避免大量难以调试的工具调用失败。

关于子 Agent 的进程全局状态保护：Hermes Agent 在委托系统中对 _last_resolved_tool_names 全局变量的保存和恢复是一个教科书级的并发安全模式。任何使用进程全局状态的系统，在引入并行子任务时都应该考虑类似的保护机制。

本文基于 2026 年 4 月 8 日 Hermes Agent v0.8.0 和 OpenClaw 2026.4.8 版本的源码分析。两个项目都在快速迭代中，部分细节可能已有变化。