工具描述的核心目标是什么？
- 定位: 工具描述的质量直接决定了 Agent 使用工具的准确性;
- 目标: 让 LLM 知道“什么时候用”，而不只是“能做什么”;
- 例子: “搜索相关内容”只是描述功能；“当需要获取实时信息或查找未知事实时使用”才能帮助 LLM 做出调用决策;
为什么要写清边界与反例？
- 例子: 文件搜索工具应明确说明它只能基于文件名匹配、不能搜索文件内容，否则 LLM 会自行猜测;
- 结论: 清晰列出做不到什么、不接受什么输入，往往比描述能力本身更重要;
- 根因: 大多数工具调用失败，不是因为模型不知道工具能做什么，而是不知道工具不能做什么;
参数描述为什么用具体例子代替抽象规范？
- 时间: “
timestamp：RFC3339 格式，例如 2024-03-15T14:30:00Z”比只写“RFC3339 格式”有效得多;
- 电话: “
phone：电话号码，使用 E.164 格式（国家代码+号码，无空格或特殊字符），例如 +8613888888888（中国）或 +12025551234（美国）”;
- 原因: 复杂任务下模型要同时处理多个工具、从历史轨迹提取信息、权衡多个决策，只能分出一小部分注意力确认参数格式，抽象术语容易出错;
- 收益: 具体例子让 Agent 直接套用，无需额外的思考步骤;
返回值与执行代价要交代什么？
- 返回值: “返回 JSON 数组，每个元素包含
title、url、snippet 三个字段”这类说明能减少后续解析出错;
- 耗时: 注明执行代价有助于 LLM 合理规划调用顺序，例如“此工具需要下载完整网页，大型网站可能需要 5-10 秒；如果只需要元信息，请考虑使用
get_page_metadata”;
调用示例为什么能提升准确率？
- 做法: 为每个工具附带 1-5 个真实的调用示例;
- 局限: JSON Schema 只能描述参数类型，无法表达调用方式与典型参数组合——例如时间戳到底是秒还是毫秒、过滤条件如何嵌套;
- 依据: 这些隐式约定靠例子最容易传达;
- 数据: 加入示例后，工具调用的准确率往往明显提升——一些基准上可从约 72% 提升到 90%（具体数值因任务而异）;
频繁选错工具时应优先检查什么？
- 原则: 优先检查工具描述，而不是怀疑模型能力;
- 依据: 大多数工具选择错误的根因在于描述不准确——边界不清、缺少反例、参数含义模糊;
- 收益: 修正工具描述的投入产出比通常远高于更换一个更强的模型;
这些原则是否只适用于专用工具？
- 范围: 同样适用于 Skill——不管工具使用何种表达方式，都需要清晰的描述文档;