05. 工具与工具集
这一章解释 Hermes 为什么能“做事”，以及你该如何控制它能做哪些事。
本章目标
- 理解 tool 与 toolset 的关系
- 了解 Hermes 内置工具的大类能力
- 学会按会话或平台启停工具
- 学会区分 terminal、file、web、browser、execute_code、delegation 的适用场景
适用读者
- 所有认真使用 Hermes 的用户
- 需要控制安全边界和执行能力的部署者
- 开发者
前置条件
- 已理解 CLI 与配置系统
核心概念
Tool 是能力单位，Toolset 是开关单位
Hermes 内置工具注册在中央 registry 中，每个工具属于一个 toolset。你平时更常操作的是 toolset，而不是单个 tool。
常见 toolset 包括：
fileterminalwebbrowserskillsmemorycode_executiondelegationcronjob
工具是否可用，取决于三个层面
- 该工具或 toolset 是否启用
- 所需环境变量或依赖是否存在
- 当前平台是否允许该能力
这意味着“文档里有这个工具”不等于“你当前会话里一定能用”。
内置工具的常见边界
-
file：适合读写搜索文本文件 -
terminal：适合执行 shell 命令和后台进程 -
web：适合搜索网页和抽取正文 -
browser：适合真正的页面交互、表单、按钮、复杂界面 -
execute_code：适合 3 步以上的机械化串联操作 -
delegate_task：适合上下文隔离、并行研究、独立子任务
操作步骤
查看当前 toolset
CLI 内：
/toolsets
/tools list
CLI 外：
hermes tools
按会话启用指定 toolset
hermes chat --toolsets web,file,terminal
hermes chat --toolsets debugging
hermes chat --toolsets all
其中 debugging 这类 composite toolset 会展开成多个核心 toolset。
在当前会话中禁用某个工具
/tools disable browser
/tools enable browser
这对“想限制行为”或“怀疑某个工具在误导模型”时非常有用。
学会按任务选对能力层级
优先顺序通常是：
- 单次网页信息获取：
web - 复杂网页交互：
browser - 代码仓库文件理解：
file - 实际跑命令、构建、测试：
terminal - 批量顺序处理：
execute_code - 并行或新上下文分析：
delegate_task
理解凭据型工具
有些工具并不是默认可用，例如：
-
web_search需要EXA_API_KEY、PARALLEL_API_KEY、FIRECRAWL_API_KEY或TAVILY_API_KEY -
image_generate需要FAL_KEY -
homeassistant需要HASS_TOKEN
如果环境变量没配好，工具会被排除或不可用。
常见场景
场景 1：代码分析
优先用 file 和 terminal。如果只是查文件结构或读取文本，没必要打开 browser。
场景 2：网页调研
优先用 web_search 和 web_extract。只有在需要登录、点按钮、处理复杂页面时再切换到 browser。
场景 3：十几个重复步骤的数据处理
优先用 execute_code，因为它能把工具调用和中间逻辑放进脚本里，避免主会话被中间结果淹没。
场景 4：三条研究线并行推进
优先用 delegate_task，让不同子代理分别处理不同问题，再回收摘要。
常见问题与排错
为什么我明明启用了 toolset，工具还是没出现
最常见原因是该工具的 check_fn 失败了，比如缺 API key、缺依赖、缺平台前提。
browser 和 web 为什么要分开
因为它们成本和能力完全不同。web 更快、更便宜、更适合信息获取；browser 更重，但能真实操作页面。
什么时候不该乱开全部工具
当你需要安全边界、成本控制或更可预测的行为时。工具越多，模型的选择空间越大，行为也越难控。
本章总结
Hermes 的执行力来自工具，但稳定性来自对工具的约束。真正高效的用法不是“什么都开”，而是为任务提供最小且足够的能力集合。
下一步建议
继续看 技能、记忆与上下文文件，理解 Hermes 如何长期保持方法和偏好。
Top comments (0)