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/),它承担三个角色:
- 消息路由
——从 Telegram/WhatsApp/Discord/Slack/iMessage 等 25+ 通道接收消息,按 session_key路由到正确的会话 - 会话管理
——维护所有活跃会话的生命周期,按 Lane Queue 串行调度同一会话内的消息 - 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
:独立子进程(如 claudeCLI),通过 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)。
一张表看懂差异
| 语言 | ||
| 架构模型 | ||
| 多会话 | ||
| 消息通道 | ||
| 子进程安全 | execute_code | |
| 记忆系统 | ||
| 工具注册 | tools/ 目录 + 插件 | ToolRegistry + @register_tool 装饰器 |
| 配置文件 | openclaw.jsonSOUL.md + TOOLS.md | config.yamlSOUL.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 Loopfor 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/sessions/) | |
| 终止条件 | 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 层 | |
| 策略层 | execute_codeos.system()、subprocess(除 hermes_tools.terminal) |
| 终端层 | local / ssh / docker / pty / background + sandbox |
| 凭据层 |
对比
| 注册方式 | @register_tool 动态注册 | |
| 安全策略 | ||
| 工具数量 | ||
| 扩展方式 | .ts 文件 → 放 tools/ 目录 → 重启 | @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 | |||
| Hindsight | hindsight_recall() | ||
| Session DB | session_search() |
Hermes 的记忆查找是三段式管道:
Hindsight recall:bge-m3嵌入 → pgvector ANN → 重排序 → top-KSession DB FTS5:SQLite 全文搜索历史会话 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 | |||
| Sub-Agent | sessions_spawn | ||
| Messaging | sessions_send | ||
| Orchestrator | |||
| CLI Agent | openclaw agent |
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 只负责调度和汇总。
对比
| 子 Agent 启动 | sessions_spawn | delegate_task |
| Agent 间通信 | sessions_send | |
| 嵌套深度 | maxSpawnDepth: 2 | max_spawn_depth: 3 |
| 模型独立 | ||
| 会话隔离 | ||
| 工具权限 | toolsets | |
| 生产案例 |
六、安全模型:信任用户 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 层就开始防御:
- Prompt Injection 检测
: threat_patterns.py匹配已知攻击模式 - 工具沙箱
: execute_code在受限 Python 环境中运行,终端命令通过策略过滤 - 凭据保险库
:AES-256-CBC 加密,master key 不由 Agent 掌握 - 爆炸半径评估
:SOUL v4.5 要求在每次行动前评估影响范围
七、选型指南:什么时候该用哪个
| OpenClaw | ||
| OpenClaw | sessions_spawnsessions_send 是第一公民 | |
| Hermes Agent | ||
| Hermes Agent | ||
| Hermes Agent | ||
| Hermes Agent | ||
| OpenClaw | ||
| OpenClaw | ||
| Hermes Agent |
八、总结:两条路线,一个终局
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形成三角对照。
夜雨聆风