乐于分享
好东西不私藏

OpenClaw 源码拆解:TypeScript Gateway 架构与 Hermes Agent 的单循环对决

OpenClaw 源码拆解:TypeScript Gateway 架构与 Hermes Agent 的单循环对决
TL;DR

OpenClaw(380K GitHub Stars)和 Hermes Agent(Nous Research)是 2026 年最受关注的两个开源 Agent 框架。它们解决同一个问题——让 AI 自主执行任务——但架构哲学截然相反:OpenClaw 用 TypeScript Gateway 作为中央控制平面管理 25+ 消息通道和 14+ 子 Agent;Hermes Agent 用 Python 单循环 run_conversation() 在进程内完成一切。本文从源码级拆解两者的 Agent 生命周期、工具系统、记忆架构、多 Agent 协作和安全模型,给出五维对照表和生产环境选型指南。


一、先看全貌:两个框架的架构哲学

OpenClaw:Gateway 控制平面

OpenClaw 启动后,会在本机绑定一个 Gateway 进程(Node.js,src/gateway/),它承担三个角色:

  1. 消息路由
    ——从 Telegram/WhatsApp/Discord/Slack/iMessage 等 25+ 通道接收消息,按 session_key 路由到正确的会话
  2. 会话管理
    ——维护所有活跃会话的生命周期,按 Lane Queue 串行调度同一会话内的消息
  3. Agent 编排
    ——通过 sessions_spawn 启动子 Agent,通过 sessions_send 实现 Agent 间通信
用户消息(Telegram) → Channel Plugin 解析 → Gateway 路由(session_key) → Lane Queue 排队 → Agent Runtime 执行(Pi-Embedded / CLI Runner) → Model Call → Tool Dispatch → Response

Gateway 之下,Agent Runtime 有两种模式:

  • Pi-Embedded Runner
    :进程内执行,共享 Gateway 的工具和配置,适合轻量任务
  • CLI Runner
    :独立子进程(如 claude CLI),通过 ACP(Agent Communication Protocol)与 Gateway 通信

Hermes Agent:Python 单循环

Hermes Agent 没有 Gateway。它是一个 Python 进程,入口在 hermes/agent.py 的 run_conversation()

用户消息 → System Prompt 组装 → Agent Loop 开始 ├── Phase 1: Memory Recall(Hindsight 语义召回) ├── Phase 2: Skill Load(匹配 skill → 注入提示词) ├── Phase 3: Model Call(API 请求) ├── Phase 4: Tool Dispatch(解析 tool_calls → 执行 → 结果注入) ├── Phase 5: Hindsight Retain(自动记忆写入) └── Phase 6: 循环或终止

关键区别:Hermes 的「单循环」意味着同一时间只处理一个会话、一个消息。没有 Lane Queue,没有 Gateway 路由,没有多 Agent 原生支持(直到 v0.16 才引入 delegate_task)。

一张表看懂差异

维度
OpenClaw
Hermes Agent
语言
TypeScript (Node.js)
Python
架构模型
Gateway hub-and-spoke
单进程直接循环
多会话
原生并发,Lane Queue 串行
单会话,靠多次调用
消息通道
25+ 内置(Telegram/Discord/Slack/WhatsApp…)
Telegram + WebUI(靠 frp/cc-switch 扩展)
子进程安全
CLI Runner + Sandbox(Docker)
execute_code
 + 6 种终端后端
记忆系统
JSONL Session Log + Daily Markdown
Hindsight PG + Memory.md + Session DB
工具注册
静态 tools/ 目录 + 插件
动态 ToolRegistry + @register_tool 装饰器
配置文件openclaw.json
 + SOUL.md + TOOLS.md
config.yaml
 + SOUL.md + skills/

二、Agent 生命周期:从消息到响应

OpenClaw:session_spawn → lane_queue → run

当一条 Telegram 消息到达:

Step 1 — Channel Plugin 接入

// src/channels/plugins/types.plugin.tsinterface ChannelPlugin { id: string; start: (gateway: Gateway) => Promise<void>; stop: () => Promise<void>; onMessage: (msg: ChannelMessage) => Promise<void>;}

所有通道插件实现同一个接口。Gateway 启动时遍历注册表,为每个通道调用 start()

Step 2 — Gateway 路由

消息从通道插件进入 Gateway 后,首先要确定 session_key

// src/routing/session-key.ts// session_key 格式示例:// agent:main:telegram:chat:12345 ← Telegram 私聊// agent:main:slack:channel:C789 ← Slack 频道

这个 key 决定了消息分配到哪个 Agent 实例的哪个会话。同一 session_key 的消息被串行化到同一条 Lane Queue。

Step 3 — Lane Queue 串行调度

Lane Queue (先进先出) ┌─────────┐ │ msg_001 │ → Agent Runtime 处理中 ├─────────┤ │ msg_002 │ → 等待 ├─────────┤ │ msg_003 │ → 等待 └─────────┘

这是 OpenClaw 最关键的设计决策之一:同一会话的消息严格串行,避免 Agent 在处理上一条消息时收到新消息导致上下文竞争。但不同 session_key 的会话可以并行。

Step 4 — Agent Runtime 执行

Pi-Embedded Runner 在进程内完成整个 Agent Loop:

// 简化的执行流程(src/agents/)async function runAgentLoop(session) { // 1. 加载会话上下文(历史消息 + 记忆) const context = await loadContext(session); // 2. 组装 System Prompt(工具列表 + 技能 + 安全策略) const systemPrompt = await buildSystemPrompt(session); // 3. 模型调用 const response = await modelCall(systemPrompt, context); // 4. 工具分发 if (response.tool_calls) { for (const toolCall of response.tool_calls) { const result = await executeTool(toolCall); context.push({ role: ”tool”, content: result }); } // 回到步骤 3,继续循环 return runAgentLoop(session); } // 5. 持久化会话 await saveSession(session); return response;}

Hermes Agent:run_conversation() 7 阶段

Hermes 的核心循环在 hermes/agent/loop.py(约 800 行),分为 7 个明确阶段:

# 简化自 hermes/agent/loop.pyasync def run_conversation(user_message, session_id):# Phase 1: 记忆召回 memories = await hindsight_recall(user_message)# Phase 2: Skill 匹配 skills = match_skills(user_message)# Phase 3: System Prompt 组装(三层:Core + Hindsight + Skill) system_prompt = assemble_prompt(memories, skills)# Phase 4: Agent Loop for turn in range(MAX_TURNS):# 4a: 模型调用 response = await model_call(system_prompt, messages)# 4b: 工具分发与执行 if response.tool_calls: results = await execute_tools(response.tool_calls) messages.extend(results)# 4c: 检查是否应该终止 if response.finish_reason == ”stop”: break# Phase 5: Hindsight 自动写入 await hindsight_retain(session_context) return messages

关键差异

OpenClaw
Hermes Agent
并发模型
Lane Queue 串行 + 多会话并行
单线程,每次一个消息
上下文管理
JSONL Session Log,按行追加
内存消息列表,超过 budget 触发 compaction
会话持久化
文件系统(~/.openclaw/sessions/
Session DB(SQLite)+ Hindsight PG
终止条件
模型返回 stop_reason
finish_reason="stop"
 或 MAX_TURNS 或 budget 用尽

三、工具系统:注册、分发与安全边界

OpenClaw 工具系统

工具定义在 src/agents/tools/ 下,按功能分目录。每个目录内是一个完整的工具模块,包含定义文件和测试文件:

src/agents/tools/├── browser-tool.ts ← Playwright 浏览器自动化 + CDP 控制├── file-tools.ts ← 文件读写(read/write/search)├── terminal-tools.ts ← Shell 命令执行(foreground/background/pty)├── canvas-tools.ts ← Canvas 渲染(HTML → 图片)├── cron-tools.ts ← 定时任务调度├── session-tools.ts ← sessions_spawn / sessions_send(多 Agent 核心)├── mcp-tools.ts ← MCP 协议客户端工具├── memory-tools.ts ← 记忆写入/读取└── ...

每个工具实现一个统一的接口:

interface ToolDefinition { name: string; description: string; parameters: JSONSchema; execute: (params: any, context: ToolContext) => Promise<ToolResult>; policy?: ToolPolicy;}

**工具策略(Tool Policy)**是 OpenClaw 安全模型的核心——不是简单地"禁用危险操作",而是给每个工具定义精细的权限边界:

// src/agents/sandbox/tool-policy.tsinterface ToolPolicy { requireApproval?: boolean; // 执行前弹出确认对话框 sandboxOnly?: boolean; // 仅允许在 Docker 沙箱内执行 allowArgs?: string[]; // 参数白名单(如 terminal 只允许 ”ls”, ”cat”) denyArgs?: string[]; // 参数黑名单(如禁止 ”rm -rf /”) maxTimeout?: number; // 最大执行时间}

工具分发流程:当 LLM 返回 tool_calls 后,Gateway 进入分发循环——逐个工具执行,结果注入上下文,再决定是否继续调用模型:

Model returns tool_calls → for each tool_call: → policy check(是否需确认?是否限沙箱?) → execute(params) → result → push to context → back to model(带工具结果)

Hermes Agent 工具系统

Hermes 用 Python 装饰器注册工具,一个装饰器搞定全部元数据

# hermes/tools/registry.py@register_tool( name=”terminal”, description=”Execute shell commands on Linux. ” ”Foreground for short commands, ” ”background=true for long-running tasks.”, parameters={ ”command”: {”type”: ”string”, ”description”: ”The command to execute”}, ”background”: {”type”: ”boolean”, ”default”: False}, ”timeout”: {”type”: ”integer”, ”default”: 180} })async def terminal(command: str, background: bool = False, timeout: int = 180):# 终端后端选择逻辑 if background: return await run_background(command, timeout) return await run_foreground(command, timeout)

工具注册表是动态加载的——启动时扫描所有 ToolProvider 子类,按需实例化。每个工具还可以携带 skill 元数据,说明它归属于哪个 skill,便于按 skill 分组管理和权限控制。

Hermes 的工具安全分层更细:

安全层
机制
Prompt 层
System Prompt 中注入工具使用规则
策略层execute_code
 沙箱:禁用 os.system()subprocess(除 hermes_tools.terminal
终端层
6 种终端后端可选:local / ssh / docker / pty / background + sandbox
凭据层
AES-256-CBC Vault,敏感参数(API Key/密码)不经过 LLM

对比

OpenClaw
Hermes Agent
注册方式
静态 TypeScript 文件
装饰器 @register_tool 动态注册
安全策略
ToolPolicy(confirm + sandbox)
四层防御(Prompt → Policy → Terminal → Vault)
工具数量
60+(含浏览器/Canvas/定时任务/MCP)
50+(含 Playwright/终端/SSH 远程/vision)
扩展方式
写 .ts 文件 → 放 tools/ 目录 → 重启
写 Python + @register_tool → 放 skills/ → 热加载
MCP 支持
原生 mcp-tools.ts
通过 native-mcp skill 接入

四、记忆系统:文件 vs 数据库

这是两个框架差异最大的模块。

OpenClaw:JSONL + Daily Markdown

~/.openclaw/├── sessions/│ └── agent_main_telegram_12345.jsonl ← 每行一个 JSON 事件├── memory/│ ├── 2026-06-24.md ← 今日记忆(Markdown 格式)│ └── 2026-06-23.md ← 昨日记忆└── SOUL.md ← Agent 人格定义
  • Session Log(JSONL)
    :记录每一条消息的完整上下文,按行追加,无限增长
  • Daily Memory(Markdown)
    :Agent 从 Session Log 中自行提炼的长期记忆,由 Agent 自己决定写什么、写到哪天
  • 没有语义搜索
    :记忆查找靠 grep + Agent 自行阅读 Markdown 文件
// sessions/xxx.jsonl 的单行示例{”timestamp”:”2026-06-24T10:30:00Z”,”role”:”user”,”content”:”帮我查天气”}{”timestamp”:”2026-06-24T10:30:02Z”,”role”:”assistant”,”content”:”正在查询...”}{”timestamp”:”2026-06-24T10:30:05Z”,”role”:”tool”,”name”:”web_search”,”result”:”...”}

Hermes Agent:三层记忆矩阵

存储
用途
查找方式
Memory.md
文件系统
紧急兜底(环境事实、偏好)
全文注入 System Prompt
Hindsight
PostgreSQL + pgvector
语义记忆(9216+ facts)
hindsight_recall()
 语义搜索 + 关键词 + 实体图
Session DB
SQLite
会话历史(FTS5 全文索引)
session_search()
 跨会话检索

Hermes 的记忆查找是三段式管道

  1. Hindsight recallbge-m3 嵌入 → pgvector ANN → 重排序 → top-K
  2. Session DB FTS5:SQLite 全文搜索历史会话
  3. Memory.md 全文注入:兜底

关键差异

OpenClaw 的记忆模型本质是文件系统 + Agent 自管理——简单、透明,但缺乏语义检索能力。当你问「上次用户说的那个配置是什么」时,Agent 需要自己 grep 文件。Hermes 的 Hindsight 可以 472ms 内从 9216 条 fact 中语义召回相关记忆。


五、多 Agent 协作:平台原生 vs 工具模拟

OpenClaw:sessions_spawn + sessions_send(第一公民)

OpenClaw 的多 Agent 模型不是后来的补丁——从架构设计的第一天起,Gateway 就承担了 Agent 编排的职责。

核心 API 只有两个:

// 1. 启动子 Agent——本质是创建一个新的会话+Agent Runtimesessions_spawn({ agent: ”code-reviewer”, // 子 Agent 的配置名(openclaw.json 中定义) prompt: ”Review PR #42 的安全问题”, model: ”claude-sonnet-4”, // 可以指定不同模型(不同 Agent 用不同模型) context: ”项目使用 Django + PostgreSQL”,});// 2. Agent 间消息——本质是向另一个会话注入一条用户消息sessions_send({ target: ”agent:code-reviewer:session_abc123”, message: ”重点检查 SQL 注入和 XSS”,});

Sessions_send 的内部实现:Gateway 找到目标 session_key,将消息作为一条新的用户输入注入该会话的 Lane Queue,触发一次新的 Agent Loop 执行。对子 Agent 来说,这条消息和用户发的消息没有区别——它不知道消息来自人类还是另一个 Agent。

社区在实践中形成了 5 种架构模式(来自 OpenClaw 社区研究文档):

模式
机制
典型场景
并发度
Routing
按消息内容匹配路由规则 → 不同 Agent
客服分流:「退款」→退款 Agent,「技术」→技术 Agent
高(按消息并行)
Sub-Agentsessions_spawn
 启动,完成后结果回传主 Agent
代码审查 Agent 审查 PR → 结果发给主 Agent
低(同步等待)
Messagingsessions_send
 Agent 间异步消息
流水线:爬虫 Agent → 分析 Agent → 报告 Agent
中(异步流水线)
Orchestrator
三层嵌套(depth ≤ 2)
Kev's Dream Team:14+ Agent,Orchestrator 分配任务
中(嵌套控制)
CLI Agentopenclaw agent
 命令行启动独立进程
一次性任务:生成 100 篇 SEO 文章
高(进程级隔离)

Kev's Dream Team(14+ Agent)的实际架构:

Kev (Orchestrator, Opus 4.5) ├── Code Reviewer (Claude Sonnet 4) ├── Security Scanner (Claude Opus 4.5) ├── SEO Optimizer (GPT-4o) ├── Content Writer (Claude Sonnet 4) │ ├── Research Sub-Agent (深度=2) │ └── Fact Checker (深度=2) ├── Data Analyst (Claude Opus) └── Publisher (Claude Sonnet)

每个 Agent 有独立的 SOUL.md、独立的内存空间、独立的工具权限。Orchestrator 通过 sessions_send 分发任务,通过 sessions_spawn 创建子 Agent。关键限制:嵌套深度最大为 2(maxSpawnDepth: 2),防止无限递归。

Hermes Agent:delegate_task + Kanban(工具层模拟)

Hermes 的多 Agent 是通过 delegate_task 工具实现的——它不是 Gateway 层的原生能力,而是一个在 Agent Loop 内部被调用的工具

# 主 Agent 在工具调用阶段执行delegate_task( goal=”分析这个错误日志,找出根因”, context=””” 日志文件: /var/log/hermes/error.log 环境: Ubuntu 22.04, Python 3.11 最近变更: 升级了 Hindsight 0.8.0 ”””, toolsets=[”terminal”, ”file”, ”web”],# 子 Agent 只能用这三个工具集 role=”leaf”# leaf: 不能再 delegate;orchestrator: 可以再 delegate)

子 Agent 在全新的独立会话上下文中运行——不知道主 Agent 之前做了什么、不知道其他子 Agent 的结果。它只能通过 context 参数接收信息,通过返回值回传摘要。

Kanban 模式kanban-codex-lane skill):

Kanban Board┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐│ Lane 1 │ │ Lane 2 │ │ Lane 3 │ │ Lane 4 │ │ Lane 5 ││ 爬取数据 │ │ 清洗数据 │ │ 分析数据 │ │ 写报告 │ │ 发布 ││ Codex │ │ Codex │ │ Codex │ │ Codex │ │ Codex │└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘

5 个 Codex CLI 子进程并行执行,通过文件系统传递中间产物。状态由看板管理,主 Agent 只负责调度和汇总。

对比

OpenClaw
Hermes Agent
子 Agent 启动sessions_spawn
(Gateway 原生 API)
delegate_task
(Agent Loop 内的工具)
Agent 间通信sessions_send
(消息注入 Lane Queue)
无直接 API,靠文件系统 / 共享内存
嵌套深度maxSpawnDepth: 2max_spawn_depth: 3
模型独立
每个 Agent 独立配置模型
默认继承父 Agent,可 override
会话隔离
独立 session_key + 独立上下文
独立 session ID + 独立上下文
工具权限
每个 Agent 独立配置 tools/ 目录
toolsets
 参数限制工具集
生产案例
Kev's Dream Team(14+ Agent)
含光 Kanban(5 Codex Lane)

六、安全模型:信任用户 vs 分级防御

OpenClaw:用户是第一道防线

OpenClaw 的安全哲学很直白——「信任用户的判断,把决策权交给用户」:

  • 危险操作(如 rm -rf /)触发 requireApproval → 弹出确认对话框
  • sandboxOnly
     策略将高风险工具限制在 Docker 沙箱内
  • 没有内置的 Prompt Injection 防御
// 安全审计入口// src/security/audit.tsopenclaw security audit --check // 检查危险配置openclaw security fix // 自动修复已知漏洞

Hermes Agent:分层防御

Hermes 从 System Prompt 层就开始防御:

  1. Prompt Injection 检测
    threat_patterns.py 匹配已知攻击模式
  2. 工具沙箱
    execute_code 在受限 Python 环境中运行,终端命令通过策略过滤
  3. 凭据保险库
    :AES-256-CBC 加密,master key 不由 Agent 掌握
  4. 爆炸半径评估
    :SOUL v4.5 要求在每次行动前评估影响范围

七、选型指南:什么时候该用哪个

你的场景
推荐
原因
需要接入多个聊天平台(Telegram+Discord+Slack+微信)
OpenClaw
25+ 通道原生支持,Gateway 统一路由
需要复杂的多 Agent 编排
OpenClawsessions_spawn
 + sessions_send 是第一公民
需要深度语义记忆搜索
Hermes Agent
Hindsight PG + pgvector,472ms 召回
在资源受限的设备上运行(树莓派/Jetson)
Hermes Agent
Python 进程,内存占用更低
需要严格的安全审计
Hermes Agent
Prompt Injection 防御 + Vault 加密 + 爆炸半径评估
你是 Python 技术栈
Hermes Agent
纯 Python,零 JS 依赖
你是 TypeScript/Node.js 技术栈
OpenClaw
TypeScript 91.4%,npm 生态
需要快速上手、开箱即用
OpenClaw
npm install + openclaw init 三步启动
需要深度定制 Agent 内部逻辑
Hermes Agent
Python 代码更直观,无 Gateway 抽象层

八、总结:两条路线,一个终局

OpenClaw 和 Hermes Agent 代表了 Agent 框架的两种路线:

  • OpenClaw平台路线——做一个 Agent 的操作系统。Gateway 是内核,Channel Plugins 是驱动,Agent Runtime 是应用。多 Agent 是设计的第一天就内置的能力,25+ 消息通道让它"无处不在"。代价是 TypeScript 技术栈的复杂度、调试门槛高,以及安全模型把防线设在"用户确认"而非"系统拦截"上。

  • Hermes Agent工具路线——做一个可编程的 Agent 运行时。run_conversation() 是核心 API,装饰器是扩展接口,Python 生态是所有自定义的起点。深层语义记忆(Hindsight PG + pgvector)是它的护城河——当你需要 Agent 从 9216 条历史事实中 472ms 召回相关知识时,OpenClaw 的 grep + Markdown 做不到。代价是通道覆盖少、多 Agent 是后来者。

从商业视角看

  • OpenClaw = 380K Star 的社区飞轮 → 生态繁荣 → 更多插件和 Skill → 正向循环
  • Hermes Agent = Nous Research 的架构实验场 → Hindsight / Profile 隔离 / Cron 自动驾驶等独有能力 → 技术深度溢价

选哪个,取决于你的核心诉求:

  • 「让 Agent 无处不在」→ OpenClaw
  • 「让 Agent 记得更牢、做得更安全」→ Hermes Agent

或者,像本文的作者一样——两个都跑,各取其长。


下一篇预告:Claude Code CLI 源码拆解——Anthropic 的 Node.js 子进程模型如何实现 ACP 协议,与 OpenClaw 的 CLI Runner 和 Hermes 的 delegate_task 形成三角对照。