📚 系列导航：上一篇 Hermes Agent 调用编码 Agent 指南 已经讲清“调用 Claude Code、Codex 与 OpenHands 指南”；本篇聚焦 Hermes Agent 工具系统；下一篇 Hermes Agent MCP 配置教程 继续学习“MCP 配置与双向集成指南”。
先给结论：工具数量不是越多越好，关键是这一轮只让模型看见真正需要的工具。 Hermes 用工具集分组、可用性检查和渐进式工具披露控制上下文开销。README 与源码计数不同，也提醒你先确认统计口径。
ℹ️ 版本说明： 原稿基于 Hermes Agent v0.16.0（2026 年 6 月）源码整理。本文保留其版本化机制分析；命令、数量和界面请以 Hermes Agent 官方文档 与本地输出为准。
Hermes Tool 与 Toolset 的区别
旧书里写 Hermes 有「40+工具」，那是官方 README 的对外口径。我这次去翻源码，用 grep 数了一遍 registry 的注册项，真正能被模型调用的工具是 64 个。如果把 spotify 那套走插件路径注册的也算上，大概 71 个。
数字对不上，是因为有两个概念被混在一起了，得先掰开。
💡 推荐
工具（tool）：模型实际能 call 的那个函数。比如 web_search、terminal、image_generate。这种有 64 个。
不推荐：
工具集（toolset）：把工具分组打包的别名。比如 web={web_search, web_extract}。这种约 50 个。
为什么要分这两层？因为「给模型暴露什么」和「按功能怎么组织」是两件事。工具是原子，工具集是套餐。后面你会看到，这套分层正是「按需暴露」的地基。
Hermes Agent 工具的五种类型
把这 64 个工具按职能归一下类，能看清 Hermes 到底能干什么。我读了 toolsets.py 和各个工具文件，归成五大类。
| 类别 | 代表工具 | 能力 |
|---|---|---|
| 执行类 | terminal、execute_code、read_file、patch、computer_use | 跑命令、读写文件、改代码。computer_use 在后台控制桌面,不抢你的鼠标 |
| 信息类 | web_search、web_extract、browser_* (12 个)、x_search | 搜网页、抓内容、开浏览器。browser 是大头,光子工具就 12 个 |
| 媒体类 | image_generate、video_generate、video_analyze、text_to_speech | 生图、生视频、看视频、语音合成。每个只暴露一个统一入口 |
| 记忆规划类 | memory、skills_list、todo、cronjob、session_search | 跨会话记忆、管 Skill、待办、定时任务、翻历史 |
| 协调类 | delegate_task、mixture_of_agents、kanban_* (9 个) | 派子 agent、多模型混合、看板协调一群 agent |
这里有个细节值得拎出来。有几个旧书的说法已经过时了。旧书写协调类「最多 3 个并发子 Agent、最多 3 层」，源码里这条限制已经解封。并发默认 3 但可以随便抬，深度也没了上限。旧书还列过一类「rl 工具」，现在 RL 环境走单独的目录，根本不进 agent 的工具面。写书引用旧版本的限制数，很容易翻车，这是我读源码时撞到的坑。
Hermes 工具可用性门控
64 个工具，如果每次对话都把 64 个工具的定义全塞进 system prompt，会发生什么？
context 被工具定义撑爆。模型还没开始干活，光读工具说明书就占掉一大块上下文。更糟的是，工具一多，模型挑错工具的概率也跟着涨。
Hermes 的解法是两层门控。第一层是 toolset 分组，第二层叫 progressive tool disclosure。先说第一层。
很多工具不是无条件出现的，它们带一个 check_fn 门控函数，只在满足运行时条件时才进模型可见的工具列表。我列几个实际的例子，你就懂这个设计有多克制。
check_fn 门控的几个实例：send_message 只在网关跑起来时才出现；Home Assistant 那套工具只在你配了 HASS_TOKEN 时才出现；computer_use 只在装了桌面驱动时才出现；kanban 那 9 个看板工具只在被看板调度器派生出来时才出现。没装、没配、没触发，模型就压根看不见它们。
还有一处我觉得设计得很聪明的安全收窄。webhook 场景下，比如有人提了个 PR、发了条评论触发 Hermes，内容可能来自不可信的第三方。这种场景 Hermes 只放出四个最安全的工具（搜索、抽取、看图、澄清），本地执行权限一个都不给。因为 webhook 里的文字可能藏着 promptinjection，万一模型被骗去跑 terminal 就完了。这是把威胁模型直接写进了工具暴露规则里。
渐进式工具披露如何减少上下文占用
第二层门控是 v0.16.0 的新东西，叫 progressive tool disclosure，工具按需暴露。
开启之后，MCP 工具和非核心的插件工具不再直接列进模型能看到的工具数组，而是被三个桥接工具替代：tool_search、tool_describe、tool_call。模型需要时自己搜一下有什么工具、查一下怎么用、再调用。像图书馆从「把所有书摊在你面前」改成「给你一个检索台」。
这里有两条让我觉得设计很有分寸的规则。一是核心工具永不延迟，源码原话是「Always load means alwaysload.Noexceptions.」最常用的那批工具该全程可见就全程可见，不绕弯子。二是有个阈值门控：当可延迟的工具占 context 还不到 10%时，这套搜索机制直接空转，工具数组原样透传。翻译一下就是工具不多就别折腾，省 context 的机制本身可不能变成新的负担。
最有意思的是源码注释里写的一句话：这个工具目录是无状态的、每轮重建。为什么不缓存？因为他们明确吸取了 OpenClaw 的教训。
⚠️ 注意
OpenClaw 曾经踩过一个坑：把工具目录做了 session 级缓存，结果缓存和实时的工具注册表漂移了，导致工具静默消失。用户以为某个工具还在，模型却看不见了，还不报错。Hermes 的注释里直接点名引用了这个回归 bug，宁可每轮重建也不缓存，就为了避开同一个坑。
我特别喜欢这种「我看着别人摔倒，所以我绕开这块石头」的工程注释。它不是抽象的最佳实践，是一手的、带血的经验。这套 progressive disclosure 本质上是 Anthropic「工具按需加载」思路的开源实现，解决的就是 MCP 接多了之后上下文被工具定义撑爆的真实问题。
Hermes 工具 Provider 插件化结构
聊完「怎么暴露工具」，再看「工具本身怎么交付」。这两个月 Hermes 最大的架构变化，是把外部能力全做成了插件。
web、browser、image_gen、video_gen 这四类，全部拆成了 plugins 目录下的一文件一后端。想加一个新的生图服务商？加个文件夹就行，不用去 fork 主工具。这就是源码里说的「四向架构对齐」，四类外部能力共用同一套插件骨架。
生图这块最能说明问题。你只看到 image_generate 一个工具，但背后挂着 5 个 provider 目录：fal、krea、openai、openai-codex、xai。具体走哪个，由配置和可用性自动路由。生视频同理， video_generate 一个入口，背后 fal 和 xai 两个后端，给纯文本就文生视频，给文本加图就图生视频。
光 FAL 这一条路由进来的生图模型就有 12 个，阵容挺豪华：FLUX 2 Pro、Nano Banana Pro（也就是 Gemini 3Pro Image）、GPT Image 2、Z-Image、Qwen Image 都在里面。源码还很细心地把尺寸规格分了三族，每个模型只收它支持的参数键，拒绝的键根本传不进去。
Krea 与 xAI 工具 Provider 示例
插件化最直接的好处，是新能力进得快。两个旧书完全没有的成员，都是这两个月靠这套骨架接进来的。
一个是 Krea2。它有独立的原生插件，也能从 FAL 那条路用到，两条路都通。Krea 的 API 是异步的：你提交后它返一个任务 ID，插件每 2 秒去轮询一次结果，对外伪装成同步调用。源码里还自带了定价和速度的元数据：Krea2Medium 大概 15 到 25 秒出图，强项是插画、动漫、绘画这类表现性风格。这种把第三方异步 API 包装成同步工具的活，正是插件骨架该干的脏活。
另一个更夸张，是 xAI。它不是一个普通的 provider，而是横跨登录、搜索、生图、生视频、语音的一条龙。
| xAI 接进来的能力 | 具体是什么 |
|---|---|
| SuperGrok OAuth 登录 | 不用 API key,订阅直接用 |
| x_search | 搜 X 上的帖子和线程 |
| Web Search provider | 和 Brave、Tavily 并列的一个搜索后端 |
| grok-imagine 生图 | 挂在 image_gen 插件里 |
| Grok Imagine 生视频 | 文生、图生、参考图引导都支持 |
| Custom Voices TTS | 语音合成加语音克隆 |
我觉得 xAI 这条线特别值得玩味。它是「一个开源 agent 怎么把一家闭源大厂的订阅能力吃干抹净」的标本：你订了 SuperGrok，Hermes 就帮你把这份订阅的搜索、生图、生视频、语音全用上，不用单独配一堆 API key。
不过有个工程细节我得替 Nous 说句公道话，他们没偷懒。x_search 的返回值里加了一个 degraded 字段：当你加了账号或日期过滤却拿不到任何引用来源时，它会标 degraded=true，等于在告诉你「这个答案是模型自己编的，不是从 X 索引来的」。把「有没有真来源」这件事做进了工具的返回值里，这种诚实挺难得。
Hermes Agent 工具系统的选择原则
回到开头那个 64 对 40 的差。它其实是整节的隐喻：工具的增长是真实的，但增长本身会变成负担。
Hermes 的回答是，不要把「能力多」直接等同于「全暴露给模型」。toolset 分组、check_fn 门控、
progressive disclosure、插件化交付，这四件事串起来是一个统一的态度—能力可以无限长，但每一刻暴露给模型的，只是此时此地真正用得上的那一小撮。OpenClaw 用工具太多掉准确率的坑，Hermes 用这套机制绕开了。
下一节我们看连接外部世界的另一条主干道：MCP。Hermes 在 MCP 上玩出了两个方向，比你想的要绕。
常见问题
Hermes Agent 为什么不一次加载全部工具？
工具定义会占用上下文，数量过多还会增加模型选错工具的概率。核心工具可以常驻，长尾插件和 MCP 工具更适合按需搜索与加载。
Tool 和 Toolset 有什么区别？
Tool 是模型实际调用的原子函数，Toolset 是按用途组织的一组工具。配置时通常通过 Toolset 控制一类能力是否可见。
这篇教程里的版本数字会变化吗？
会。原稿以 Hermes Agent v0.16.0 为分析基线，平台、工具、命令参数和默认配置可能继续变化；实际操作前请核对当前官方文档和本地命令帮助。