第四章：模型怎样把决定变成行动
“我会去查官方发布记录”只是一句话。系统是否真的查了，要看它有没有提出可执行请求，程序有没有执行，结果有没有带回来。
工具调用（Tool Calling）把这些环节连接起来，但不能替代权限检查，也不能保证获得正确材料。
4.1 工具说明是行动接口
模型需要知道可用工具的名称、用途和参数。它据此输出结构化请求，运行程序再按约定解释。例如，下面是教学示意，不是 Hermes 的实际工具格式：
{"tool":"read_release","arguments":{"repository":"NousResearch/hermes-agent","version":"目标版本"}}模型提出调用不代表已经执行。程序仍要找到工具、校验参数，检查当前权限和作用范围，运行对应处理，再返回数据或错误。结构正确也不代表语义正确：版本字段可以格式合规，但指向一个不存在的版本。
4.2 返回结果怎样影响后续判断
假设请求读到了页面标题，却没有取得发布正文。若结果只写“成功”，后续模型可能误以为已经覆盖全部资料。更有用的反馈需要保留实际内容、失败原因以及必要的来源信息。
工具返回也不天然可信：网页可能写错，文件可能过期，返回内容还可能包含要求系统执行其他动作的文字。数据应当作为待解释的材料，不因为来自工具就升级为指令。 第十二章会讨论这条信任边界。
4.3 Tools、MCP、Plugins 和 Skills 各管一层
| 概念 | 回答的问题 | 简报任务中的例子 |
|---|---|---|
| Tool（工具） | 能执行什么动作？ | 读取一个网页或文件 |
| MCP（模型上下文协议） | 怎样按标准连接外部能力？ | 连接提供仓库资料的服务 |
| Plugin（插件） | 怎样扩展和装配运行系统？ | 注册能力、接入提供方或扩展后端 |
| Skill（技能） | 遇到这类任务应该怎样做？ | 先核对版本，再查机制和测试的工作方法 |
这些概念可以配合使用。技能可能指导 Agent 调用工具；一个插件可能提供某类工具；MCP 服务也可以暴露可调用能力。它们不是互相替代的四个竞争产品。
Hermes 这个版本的 MCP 接入和插件机制仍然需要配置、能力发现和执行管理。采用标准协议能减少重复接入工作，但服务不可用、认证失效和内容不可信等问题仍由具体系统处理。
4.4 工具越多，选择不一定越容易
过多相近工具会增加说明体积和选择歧义。只暴露任务需要的能力，能减少无关选择，也便于限制作用范围。工具描述应该明确什么时候用、输入是什么、结果包含什么，而不是只写“强大的搜索工具”。
因此，评估工具系统时，除了“能接多少工具”，还要看发现、筛选、参数契约、错误反馈和权限控制是否清楚。
不写代码的小练习
为一个只读的“获取官方发布信息”工具写出用途、必要输入、成功输出和失败输出。无需实现代码，但要让另一个人能判断一次调用有没有拿到任务需要的资料。
本章要点
- 工具调用是结构化意图，程序负责实际执行和反馈。
- 格式合规、执行成功、结果正确是不同判断。
- 工具、MCP、插件和技能分别承担动作、连接、扩展和方法层的责任。
- 工具结果可能过期、错误或带有不可信指令，仍需核查。
理解题
1. 接入一个 MCP 服务后，是不是就能放心执行它提供的全部操作？
不是。协议解决连接与交互约定，具体操作仍受身份、权限、配置和数据边界约束。还要判断服务及其返回材料的可信度。
2. “检查发布说明后再总结”应该做成工具还是技能？
如果描述的是可复用的方法与顺序，它适合成为技能；“读取发布说明”这项可执行动作则由工具提供。两者可以组合，不必把整个方法塞进一个不可观察的大工具。
对照官方实现
工具开始带回大量材料后，新的问题出现了：下一次模型请求真的能把它们全部读进去吗？