两个工具描述相似时，模型无法可靠区分——重叠对之间 40% 误路由。修复：扩展描述，瞄准具体被混淆的工具对，用分层方法（描述解决 88%，few-shot 例子解决剩余 12% 的边缘情况）。
误路由数据模式
6 个工具，1,000 次调用：
get_customer↔get_account：25% 互相误路由search_orders↔search_transactions：18% 互相误路由process_refund：2%（可接受）update_address：1%（可接受）
描述改进聚焦在两个高误路由对上。process_refund 和 update_address 已经有清晰有效的描述——不要在它们上面浪费精力。
扩展描述：模板
每个描述应该针对三种误路由类型：
- 重叠（工具被互相混淆）：区分用途、输入类型、返回格式
- 范围（工具被用于它做不了的事）：边界条件加”不用于” + 重定向
- 顺序（工具被以错误顺序调用）：相对其他工具的使用时机提示
模板：“用途：[做什么]。输入：[格式]。返回：[什么]。用于：[具体场景]。不用于：[常见混淆]——用 [替代] 代替。在 [前置工具] 之后使用可获得丰富数据。“
名称 + 描述一起改
只改名不够。一个叫 csv_parser 但描述是”Processes data”的工具还是模糊的。模型主要用描述来选择，不是名称。好名字提供快速信号；好描述提供选择关键的细节。两个都应该一起改进。
分层方法：描述 + few-shot
描述扩展后：
- 之前：60% 准确率
- 描述改进后：88% 准确率
- 剩余 12%：工具确实有真实重叠的合理边缘情况
对于剩余 12%，在 system prompt 中加 few-shot 例子，示范模糊查询下的正确工具选择。描述定义”每个工具做什么”（解决 88%）。例子展示”工具重叠时怎么决定”（解决剩余 12%）。
可扩展性：15+ 工具保持高准确率
15 个工具只有 70% 准确率。研究表明选择准确率随工具数增加而下降。
修复：扩展描述同时把工具分布到专门的子代理中。每个子代理有 4-5 个和角色相关的工具。协调者选对子代理（更少选项，更容易），然后子代理在聚焦的工具集中选择（每个 agent 高准确率）。工具总数还是 15+，但没有单个 agent 面对全部 15 个选项。
什么时候拆 vs 什么时候改描述
如果两个工具确实做同样的事只有细微差别，考虑合并成一个工具加参数。更少但用途清晰的工具比很多描述重叠的工具路由更好。
如果两个工具用途不同但模糊描述没揭示出来，扩展描述来区分。工具本身是不同的——描述只需要把这点讲清楚。
一句话总结： 瞄准具体高误路由对做描述修复（数据驱动），用模板（用途、I/O、“不用于” + 重定向、顺序提示），描述（88% 修复）加 few-shot 例子（12% 边缘情况）分层——15+ 工具时分布到各有 4-5 个聚焦工具的子代理中。