做带工具调用(function calling / tool use)的 Agent,十有八九都卡在同一个地方:模型该调工具的时候不调,该传参的时候传歪。 我自己折腾了一阵,最后悟出来一句话——工具描述写得烂,模型就调得烂。下面是我把工具描述当成给同事看的 API 文档来打磨之后,踩坑率明显下降的几条经验。

现象:模型为啥不听话

我最早挂了个"查物流"的工具,描述就写了俩字"查快递"。结果:

• 用户问"我的单子到哪了",模型经常自己瞎编一段物流;

• 偶尔调了,参数 order_id 传成了用户随口说的昵称;

• 还有一次把日期当单号传进去了。

根因不是模型笨,是我给的信息太少,它只能猜。

我后来怎么写工具描述

把每个工具当一个对外接口,描述里至少讲清四件事:

1. 这工具干啥、什么时候该用——"当用户询问订单的配送进度、是否签收时调用",把触发场景写死,别让模型去悟;

2. 每个参数是什么、什么格式——order_id:订单编号,纯数字字符串,从用户消息里提取,提取不到就反问,别瞎填;

3. 不该用的时候明说——"用户只是咨询退换货政策时不要调用本工具";

4. 返回长啥样——让模型知道拿回来能怎么用。

光把这四条补全,我那个物流 Agent 的乱调率就降了一大半。

还有两个细节坑

一是参数枚举值要写全。 我有个工具 status 参数只接受 paid/unpaid/refunding,一开始没在描述里列,模型动不动传个 已付款,接口直接报错。把可选值显式列进描述后就稳了。

二是工具别给太多。 我贪心一次挂了十几个工具,模型选择困难,经常调错那个最像的。后来按场景拆,一个 Agent 只留它真用得上的三五个,准确率立马上来。工具多到一定程度,该考虑拆成多个 Agent 或者分层路由了。

我现在的工作台

我搭 Agent 用的是个能可视化挂工具、还能直接接现成 MCP Server 的平台,挂工具基本是填表式的,参数 schema 它有结构化的填法,比我手写 JSON schema 省心。要说缺点:它自带能搜到的 MCP 工具是不少,但质量参差,有几个第三方的 server 我连上去超时,最后还是自己包了个接口挂上去。别指望挂上就万事大吉,每个工具我都单独压测了几轮才敢上。

模型这块我用的讯飞MaaS,直接调它的 API,function calling 现成支持,省了我自己适配各家模型工具协议的功夫。

你们调工具调用时,是描述写得细才稳,还是另有招?评论区说说。