72 比 12。同样 4 个任务，工具列表从 26 个砍到 6 个，agent 找对工具要做的路由试探从 72 次掉到 12 次。数据来自对照实验（脚本 tools/verify-tool-list-route.py，桩模型固定输出序列驱动），先摆表，后解释。
对照数据
抽稀前: 工具 26 个，4 个任务路由试探合计 72 次
抽稀后: 工具 6 个，4 个任务路由试探合计 12 次
单工具位置对照（按字母序的下标 + 1 = 最少试探次数）:
bash 全表第 1 位 → 抽稀表第 1 位
grep 全表第 22 位 → 抽稀表第 2 位
read_file 全表第 24 位 → 抽稀表第 4 位
write_file 全表第 26 位 → 抽稀表第 6 位
spell_fix 全表第 25 位 → 抽稀表第 5 位
list_thin 全表第 23 位 → 抽稀表第 3 位
C(26,6) = 230230 种抽稀组合，比 6 个工具全排列 720 种还多
怎么读
72 次和 12 次的比值是 6，恰好等于工具数之比（26 对 6 大约 4.3 倍，但试探次数的分布是线性的：每次试探固定消耗一次调用，命中率取决于目标工具在列表里的位置）。抽稀表里 6 个工具都是高频工具，平均位置 3.5，全量表里它们的位置平均 16.8。位置差 4.8 倍，试探次数差 6 倍，两者对得上。
位置对照那一块里最有意思的是 bash：全表第 1 位，抽稀表还是第 1 位。它没从抽稀里得到任何位置收益，这提示抽稀的收益不是均匀的，本来就在头部的工具几乎不变，尾部的高频工具才是最大赢家。write_file 从第 26 位提到第 6 位，试探次数直接砍到不足四分之一。
最后一行是给做工具设计的人看的：230230 种抽稀组合远超 720 种排列。想靠穷举找最优工具子集是不现实的，只能按调用频次和任务类型手工分表，或者按场景动态挂载。
这个实验的边界
桩模型是写死的序列：每个任务按「读一遍列表、猜一个工具，错了就重试」的固定策略推进，不调用任何真实模型。所以 72 和 12 这两个绝对值没有意义，有意义的是比值背后的机制：列表越长，头部位置的稀缺性越贵，目标工具的期望试探次数越大。真实 LLM 的路由策略比固定试探聪明，也可能被工具描述的措辞带偏到固定策略到不了的地方，这些都没实测。
现在的做法
不猜模型怎么选工具，直接控制变量：会话里只挂当前任务需要的 6 个以内工具，其余的按需再挂。这个做法在两类场景里有明显收益，多轮循环类任务（试探次数按轮数倍增）和上下文紧张的长会话（工具列表本身也占 token）。工具描述写得再好，也架不住列表里有 20 个「可能相关」的邻居在分散注意力。
