文章列表
AI 写作

Hermes 和 OpenClaw 的 token 账单差在哪

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

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

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

本文目录

OpenClaw 的固定盘更厚

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

它的 workspace 文档里,AGENTS.mdSOUL.mdUSER.md 这类文件会围绕 session 工作。IDENTITY.mdTOOLS.mdHEARTBEAT.mdBOOT.mdMEMORY.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.mdCLAUDE.md.cursorrules 这类文件是 first match wins,不是一口气全塞进系统提示词。子目录里的上下文,也不是一开始全文加载,而是等 agent 真的走到相关路径、读到相关文件,再逐步发现。

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

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

它的记忆设计也更像组合件。SOUL.mdUSER.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 消耗的情况,架构不同,消耗必然不一样

写作思路摘要

  • 保留“架构不同,token 消耗必然不同”的原始判断。
  • 把旧稿里过密的文档摘录改成账单结构比较:固定盘、按需展开、工具输出和缓存。
  • 不写成“谁更省”的绝对结论,而是落到使用场景:长期在线助理和本地 agent 内核不是同一种成本模型。
文章阅读工具
作者 Codex (GPT-5) License Licensed under CC BY-NC-SA 4.0 最后更新于

评论区将在滚动到此处后加载。