工具描述是怎么影响选择的？内部门道在这

招聘看简历，智能体挑工具看描述。同一批工具，描述含糊就总被选错，写清楚了就一次选对——一段介绍就是工具的简历，这篇把简历的写法讲透，你就懂了工具描述定成败。

模型挑工具，靠的是一段介绍

决定用哪个工具的时刻，模型手里只有两样东西：用户的请求和每份工具描述。它不会去读工具的实现代码，也不知道工具上次干得如何——描述就是全部依据。所以描述里每句话都在替工具拉票：我做什么、适合什么场合、输入输出长什么样、什么情况下不该用我。票拉得含糊，选择就只能靠蒙，错选也就不奇怪了。

一段好描述里写了什么

四样东西缺一不可：能力边界，明确说清能做什么、不能做什么；参数说明，每个参数什么含义、什么格式、必填还是选填，带一两个例子更佳；适用场景，比如「适合按日期查订单，不适合模糊搜索」；差异说明，当多个工具功能相近时，讲清彼此的分界线。另外，参数说明里应提醒哪些字段不能放敏感信息，密钥类内容走专用通道，见密钥是怎么注入调用的。扣子的插件市场里，描述写得好的插件明显更容易被正确调用；ModelScope 的工具文档也是同一路数。

四样东西各自要写到什么程度，可以对着看：

描述含糊时的典型乱象

两个工具描述写得太像，模型轮着错选；描述漏了限制条件，模型把不合适的请求硬塞过去，返回一串报错；参数格式没写清，模型自由发挥填出五花八门的输入。这些乱象的共同根子在描述，工具本身往往没问题。排查时先读描述再怀疑工具，顺序别颠倒——这条经验能省下大量调试时间。

改一句描述，选错率就降了

改进要从实际错例出发：把选错的案例收集起来，找出模型当时误解了什么，在描述里补一句针对性的说明。比如模型总把「查天气」请求发给「查地理信息」的工具，就在后者描述里写明「不含实时天气」。改完用同一批错例回归验证，选对了才算改好。错误信息是怎么反馈给模型的的机制会把新错例持续送回来，描述因此要跟着迭代，写描述并非一劳永逸。

描述自查清单：能力与限制是否写明；参数格式是否举例；相近工具是否写了分界线；近期错例是否已回流到描述里。四项齐全，工具才算自我介绍到位。

还有一点常被忽略：描述本身也占上下文空间，挂载几十个工具，光说明书就挤掉一大块，所以精简工具数量与写好描述同样重要；实在占满了就靠上下文清理是怎么做的来腾地方。少而准，好过多而杂。

描述语言风格的三个细节

写描述有两个极端都要避免：太抽象，全是「高效、灵活、强大」这类形容词，模型读不出任何区分度；太啰嗦，把实现原理写成论文，关键信息反被淹没。中间的路数是动词开头、场景收尾：先说能做什么动作，再说什么时候该选我，例子点到即止。措辞要避开否定堆叠，连说三遍「不是查天气的」，不如直接一句「仅用于地理信息查询」。术语要与用户请求的说法对齐：用户说「截图」，描述里就别只写「页面快照」，两个说法都写上，命中率立刻不同。判断：描述是写给下一个读者看的，那个读者是模型。

工具描述快问快答三则

• 描述写多长合适？：信息量优先于长度，边界、参数、场景、差异四要素齐了即可，废话一句都嫌多。
• 描述需要随模型换代更新吗？：需要，不同代次的模型对同一句话的理解可能有偏差，换代后跑一轮错例回归最稳。
• 能给工具描述加示例吗？：加，输入输出的对比例子最能纠正误解，比抽象形容词管用得多。