第四章：工具怎样从可用走到执行
上一章给模型准备了一份行动菜单。但菜单上的“读取材料”怎样对应到真正读取的程序？如果工具已经安装，却没有配置好，模型还应该看到它吗？如果两个扩展使用相同名字，又该找谁执行？
工具系统需要把能力说明、实际执行者和运行条件连接起来。本章沿着登记、发现、筛选、派发与反馈这条职责链，看 Hermes 怎样组织工具，以及这些选择的代价。
本章还提供一次真实受控观察：直接运行固定版本的 Hermes 工具注册表。请求由实验驱动提供，没有调用模型。它让我们能观察局部机制，但不能据此评判完整 Agent 的任务效果。
4.1 一项能力需要两份不同的说明
先为简报准备一个“读取材料”工具。模型需要知道它能解决什么问题、应该提供什么输入；运行程序还需要知道真正由哪个执行者处理请求。
| 需要登记的东西 | 本例中的含义 | 面向谁 |
|---|---|---|
| 名称 | 读取材料的稳定标识 | 模型请求与程序匹配 |
| 用途与输入约定 | 提供材料编号，返回相应内容 | 主要帮助模型选择和构造请求 |
| 执行者 | 真正读取固定材料的处理程序 | 运行程序 |
| 分组与可用条件 | 属于取材能力，当前材料服务是否就绪 | 配置、发现和筛选 |
输入约定常以 Schema 表示，可以先把它理解为字段和结构的约定。例如“需要一个材料编号”，比“给我合适的参数”清楚。它不直接包含执行程序，也不保证模型理解了所有业务条件。
尤其要注意，面向人的工具管理说明，与实际发送给模型的用途描述，可能是不同字段。配置界面上写得很详细，不代表模型本轮收到的定义同样完整。在 Hermes 这个版本中，收集模型定义时会使用登记的相应 Schema 信息，需要检查真正暴露的内容。
4.2 为什么使用集中登记，而不是到处写判断
最简单的派发办法，是在核心程序里不断增加规则：“名字是读取就调用读取程序，名字是搜索就调用搜索程序”。工具很少时，这种做法可以工作。
但随着能力增加，名称、用途、参数、可用条件与执行者容易散落在不同地方。新增工具要同时维护多个列表，某处漏改后，模型看到了能力，程序却找不到执行者；或者执行者已经存在，模型却不知道怎样调用。
Hermes 使用中央工具注册表。工具模块声明自己的信息，系统通过共同的查询和派发入口来组织能力。内置工具还具有发现机制，按约定找到包含登记声明的模块并加载；可选工具加载失败，不应让所有其他工具一起无法使用。
这项选择让能力扩展与运行核心减少直接纠缠，也产生新的治理要求：名称不能随意冲突，输入约定需要有效，可用条件要清楚，执行结果还要符合公共返回约定。
注册表不是一种天然正确的高级设计。能力固定、数量很少的程序，显式安排调用关系也可能更直接。注册表的价值在于，新增和选择能力时存在值得统一管理的共同责任。
4.3 系统知道它，不等于模型这一轮看得见
现在再登记一个“发送简报”工具。它也存在于系统中，但当前阶段没有设置发送条件，而且任务只要求形成草稿。
Hermes 会结合工具分组、配置与可用性来形成工具定义。某项能力缺少依赖、服务没有就绪，或不在所选范围内时，不应简单地把所有说明照单交给模型。
减少不可用能力的暴露，有助于避免无效选择，也减少说明体积。但它依赖准确的可用性判断；判断过时或过于宽泛，也可能隐藏本来可以使用的能力。因此，发现和可见列表本身就是需要观察的状态。
还要把“可见”与“授权”分开。模型看不到某个工具，不足以证明所有其他调用路径都被访问控制拒绝。真正允许做什么，还要由相应运行路径和工具边界落实。反过来，模型看到了发送说明，也不能改变本次任务“不发送”的要求。
4.4 请求怎样找到执行者
模型返回的调用至少要让程序知道名字与输入。此后程序需要完成匹配、派发与执行，再把内容或错误放进对应的反馈。
对普通读取工具而言，可以把这段过程理解为：找到登记项，交给相应处理程序，取得结果，再按约定组织输出。有些能力还依赖当前 Agent、会话或任务状态，需要额外上下文或专门处理，不能都看成完全独立的小函数。
一条请求还可能在不同环节失败：名字不存在、参数无法使用、材料不存在、网络服务异常，或返回类型不符合约定。这些结果对下一步的意义不同。只返回“失败”会让后续难以区分该改什么。
参数约定也不是自动执行的魔法。登记了 Schema，不等于任意绕过模型的直接调用都会经过全部业务校验。检查可能位于请求处理、工具实现或其他边界。我们的受控观察就会看到：缺少编号的请求进入读取处理器后发生异常，再由注册表封装成错误结果。
4.5 观察原始注册表的一次受控执行
实验载入的是 Hermes v0.22.5 固定提交的原始注册表及最小依赖，没有修改这些模块。我们额外提供两个自编处理器：读取教学资料和模拟发送；后者没有被调用，也不会产生真实发送。
调用请求由固定实验驱动提供，而非模型生成。实验只覆盖同步派发，不代表完整 Hermes 的所有工具都经过相同路径。
| 实际操作 | 观察结果 | 对设计的解释 |
|---|---|---|
| 登记读取与发送两个工具 | 已登记名称中有两个工具 | 能力信息已进入注册表 |
| 读取可见定义 | 只有读取工具 | 发送的可用性条件不满足 |
| 请求读取 A | 返回 A 的正文和图片限制 | 名称找到了对应执行者 |
| 请求未登记名称 | 返回“未知工具”错误 | 无法找到对应项，不能凭名称执行 |
| 读取请求缺少编号 | 返回包含编号缺失原因的错误 | 处理器异常被封装为反馈 |
最后一项尤其重要：我们并没有观测到“注册表提前检查出所有参数错误”。实际发生的是处理器取不到所需编号并抛出异常，派发逻辑将其变成错误结果。讲清发生在哪一层，才有可能正确理解责任边界。
这份记录也没有证明模型会选对工具。它证明的是，当驱动给出这些请求和条件时，这段真实模块执行产生了相应结果。完整模型运行、真实联网与授权机制需要另行观察。
原始记录可在贯穿案例页查看和下载；阅读本章不需要执行脚本。
4.6 错误结果怎样变成下一步的依据
收到“未知工具”，下一步应当检查当前可用定义与名称；缺少材料编号，应修正输入；取得 A 的正文，才有材料核对 B 的图片说法。
工具返回的内容仍然是待解释的材料。A 与 B 是否冲突、事件是否重复、两条草稿是否足够，不能由读取工具的“执行完成”状态代替。工具主要回答“这项动作得到了什么”，任务判断还要结合目标和其他证据。
对发送等会改变外部状态的工具，问题更多：没有拿到确认，可能是没执行，也可能是已执行但确认丢失。我们当前只读材料，后面讲恢复时再分析这种差异，不能把只读实验的重试经验直接移到发送行为。
4.7 MCP、插件与技能怎样接到这条链
从职责出发，这些概念会更容易理解：
| 概念 | 主要解决什么问题 | 怎样与工具链配合 |
|---|---|---|
| 工具 | 实际可执行什么动作 | 提供调用说明与执行结果 |
| MCP | 怎样按共同协议连接外部能力 | 外部服务提供的能力可以经过发现和接入成为可调用工具 |
| 插件 | 怎样扩展和装配运行系统 | 可以引入工具，也可以扩展其他运行责任 |
| 技能 | 遇到这类任务应该怎样做 | 提供方法，指导什么时候调用已有能力 |
Hermes 在内置工具之外，还会接入 MCP 和插件提供的能力。不同来源最终需要与可用性、名称、说明及执行管理配合。插件带来扩展性，也增加冲突处理和信任来源的责任，不能简单认为后来加载的工具就应该覆盖先前工具。
技能则主要提供方法。例如“先去重，再核对原公告，保留不能确认的范围”可以指导任务推进；它不会因为写在文档里就自动读取材料。真正行动仍需工具。
本章不要求记住每一种扩展配置。重要的是能把新名词放回职责链：它提供动作、连接能力、扩展系统，还是提供做事的方法？
4.8 给本例设计一张工具卡
现在请为读取材料写清用途、需要的编号、返回内容与可能错误，再说明谁检查“编号能否使用”。随后为发送简报写下不同条件：此时没有发送任务，也没有观察真实投递，应当怎样控制它的暴露和执行？
如果发现三份材料只有两件事，应该调整交付说明或继续取得允许的材料；新增一个“强行生成第三条”工具并不能解决证据不足。这也说明，工具设计需要回到任务目标，而非只追求能力数量。
本章留下的产物是工具职责链和真实局部实验结果。接下来我们已经具备模型输入与真实动作两端，可以进一步研究它们怎样通过行动循环连接。
本章要点
- 工具信息要连接名称、模型可读说明、输入约定、执行者和可用条件。
- 集中登记有助于统一查询与扩展，也需要处理名称冲突、契约和可用性。
- 已登记、模型可见、已请求、实际执行和任务完成是不同状态。
- 参数检查与授权可以分布在不同位置；可见性筛选不能代替完整访问控制。
- 受控实验能验证具体模块路径，不能证明模型决策或完整 Agent 的效果。
- MCP、插件和技能可以配合工具链，各有不同责任。
理解题
1. 实验中发送工具已登记但没有出现在可见定义里，能否推断它没有被安装？
不能。登记列表与模型可见定义回答不同问题。应先检查工具分组、配置与可用条件。本实验刻意使发送的可用性条件不满足；它没有证明其他调用路径也已经被授权系统阻止。
2. 缺少材料编号时返回了错误，说明系统在哪一层完成了校验？
仅凭错误状态无法判断。本次真实记录显示请求进入处理器，读取编号时抛出异常，再由派发逻辑封装返回。要声称派发前已完成某种格式校验，需要额外证据，不能从 Schema 的存在直接推断。
3. 三个工具都能搜索，怎样避免只靠名字碰运气？
比较它们实际暴露的用途、输入、返回范围与适用条件，只提供当前任务需要的能力，并让说明表达清楚差异。增加工具可能改善覆盖，也会增加输入体积和选择歧义，需结合任务验证。
4. 已经取得 A 的正文，下一步是否应当立刻形成完整三条简报？
仍要结合 B、C 与完成标准判断。A 的成功读取只证明取得一份材料；原公告与转述的冲突、事件重复和数量不足仍需处理。行动循环将使用这些真实结果继续推进，直到能交付有边界的结论。
下一章把这些工具结果带回行动循环，观察每次反馈怎样改变后续行动。