夜雨聆风
从一个工程问题开始
如果你只是想知道"用哪个"，上一篇已经说清楚了：OpenClaw 管入口，Hermes 管经验。
这篇往深走一层——从源码和工程实现角度，看两个系统的设计决策到底差在哪里。
为什么同样叫"通用 Agent 系统"，工程重心会完全不同？为什么 Hermes 的 Skills 和 OpenClaw 的 Skills 虽然用同一个词，但实现逻辑差很远？为什么两者的安全策略走了完全不同的路？
这些问题，功能对比表回答不了，要看代码。
核心技术栈的差异，决定了设计风格
先看基础：
• OpenClaw：Node.js / TypeScript，Gateway 和 Daemon 是长期运行的服务进程，通过 WebSocket 控制面和各渠道保持连接
• Hermes：Python 3.11，CLI 优先，Agent loop 是同步执行的，通过 SQLite 做持久化
这个差异不只是语言选择，它直接影响了两个系统的设计风格。
TypeScript 的异步模型和事件驱动很适合处理多渠道并发消息，OpenClaw 的 Gateway 天然适合这种场景。Python 的同步执行模型更适合 Agent loop 里的工具调用链，Hermes 的 run_agent.py 就是一个完整的同步 conversation loop。
OpenClaw：Gateway 是怎么工作的
OpenClaw 的核心是 Gateway——一个本地运行的控制面，负责接入渠道、管理会话、路由消息、控制权限。
渠道接入层
OpenClaw 支持 25+ 渠道，每个渠道有独立的 Gateway 适配器。以 Telegram 为例，它通过 Bot Token 接入，支持私聊和群聊，群聊里需要满足激活规则才会触发 Agent（避免每条消息都响应）。
渠道之间是隔离的：一个 Telegram 会话的上下文不会泄露到 Discord 会话里。这个隔离是通过 workspace 边界实现的，不同渠道可以映射到不同 workspace，每个 workspace 有独立的记忆和技能加载范围。
会话管理
OpenClaw 的会话是串行的——同一个 workspace 里，消息按顺序处理，不并发。这个设计保证了会话状态的一致性，代价是吞吐量受限。
会话压缩前有一个关键操作：静默记忆写入。在上下文被压缩之前，系统会把当前会话里的关键信息写入记忆文件，防止压缩丢失重要 context。
节点系统
OpenClaw 支持 macOS 菜单栏 App、iOS/Android 节点作为"设备节点"接入 Gateway。这意味着你可以在手机上发消息，Agent 在服务器上执行，结果推回手机——整个链路由 Gateway 统一管理。
这是 OpenClaw 和 Hermes 最大的工程差异之一：OpenClaw 有一套完整的设备节点和远程访问架构，Hermes 目前没有。
Hermes：学习循环的源码实现
Hermes 的核心是 run_agent.py，一个完整的 tool calling conversation loop。
run_agent.py：Agent Loop 的主干
# 简化后的核心逻辑while True: response = llm.call(messages, tools) if response.stop_reason == "end_turn": break tool_results = execute_tools(response.tool_calls) messages.append(tool_results) # 每 ~15 次工具调用后触发技能蒸馏 if should_distill(tool_call_count): skill_manager.distill_from_session(messages)每次工具调用后，系统会检查是否达到蒸馏阈值。这个"约 15 次"不是硬编码的常数，而是基于任务复杂度动态判断的。
model_tools.py：工具发现和分发
Hermes 的工具分发层做了一件有意思的事：它把工具分成两类——内置工具（terminal、browser、file operations）和动态工具（从 Skills 加载的工具）。
动态工具的发现是运行时的：Agent 在执行过程中可以通过 skill_manage 工具加载新技能，新技能里定义的工具会立刻进入可用工具列表。这意味着 Agent 可以在执行过程中扩展自己的能力边界。
skill_manager_tool.py：过程记忆的实现
这是 Hermes 最有特色的模块，开头注释写得很清楚：
"""Skills are the agent's procedural memory: they capture how to do a specific kind of task. Unlike factual memory (what happened), procedural memory captures the method (how to do it)."""技能文件是 Markdown 格式，保存在 ~/.hermes/skills/ 下。一个典型的技能文件包含：
• 任务描述（什么情况下用这个技能）
• 执行步骤（具体怎么做）
• 已知坑（上次踩过的错误）
• 成功标志（怎么判断做完了）
Agent 在创建技能时，会从当前会话的工具调用历史里提取成功路径，过滤掉失败的尝试，只保留有效的执行流程。
技能的自我修补也在这个模块里：当 Agent 发现某个技能的步骤不再有效（比如 API 变了、命令行参数变了），它会直接 patch 技能文件，而不是创建一个新技能。
hermes_state.py：SQLite + FTS5 的会话存储
# WAL 模式保证并发读写conn.execute("PRAGMA journal_mode=WAL")# FTS5 虚拟表，支持全文检索conn.execute(""" CREATE VIRTUAL TABLE IF NOT EXISTS sessions_fts USING fts5(content, source, session_id)""")Hermes 用 SQLite 的 FTS5 扩展做会话全文检索。FTS5 是 SQLite 内置的全文搜索引擎，支持 BM25 排序和前缀搜索。
这个设计的好处是零依赖——不需要 Elasticsearch 或向量数据库，本地就能跑。代价是检索质量有上限，复杂语义查询不如向量检索准确。
WAL（Write-Ahead Logging）模式允许并发读写：多个进程可以同时读取会话历史，写入不会阻塞读取。这对 Hermes 的 CLI + Messaging Gateway 双入口场景很重要。
会话按 source tag 过滤：cli、telegram、discord 等，不同入口的会话可以独立检索，也可以合并检索。
Skills 的加载机制：治理 vs 自治
OpenClaw 的 Skills 加载优先级
OpenClaw 按五个层级加载技能，优先级从高到低：
1. workspace skills（当前工作区的私有技能）2. personal agent skills（用户个人技能）3. project agent skills（项目级技能）4. managed/local skills（本地管理的技能）5. bundled skills（系统内置技能）高优先级的技能可以覆盖低优先级的同名技能。这个机制允许用户在不修改系统技能的情况下，用自己的版本覆盖默认行为。
技能加载还有 gating 机制：某些技能需要特定的环境变量、二进制文件或配置才能激活。比如 1password 技能需要 op CLI 已安装，voice-call 技能需要 ElevenLabs API Key。系统在加载时会检查这些前置条件，未满足的技能不会进入可用列表。
Hermes 的 Skills 运行时加载
Hermes 的技能加载是运行时动态的。Agent 可以在执行过程中：
skill_manage create "research_workflow" "步骤1: ... 步骤2: ..."skill_manage update "research_workflow" "修正步骤2: ..."skill_manage delete "outdated_skill"skill_manage list # 查看所有可用技能这些操作会直接修改 ~/.hermes/skills/ 下的文件，立刻生效。
Hermes 预置了 26 个技能类别（research、software-development、data-science、devops、mlops 等），兼容 agentskills.io 开放标准，理论上可以和 OpenClaw 的技能生态互通。
安全实现的具体差异
OpenClaw 的安全漏洞复盘
今年 2 月的 WebSocket Token 泄露漏洞，根本原因是 Gateway 的 WebSocket 连接使用了可预测的 Token 生成方式，外部攻击者可以在不知道 Token 的情况下枚举有效连接。
修复方案：改用加密安全的随机 Token，并增加了连接来源验证。
第三方技能的安全问题更复杂。ClawHub 上发现的恶意技能，主要攻击向量是：
1. Prompt 注入：技能的 SKILL.md 里包含隐藏指令，覆盖系统提示
2. 数据外泄：技能在执行过程中把上下文数据发送到外部 URL
3. 权限提升：技能声明需要某个工具权限，实际用于其他目的
OpenClaw 的应对方案：引入 openclaw security audit --deep 扫描技能文件，在 ClawHub 上增加人工审核，以及 Workspace Memory Trust Boundary 机制（跨 workspace 的记忆访问需要显式授权）。
Hermes 的纵深防御实现
Hermes 的危险命令审批是通过拦截 terminal 工具调用实现的：
DANGEROUS_PATTERNS = [ r"rm\s+-rf", r"sudo\s+", r"chmod\s+777", r"curl.*\|.*bash", # ...]def check_command_safety(command: str) -> ApprovalRequired: for pattern in DANGEROUS_PATTERNS: if re.search(pattern, command): return ApprovalRequired(reason=f"匹配危险模式: {pattern}") return Safe()超时未批准（默认 30 秒）自动拒绝，避免 Agent 卡在等待状态。
容器隔离通过 Docker backend 实现：
hermes config set terminal_backend dockerhermes config set docker_image "hermes-sandbox:latest"在 Docker 模式下，所有 terminal 命令在容器内执行，文件系统访问限制在挂载的工作目录内，网络访问可以通过 Docker 网络策略控制。
NixOS 模式提供了更细粒度的 namespace 隔离：
[Service]ProtectSystem=strictProtectHome=read-onlyPrivateTmp=trueNoNewPrivileges=true六种执行后端的对比
Hermes 支持六种 terminal backend，这是它和 OpenClaw 在部署架构上的另一个重要差异：
Modal 和 Daytona 的 serverless 模式值得单独说：Agent 不执行任务时，不占用任何资源，成本趋近于零。对于低频但需要长期运行的 Agent（比如每天跑一次的日报生成），这个模式很有吸引力。
OpenClaw 没有对应的多 backend 设计，它的执行环境是本地的，通过 Daemon 常驻运行。
迁移的完整命令和边界条件
# 预览会迁什么（不执行）hermes claw migrate --dry-run# 谨慎迁移（不含 secrets）hermes claw migrate --preset user-data# 完整迁移（含 allowlisted secrets）hermes claw migrate --preset full# 覆盖已有冲突hermes claw migrate --overwrite能迁的：SOUL.md、MEMORY.md、USER.md、用户创建的技能、命令白名单、部分消息平台配置、Telegram/OpenAI/Anthropic/ElevenLabs 等 API Key。
不能迁的：OpenClaw 的 Gateway 配置（Hermes 的 Gateway 实现不同，需要重新配置）、WhatsApp 等二维码配对型渠道（需要重新扫码）、workspace 边界设置（Hermes 没有对应概念）。
迁移后必做：
hermes model # 重新选择模型（迁移不会带过来）hermes gateway setup # 重新配置消息渠道hermes doctor # 诊断配置问题迁移的技能会放在 ~/.hermes/skills/openclaw-imports/ 下，新会话启动后才生效。建议迁移后先用 hermes CLI 跑几个任务验证，再开启 messaging gateway。
写在最后
从源码角度看，两个系统的工程决策都是自洽的：
OpenClaw 选择 TypeScript + 事件驱动，因为它要处理多渠道并发消息，这是最自然的选择。它把复杂度放在入口层和控制面，执行层相对简单。
Hermes 选择 Python + 同步循环，因为它要做工具调用链和经验蒸馏，同步模型更容易推理执行状态。它把复杂度放在执行层和记忆层，入口层相对简单。
两个系统解决的是 Agent 工程的不同层问题，不是同一个问题的两种解法。
如果你在搭自己的 Agent 基础设施，这两个项目的源码都值得读——不是为了选一个，而是为了理解 Agent 系统的两个核心难题：怎么管入口，怎么管经验。
结尾互动
如果这篇文章对你有帮助，点击右下角"在看"，让更多人看到。
关注「飘雪思考」，每周更新 AI 技术解析与工程实践，和 10 万+ 读者一起搞懂 AI。
💬 你怎么看？ 你在自己的 Agent 项目里，更关注入口治理还是经验沉淀？遇到过哪些工程上的坑？
欢迎在评论区留下你的想法，我都会看的。
📌 收藏这篇文章，下次做 Agent 架构选型时直接翻出来参考。
觉得有用就转发给朋友，说不定正好帮到需要的工程师。
