前几天研究 Hermes 的“上下文减负”时，我还觉得每轮少带几千 Token 已经够狠了。
结果这件事根本没停。
我今天重新翻了一遍 Hermes 官方专门建立的「Context Burden Reduction Campaign」，也就是“上下文负担削减行动”，发现里面的数字还在继续往上涨。
目前官方给出的最新汇总已经大致来到：
开启 video_generate 的相关场景：每次 API Call约少带 11,000 Token不包含 video_generate：每次 API Call约少带 10,700 Token这里先提醒一句。
标题里为了好理解，我用了“1.1 万 Tokens/轮”，但官方更严谨的统计单位其实是：
Token / API Call也就是说，一个复杂 Agent 任务如果中间连续进行了多次模型调用，省下来的固定上下文可能还会继续累加。
更有意思的是，Hermes 现在已经不满足于“删几段提示词”。
它正在系统性地检查：
这个 Tool 用户根本没启用为什么每轮还要告诉模型？这个参数当前模型根本不支持为什么还要显示？这条规则另一个 Tool 已经讲过为什么这里还要重复一遍？这个知识只有出错时才需要为什么开工前就让模型背下来？这才是这轮减负真正值得研究的地方。
我从里面挑了 10 个最有代表性的“瘦身技巧”，把 Hermes 到底怎么把上下文一点点减下来的讲清楚。
一、先搞懂：Hermes 为什么还没开始干活，就已经消耗一大堆 Token？
很多刚接触 Agent 的朋友，很容易把 Token 消耗理解成：
我输入多少字AI 回答多少字其实远远不止。
Hermes 每次把请求发给模型之前，还会附带很多模型必须知道的东西：
System PromptTool Schema工具参数调用规则安全限制错误处理说明当前环境信息……比如 computer_use。
Hermes 不能只告诉模型：
这是一个控制电脑的 Tool它还得解释：
有哪些 Action每种 Action 怎么调用哪些参数必须填坐标如何传截图怎么处理什么时候需要批准遇到异常怎么办……结果就是：
用户的问题可能只有几十个 Token，但 Agent 真正提交给模型的请求，开头已经背着几千甚至上万 Token 的“说明书”。
更麻烦的是，一个 Agent 任务往往不只调用模型一次。
例如：
用户：帮我查一下这个项目并整理结论Call 1模型决定先搜索Tool 执行Call 2模型读结果，决定打开网页Tool 执行Call 3模型继续分析Call 4最终回答如果固定 Tool Schema 每次都要重复带上，那么一次任务背了 4 遍。
所以 Hermes 这轮优化盯上的，正是这部分：
每次请求都在重复消耗、但并不一定真正有用的固定上下文。
二、第一刀最干脆：你根本没启用的能力，就别让模型知道
这是我最喜欢的一类优化，因为逻辑特别简单。
A2A 没配置，5 个 Tool 直接不加载
Hermes 有一套 A2A，也就是 Agent-to-Agent 能力，可以让不同 Agent、机器甚至其他框架之间互相通信。
对应有 5 个 Tool：
a2a_discovera2a_calla2a_lista2a_historya2a_orchestrate问题在于，过去就算你：
根本没有配置 A2A Agent这 5 个 Tool 还是会进入模型上下文。
换句话说：
用户：完全不用 A2AHermes：每轮仍然给模型读一遍A2A 使用说明而这些 Tool 真被调用以后，往往只能告诉模型：
no peers configured现在 Hermes 终于改成：
没配置 A2A5 个 Tool 不展示561 Token → 0什么时候配置了 Peer，或者真正开启 A2A，再把它们加回来。
这个思路我觉得应该直接写进 Agent 设计教科书：
能力可以存在，但没有启用以前，不应该占模型上下文。
类似的还有以前的 bfl_flux3_* Promo Tools。
活动结束以后，Hermes没有继续保留一堆：
“这个功能现在不能用了”的说明，而是整组移除。
这一项单独就少了大约：
2260 Token / Call再加上一块已经没有必要每轮重复出现的 Nous Subscription System Prompt：
约 1180 Token / Call光这种“根本没必要继续带着”的内容，就已经砍掉了一大截。
三、第二刀更聪明：当前模型不会的参数，连看都不用看
删掉完全没用的 Tool 只是第一层。
Hermes 接下来做的，是让 Tool Schema 开始根据当前模型动态变化。
最典型的就是 image_generate。
以前无论你使用什么生图模型，都可能看到一大套参数：
image_urlreference_image_urlsupscale……可问题是，不同模型能力完全不同。
例如：
模型 A只会文字生图模型 B支持图片编辑模型 C支持多张参考图模型 D还支持 Upscale过去的办法相当于：
所有人先看完整菜单再在说明里告诉模型：“这个功能有些模型不支持”现在直接反过来：
当前模型会什么Schema 才出现什么如果是纯 Text-to-Image：
只展示文字生图需要的参数支持编辑以后才出现：
image_urlreference_image_urls支持 Upscale 才出现：
upscale于是编辑型配置下：
554317 Token减少约 43%纯生图模型甚至可以压到大约：
180 Tokenvideo_generate 紧接着也用了同样的办法。
以前统一展示：
image_urlreference_image_urlsnegative_promptaudioseedupscale……现在改成根据：
Provider具体 Model动态生成 Schema。
最终不同配置可以从原来约：
814 Token降到：
458甚至 377减少约：
44%～54%这个变化表面上只是少了一些参数，背后的逻辑却很重要：
Tool Schema 开始从“功能大全”，变成“当前这台机器真正能用的操作面板”。
四、第三刀：不同模型学不同教材，Claude 没必要天天背 Codex 的语法
最近新合并的 Patch 优化，是这轮减负里一个非常有意思的案例。
Hermes 修改文件主要有两类方式。
一种大家都比较容易理解：
找到 old_string替换成 new_string另一种是：
V4A PatchV4A 可以理解成 OpenAI / Codex 系模型非常熟悉的一种 apply_patch 风格。
问题来了。
以前：
GPTClaudeKimiDeepSeek其他模型全部先学习这两套模式。
也就是说，即使当前根本不是 OpenAI 系模型，它每轮还是得理解：
modepatchV4A 格式两种模式分别需要哪些参数……现在 Hermes 开始“因材施教”。
OpenAI / Codex 系：
继续展示 V4A其他模型：
只展示通用 Replace于是非 OpenAI 场景：
365195 Token减少约 47%单次少：
约 149 Token而且这里有一个设计细节我特别喜欢。
Hermes 只是：
不主动教学并没有：
删除后端能力如果一个非 OpenAI 模型自己真的会输出 V4A，Handler 仍然能够接收。
也就是：
减少教学，不等于阉割能力。
这个思路其实比“单纯把 Tool 砍小一点”高级多了。
五、第四刀：该出错时再讲的知识，别每天开工前都背
另一个非常明显的趋势，是 Hermes 开始把很多“提前教学”改成“按需教学”。
最典型的是 Session_search。
以前模型每轮都要提前学习：
该怎么搜 Session搜不到怎么办什么时候扩大搜索不同结果怎么处理如何恢复旧上下文……这些内容当然有用。
但真正的问题是：
模型这一轮根本没用到 session_search，为什么也要读？
所以 Hermes 把很多教学内容挪到了：
真正调用以后或者搜不到结果以后再告诉模型。
结果：
1570695 Token少了 875减少约 56%更关键的是，他们还专门做了 A/B 测试。
一共：
3 个模型108 次 Run最后：
旧 Schema：49 / 54精简 Schema：52 / 54也就是说至少在这组测试里：
说明书短了任务表现没有变差clarify 也是类似思路。
以前单问题、多问题、各种字段有多套表达方式。
现在主要统一成：
questions[]一个问题：
数组放 1 个五个问题：
数组放 5 个于是：
880330 Token减少约 62%接口越统一，需要解释的东西自然越少。
六、第五刀：相同规则只讲一次，Tool 之间别互相抄说明书
这一类优化特别像我们平时整理文档：
同一句话如果三个地方都出现，以后一定会越来越乱。
skill_manage 就曾经存在这个问题。
它里面会重新解释：
old_string 怎么匹配new_string 怎么替换replace_all 怎么使用怎样保证字符串唯一……但 Hermes 明明已经有一个专门的：
patchTool。
两边使用的底层匹配逻辑又基本一致。
过去就相当于：
patch写一份说明书skill_manage再抄一遍现在 skill_manage 直接告诉模型：
匹配规则和 patch Tool 相同只保留 Skill 自己特有的内容。
经过两轮压缩：
约 920427 Token类似的还有 delegate_task。
以前一共有 9 个参数，其中一些甚至已经：
DEPRECATEDIGNORED也就是：
参数已经不工作了，但模型还得学习“这个参数不工作”。
现在直接删掉这些无效教学，再把单任务、多任务收口到：
tasks[]最后：
1201773 Token减少约 36%terminal、todo、process、read_file、vision_analyze 也都在做类似的事情：
terminal837 → 684todo323 → 232process306 → 228read_file426 → 263 左右vision_analyze271 → 181这些单项看着没有一两千那么夸张。
但是：
1001509016090……一项项叠起来，最后就是标题里的上万 Token。
七、最典型的一场大手术：Computer Use 从 3469 Token 砍到约 1300
如果让我从整轮减负里只挑一个最能说明问题的案例，我会选 computer_use。
它经历的不只是删点文案，而是整个能力边界重新整理。
早期：
computer_use SchemaSystem Prompt 额外教学≈ 3469 Token / Call第一轮优化以后，Hermes 把大量重复教程删除或合并：
34692064已经少了：
1405 Token后来 Browser Use 越来越成熟以后，团队又发现一个问题：
既然 Browser 已经有专门的 Browser Tool，Computer Use 为什么还要再背一套网页操作？
原来的 Computer Use 里面还有：
9 个 cua_browser_* Action大量 Browser 专用参数比如网页元素、Browser Route、Transfer、各种网页操作字段。
Real Profile Browsing 等 Browser 能力完善以后，这整套重复能力开始从 Computer Use 里拆出去。
现在整个路线已经从：
3469约 1300 Token相当于砍掉六成左右。
而且能力边界反而更清楚了：
网页操作Browser桌面软件鼠标键盘窗口截图Computer Use这让我觉得 Hermes 这轮减负最值得看的地方，其实并不是：
删了多少 Token而是：
它开始通过重新划分 Agent 的能力边界，自然地让上下文变小。
这比单纯压缩几句 Prompt 健康得多。
八、还有一刀根本没算进 1.1 万：长会话一次最多再少十几万 Token
到这里讲的 1.1 万左右，主要都是：
每次模型请求固定背着的 Tool SchemaSystem Prompt但 Hermes 还有另一条减负线：
Context Compression这一块数字甚至更夸张。
以前在 1M Context 的大上下文模型上，进行一次压缩以后，可能仍然保留：
约 170K Token的 Verbatim Tail，也就是近期原文。
于是用户经常会发现：
明明 Compress 了怎么上下文还是这么大？现在默认换成 Lean Tail：
10K ～ 25K Token一次 Compression 在极端大上下文场景，可以少保留：
约 145K ～ 160K Token而且它并不是简单把东西一删了之。
Hermes 会用：
Digest压缩历史内容Anchor Index保留 PR、SHA、路径、错误等关键锚点Verbatim User Messages保留用户重要原话session_search真正需要旧细节时再找回来所以 Hermes 现在实际上同时在处理两种“肥胖”：
第一种：模型每次开工前背的说明书太厚约少 1.1 万 Token / Call第二种：长会话压缩以后还保留太多历史原文最多再少十几万 Token这两件事放在一起看，才是这一轮减负真正完整的样子。
九、干货总结：Hermes 这 10 个瘦身思路，真正值得记住的是方法
最后把前面的内容压成一张速查表。
Hermes 最新 10 个减负技巧1. A2A 没配置就不加载5 个 Tool561 → 02. 过期 Promo Tool 直接删除约 -2260 Token / Call3. image_generate 动态展示参数554 → 317部分配置可降到约 1804. video_generate 按模型生成 Schema814 → 458 / 3775. 非 OpenAI 模型不教学 V4A365 → 1956. session_search 改成需要时再教学1570 → 6957. clarify 统一 questions[]880 → 3308. skill_manage 不重复 patch 规则约 920 → 4279. delegate_task 从 9 参数精简到 41201 → 77310. Computer Use 拆掉重复 Browser 能力3469 → 约 1300如果只看这些数字，很容易把这轮更新理解成：
Hermes 在省钱。
我觉得还不够准确。
它真正做的是四件事：
没启用的→ 不加载当前模型不会的→ 不展示重复的→ 只讲一次只有出问题才需要的→ 出问题再教这四条其实就是非常朴素的产品逻辑。
但 Agent 发展早期，大家都忙着不断加功能，Tool 越来越多、Schema 越来越长、Prompt 越来越复杂，很少有人认真回过头问：
这些东西真的需要每一轮都让模型重新读一遍吗？
Hermes 现在开始问这个问题了。
所以标题里的约 1.1 万 Token/Call 当然很亮眼，但我觉得真正重要的信号是：
Hermes 开始把“上下文”当成一种昂贵资源来管理，而不是一个能塞多少就塞多少的垃圾桶。
对长期运行、多 Tool、多 Agent、大上下文的用户来说，这种变化很可能比再增加十几个新功能更实用。
热门跟贴