工具调用老是参数不对?我把工具描述当 API 文档来写就好了

做带工具调用(function calling / tool use)的 Agent,十有八九都卡在同一个地方:模型该调工具的时候不调,该传参的时候传歪。我自己折腾了一阵,最后悟出来一句话——工具描述写得烂,模型就调得烂。下面是我把工具描述当成给同事看的 API 文档来打磨之后,踩坑率明显下降的几条经验。现象:模型为啥不听话我最早挂了个查物流的工具,描述就写了俩字查快递。结果:用户问我的单子到哪了,模型经常自己瞎编一段物流;偶尔调了,参数order_id传成了用户随口说的昵称;还有一次把日期当单号传进去了。根因不是模型笨,是我给的信息太少,它只能猜。我后来怎么写工具描述把每个工具当一个对外接口,描述里至少讲清四件事:这工具干啥、什么时候该用——当用户询问订单的配送进度、是否签收时调用,把触发场景写死,别让模型去悟;每个参数是什么、什么格式——order_id:订单编号,纯数字字符串,从用户消息里提取,提取不到就反问,别瞎填;不该用的时候明说——用户只是咨询退换货政策时不要调用本工具;返回长啥样——让模型知道拿回来能怎么用。光把这四条补全,我那个物流 Agent 的乱调率就降了一大半。还有两个细节坑一是参数枚举值要写全。我有个工具status参数只接受paid/unpaid/refunding,一开始没在描述里列,模型动不动传个已付款,接口直接报错。把可选值显式列进描述后就稳了。二是工具别给太多。我贪心一次挂了十几个工具,模型选择困难,经常调错那个最像的。后来按场景拆,一个 Agent 只留它真用得上的三五个,准确率立马上来。工具多到一定程度,该考虑拆成多个 Agent 或者分层路由了。我现在的工作台我搭 Agent 用的是个能可视化挂工具、还能直接接现成 MCP Server 的平台,挂工具基本是填表式的,参数 schema 它有结构化的填法,比我手写 JSON schema 省心。要说缺点:它自带能搜到的 MCP 工具是不少,但质量参差,有几个第三方的 server 我连上去超时,最后还是自己包了个接口挂上去。别指望挂上就万事大吉,每个工具我都单独压测了几轮才敢上。模型这块我用的讯飞MaaS,直接调它的 API,function calling 现成支持,省了我自己适配各家模型工具协议的功夫。你们调工具调用时,是描述写得细才稳,还是另有招?评论区说说。