架构一换，Hermes 和 OpenClaw 的 token 就不是一个吃法

OpenClaw 为什么默认就更重

OpenClaw 的设计逻辑，本来就不是“来一个轻量 agent，先聊两句再说”，而是“先把一个长期存在的 agent 工作台搭起来”。这一点在官方 workspace 文档里写得很直白。

AGENTS.md、SOUL.md、USER.md 都是每个 session 都会加载。IDENTITY.md、TOOLS.md、HEARTBEAT.md、BOOT.md、MEMORY.md 这些文件，也都围着同一个 workspace 在转。文档甚至专门提醒，HEARTBEAT.md 要保持很短，避免 token burn。这种提醒本身就说明，OpenClaw 很清楚自己的默认上下文是偏厚的。

不过有一点也得说清楚，OpenClaw 不是所有东西都傻乎乎全文常驻。它官方的 token 文档明确写了，skills 进系统提示词时默认只是 metadata，具体说明要按需 read。所以它的问题不是“不会省”，而是“默认要带着走的底座本来就更大”。

这事其实不难理解。OpenClaw 要解决的是“长期在线”和“多消息面存在感”。

你让一个 agent 同时活在 Telegram、Discord、Slack、WhatsApp 这些地方，还要带身份、带路由、带边界、带 delegate，很多规则就不能是临时拼上去的。它得先知道自己是谁，怎么说话，面对谁，当前工作区的约束是什么，技能从哪里找，哪些记忆该带，哪些记忆不该带。

所以 OpenClaw 的 token 消耗，更像固定开销比较大。

你每次发消息，不只是跟一个模型说一句话，而是在调起一整套已经成型的“助理环境”。这套环境好用，代价就是基础 prompt 更厚，很多上下文即使这一轮没直接用上，也会先放在那里。

Hermes 为什么看起来更克制

Hermes 这边，文档里最有意思的地方，是它一直在强调两件事：按需加载，和 prompt cache preservation。

先看 context files。Hermes 在 session 启动时只加载当前工作目录命中的那一类项目上下文，像 AGENTS.md、CLAUDE.md、.cursorrules 这些是 first match wins，不会一口气全塞进去。更关键的是，子目录里的 AGENTS.md 不是开局全读，而是等你真的走到那个目录、读到那个文件、跑到那条路径时，才逐步发现、逐步注入。

官方文档把这个设计的好处写得很明确：

no system prompt bloat
prompt cache preservation

这个味道和 OpenClaw 很不一样。Hermes 很像在说，系统提示词最好别乱长，能后置的上下文就后置，能只在相关时刻出现的，就别在第一轮先塞满。

skills 也是同一个思路。Hermes 的 skills 文档明确写了 progressive disclosure，目标就是 minimize token usage。换句话说，skill 不是默认全文常驻，而是让模型先看到一个轻量索引，真需要的时候再展开具体内容。

再加上它的记忆体系也偏组合式。官方文档把内置记忆限制得很死，MEMORY.md 大约 800 tokens，USER.md 大约 500 tokens，合起来固定盘差不多 1300 tokens。SOUL.md 是固定身份，USER.md 和记忆会进系统提示词，但 session search、memory provider、Honcho 这些更像外挂层。这个结构不会天然让 prompt 变短，但它给了一个更容易控成本的默认姿势。

所以从架构倾向上看，我会更愿意把 Hermes 归类成“默认克制，逐步变重”。

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

很多对比文章喜欢把 token 消耗写成单一结论，这个我觉得不太对。

OpenClaw 更重，不代表它设计差。相反，它是故意把很多东西前置了。你要一个长期在线、跨平台、带人格、带工作区、带路由的助理，那这些上下文迟早都要付钱。它只是选择在默认路径上先把这些东西带齐。

Hermes 更克制，也不代表它没有大开销。你一旦把长 SOUL.md、项目 AGENTS.md、多 skill、MCP、memory provider、sub-agent、长工具输出一起叠上去，token 一样能滚得很快。特别是如果工具结果本身就很长，或者你让它在复杂代码库里来回搜索，那也不是靠架构名字就能省下来的。

所以更准确的说法应该是：

OpenClaw 把成本前置到“助理环境常驻”上。

Hermes 把成本后置到“能力按需展开”上。

这两种路子没有绝对高下，但是账单结构完全不一样。

真正拉开差距的，不只是 system prompt

还有几个细节，挺容易被忽略。

第一，Hermes 在 context files 这块明确为了稳定前缀去做设计。子目录 hint 是追加到相关工具结果里，而不是把所有项目上下文不断回灌到 system prompt 里。这个做法不只是在省 token，本质上也是在给 provider 的 prompt cache 留空间。

第二，Hermes 的 execute_code 这种工具，设计上就只把脚本最终 print() 出来的结果回给模型，中间那堆 RPC 工具调用结果不会全部进上下文。复杂流程里，这种结构能少掉一大截无意义的工具噪音。

第三，OpenClaw 的 workspace 哲学决定了它更像“把家当都带着”。哪怕很多文件本身不长，只要种类多、人格层多、规则层多、技能和记忆层次多，基础上下文就会一点点厚起来。这个厚度不是 bug，是它的产品取舍。

第四，两边对 sub-agent 的处理，也会影响总账。Hermes 的很多设计都在强调局部上下文和局部执行，OpenClaw 则更强调多 agent 身份、route、delegate 的组织能力。一个更像在切上下文，一个更像在组织存在关系。最后打到 token 账单上，形状当然不一样。

真要算，别靠嘴

如果你真准备长期用，别听谁一句“这个更省”就完事，直接看工具给出来的数据。

OpenClaw 官方有 /context detail 和 /usage tokens 这类命令，文档也会提醒你哪些文件会在每次 session 启动时注入。这个很适合看基础盘到底有多厚。

Hermes 这边，官方在 Honcho 和相关特性里也给了 token budget、skills progressive disclosure、context files 注入方式这些线索。你可以结合 hermes insights、session 存储和实际 provider 账单一起看。

说白了，架构只能决定“怎么花”，不能替你决定“花多少”。真正决定账单的，还是你写了多长的 SOUL.md，塞了多少记忆，开了多少 skill，工具输出有没有收住，模型本身贵不贵。

我最后还是站这一边

如果只看默认架构，不看极端配置，我还是倾向于认为 Hermes 更容易把 token 消耗压在一个相对克制的范围里。

不是因为它更强，而是因为它从 prompt 设计开始，就一直在躲“无意义的常驻上下文膨胀”这件事。OpenClaw 则相反，它宁愿多带一点，也要保证那个长期在线助理的身份、工作台和消息面边界别散掉。

所以如果你特别在意 token 成本，而且工作流主要发生在本地、CLI、代码仓库、技能沉淀这些场景里，Hermes 这套思路一般会更顺手。

如果你要的是一个真的活在各种消息面上的长期助理，那 OpenClaw 多花一点 token，我觉得反而是正常代价。你总不能既要它像个人一样长期在线，又要求它每轮都像一次性小工具那么轻。

哎，这事最后还是回到老问题。

你到底是在养一个在线助理，还是在养一个本地 agent 内核。想清楚这个，token 账就没那么难理解了。

参考资料

写作附记

原始提示词

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

写作思路摘要

延续上一篇的判断，但把主线收窄到 token 消耗，不再重复总体架构对比。
重点比较两边的默认上下文装配方式，而不是空谈“谁更省”。
Hermes 侧重点放在 progressive disclosure、按需发现和 prompt cache preservation。
OpenClaw 侧重点放在 workspace 常驻文件、长期在线助理环境和固定开销。
结尾保留用户给出的核心判断，但补了一层现实提醒：真要看账单，还得结合官方 usage/context 工具和实际 provider 计费。