★ FEATURED ARTICLE 上一篇《给 Agent 挂了 47 个工具后它连周报都不会写了》发出来之后评论区问得最多的是同一个问题 工具我也收敛了为什么它还是选错答案往往不在工具数量在工具的 description。这篇就把这块单独拎出来讲透。先给结论大部分人选错工具不是模型笨是你写的描述根本没告诉它什么时候该用我。---一、先看一个反例改版前我的文本处理工具描述是这么写的yamlname: text_processdescription: 强大的智能文本处理工具支持多种文本操作一键满足各类文本需求。你品品这句话。它告诉了模型什么能处理文本 ✅具体处理什么没说什么时候用没说和别的文本工具什么关系没说这本质是一句广告文案不是接口文档。模型拿到它只能靠工具名字去猜。而我当时挂了 6 个文本类工具——6 个都靠猜选对率能高才怪。---二、5 个反例对号入座我把改版前踩过的坑整理成 5 条你对照自己的工具定义看中了几条。反例 1只写能做什么不写什么时候用❌ 支持文本改写、翻译、摘要、分类✅ 用于【改写已有文本】。用户已提供原文、要求润色/精简/换语气时使用。差别在哪前者是能力清单后者是触发条件。模型需要的是后者。反例 2不写什么时候别用我这是最容易被忽略、也最省心的一条。❌ 只写适用场景✅ 加上 ❌ 不适用从零生成内容 → 用 text_generate跨语言 → 用 text_translate为什么要写排除条件因为模型面对多个候选工具时排除法比优选法更可靠。不要选它是一条明确指令选它只是一个建议。反例 3工具之间没有边界❌ text_rewrite改写文本 / text_optimize优化文本这两个描述在语义上几乎重合模型只能掷骰子。✅ 明确切分text_rewrite保持原意改语气/长度/风格text_optimize允许改意为特定目标如 SEO做内容增强一句话原则两个工具如果不能用一句话说清区别就该合并。反例 4参数描述写业务黑话❌ type: string, 描述类型✅ type: enum[rewrite,compress,tone], 描述改写类型。rewrite保持原意重写compress压缩到指定字数tone调整语气参数是模型填的。你写类型它就只能瞎填。反例 5没有示例❌ 纯 schema 描述✅ 附一个输入输出示例对复杂参数一个例子胜过三行说明。这也是为什么很多协议规范都建议在描述里带 example。---三、可复制的模板把上面 5 条合并就是我现在每个工具都在用的模板yamlname: 动词_名词description: |一句话说清做什么。✅ 适用触发条件越具体越好❌ 不适用排除条件 → 改用 替代工具边界与最相近工具的区别输入参数含义枚举值逐个解释输出返回结构示例一组输入输出47 个工具全部按这个模板重写一遍工作量不小但这是一次性投入收益是持续的。---四、效果与代价改完之后最直观的变化是那 6 个文本工具不再打架了。但要说代价也得说清楚描述越详细占用的上下文越多。一个工具描述从 30 Token 涨到 200 Token47 个工具就是 8000 Token 的额外开销。所以这套写法必须配合上一篇讲的渐进式加载用——入口层只放高频工具描述可以写厚仓库层的工具schema 按需注入。否则你解决了混淆又制造了膨胀。这两件事是一体的拆开做都会翻车。---五、小结工具选择这件事可以拆成三个层次1.数量层控制在 15 个以内入口可见的2.描述层写触发条件、排除条件、边界不写广告词3.加载层非高频工具按需注入别全量倾倒三层里描述层的性价比很高——不用改架构改几行字就能见效。下次 Agent 再选错工具先别急着换模型。打开你的工具定义读一遍那句 description——你自己看完知道什么时候该用它吗---*本文为「AI实战系列」第 2 篇。第 1 篇《给 Agent 挂了 47 个工具后它连周报都不会写了》。*
阅读完成 · 觉得有帮助？
