做带工具调用(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 现成支持,省了我自己适配各家模型工具协议的功夫。
你们调工具调用时,是描述写得细才稳,还是另有招?评论区说说。
