Agent 框架技术架构揭秘：OpenClaw 与 Hermes Agent 深度解析

大模型很强，但只会说——它能告诉你怎么改代码，却不会帮你改；你上周跟它聊过的方案，今天再打开完全不记得。Agent 框架就是为了解决这个问题而生的：给大脑装上四肢和记忆，让模型从能说会道变成能说能做。

本文深入解析两个走在最前面的开源 Agent 框架——OpenClaw（Node.js，多通道消息网关）和 Hermes Agent（Python，自进化学习），从架构设计到实现细节，从共同哲学到各自特色。

---

第一章：为什么需要 Agent 框架

大模型很强,但只会"说"

我们都知道大模型现在很强,GPT-4、Claude、Gemini、Qwen,能力越来越接近。但你有没有想过一个问题–不管模型多强,它本质上还是在"说"。你问它怎么改代码,它告诉你怎么改,但它不会帮你改。你上周跟它聊过的方案,今天再打开,它完全不记得了。

它是一个很强的大脑,但没有手、没有记忆、不会主动做事。它只会"说"。

Agent = 能动手、能记忆的大模型

那什么时候大模型才算真正能干活?两件事补上就行。

第一,工具使用。让模型能读文件、改代码、跑命令、上网搜索。它不再是"建议你怎么做",而是直接帮你做完。

第二,长期记忆。让模型记得你是谁、你的项目是什么、上次讨论到哪里了。它不再是每次对话都从零开始的陌生人,而是一个越用越懂你的搭档。

这两个能力加上去,大模型就变成了 Agent。这不是量变,是质变。

Agent 框架:给大脑装上四肢和记忆

但这两个能力,模型厂商自己不提供。OpenAI 给你一个 API,Anthropic 给你一个 API,它们提供的是大脑–推理能力。但工具怎么接、记忆怎么存、消息从哪来到哪去,这些事它们不管。

这就需要一层基础设施来补上。我们叫它"Agent 框架"–它不是模型本身,而是让模型变成 Agent 的那层东西。给大脑装上四肢和记忆。

今天介绍的 OpenClaw 和 Hermes Agent,就是两个走在最前面的开源 Agent 框架。

跟传统的 Agent 平台有什么不一样?

你可能会问,这两个框架跟 Dify、Coze 这些平台有什么区别?

最大的区别是–Dify、Coze 你在网页上拖拽、填表单,配置存在平台的云端。而 OpenClaw 和 Hermes,你的 Agent 就是项目目录里的几个 Markdown 文件,跟代码一起 git 管理。

OpenClaw 是 Node.js 写的,主打自托管和 25+ 通讯渠道统一接入;Hermes 是 Python 写的,主打自进化和研究能力。但它们有一个共同点–Agent 躺在你的 git 仓库里,不在别人的云上。

两个框架,相似的理念

OpenClaw 和 Hermes Agent 是两个独立的开源项目,不是 fork 关系。

OpenClaw 用 Node.js 写,侧重的是多通道消息路由和网关能力–25+ 通讯渠道统一接入,还能通过 ACP 协议桥接 Codex、Claude Code 这些外部编码工具。

Hermes Agent 是 Nous Research 独立开发的,用 Python 写,侧重的是自进化和研究能力–Agent 能自动生成和改进 Skills,支持 7 种终端后端含 Serverless,还能生成 RL 训练轨迹。

接下来我们分别看看它们的架构。

第二章：OpenClaw — 多通道 AI 网关

Gateway 架构总览:一个进程,五条数据流

我们从架构开始。OpenClaw 的核心是一个长驻的 Gateway 守护进程。我们从数据流的角度,把它内部拆成五个环节来理解–这不是官方的分层术语,而是帮助大家看清一条消息从进来到回复出去经过了什么。

最外层是通讯层–25+ 通讯渠道的连接器,WhatsApp 用 Baileys、Telegram 用 grammY、Discord、Signal、飞书、微信,甚至 IRC 和 Nostr 都有。所有消息在这里被统一成内部格式。

第二层是路由层–Bindings 规则决定每条消息交给哪个 Agent。

第三层是会话层–管理对话状态、上下文窗口、消息队列。

第四层是Agent 运行时–也叫 Agent Loop,这是核心:接收消息、组装 Prompt、调用模型、执行工具、流式输出。

最后是工具执行–文件操作、命令执行、浏览器、搜索、Skills 扩展。

整个系统就这一个进程。控制面(CLI、Web UI、macOS App)通过 WebSocket 连接,协议是 JSON 文本帧。不需要数据库、不需要消息队列。一行 npm install -g openclaw 就跑起来了。

通讯层 + 路由层:25+ 渠道,一套规则

通讯层支持 25 个渠道。内置的有 WhatsApp、Telegram、Discord、Signal、Slack、iMessage、IRC、WebChat、Google Chat。通过插件扩展的有飞书、BlueBubbles、Matrix、Microsoft Teams、QQ Bot、LINE、Nostr、Twitch、Zalo 等。

路由规则叫 Bindings。它的作用是–每条消息进来时,决定交给哪个 Agent 处理。这个匹配是确定性的,不是模型决定的,而是用户在配置文件里写好的。

匹配顺序有 8 级,最具体的优先:

第一级,peer 匹配–精确到某个人或某个群的 ID,比如"这个 WhatsApp 号发来的消息全部交给 work Agent"。
第二级,parentPeer 匹配–线程继承,子线程自动跟随父会话的路由。
第三级,guildId + roles–Discord 服务器 + 角色级别的匹配。
第四级,guildId–Discord 服务器级别的匹配。
第五级,teamId–Slack 工作区级别的匹配。
第六级,accountId 精确匹配–按渠道账号路由,比如 WhatsApp 的 personal 账号和 biz 账号分别路由到不同 Agent。
第七级,渠道级匹配–accountId 通配("*"),该渠道下任何账号都匹配。
第八级,默认 Agent–以上都没匹配上就落到默认。

同一级内,先写的 binding 优先。配置长这样:

{
  bindings: [
    { agentId: "home", match: { channel: "whatsapp", accountId: "personal" } },
    { agentId: "work", match: { channel: "whatsapp", accountId: "biz" } },
  ]
}

这个例子就是–WhatsApp 的 personal 账号走 home Agent,biz 账号走 work Agent。同一个渠道,两个号,各自独立。

一个 Gateway 进程,就是一个完整的通讯中心。

会话层:隔离、生命周期与消息队列

会话层是 OpenClaw 设计得很精巧的一层。

首先是隔离策略。默认情况下,所有私聊共享一个会话–你从 WhatsApp 发的消息和从 Telegram 发的消息在同一个上下文里,跨平台对话是连续的。但如果多人共用一个 Agent,就必须开启隔离,否则 Alice 的私聊内容 Bob 也能看到。

隔离策略通过配置文件里的 session.dmScope 字段来设置,四种模式选一个:

{ session: { dmScope: "per-channel-peer" } }

main 是默认值,所有私聊共享一个会话;per-peer 按发送者隔离但跨渠道共享;per-channel-peer 按渠道+发送者隔离,官方推荐;per-account-channel-peer 最严格,连同一渠道的不同账号也隔离。

实现原理很简单–每条消息到达时,Gateway 用"渠道+发送者"拼接出一个 sessionKey,比如 agent:my-bot:telegram:123456。渠道不同或发送者不同,sessionKey 就不同,自然落入不同的会话。如果同一个人从多个渠道联系你,可以用 identityLinks 把身份关联起来,共享同一个会话。

群聊则天然按群隔离,不需要配置。

有一点要注意–dmScope 隔离的是对话历史,不是工作空间。同一个 Agent 下的所有 session 共享同一个 workspace,也就是共享 MEMORY.md、SOUL.md 这些文件。Agent 跟 Alice 聊天时写入的记忆,跟 Bob 聊天时也能看到。如果要记忆也隔离,就得给不同用户分配不同的 Agent–每个 Agent 有独立的 workspace。

然后是生命周期。会话默认每天凌晨 4 点自动重置–新的一天,新的上下文。也可以配空闲超时重置。用户随时 /new 手动开新会话。

最关键的是命令队列。当 Agent 正在处理一条消息时,新消息进来怎么办?这个行为是用户通过配置 messages.queue.mode 来决定的,不是框架自动判断。OpenClaw 提供了 7 种队列模式,还可以按渠道分别配置。最常用的三种:collect 是默认模式–把排队的消息合并成一个 followup turn,减少重复回复;steer 是把新消息注入到当前正在运行的 Agent turn 里,在下一个工具调用边界生效;followup 是等当前 turn 结束再开始新的。还有 steer-backlog、steer+backlog、queue、interrupt 等变体。

还有 Compaction–当对话太长快要超出上下文窗口时,自动把旧消息压缩成摘要。压缩前还会先跑一个 memory flush,提醒 Agent 把重要信息写入记忆文件,防止信息丢失。

Agent 运行时:一次 Agent Loop 的完整旅程

现在到最核心的部分–Agent Loop。OpenClaw 的 Agent 运行时是基于 Pi Agent Core 的嵌入式运行时。当一条消息到达,到最终回复发出,中间经历了什么?

第一步,消息接收与会话解析–Gateway 收到消息后,解析出对应的 session,确定交给哪个 Agent。

第二步,上下文组装–这是最精密的部分。OpenClaw 每次运行都会构建一个自定义的 System Prompt,根据官方文档,里面包含:工具列表和简述、Skills 列表(只加载元数据,具体内容按需加载)、Bootstrap 文件内容(AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md、MEMORY.md 等,大文件会截断)、时区和运行时元数据。然后加上会话历史消息,控制在上下文窗口内。

第三步,模型推理–调用 LLM。OpenClaw 支持 35+ 个模型提供商,包括 Anthropic、OpenAI、Google、OpenRouter、通义千问、深度求索、Ollama 等,有内置提供商也有通过插件扩展的。模型可以返回纯文本,也可以返回工具调用请求。

第四步,工具执行–如果模型请求调用工具,执行工具并把结果反馈给模型,模型继续推理。这个循环可能多轮。

第五步,流式输出与交付–模型的回复通过流式传输实时推送给用户,同时工具执行状态也会实时反馈。

整个过程是序列化的–同一个 session 同时只有一个 Agent run,新消息进来的处理方式取决于前面讲的队列模式。

多 Agent 隔离:一个 Gateway,多个大脑

OpenClaw 的多 Agent 不是"多个角色",而是真正的隔离。

每个 Agent 有三个独立的存储空间:workspace(工作目录,放人格文件、代码、记忆)、agentDir(认证配置、模型注册)、session store(对话历史)。Agent 之间默认零共享。

你可以用多种方式分配 Agent:一个 Discord Bot 账号对应一个 Agent;同一个 WhatsApp 号按联系人手机号路由到不同 Agent;按 Discord Guild 的角色分 Agent;甚至按渠道分–WhatsApp 走快速模型的日常 Agent,Telegram 走 Opus 的深度工作 Agent。

每个 Agent 还可以有独立的安全策略–sandbox 模式(off/non-main/all)、工具白名单和黑名单、独立的 Skills 允许列表。比如给"家庭群"Agent 只开放 read 工具,禁止 write/exec。

一个 Gateway 就是一个 Agent 管理平台。

举个实际的配置:WhatsApp 的 personal 账号路由到 home Agent,biz 账号路由到 work Agent。Discord 按 Guild 分,A 服务器走 coding Agent,B 服务器走 support Agent。每个 Agent 的 sandbox 模式可以不同–个人 Agent 不沙箱(信任自己),群聊 Agent 强制沙箱(不信任别人)。工具白名单也可以不同–家庭群 Agent 只开放 read 和 web_fetch,禁止 write/exec。

工具系统总览:内置工具 + Skills + 插件

工具层分三个子系统,先看它们的关系。

内置工具是硬编码的核心能力–read/write/edit 操作文件,exec/process 执行命令,browser 浏览器自动化,web_fetch 抓取网页,memory_search 检索记忆,cron 定时任务,sessions_spawn 创建子 Agent。这些工具受 tool policy 控制,可以按 Agent 配置允许/禁止列表。

Skills 不是工具本身,而是教 Agent 怎么用工具的指导文档。每个 Skill 是一个目录,里面有 SKILL.md,兼容 AgentSkills 开放标准,社区共享在 ClawHub 上。

插件是深度扩展机制,可以给 OpenClaw 添加新的推理提供商、新的通讯渠道、新的工具。内置的飞书、Matrix、QQ Bot 等渠道就是通过插件实现的。

接下来我们分别看看各自的内部结构。

工具结构与调用过程

具体看一个工具是怎么工作的。以"列目录"为例–你跟 Agent 说"看看当前目录有什么文件",模型返回一个工具调用请求,指定调用 exec 工具、参数是 ls -la。Gateway 拿到这个请求,检查 tool policy(允许吗?)、检查 sandbox(需要隔离吗?),然后执行命令,把输出结果返回给模型。模型看到结果后再继续推理–可能直接回复用户,也可能再调用下一个工具。

工具注册管线

工具从定义到可用,经过一条注册管线。插件通过 register(api) 回调注册能力,SDK 提供了近 30 种 register 方法:registerProvider(文本推理)、registerSpeechProvider(语音合成)、registerImageGenerationProvider(图像生成)、registerChannel(通讯渠道)、registerTool(自定义工具)、registerHook(事件钩子)、registerContextEngine(上下文引擎)等。内置的飞书、Matrix、QQ Bot 等渠道就是通过插件实现的。

Skill 加载阶段

Skill 的生命周期分两个阶段。先看加载阶段。

Gateway 启动或新 Session 开始时,会扫描 6 个位置加载 Skills:workspace skills 优先级最高,然后是 project agent skills、personal agent skills、managed skills、bundled skills,extra dirs 最低。同名 Skill 高优先级覆盖低优先级。

扫描完还要过滤–每个 Skill 的 YAML frontmatter 里可以声明依赖条件,比如需要某个二进制在 PATH 上、需要某个环境变量存在。不满足的直接跳过。

通过过滤的 Skills 缓存为快照,整个 Session 复用。然后只把名称、描述和文件路径注入 System Prompt–注意,内容不注入。每个 Skill 约 97 个字符加上字段长度,token 消耗很低。

Skill 触发阶段

Skill 怎么被触发?两条路径。

主要路径是模型自动触发。模型在 System Prompt 里看到了 Skills 列表,分析用户意图后判断需要哪个 Skill,就通过 read 工具加载完整的 SKILL.md,然后按里面的指令调用对应的 Tools 执行。

另一条路径是用户通过斜杠命令触发,比如输入 /skill image-lab 生成猫图。默认情况下转发给模型处理,也可以配置为绕过模型直接调用工具。

Skill 核心要点

三个核心要点。

第一,Skill 不是可执行函数。它是 Markdown 文件,定义的是"怎么用工具"的指导,不是工具本身。

第二,按需加载。System Prompt 只注入名称和描述,不注入内容。模型需要时才通过 read 加载完整内容,控制 token 消耗。

第三,最终执行的是 Tools。Skill 的作用是给 Agent 提供上下文、约束和指导,引导模型调用 exec、write、browser 等 Tools 来完成实际工作。

Sub-agent、ACP 与上下文引擎

三个高级能力。

Sub-agent:主 Agent 可以 spawn 出子 Agent,每个跑在独立 session 里。关键设计是 push-based–完成后自动把结果 announce 回父 session 的聊天渠道,不需要轮询等待。每个 sub-agent 可以配不同模型–主 Agent 用 Opus 做判断,sub-agent 用 Sonnet 做执行,省钱。Sub-agent 默认不给 session 工具,防止权限扩散。

ACP 协议:Agent Client Protocol 让 OpenClaw 桥接外部编码工具。你可以在 Discord 线程里绑定一个 Codex 会话,或者在 Telegram 对话里绑定 Claude Code,OpenClaw 统一管理生命周期–spawn、steer、cancel、close。支持 thread-bound 持久会话,也支持 one-shot。内置 acpx 运行时插件,开箱即用。

Context Engine:这是一个可插拔的上下文组装引擎。默认的 legacy 引擎用 OpenClaw 内置的摘要压缩。但你可以通过插件替换–比如社区的 lossless-claw 插件实现无损上下文管理。引擎有四个生命周期点:ingest(消息存储)、assemble(构建模型输入)、compact(压缩历史)、after turn(run 结束后持久化状态)。assemble 还可以返回 systemPromptAddition,在不修改静态文件的情况下动态影响 Agent 行为。

记忆系统:Markdown 文件 + 语义搜索 + Dreaming

OpenClaw 的记忆系统跟 Hermes 的思路不太一样。Hermes 是两个有严格容量限制的文件(MEMORY.md 2200 字符、USER.md 1375 字符),写满了就拒绝写入,必须先整理。OpenClaw 不一样,MEMORY.md 没有硬性字符数限制,但作为 bootstrap 文件注入时单文件最大 20000 字符,超出会截断。它用三层文件来组织记忆。

第一层是 MEMORY.md–长期记忆,存持久的事实、偏好、决策。每次私聊会话开始时自动加载。

第二层是 memory/YYYY-MM-DD.md–每日笔记,运行中的上下文和观察。今天和昨天的笔记自动加载。

第三层是 DREAMS.md–这是一个实验性功能叫 Dreaming,后台自动整理短期记忆,筛选出值得长期保留的内容提升到 MEMORY.md。类似人的睡眠整理记忆。

搜索方面,OpenClaw 提供 memory_search 和 memory_get 两个工具。memory_search 支持混合检索–结合 embedding 向量相似度和关键词匹配,即使用词不同也能找到相关内容。配置了 OpenAI、Gemini、Voyage 或 Mistral 的 API Key 就自动启用。

记忆后端有三种选择:Builtin 是默认的 SQLite 后端,开箱即用;QMD 是本地优先的侧车,支持重排序和查询扩展;Honcho 是 AI 原生的跨会话记忆,支持用户建模。

还有一个重要机制–Compaction 前的自动 memory flush。当对话太长需要压缩时,OpenClaw 会先跑一个静默的 turn,提醒 Agent 把重要信息写入记忆文件,防止压缩时丢失上下文。这个是默认开启的,不需要配置。

自动化:Cron + Heartbeat + Hooks

OpenClaw 的自动化不只是"定个闹钟"。

Cron 支持三种调度:一次性(at)、固定间隔(every)、cron 表达式。每个 cron job 可以选择在 main session 注入系统事件,或者在 isolated session 里独立运行一个 Agent turn。isolated session 意味着独立的上下文、可以配不同模型、不污染主对话。

Heartbeat 是周期性心跳。Agent 定时醒来,读取 HEARTBEAT.md 里的检查清单–查邮件、看日历、检查监控。适合需要批量检查的场景,减少 API 调用。

Hooks 是事件驱动的脚本。分两种:内部 hooks 和插件 hooks。内部 hooks 包括 agent:bootstrap(在 bootstrap 文件注入前触发,可以添加或替换文件)、command:new、command:reset、command:stop(拦截用户命令)。插件通过 registerHook 注册更多事件钩子。

还有 Webhook 入站触发和 Standing Orders(代理人模式下的自主行动规则)。Agent 从被动响应变成了主动工作的代理人。

安全模型:分层防御

安全是分层的,从外到内四道防线。

第一层是 Channel Allowlist–控制谁能跟 Agent 对话。WhatsApp 可以配允许的手机号列表,Discord 配允许的频道,Telegram 配 pairing 审批。

第二层是 Exec Approvals–Agent 要执行命令时,可以要求人工审批。支持 allowlist 模式(只有白名单命令免审批)和 ask-on-miss 模式(未知命令弹审批)。审批支持原生 UI 按钮(Discord/Web)或聊天命令。

第三层是 Sandbox–工具执行在隔离环境里跑。支持三种后端:Docker、SSH、OpenShell。mode 可以设为 off(关闭)、non-main(非主会话强制沙箱)、all(全部沙箱)。可以按 Agent 配置–主 Agent 不沙箱,群聊 Agent 强制沙箱。沙箱内的浏览器也有独立的 Docker 网络。

第四层是 Tool Policy–按 Agent 配置工具的允许/禁止列表。比如家庭群 Agent 只允许 read,禁止 write/edit/exec。

所有 WebSocket 连接都需要设备配对–首次连接需要审批,后续用 device token 重连。远程访问推荐走 Tailscale 或 SSH 隧道。

最后是移动节点。手机装上 OpenClaw App 配对后,Agent 获得物理世界的感知能力–调用摄像头拍照、获取 GPS 定位、录屏。节点通过同一个 WebSocket 协议连接,声明 role: node 和可用的 commands/caps。

OpenClaw 架构总结

总结 OpenClaw 的架构。它是一个单进程的多通道 AI 网关,我们从数据流角度梳理了五个核心环节:消息接入统一 25+ 渠道,Bindings 做确定性路由,Session 管理隔离和队列,Agent Loop 跑完整的推理-工具循环,工具系统通过内置工具 + Skills + 插件无限扩展。

它的关键差异化在于:多通道统一接入–你的 Agent 活在所有通讯工具里;多 Agent 真隔离–workspace、auth、sessions 三层分离;ACP 桥接–Codex、Claude Code、Gemini CLI、Cursor 等都可以通过 OpenClaw 统一管理;可插拔 Context Engine–上下文组装策略可以替换;分层安全–从 Allowlist 到 Sandbox 四道防线。

如果你需要一个"让 Agent 活在所有通讯工具里"的基础设施,OpenClaw 是最成熟的开源选择。Node.js 生态,npm install -g openclaw 一行安装,openclaw setup 配置,openclaw gateway start 启动。文档在 docs.openclaw.ai,技能市场在 clawhub.ai。

那 Hermes Agent 在此基础上又做了什么不同的事?

第三章：Hermes Agent — 自进化的 Agent

Hermes Agent:架构总览

Hermes Agent 是 Nous Research 推出的开源 Agent 框架,Python 写的,口号是"The self-improving AI agent"–自进化的 AI Agent。

它不是某个 IDE 的编程助手,也不是套了个壳的聊天机器人。它是一个能自主成长的 Agent–越用越强,自己创建技能、自己改进技能、自己提醒自己持久化知识,还能用 FTS5 搜索所有过去的对话。$5 的 VPS 就能跑起来,也可以跑在 GPU 集群或 Serverless 上。不绑定你的笔记本–你在 Telegram 上聊天,它在云端 VM 上干活。

架构上,Hermes 有五个入口:CLI 是交互式终端界面,Gateway 是消息平台网关(支持 20+ 平台),ACP(Agent Client Protocol)是编辑器集成(VS Code/Zed/JetBrains),Batch Runner 用于批量轨迹生成,API Server 提供 HTTP 接口。五个入口共享同一个核心引擎–AIAgent 类,负责 Prompt 组装、工具调度、Provider 故障切换。下面的存储层分三块:Session Storage(SQLite + FTS5 全文搜索)、Tool Backends(7 种终端后端 + 5 种浏览器后端 + MCP 动态工具,共 70+ 内置工具)、Memory & Skills(MEMORY.md + USER.md + ~/.hermes/skills/)。

Agent Loop: 一次完整对话的生命周期

Hermes 的 Agent Loop 有两个入口:chat() 是简单接口,返回最终响应字符串;run_conversation() 是完整接口,返回包含消息历史、元数据、用量统计的字典。

API 模式有三种:chat_completions 用于 OpenAI 兼容端点(OpenRouter 等),codex_responses 用于 OpenAI Codex,anthropic_messages 用于原生 Anthropic API。三种模式在调用前后都收敛到统一的 OpenAI 消息格式。

每次对话的生命周期:1) 生成 task_id,2) 追加用户消息到历史,3) 构建系统 Prompt(含 SOUL.md、记忆、Skills、上下文文件),4) 检查是否需要压缩(超过 50% 上下文时),5) 调用模型,6) 解析响应–如果是 tool_call 就执行并循环,如果是文本就持久化并返回。

关键设计是中断支持–API 调用在后台线程运行,主线程监控中断事件。用户发新消息或按 Ctrl+C 时,API 响应直接丢弃,Agent 可以处理新输入或干净关闭。

跟 OpenClaw 对比一下:OpenClaw 的 Agent Loop 基于 Pi Agent Core 嵌入式运行时,工具定义和调度由 OpenClaw 层管理,新消息处理通过 7 种队列模式配置。Hermes 是纯 Python 单文件实现,工具注册和调度全在 AIAgent 内部完成,中断支持是内建的。简单说,OpenClaw 是分层架构,Hermes 是单体架构。

工具系统:70+ 内置工具

Hermes 有 70 多个内置工具,覆盖 Web 搜索、浏览器自动化、终端执行、文件编辑、记忆、任务委派、消息投递、Home Assistant 等类别。每个工具模块在导入时调用 registry.register() 注册自己–name、toolset、schema、handler、check_fn。discover_builtin_tools() 用 AST 扫描 tools/目录,找到顶层的 registry.register() 调用就导入,所以新工具文件自动被 pickup,不用维护列表。

每个工具可以有 check_fn–返回 True/False 表示是否可用。比如 web_search 的 check_fn 是检查 SERP_API_KEY 环境变量。构建 schema 列表时会运行所有 check_fn,不可用的工具直接从模型可见列表中移除。

Toolset 解析支持三种方式:显式的 enabled/disabled 列表、平台预设(hermes-cli、hermes-telegram 等)、动态 MCP toolsets。get_tool_definitions() 是主入口,解析后传给 registry.get_definitions() 做 check_fn 过滤。

这里要解释一下 Tool 和 Toolset 的区别。Tool 是单个工具，比如 exec、read、memory，每个都有自己的 name、description、parameters、execute()。Toolset 是一组 Tool 的集合，决定模型在某个平台或场景下能看到哪些工具。简单说，Toolset 是工具的“可见性过滤器”。

然后说一下 Toolset 和大模型的关系。模型能调用哪些工具,完全取决于 Toolset 解析后传给它的工具列表。没进列表的工具,模型根本看不到,也就不会调用。这就是为什么不同平台可以有不同的工具集–比如 hermes-cli 预设开放终端和文件工具,hermes-telegram 预设可能关掉某些本地工具。这不是模型自己判断的,而是框架在调用模型之前就决定好了。

调度时,model_call → handle_function_call() → 4 个 Agent 级工具(memory、todo、session_search、delegate_task)由 Agent Loop 直接处理,其他工具走 registry.dispatch() 查表执行。

另外提一句,terminal 工具支持 7 种执行后端(Local/Docker/SSH/Singularity/Modal/Daytona/Vercel Sandbox),可以把代码执行环境和聊天环境分离。

学习闭环:Agent 如何自我进化

Hermes 的学习闭环是它最核心的创新。四个环节,我分别展开讲。

第一,自动生成 Skill。Agent 完成一个复杂任务后–比如帮你部署了一个 K8s 服务,中间调了十几次工具、踩了几个坑、最终成功了–它会把整个过程提炼成一份 SKILL.md 文件,存到 ~/.hermes/skills/ 里。这个文件包含四个部分:When to Use(什么时候该用)、Procedure(具体步骤)、Pitfalls(容易踩的坑)、Verification(怎么验证成功了)。下次再遇到类似任务,Agent 直接加载这个 Skill,不用重新摸索。

第二,使用中改进。Skill 不是写完就固定了。Agent 下次用这个 Skill 的时候,如果发现步骤可以优化、或者踩了新的坑,它会直接更新 SKILL.md。比如上次写的步骤是"先 build 再 push",这次发现应该"先跑测试再 build",Skill 就自动更新了。越用越准。

第三,主动持久化。Agent 用 memory 工具往两个文件里写东西。MEMORY.md(2200 字符)是 Agent 自己的笔记–你的机器跑的什么系统、项目用什么框架、上次发现的工具注意事项。USER.md(1375 字符)是关于你的画像–你喜欢简洁回答还是详细解释、你的时区、你的技术水平。不是什么都记,只记值得记的。而且是 Agent 主动记,不用你说"记住这个"。

第四,跨会话检索。session_search 工具基于 SQLite + FTS5 全文搜索,可以搜所有过去的对话。比如你问"上周我们讨论过数据库迁移方案吗?",Agent 能搜到并给你摘要。Memory 是容量有限的精华(约 1300 tokens,MEMORY.md ~800 + USER.md ~500),Session Search 是无限容量的历史档案。

为什么这四步能形成进化循环?因为它们之间有反馈回路。Agent 做任务→解决了问题→生成 Skill→下次用 Skill 做类似任务→发现可以更好→改进 Skill→过程中学到的环境知识写入 Memory→再下次做任务时 Memory 提供上下文让 Agent 做得更好→忘了之前怎么处理的? Session Search 找回来→又可以生成或改进 Skill。

不是顺序转一圈,而是任何一步的输出都可能触发另一步。做得越多,Skill 越多越准,Memory 越丰富,可检索的历史越多,Agent 就越强。这就是"自进化"–不是有人来升级它,是它自己在用的过程中变强。

Skills 系统:agentskills.io 开放标准

Hermes 的 Skills 系统兼容 agentskills.io 开放标准。所有 Skills 存在 ~/.hermes/skills/,按类别分子目录(mlops/axolotl/、devops/deploy-k8s/)。每个 Skill 的 SKILL.md 包含 YAML frontmatter(name、description、version、platforms、metadata)和 Markdown 正文。

Progressive Disclosure 是核心设计:Level 0 只加载 skills_list()(名称 + 描述 + 类别,约 3k tokens),Level 1 在需要时加载完整 SKILL.md,Level 2 按需加载 references/下的具体文件。Agent 只在真正需要时才加载完整内容。

Skills 可以声明 platforms(macos/linux/windows)限制操作系统,也可以用 fallback_for_toolsets 做条件激活–比如 duckduckgo-search 只在 web toolset 不可用时显示,作为付费工具的免费备选。

Secure Setup on Load 允许 Skill 声明 required_environment_variables,缺失时 Hermes 只在本地 CLI 询问,消息平台不会在聊天里要密钥。External Skill Directories 让你可以指向 ~/.agents/skills/等外部目录,多个 AI 工具共享 Skills。

记忆系统:MEMORY.md + USER.md + Session Search

Hermes 的记忆系统设计得很精巧。两个文件:MEMORY.md 是 Agent 的个人笔记(环境事实、项目约定、工具使用注意事项,2200 字符约 800 tokens),USER.md 是用户画像(偏好、沟通风格、期望,1375 字符约 500 tokens)。都存于 ~/.hermes/memories/。

关键设计是冻结快照–会话开始时加载到系统 Prompt,整个会话期间不变。这样做的目的是保留 LLM 的 prefix cache,提升性能。Agent 用 memory 工具写入时,磁盘立即更新,但新内容要到下次会话才出现在 Prompt 里。

memory 工具有三个动作:add、replace、remove。replace 和 remove 用子串匹配–你不需要提供完整条目,只要给一个能唯一标识的子串就行。比如旧内容是"User prefers dark mode",你用 old_text=“dark mode” 就能匹配到。

容量管理很严格:MEMORY.md 超过 2200 字符就拒绝写入,Agent 必须先整理现有条目腾出空间。另外 Hermes 支持外部记忆插件,比如 Honcho 提供跨会话的用户建模能力。

跟 OpenClaw 的记忆系统对比:OpenClaw 有三层文件(MEMORY.md + 每日笔记 + Dreaming),没有硬性字符数限制但注入时截断,支持 embedding 语义搜索,有三种后端(SQLite/QMD/Honcho)。Hermes 更简洁–两个有严格容量的文件 + FTS5 全文搜索。OpenClaw 偏"大而全",Hermes 偏"小而精"。

网关与消息平台:20+ 渠道统一接入

Hermes 的网关跟 OpenClaw 类似,但实现细节不同。支持 20 多个平台:Telegram、Discord、Slack、WhatsApp、Signal、Matrix、Mattermost、Email、SMS、钉钉、飞书、企业微信、微信、BlueBubbles、QQ Bot、元宝、Home Assistant、Microsoft Teams、Google Chat、LINE 等。

消息流程:平台事件 → Adapter.on_message() → MessageEvent → GatewayRunner._handle_message() → 授权用户 → 解析 session key → 创建 AIAgent(带会话历史)→ AIAgent.run_conversation() → 通过适配器返回响应。

Session 存储用 SQLite + FTS5,所有 CLI 和消息会话都持久化,支持全文搜索。配对授权控制谁能跟 Agent 私聊。Hook 系统支持在消息处理、工具调用等关键节点插入自定义逻辑。跨会话镜像可以把一个会话的消息同步到另一个。

跟 OpenClaw 网关对比:OpenClaw 支持 25+ 渠道(内置+插件),有 Bindings 8 级路由和 7 种消息队列模式;Hermes 支持 20+ 平台,每个平台有独立的适配器,消息流程更直接–平台事件到 AIAgent 一条线,中间没有复杂的路由层。两者的共同点是都能从一个网关进程连接所有平台,都支持语音消息转录。

Cron 调度与研究能力

Hermes 的 Cron 系统和 OpenClaw 的思路不同。Scheduler 从 jobs.json 加载到期任务,为每个任务创建一个全新的 AIAgent–不带历史会话,注入 attached skills 作为上下文,执行任务 Prompt,然后把响应交付到目标平台。对比 OpenClaw:OpenClaw 支持在 main session 注入系统事件或在 isolated session 独立运行;Hermes 总是创建独立 Agent,适合无状态的定时提醒、日报生成等场景。

另一个 Hermes 独特的定位是研究就绪。具体怎么做的呢？分三步。

第一步，生成训练轨迹。batch_runner.py 支持批量轨迹生成——给 Agent 一批任务，让它大规模执行，记录完整的工具调用轨迹：模型收到什么提示、决定调用哪个工具、传了什么参数、工具返回了什么、模型最终怎么回复。这些轨迹就是训练数据。

第二步，RL 训练。environments/ 目录集成了 Atropos RL 训练环境。用第一步生成的轨迹做强化学习，训练模型在什么场景下应该调用什么工具、怎么传参数。相当于用 Agent 的实战经验来训练下一代工具调用模型。

第三步，让新模型生效。训练出来的新模型可以直接在 Hermes 里使用——因为 Hermes 支持 35+ 个 Provider，包括本地部署的模型。把新模型部署到本地或云端，在 Hermes 配置里切换 Provider，就能用上新模型了。然后又可以用新模型生成更多轨迹，继续迭代。这就是一个闭环。

Nous Research 本身就是 AI 研究机构（Hermes、Nomos、Psyche 模型的创造者），所以 Hermes 的设计从一开始就考虑了研究需求。

Hermes Agent 的定位

总结 Hermes Agent 的定位:它是一个自进化的 Agent 框架。Python 生态,内置完整学习闭环(自动生成和改进 Skills、主动持久化记忆、跨会话检索),7 种终端后端(含 Serverless 持久化),20+ 消息渠道统一接入,研究就绪(批量轨迹 + RL 训练)。

如果你的核心需求是"Agent 越用越强,而且我可能想用它做研究",Hermes 是更好的选择。如果你更看重多通道消息路由、ACP 桥接外部编码工具、移动节点这些能力,OpenClaw 更合适。两者数据兼容,hermes claw migrate 一键迁移。安装也很简单:一行 curl 命令,hermes setup 配置,hermes 就能聊。文档在 hermes-agent.nousresearch.com/docs,技能市场在 agentskills.io。

那两个框架在底层,到底共享了什么设计哲学?

第四章：共同的设计哲学 — 代码即 Agent

文件即配置:Agent 的 DNA

两个框架最核心的共同点–Agent 的一切都定义在文件里。

两者都有的核心文件:SOUL.md 定义性格,AGENTS.md 定义行为规范,USER.md 存用户画像,MEMORY.md 存长期记忆。这四个文件定义了 Agent 是谁、怎么做事、认识谁、记得什么。

但具体实现有差异。OpenClaw 还有 TOOLS.md(工具使用笔记)、IDENTITY.md(名称/形象)、BOOTSTRAP.md(首次运行向导)、HEARTBEAT.md(心跳检查清单),这些 Hermes 没有。Hermes 则支持 .hermes.md 作为项目上下文,还兼容 CLAUDE.md 和 .cursorrules,OpenClaw 没有。

另外两者的加载位置也不同。OpenClaw 的所有 bootstrap 文件都在 workspace 目录里。Hermes 的 SOUL.md 只从 ~/.hermes/ 加载,MEMORY.md 和 USER.md 在 ~/.hermes/memories/ 里,AGENTS.md 则支持子目录渐进发现–Agent 进入某个子目录工作时,会自动发现并加载该目录的 AGENTS.md。

但核心理念是一样的–你改一行 Markdown 文字,Agent 的行为就变了。文件就是 Agent 的全部。

为什么是 Markdown,不是 JSON/YAML?

你可能会问,为什么用 Markdown 而不是 JSON 或 YAML?

三个原因。第一,Markdown 对人和 LLM 都友好–你读得懂,模型也读得懂。第二,git 友好–Markdown 的 diff 比 JSON 好看得多,Code Review 很自然。第三,低门槛–非程序员也能编辑 Agent 的配置,产品经理可以直接改 SOUL.md。

本质上,这是"自然语言即配置"。你不需要学一套 DSL,用人话描述就行。

举个例子:你想让 Agent 在写代码时遵守团队规范,不需要写一个 JSON schema 来约束它,直接在 AGENTS.md 里用中文写"所有 API 接口必须返回 {data, error, meta} 格式"就行。模型读得懂,而且你改一行文字就能调整行为,不需要重新部署。

Workspace = Agent 的世界

Workspace 这个概念,两个框架的做法不一样。

OpenClaw 有一个明确的 workspace 目录，默认是 ~/.openclaw/workspace。SOUL.md、AGENTS.md、MEMORY.md 等 Agent 身份和记忆文件都在 workspace 里。而 ~/.openclaw/ 存放配置、凭证、会话等运行时数据，两者分离。多 Agent 时每个 Agent 有独立的 workspace，工具也在这里执行。

Hermes 的做法不同。Agent 的工作目录是你启动时所在的项目目录,AGENTS.md 从工作目录发现,更像"走到哪个项目目录就在哪干活"。

OpenClaw 的多 Agent 方案是在一个 Gateway 进程内托管多个 Agent,每个 Agent 有独立的 workspace、agentDir 和 session store,通过 bindings 路由决定消息分发给哪个 Agent。一个进程统一管理,路由灵活。

Skills:可复用、可共享的能力

Skills 系统是两个框架的杀手级功能。

一个 SKILL.md 文件,本质上就是程序性记忆–"如何做某件事"的结构化描述。你教 Agent 怎么用你们的部署脚本,写成 SKILL.md,它就永远会了。

更强大的是社区共享。OpenClaw 有 ClawHub,Hermes 兼容 agentskills.io 开放标准。别人写好的 Skill,你一行命令装上就能用。

从"每次教 Agent"变成了"教一次,永远会",而且社区教过的,你不用再教。

Skills 把团队规范变成 Agent 能遵守的规则

这里有一个很深刻的变化。以前团队的代码规范、架构原则、最佳实践,存在哪里?存在人的脑子里,靠 Code Review 口口相传。

现在你得把它们写成 SKILL.md、写成 anti-patterns 清单、写成 workflow 里的 Gate 条件。Agent 就自动遵守。

这需要很强的抽象能力–你得先想清楚"好代码的标准到底是什么",然后才能把它形式化。讽刺的是,这比自己写代码要难。但一旦写好,整个团队的 Agent 都会遵守同一套标准。

举个例子:以前 Code Review 时说"这个函数太长了",每个人对"太长"的标准不一样。现在你写成 Skill:“函数超过 50 行必须拆分,拆分后每个子函数要有单独的单测”。Agent 严格执行,不会因为赶工期就放水。

Agent 还是 Skill?什么时候用哪个

理解了 Agent 和 Skill 之后,一个非常实际的问题来了–我手上这个任务,应该交给 Agent 直接做,还是应该封装成 Skill?

先说结论:Skill 是"怎么做",Agent 是"做什么"。 如果一个任务的步骤是确定的、可重复的,封装成 Skill。如果一个任务需要理解上下文、做判断、走不同分支,交给 Agent。

具体来说,封装成 Skill 的信号有三个。第一,你发现自己在跟 Agent 重复说同样的话–“先跑 lint,再跑测试,再提交”–这就是 Skill。第二,步骤是固定的,不管上下文怎么变,流程不变。第三,别人也可能需要–Skill 是可共享的,Agent 的对话不是。

保留给 Agent 的信号也有三个。第一,任务是开放式的–“帮我重构这个模块”,怎么重构取决于具体代码。第二,需要多轮判断–“这个 API 该用 REST 还是 gRPC?”,要根据场景权衡。第三,上下文敏感–需要结合当前项目状态、最近的讨论、用户偏好来决定怎么做。

还有一个中间地带–Agent + Skill 组合。Agent 负责判断"现在该做什么",然后调用 Skill 来执行具体步骤。比如 Agent 判断"这个 PR 需要做性能测试",然后调用 perf-test Skill 来跑。判断是 Agent 的事,执行是 Skill 的事。

打个比方。Agent 像一个刚毕业的大学生–基础素养没问题,能理解需求、能写代码、能沟通,但缺少实战经验。Skill 就是在公司积累的具体技能–怎么做代码审查、怎么写部署脚本、怎么处理线上事故。Agent 加上越来越多的 Skill,就从应届生成长为高级工程师。

用写代码的类比来说:Agent 像项目,Skill 像模块。项目决定做什么、怎么组织,模块是可复用的具体实现。你不会把整个项目复制粘贴到另一个项目里,但你会把通用模块抽出来复用。

一个经验法则:如果你教了 Agent 三次同样的事,第四次就该写成 Skill。

对比:OpenClaw vs Hermes Agent

直接对比一下两个框架。

技术栈:OpenClaw 是 Node.js,npm 安装;Hermes 是 Python,uv/pip 安装。

核心定位:OpenClaw 偏重多通道消息路由和网关能力;Hermes 偏重自进化学习和研究基础设施。

OpenClaw 独有的:移动节点(手机摄像头/GPS)、可插拔 Context Engine、Dreaming 记忆整理、25+ 渠道接入。

Hermes 独有的:自动 Skill 生成和改进、Honcho 用户建模、7 种终端后端(含 Serverless)、RL 轨迹生成、Profiles 多 Agent 管理。

两者都支持 ACP 协议,但用法不同:OpenClaw 用 ACP 桥接 Codex/Claude Code/Cursor 等外部工具,统一管理它们的生命周期;Hermes 用 ACP 对接 VS Code/Zed/JetBrains 编辑器。

共同的:文件即配置、多 Agent 隔离、多平台消息、Skills 系统、Cron 自动化、长期记忆、Sub-agent。

选哪个?如果你已经有 Node.js 生态且需要 ACP 桥接,用 OpenClaw。如果你想要 Agent 自我进化且在 Python 生态里,用 Hermes。两者的数据是兼容的,迁移成本很低。

用 Agent 框架写代码是什么体验

很多人对"用 AI 写代码"的想象是–跟 AI 说一句话,代码就出来了。实际上远不是这样。

你真正需要的不是一个"能写代码的聊天机器人",而是一套工作流。通过 SKILL.md 把团队的代码规范、架构约定教给 Agent。在关键节点设置 Gate–人确认才放行。用结构化文件追踪进度。

核心模式:人做判断,Agent 执行。人定规则,Agent 守规则。这在 OpenClaw 和 Hermes 上都是一样的。

具体来说:你在 SKILL.md 里写好"提交代码前必须跑 lint + 测试",Agent 每次都会照做。你在 AGENTS.md 里写好"不允许直接修改 migration 文件",Agent 就不会碰。规则越明确,Agent 的输出质量越稳定。

代码自审 + Gate 机制 = 双保险

质量怎么保障?两个框架都支持类似的机制。

代码自审–Agent 每写完一段代码,在写入文件之前自己检查:符不符合项目风格?有没有命中反模式清单?有没有违反规范?通过才写入。

Gate 机制–每个关键阶段结束,人来确认。不确认就不往下走。

三道防线:Agent 自审是第一道,人 Review 是第二道,集成测试是第三道。这不是因为不信任 Agent,而是因为软件工程本来就需要多层检验。

第五章：Agent 时代，工程师的角色变化

软件工程正在分裂成两层

如果你仔细想,OpenClaw 和 Hermes 代表的不只是两个工具,而是一个根本性的变化–软件工程正在分裂成两层。

过去只有一层:人写代码,控制计算机。现在变成了两层:上层,人设计工作流、定义规则、制定约束,控制 Agent;下层,Agent 写代码,控制计算机。

工程师的战场正在从下层转移到上层。SKILL.md、SOUL.md、AGENTS.md–这些文件就是"上层编程"的代码。

这不是说下层不重要了。你仍然需要懂代码才能写好 Skill、才能判断 Agent 的输出对不对。但你花时间的重心在变–从"怎么写这段代码"变成"怎么设计规则让 Agent 稳定产出好代码"。

新的核心能力:设计约束系统

编程计算机,你写什么它执行什么,确定性的。编程 Agent 不一样–它是概率性的。同样的指令,它可能理解偏差、可能漂移、可能过度设计。

所以你需要 Gate 来设置检查点,需要自审机制防止低级错误,需要结构化追踪来保持可见性,需要回退规则来处理失败。

这些"约束系统"的设计难度,不亚于写代码本身。但这正是新时代工程师最核心的能力–你能不能把脑子里的质量标准,变成 Agent 能遵守的规则?

这就像写单元测试–测试本身不产生功能,但它保证功能是对的。约束系统不产生代码,但它保证 Agent 产出的代码是对的。会写约束的工程师,比会写代码的工程师更稀缺。

从"我来写"到"我来验"

最后一个转变:从"我来写"到"我来验"。

这个方案好不好?这段代码能不能上线?这个 trade-off 值不值得?这些判断,Agent 做不了。

有意思的是–做好这些判断需要的经验、直觉、对业务的理解,恰恰来自你过去写代码的积累。不是说写代码不重要了,而是写代码从"目的"变成了"手段"。你的编码经验,变成了你判断 Agent 代码的能力。

建议:现在就开始用 Agent 框架,边用边积累"验"的能力。判断力只能在实践中练出来。

开源、自托管、以代码为核心

回到今天的主题。OpenClaw 和 Hermes Agent 代表了一种新范式–Agent 不是某个厂商的黑箱 SaaS,而是你 git 仓库里的代码。

SOUL.md 定义它是谁,AGENTS.md 定义它怎么干活,MEMORY.md 让它记住经验,Skills 让它越用越强。全部是文件,全部在你的 git 仓库里。开源、自托管、以文件为核心。

你的判断力,加上 Agent 的执行力,等于前所未有的生产力。新的工作范式已经来临。

---

附录：快速上手

OpenClaw

npm install -g openclaw
openclaw setup
openclaw gateway start

• 文档：https://docs.openclaw.ai
• GitHub：https://github.com/openclaw/openclaw
• 技能市场：https://clawhub.ai

Hermes Agent

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
source ~/.bashrc
hermes setup
hermes

• 文档：https://hermes-agent.nousresearch.com/docs/
• GitHub：https://github.com/NousResearch/hermes-agent
• 技能市场：https://agentskills.io

---

你的判断力，加上 Agent 的执行力，等于前所未有的生产力。新的工作范式已经来临。