你的 AI Agent 在替云厂商打工？73% 的 Token 消耗其实与你无关

上下文都烧在哪了#

Agent 的上下文消耗，大头集中在三个地方：MCP 服务、Skill 指令、Tool 定义。其中最吃 Token 的永远是 Tool schema。

所谓 Tool schema，就是以 JSON Schema 格式描述每个工具的调用接口——名称、参数列表、类型约束、详细描述、返回值。这些信息会被直接嵌入 prompt，让模型判断”何时调用哪个工具、如何正确填充参数”。工具越多、描述越详细，token 就越夸张。而且即使只保留几个常用工具，schema 本身的 verbose 程度也十分可观——JSON Schema 的格式天然冗余，跟谁写的关系不大。

所以社区当前的共识是放弃”一股脑全塞”，转向按需动态加载。用到了再加载 schema，用完释放。

两方激辩#

Hermes 团队的态度很明确。他们的设计目标就是开箱即用，不想让用户花几周时间配 Agent，那就预装更多功能。不想要的可以关掉——hermes skills config 和 hermes tools 就是干这个的。

但社区一些用户和开发者并不买账。

有开发者表达担忧：最麻烦的不是总数变大，是你只看到 token 烧了多少，却看不清到底哪段链路最费。

LobeHub 开发负责人自述踩坑经历——早期也给 Agent 塞了一堆工具和技能，结果用户大量抱怨 Token 占用太多。最后不得不把老的 Chat 模式搬回来，重新迭代技能配比。

他们的结论是：好的平衡不是”预装一切”，而是技能自发现、按需启用。即使内置精选做得再好，对前端工程师和产品经理来说仍然不能一刀切—— 他们需要的不是「哪 10 个技能最好」，而是「根据我是谁、我做什么」来个性化配置 。

当然也有站在中间的人。有人打了个比方：macOS 预装了 Pages 和 Numbers，我从来不用，但有人需要——你用不到不代表别人用不到。

两派都有道理。本质上仍是不同用户需求的角度罢了。不管怎么争，有一点无法回避：为什么是现在爆发？

房间里的大象#

过去一年，Hermes 和 OpenClaw 爆发式增长。很多人以为是产品做得好。但有一个被忽略的前提——云服务商的 Coding Plan。极致的低成本和免费额度，直接卸掉了复杂智能体的研发成本枷锁。用户每月有几百万免费 Token，浪费几千个根本无感。

这场繁荣的本质，是 云服务商的普惠算力让利和开源社区高效迭代 的一次双向奔赴。

但 Coding Plan 正在全面退场。云厂商转向按量计费的 Token Plan。潮水退去后，每一笔 Token 消耗都变成了账单上的数字。

不是 Hermes 变差了。是之前有人替你买单。

这大概能解释 Hermes 团队在 v0.15.0 “Velocity” 版本里为什么下了狠手——76% 的代码重构，run_agent.py 从 16,083 行压缩到 3,821 行，47% 的单轮函数调用削减，基于 BM25 的 Tool Search 实现 85% Token 削减。

从狂欢到精算#

行业正在从一个阶段切换到另一个阶段。

Coding Plan 时代，用户和开发者不需要关心效率——云厂商的补贴扛着一切。每一行代码、每一次调用，背后都有免费额度在兜底。大家的精力全放在功能堆叠上：技能越多越好，工具越全越好，Agent 越”智能”越好。

Token Plan 时代来了，规则变了。每一笔消耗都是真金白银。冗余不再是”有总比没有好”，而是”你要为它付钱”。

所以，这场争论的意义在哪？

它不只是两个技术哲学的对撞。是一个行业在告别补贴时代后，被迫重新审视每一笔开销。 「开箱即用」和「少即是多」之间没有根本对错 ——但在成本显性化的今天，“我不知道这些 Token 花在哪”才是真正的风险。

有几个方向已经是共识。

1. 工具搜索按需加载 ：不一股脑把所有 Tool schema 塞进上下文，用的时候再加载，用完就释放。BM25 搜索不是花活，是刚需。

2. 多 Agent 场景分离 ：Coding 用 Pi 或 Claude Code，日常助理用 Hermes 或 OpenClaw，各配各的技能密度。不在一个 Agent 里堆所有事。

3. 可见性优先 ：不管是裁剪技能还是配置工具，先能看到 Token 花在哪。看不见就管不了。

Coding Plan 时期，效率是云厂商替你操心的事。Token Plan 时期，效率是你自己的事。

争论还会继续。但这不是坏事。