OpenClaw on 向叔记事簿

Hermes 和 OpenClaw 的 token 账单差在哪

Thu, 16 Apr 2026 01:13:53 +0800

写完上一篇 Hermes 和 OpenClaw 的对比以后，我又去翻了一遍两边文档。越看越觉得，如果只问功能像不像，很容易看偏。

更直接的问题是：它们把 token 花在了哪里。

OpenClaw 更像一个长期在线的助理工作台，默认就要带身份、工作区、消息面和记忆边界。Hermes 更像一个本地 agent 内核，默认先把上下文压住，需要时再发现、再注入、再展开——一个把成本前置，一个把成本后置。最后账单长得当然不一样。

OpenClaw 的固定盘更厚

OpenClaw 的出发点，不是“启动一个轻量 CLI agent 先干活”，而是“让一个助理在工作区里长期存在”。

它的 workspace 文档里，AGENTS.md、SOUL.md、USER.md 这类文件会围绕 session 工作。IDENTITY.md、TOOLS.md、HEARTBEAT.md、BOOT.md、MEMORY.md 也都在同一套助理环境里。文档还专门提醒 HEARTBEAT.md 要短，避免 token burn。

这句话其实很说明问题。OpenClaw 不是不知道 token 贵，而是它的产品目标决定了很多上下文必须提前在场。

你要一个 agent 同时面对 Telegram、Discord、Slack、WhatsApp，还要知道自己是谁、该怎么说话、该怎么路由任务、哪些记忆能用、哪些工具能开，这些规则就不能每次临时拼。

所以 OpenClaw 的 token 消耗更像一张“长期在线助理”的账：

固定身份要带；
工作区规则要带；
多消息面边界要带；
记忆和路由规则要带；
一部分工具和技能索引也要能被看见。

它不是不会省。OpenClaw 的 token 文档也写了，skills 默认进系统提示词的是 metadata，具体内容按需读。问题在于，它的底座本来就更像一个完整助理环境。这个底座好用，但不会特别轻。

Hermes 的默认姿势更克制

Hermes 的文档里反复出现两个思路：按需加载，保住 prompt cache。

它处理 context files 的方式很典型。启动时只拿当前目录命中的项目上下文，像 AGENTS.md、CLAUDE.md、.cursorrules 这类文件是 first match wins，不是一口气全塞进系统提示词。子目录里的上下文，也不是一开始全文加载，而是等 agent 真的走到相关路径、读到相关文件，再逐步发现。

这和 OpenClaw 的气质完全不一样。

Hermes 更像是在说：系统提示词最好别乱长。能后置的就后置，能按需出现的就按需出现。skill 也是同一套 progressive disclosure 逻辑，先给模型一个轻量索引，需要的时候再打开具体说明。

它的记忆设计也更像组合件。SOUL.md、USER.md、内置 memory 有固定边界，session search、memory provider、Honcho 这些再按需要叠上去。这个设计不保证所有任务都省 token，但它让默认路径更不容易膨胀。

所以我会把 Hermes 归成另一种账：

开局固定上下文更克制；
项目上下文按路径发现；
skill 按需展开；
工具输出尽量只回关键结果；
真复杂时再把 memory、sub-agent、长工具结果叠上去。

它不是“天然便宜”，而是更容易从轻状态开始。

谁更省，要看你在养什么

很多工具对比最后都会落成一句“谁更省 token”。这个说法太粗。

如果你要的是长期在线、跨平台、有身份感、能维持多消息面关系的助理，OpenClaw 把上下文前置是合理代价。你不能既要它像一个一直在场的人，又要求每轮都像一次性 CLI 小工具那么轻。

如果你主要在本地仓库里做代码、技能、上下文发现和工具执行，Hermes 的后置加载会更顺手。它把“现在不用的东西先别进上下文”当成默认设计，token 账就更容易控。

这不是谁更先进，而是谁把成本放在哪。

取舍	OpenClaw	Hermes
默认形态	长期在线助理工作台	本地 agent 内核
成本位置	身份、工作区、消息面先在场	上下文和能力按需展开
优势	存在感稳定，多平台边界清楚	起步轻，prompt cache 更容易保住
风险	固定盘容易变厚	复杂任务展开后一样会烧 token

如果只看默认架构，我会倾向于说 Hermes 更容易把 token 压住。但如果任务目标是“养一个在线助理”，那 OpenClaw 多花的 token 不一定是浪费，可能就是它要交付的产品体验。

真要算账，别靠体感

还有一点比架构名字更重要：实际账单要看工具给出的上下文和用量。

OpenClaw 有 /context detail、/usage tokens 这类命令，适合看每次 session 到底带了什么。Hermes 也可以结合 context 注入、skills 展开、Honcho 或 provider 账单去看实际消耗。

光看文档只能判断倾向，不能替你算最终成本。真正决定账单的，是你写了多长的 SOUL.md，塞了多少 memory，开了多少 skill，工具输出有没有收住，模型本身贵不贵。

我现在会这样看：

如果每轮都要带身份、人格、消息面和工作区规则，那是固定开销；
如果每次任务都要读一大段工具输出，那是工具噪音；
如果 skill 和 memory 全开，那是能力扩张；
如果子代理各自复制大量上下文，那是并行成本；
如果 prompt 前缀稳定，缓存命中才有意义。

所以比较 Hermes 和 OpenClaw，不该只问“谁省”。应该问：我的任务是不是需要一个长期在线助理，还是只需要一个能在本地仓库里按需展开的 agent。

这个问题答清楚，token 账就清楚了一半。

参考资料

写作附记

原始提示词

提示词：Hermes 和 OpenClaw 再写一篇文章，关于两者 token 消耗的情况，架构不同，消耗必然不一样

Hermes 不能按 OpenClaw 平替来估

Wed, 15 Apr 2026 23:52:20 +0800

这两天我把 Hermes 和 OpenClaw 的文档来回翻了一圈，越看越觉得，很多人把这两个项目放在一起比，其实一开始就比偏了。

它们当然都在做"个人 AI 助手"。都能接消息、调模型、跑工具、留住一点上下文。Hermes 甚至还专门做了 hermes claw migrate，摆明了是知道自己会接到一批 OpenClaw 用户。

但是说白了，Hermes 不是换皮版 OpenClaw，OpenClaw 也不是多了几个消息入口的 agent framework。一个是从 Gateway 往外长，一个是从 AIAgent 往外长。这个差别不先看明白，后面谈架构、设计理念和生态，基本都会越聊越乱。

它们一开始就没打算长成一个东西

OpenClaw 官方文档把 Gateway 放在非常前的位置。它的定义很直接：一个长期运行的 Gateway 持有所有消息面，控制面客户端、Web UI、Node 设备都通过 WebSocket 连到这个 Gateway 上，而且一个 host 上只有一个 Gateway 去管核心消息连接，像 WhatsApp 这种会话也明确由它独占。

这意味着什么？意味着 OpenClaw 的世界观不是“先有一个 agent，再给它接几个入口”，而是“先有一个常驻的通信和控制平面，再把 agent runtime、session、skills、delegate、sub-agent 都组织到这个平面里”。

Hermes 就不是这个味道。它的架构图一上来写得很明白，CLI、Gateway、ACP、Batch Runner、API Server、Python Library 这些入口，最后都汇到同一个 AIAgent 核心。Session storage 是 SQLite + FTS5，工具后端、provider resolution、prompt builder 都是围着这个 core 组织的。

所以从骨架上看，OpenClaw 更像一个“常驻型个人助理系统”；Hermes 更像一个“agent runtime 平台”，消息入口只是它的一个延伸面。

一个把 Gateway 当主角，一个把 Agent 当主角

这个架构差异，最后会直接变成使用体验差异。

OpenClaw 的强项，是把“我怎么在很多渠道上拥有一个长期在线、带身份、带边界、可路由的助手”这件事做得非常重。它有默认的 DM pairing、安全策略、按 channel/account/peer 做 routing、多 agent 绑定、delegate 模式，甚至连“代表谁发、用哪个账号收、在哪个群里出现”这种组织级问题都专门写成文档了。

换句话说，OpenClaw 想先解决的是存在性问题。这个 agent 先得像个真的人，或者像个真的组织助理，活在 Telegram、Discord、Slack、WhatsApp、Signal、WebChat 这些面上，然后你再去谈它会不会写代码、会不会做任务分发。

Hermes 的重心更偏“能力积累”。它当然也有 Gateway，也能接 Telegram、Discord、Slack、WhatsApp 这些平台，但官方叙事里最靠前的词不是路由和账号，而是 persistent memory、skills、MCP、sub-agents、toolsets，还有 batch processing、trajectory export、RL training。

这就很关键了。Hermes 要解决的核心问题不是“怎么把一个 AI 接到尽可能多的消息面上”，而是“怎么让这个 agent 逐步长出自己的技能、记忆和可复用能力，甚至还能顺手拿去做训练数据和实验”。

所以我更愿意这么概括：

OpenClaw 是 communication-first 的 personal assistant system。

Hermes 是 agent-core-first 的 self-hosted agent platform。

记忆、技能和扩展方式，也不是一个味道

很多人会说，这俩不都支持 skill、memory、plugin 吗。没错，都支持。但是落点不一样。

OpenClaw 的 agent runtime 里，workspace 是很重的概念。AGENTS.md、SOUL.md、TOOLS.md、BOOTSTRAP.md、IDENTITY.md、USER.md 这些文件会在新 session 的第一轮直接注入上下文。技能加载也有一整套优先级：workspace 里的、项目里的、个人目录里的、~/.openclaw/skills 里的、bundled 的，都能往里叠。它本质上是在搭一个“人格 + 规则 + 工作区 + 通道”统一的长期助手环境。

Hermes 的技能系统明显更偏“程序化记忆”。官方文档直接说，skills 是 on-demand knowledge documents，走 progressive disclosure，兼容 agentskills.io 的开放标准，统一放在 ~/.hermes/skills/ 下面，而且 agent 自己就能修改和删除 skill。这个味道就不是“给助手配几份说明书”了，而是“把做过的事沉淀成可以再次加载的能力块”。

记忆也一样。Hermes 内置的是很克制的 MEMORY.md 和 USER.md，再配一个 SQLite + FTS5 的 session search，另外再往外挂 8 类 memory provider。这个设计挺有意思，它没有一上来把“长期人格环境”写得特别厚，而是把短记忆、检索式回忆、外挂式长期记忆拆开了。

OpenClaw 不是没有记忆，也不是没有 sub-agent、多 agent、delegate 这些进阶能力。相反，它这些都不少。但从文档结构和默认心智模型看，它更像在经营一个持续在线的 assistant workspace；Hermes 更像在经营一个会持续进化的 agent capability graph。

生态为什么会越走越开

生态这块，表面看都是“开源 + 可扩展”，实际上也分叉得很明显。

OpenClaw 的生态更宽，更偏外部接入层。官方插件可以扩 channels、model providers、tools、skills、speech、web fetch、web search、memory，社区插件和 ClawHub 也在围着“接更多平台、接更多账号、接更多工作流”长。它甚至明确兼容 .codex-plugin、.claude-plugin、.cursor-plugin 这类 bundle 形态。这个动作很聪明，说白了就是先把别家生态的壳也吃进来，先把入口做大。

再看 OpenClaw 的文档，你会发现它对 sub-agent、delegate、组织代理、thread binding、DM pairing、group mention 这些东西写得非常细。说明它的生态目标，不只是单机玩家折腾，而是希望真的变成一个长期运行的 agent operating system。

Hermes 的生态则更像“内核能力外接”。它有 Python plugin system，有 memory provider plugin，有 context engine plugin，有 MCP server 接入，也有 Skills Hub 和 agentskills.io 这种开放 skill 标准。再加上 batch runner、trajectory export、Atropos 这些训练相关接口，Hermes 的生态天然会吸引两类人。

一类是把它当个人 agent 用的人。

另一类是把它当研究、训练、实验、workflow substrate 用的人。

这两类用户的需求差异很大，但 Hermes 的架构刚好都能兜住。所以你会感觉 Hermes 的生态虽然未必像 OpenClaw 那样先在“渠道数量”和“消息存在感”上铺开，但我会更倾向于觉得，它在 agent substrate 这块的后劲会更大。

还有一个挺有意思的细节。Hermes 官方 README 里不光有 hermes claw migrate，还挂了一个社区项目 HermesClaw，用来在同一个 WeChat 账号上同时跑 Hermes Agent 和 OpenClaw。这个信号已经很明显了：Hermes 不是假装自己和 OpenClaw 没关系，它是在承认这条用户迁移链路存在，然后顺手把这条链路产品化了。

我最后的判断

如果你要的是一个“真的活在消息面上的个人助理系统”，要的是账号、渠道、路由、delegate、组织边界、长期在线、强控制面，那 OpenClaw 这条路更完整，也更像一个成熟的通信底座。

如果你要的是一个“会越用越像自己工作台的 agent core”，看重的是 skill 沉淀、memory 组合、MCP、插件、sub-agent、训练数据和后续可塑性，那 Hermes 更顺手。

所以别再简单问“Hermes 能不能替代 OpenClaw”了。这个问题问得有点糙。

更准确的问法应该是：

你到底想要一个长在消息网络里的 AI 助理，还是一个长在本地工作流和 agent runtime 里的 AI 平台？

想清楚这个，选择就没那么拧巴了。

参考资料

写作附记

原始提示词

提示词：Hermes 和 OpenClaw 的不同，架构上的不同，设计理念上面的不同，生态的不同