LangChain 里注册了 20 个工具，描述都在 300 字以上，模型总调 search_docs 而不是 search_ticket，把描述压到 1024 字符以内后反而更差。
一开始怀疑是「没有写适用场景和不适用场景」，查了一圈，方向不对。
排查方向其实有限，先把可能性排一排。描述过长被截断，关键限定词刚好在尾部。还有一种是多个工具的描述高度重叠，模型分不清边界。
不容易想到的是，参数 description 为空，模型只能猜。
先统计每个工具 schema 的长度
python -c "import json;t=json.load(open('tools.json'));print([(x['name'],len(x['description'])) for x in t])"再往下把描述压到 300 字符并写清触发条件
python -c "print('when: 工单号查询; not for: 文档检索')"给每个参数补上 description
python -c "print({'query':{'type':'string','description':'工单号或关键词'}})"末了跑一轮离线工具选择评测
python eval_tools.py --cases 200 --top1排查用的命令都是临时敲的，没有写成脚本，事后才整理。
改完先别撤，确认这几项。工具选择 top1 准确率从 54% 升到 91%，search_docs 的误调用从 38 次降到 4 次，参数校验失败归零。
容易忽略的是，工具描述是提示词的一部分，短而具体比长而全有效，先写边界再写功能。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。