工具声明与候选集 · 第 6 课

1一个工具由哪几项描述

名称、说明、输入结构、产出——四项各管一件事，缺一项模型便难以正确使用。

这个工具的唯一标识：模型提出调用时靠它指名，宿主解析时也靠它对应到服务器上的某个工具。同一台服务器内不可重名。

一段自然语言，写清这个工具做什么、什么时候应使用。它会原样进入提示词——模型判断「是否应当调用这个工具」，依据就是这段说明。

用 JSON Schema（一种描述 JSON 数据结构的规范）写出参数名、类型、是否必填。模型据此填写参数，宿主据此校验参数。

返回的是内容数组，每项可以是文本、图像或资源引用，并带一个「是否出错」的标记，用来区分「工具正常返回了空」与「工具自己报错了」。

发现结果之所以必须是机器生成的，正因为它要同时喂给模型与校验器两处。

说明不是注释，而是这个工具交给模型的唯一一份使用说明，模型据以判断的就是它。

说明写坏有两类典型后果：说明过宽，模型在不应调用的场景误调；说明与实际行为不符，模型调用后才发现取不到所需内容。前者增加无效调用，后者污染回答。因此说明的验收标准不是「表述通顺」，而是「按其描述调用不会出错」。

把全部工具不加筛选地交给模型，既危险也低效。应先划定一个候选子集，再让模型在子集内选择。

工具越多，选错的概率越高；模型可用的动作越多，一次误判的后果也越大。此外，每条工具声明都占用上下文窗口（context window），几十个工具即数千个词元，成本与延迟都切实存在。

按场景、角色或任务先划定一个候选子集，只把子集内的工具转换为工具声明，随本次提问发出。模型只能在子集内选择，子集外的工具它根本看不到。

最小权限原则（least privilege：只授予完成当前任务所必需的权限）：先按用途划定上限，再让模型在上限之内自主决定。它是工具调用上的第一道防线，且在模型出场之前就已生效。

候选集决定的是「最多能用哪些」，模型决定的是「本次用哪个」。前者属配置期问题，后者属运行期问题——把两者分开，事后才能追溯一次调用为何发生。

一条引用（「工具名@服务器名」这样的写法）要过四类检查。原则是：能在配置期发现的错误，就不应留到运行期。

配置期从严、运行期从简：前者查的是稳定事实（改一次管很久），后者只判断当前是否可用。若在运行期把四道检查都重做一遍，每次提问都要多一次完整校验，服务器瞬时抖动还会把正常的提问判为失败。

也要承认这条局限：校验只发生在保存那一刻，此后服务器断开、改名或被删除，引用不会随之改变，调用即失败——这不是校验遗漏，而是检查时与使用时的时间差（TOCTOU，time-of-check to time-of-use）所致。

这套取舍可概括为：把能当场判定的错误推到离出错者最近的位置。配置错误应在配置者眼前报错，而不是变成用户看到的一段答非所问。

本课用「工具名@服务器名」这一写法把工具与它所在的服务器绑成一条引用。

两段分别定规矩是有理由的：工具名来自服务器，字符集由协议与实现约定，收紧一些更可控；服务器名由人命名、需要可读，因此放宽到允许连字符。