直接给结论：模型调不调你的工具、调得对不对，八成取决于工具描述写得好不好，而不是模型聪不聪明。我给 Agent 配过十几个工具，踩坑踩出来一份清单，照着写能少很多"该调不调""调了传错参"的怪事。

下面是我自己的避坑清单，按重要性排：

1. 描述里必须写清"什么时候该调"，而不是只写"这个工具是干嘛的"。 我早期写工具描述全在介绍功能："本工具用于查询订单"。模型经常该调不调。后来我改成"当用户提到订单号、问发货状态、问物流时，调用本工具"，触发率立刻上来。模型是靠描述里的触发场景来匹配的，你不写场景，它就得自己猜。

2. 同时写清"什么时候不该调"。 光写该调的还不够。有个查天气的工具，用户随口说"今天心情像下雨"，模型也去查天气了。我补了一句"仅当用户明确询问某地天气时调用，比喻性表达不调用"，误触发就没了。

3. 参数名要见名知意，别用 a、b、p1。 模型填参靠的就是参数名的字面含义。我见过有人参数叫 param1，模型根本不知道该往里塞啥。改成 city_name、order_id 这种，模型填对率明显高。

4. 每个参数都写格式约束和示例。 比如日期参数，光说"日期"，模型一会儿传"2026年6月"一会儿传"下周一"。我会写明"date：格式 YYYY-MM-DD，如 2026-06-23"，输出立刻规整。约束写进描述比事后清洗划算得多。

5. 必填和选填要标出来。 不标的话，模型经常把选填项也硬填一个值，或者把必填项漏了。我习惯在每个参数后面直接标 (必填) / (选填)。

6. 一个工具只干一件事，别堆功能。 我犯过的最大的错是做一个"万能工具"，又能查又能改又能删，靠一个 action 参数切换。模型经常选错 action。后来拆成三个独立工具，每个职责单一，调用准确率直接起飞。工具多一点没关系，模糊才要命。

7. 枚举值要把可选项列全。 如果某参数只能取固定几个值，就在描述里列出来："status：可选 pending / shipped / done"。不列的话模型会自己发明值，传个 processing 进来，后端直接报错。

8. 描述别太长，但关键信息不能省。 太长的描述会稀释重点，模型抓不住核心。我的经验是触发条件 + 参数说明控制在几行内，把"何时调、传什么、什么格式"说清就停，别写废话。

9. 拿真实问题反复测，描述是磨出来的。 没有一次写对的工具描述。我每次都是先写个初版，拿二三十条真实用户问法跑一遍，看哪些该调没调、哪些传错参，再回去改描述。这个循环我一般要转三四轮才稳。

10. 多个工具之间，触发条件别重叠。 如果"查订单"和"查物流"的描述写得模棱两可，模型会在两个工具之间反复横跳，甚至两个都调。边界划清楚，各管各的场景。

我现在用的是个零代码就能挂工具配 Agent 的平台，工具描述就是个文本框，上面这些规则全在这个文本框里落地，改完即时生效，调起来挺快。

要说麻烦的地方，主要是第 9 条——测评用例得自己一条条攒，没人替你攒。前期会觉得繁琐，但这是唯一能让工具调用稳定的办法，省不了。

底层模型我走的讯飞星辰 MaaS，现成大模型 API 直接调，没自建算力那套负担。