给八个工具写描述，每个贴了三百多字的产品说明，上线后模型频繁把查询订单调成查询物流，把描述压到两行并补一句使用边界后准确率从 61% 回到 94%。
一开始怀疑是「描述里带示例参数，模型误以为是固定值」，查了一圈，方向不对。
把日志和配置对完，能解释这个现象的基本就这几处。描述里混入业务背景，关键差异被淹没。另一种情况是多个工具描述用词高度相似，模型无法区分。
不容易想到的是，工具数量多，描述总长挤占了上下文预算。
上来先统计每个工具描述的字符数与总 token
python -c "import json,tiktoken;e=tiktoken.get_encoding('cl100k_base');ts=json.load(open('tools.json'));print(sum(len(e.encode(t['function']['description'])) for t in ts))"接着按「做什么、什么时候用、不要用什么」三段重写
python rewrite_desc.py --src tools.json --max-chars 120 --out tools_v2.json再往下用一批历史问题做工具选择回归
python eval_tools.py --cases cases.jsonl --tools tools_v2.json等前面都确认过，再把仍有歧义的两条描述再拉开措辞
python diff_desc.py --tools tools_v2.json --pair order,logistics恢复的判定其实很直接。回归集上工具选择准确率到 94%，同一问题的选择在三次运行里保持一致，描述总 token 下降六成。
这里还有个坑。描述是给模型看的路由规则，不是产品文档，写清边界比写全功能更有用，越长的描述越容易被忽略。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。