在云栈社区，这周我深度研究了一个宝藏开源项目 OpenClacky，结果发现一个相当荒诞的事实。现在市面上知名的开源 Agent 框架不少——OpenClaw、Hermes Agent、Claude Code等等，但如果真的用同一个任务在它们上跑一下，即使模型完全一样，消耗的 token 数量也可能天差地别！我只拿一个很简单的任务做了测试：Hermes 与 OpenClacky 同场较量，一个花了 3 块，一个只花了不到 5 毛钱。
任务本身并不复杂：“去豆瓣看看最近有什么热门的电视剧、电影，评分是多少，然后帮我做成一个 HTML 网页。”两个框架最终完成度相似，模型一样，结果也类似。那么这堆多出来的 6 倍开销到底跑哪去了？为了便于对比，我特意为每个框架单独申请了对应名称的 API key。从账单上看，OpenClacky 在本任务中缓存读取花了 2 毛，不走缓存的生成部分只花了 1 毛 8，总共 3 毛 8。而 Hermes Agent 那边，缓存读取 2 毛 9，缓存写入 4 毛 4，不走缓存的生成足足花了 2 块 3，合在一起轻松超过 3 块。
所以为什么会有这么大的差距？你的 Agent 框架是不是也在这样疯狂烧钱、白白浪费 token？仔细琢磨一番之后，我发现这背后其实藏着好几道门道。OpenClacky 作为一个开源的明星项目，GitHub 的 Star 曲线已经开始直线起跳。
README 里放了一张对比表，把几个热门框架并列起来：如果把 Claude Code 的 token 成本当成基准 1.0 倍，那么“龙虾”OpenClaw 大约要多花 1.5 倍，“爱马仕”Hermes 要多花 3 倍，而 OpenClacky 只需要 0.8 倍。
那么，token 到底花到哪里去了？
第一笔是工具税。 举个最简单的例子：Hermes Agent 内置了 52 个工具。每次你和它对话，每次它向模型发送一个请求，这 52 个工具的完整 schema 定义（包括名称、每个参数的类型和说明）都会被当成上下文的一部分打包送进去。很多时候你可能只是随口问一句，但模型实际上读到的信息却是：“这里有 52 个工具可用，请看完之后决定调用哪一个。” OpenClacky 的默认设计只塞了 16 个工具，多余的能力交给 Skill，真正按需加载。这样一来，每次请求的提示词一下精简了不少。做个小对比就知道差距有多大：
你可以使用浏览器吗？
Hermes 为此消耗了 13.7k token，而 OpenClacky 只花了 5243 token。工具从 52 个降到 16 个，节省效果立刻显现。
第二笔是 Cache。 最近 deepseek v4 让“prompt cache”这个词变得非常具象，后台一眼望去全是浅蓝色，缓存命中率极高。原理很简单：如果你连续两次请求的文本前缀相同，第二次只需为新增部分付费。一旦命中，费用立刻省下 90%。
可如果框架底层对这块设计得比较糟糕——比如在 System Prompt 里塞入一堆动态变量（当前时间、文件列表、已安装 Skill 列表等等），这些东西一变，整个前缀就变了，之前的 Cache 全部失效。或者 Skill 一重载，上下文结构变了；模型一切换，session 直接重启。Anthropic 在 Claude Code 从 2.1.36 版本开始，就曾在 system prompt 开头恶意塞入随机码，让非自家模型用户的缓存命中率直接归零，堪称经典案例。
我仔细对比了 OpenClacky 与 Hermes Agent 在提示词组织上的差异。OpenClacky 严格控制哪些部分可变，可变的部分绝对不能干扰到之前的缓存。
正因如此，自然就出现了开头那一幕：同一个任务，把 prompt cache 做好的框架，可以大幅省钱。
第三笔是历史上下文负担。 用 Hermes Agent、OpenClaw 这类框架时，不少朋友习惯在一个 session 里一直聊，甚至中午出去吃个饭回来还在同一个 session。这就会引出问题：比如 Claude 在定价上区分了 5 分钟缓存命中和 1 小时缓存命中，一顿饭的工夫，之前的缓存可能已经跨了时间段，重新定价后更贵了。更普遍的情况是，我们往往会在这个 session 里开始全新问题（尤其是手机端持续远程控制时），但 Agent 仍然带着漫长历史对话的上下文去请求模型，成本直线上升。新任务本身未必多复杂，历史上下文带来的 token 消耗反而占了大头。OpenClacky 的设计会每隔一段时间自动压缩上下文，让新任务不再背上历史的包袱。
尽管看着像是产品设计理念的差异，但在工程层面同样讲究。OpenClacky 在压缩时不切换 session，也不动 system prompt，因此压缩过程中还能继续复用之前的缓存前缀。Hermes Agent 压缩时则会轮换 session_id 并重建 system，等于是软重启了一把，cache 全数失效。
最后一笔是多 Agent。 多 Agent 架构本身就是个烧 Token 的大户，Hermes Agent 算是这条路线上的激进代表。它的 delegate_task 是一个内置工具，模型可以随时随地派发子任务。每多开一个子 Agent，就是一套完整的工具 schema、一份完整的系统提示词、一次完整的上下文初始化。OpenClacky 走的是单一 Agent 路线，但提供了一个 fork_subagent 机制。子 Agent 会继承父 Agent 的历史会话，完成后只返回一段摘要给父 Agent。在 OpenClacky 里，模型不能自由编排子任务，多 Agent 只是 skill 或记忆的实现细节，用户始终感知到的是一条连贯的对话。
还有很多琐碎的工程细节堆叠在一起，最终呈现的结果就是：同一个模型，不同框架之间的 token 消耗差异极为夸张。正如开头那个任务，Hermes 花了 15 万 token，OpenClacky 只花了 4 万 token，直接拉开近 4 倍的差距。
写在最后
省 token 这件事，往小了看像是“抠门”，往大了看其实更像是架构层面的智能。“压缩即智能”——智能的本质就是用更少的信息去描述更复杂的世界。如果某个 Agent 用 50 次请求就能做完别人 200 次才能搞定的事，那这个 Agent 是不是天生就更聪明？
如今比模型，大家都差不多；比工具，同质化也越来越重；比编排，套路也就那几种。于是比花钱速度，反而成了一个很好衡量 Agent 框架工程水平的维度。各个厂商的 coding plan 也几乎全面转向 token plan。像智谱 50 块的订阅，5 小时内 3000 万 token，没几下就见底。在这个时间节点，重视 token 效率、重视 Agent 框架的工程设计，或许才是更务实的选择。OpenClacky 无疑开了一个很好的头。
参考地址：https://github.com/clacky-ai/openclacky
发表于 昨天 21:27
|
查看: 5|
回复: 0
