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 替代品,可能一开始就看偏了
- Hermes Agent Features Overview
- Hermes Agent Context Files
- Hermes Agent Personality & SOUL.md
- Hermes Agent Skills
- Hermes Agent Built-in Tools Reference
- Hermes Agent Honcho Memory
- OpenClaw Agent Workspace
- OpenClaw Token Use and Costs
- OpenClaw Memory
- OpenClaw Multi-Agent Routing
- OpenClaw Context Reference
写作附记
原始提示词
提示词:Hermes 和 OpenClaw 再写一篇文章,关于两者 token 消耗的情况,架构不同,消耗必然不一样
写作思路摘要
- 保留“架构不同,token 消耗必然不同”的原始判断。
- 把旧稿里过密的文档摘录改成账单结构比较:固定盘、按需展开、工具输出和缓存。
- 不写成“谁更省”的绝对结论,而是落到使用场景:长期在线助理和本地 agent 内核不是同一种成本模型。
评论区将在滚动到此处后加载。