Hermes Agent 省 token：把工具说明书换成目录，能省 98%

TL;DR

平时不调用工具的那些轮次，把工具说明书换成目录能省 98%；但真正按下“调用工具”的那一刻，省下来的部分被整轮输入摊平，实际只有不到 2%。两种场景都真实存在，只是量的是不同的东西。所以最终能省多少，取决于你平时是问得多还是干活多。

先给结论

平时不说话的那些轮次，能省 98%。真调用工具的那一刻，省不到 2%。

这后半句是我自己实测出来的，前几篇没写。放在开头，是因为不写清楚就是骗人。

先说工具说明书是什么

你在 Hermes 里接 46 个工具。

每个工具都有一本“说明书”：叫什么名字、能传哪些参数、每个参数是什么类型、有哪些坑。

AI 每开一次口，这 46 本说明书都得重读一遍。

不是读一次记下来。是每轮重读。

我这套说明书加一起，9,012 个 token。

你跟它聊十轮，它就读了九万多。对话本身反而是零头。

怎么换成目录

思路很简单——平时别发说明书，只发目录。

目录是什么？每个工具一行，写清它叫什么、大概能干什么。

比如目录长这样：

search_web —— 搜索网页并返回结果
read_file —— 读取指定文件内容
run_code —— 在沙箱里执行一段代码
send_email —— 发送一封邮件

这 46 行加起来，约 157 个 token。

一整本 9,012 的说明书，变成 157 个 token 的一张目录。

省了 98%。

真正要用某个工具的那一刻，再把那一本发过去。

功能一点没少，46 个工具都在。

但是——我实测的时候发现了问题

上面那个 98%，我一开始当成“到处都能省”。

后来我做了一次真调用测试：不只是量手册本身，而是让模型真的去调一个工具，量输入侧实际发了多少。

结果：

跟上面那个 98% 差得远。

把两种场景摆在一起看，差异就清楚了：

我一开始以为是量错了

第一反应是自己搞错了，反复查了两遍。

数字没错。

后来想明白差别在哪：

• 9,012 → 157 量的是“那本说明书本身”。
• 43,400 → 42,650 量的是“整轮对话的真实输入”——里面除了说明书，还有系统提示、有历史对话、有本次的问题。

说明书只占其中一块。

换目录能把那一块压到 157，但压不动另外那些。

所以真实的降幅被摊薄成了 2%。

所以 98% 到底该怎么理解

它只在“这一轮不调用任何工具”的时候成立。

典型的场景：你在问它问题、让它分析、写代码让它读文件之前的那段讨论。

这些轮次，98% 是真的。

反过来，你按下“调用工具”那一刻，目录省下的那点被整轮输入摊平了，比例就是 2%。

两种场景都真实存在。我之前只报了前一种。

还有个没说的成本

顺便记一笔：换完之后，那层桥冷启动要 40 秒。

第一次调用的时候你会等一下。第二次之后就快了。

这是我自己在用的时候感觉到的，具体什么机制我还没深究。

折腾到这儿我顺手去 GitHub 搜了搜

想看看有没有现成的。

搜“mcp token 压缩”，翻到一个叫 mcptoon 的项目，两百多颗星，做法跟我上面说的一致：平时发目录，用到才发详细那页。

仓库在 GitHub 上：https://github.com/mcptoon/mcptoon。它跟本文方案的核心差异在于，mcptoon 是把它做成一个可插拔的中间层，直接挂在 MCP 客户端和服务器之间，开箱即用；而本文这套是自己在 Hermes 里手动改的目录策略，更贴近底层、也更依赖你自己的配置。想直接抄作业的话，看它 README 里的「Usage」一节就够了。

我的结论

“省 98%”这个说法只在特定场景成立，不是无条件的。

要看你平时是怎么用的：

• 大部分时间在讨论、在问问题 —— 那 98% 你真能拿到
• 大部分时间在跑工具 —— 那你拿到的就是个位数

我不打算把这个说成“人人都能省 98%”。这是我这一台、这一套配置的实测数字。

想问问各位：你们用 Agent 的时候，是问得多还是干活多？我挺想知道这个比例大概是什么样——因为它直接决定这个 98% 对你值不值。