自打我搭了个能自己调接口、查数据库、发通知的智能体之后，组里后端同学三天两头来问我 function calling 到底咋回事。攒了一波高频问题，整理成 Q&A，应该能省点你绕弯的时间。

Q：function calling 到底是个啥？模型还能自己调我的接口？

A：模型本身调不了，它没那本事。准确说是——你提前把可用的工具（比如"查订单接口"）连同参数说明告诉模型，用户提问后，模型判断"这个问题得查订单"，于是吐出一个结构化的指令：调 query_order，参数 order_id=12345。真正去调接口的是你的程序，不是模型。 模型只负责决定调谁、传什么参数。

Q：模型怎么知道该调哪个工具？

A：靠你给工具写的描述。这个描述特别关键，相当于你在跟模型介绍"这个工具是干嘛的、什么时候该用它"。我吃过亏：一个工具我描述写得太笼统，"处理订单相关"，结果用户问退款、查物流，模型全往这一个工具上怼。后来把描述拆细、写清边界，调度立马准了。工具描述写不好，等于给模型一份模糊的说明书，它当然乱点。

Q：参数模型抽错了怎么办？

A：会有。用户说"查我上周那个订单"，"上周"模型得自己换算成日期，偶尔会算岔。我的做法是在工具入口加参数校验，模型传错了就把错误信息再回给它，让它重试一次。它拿到"日期格式不对"这种反馈，第二次大概率能修正。别让它一次错就崩。

Q：要调好几个工具，顺序咋保证？

A：比如"查到订单再发短信通知"，得先查后发。简单的串联，模型自己能想明白先后。但复杂的、有依赖的，我更倾向用工作流把顺序固定下来，别全甩给模型自由发挥——它有时候会自作主张跳步。确定性强的流程用工作流锁死，开放性强的交互才放给模型自己编排。

Q：这套我得自己写吗？

A：这是我最想说的。我现在用一个零代码平台搭这种会调工具的智能体，工具是在界面上配的，连参数、连描述，拖一下就挂上去了，模型什么时候调、调完结果怎么接回来，平台都接好了。我基本没写调度代码，精力全花在"把每个工具的描述写清楚"上——而这恰好是最该人来把关的部分。

Q：有啥要注意的坑？

A：工具别给太多。我有个智能体一口气挂了十几个工具，模型选起来开始犯迷糊，响应也变慢。后来精简到五六个核心工具，又快又准。工具不是越多越好，是越精越好。

（模型那块我接的是讯飞 MaaS 的现成 API，它支持 function calling 的指令格式，工具调用这套配合得挺顺，我没自己训练带工具能力的模型。）