给智能体配备工具:函数调用基础

函数调用(Function Calling)让智能体从"只会说话"变成"能干活",是智能体落地生产环境的关键能力。

大语言模型本身只能生成文本,无法查询数据库、调用API或操作文件。函数调用机制让模型能够"决定调用哪个函数、传什么参数",由外部代码执行后再把结果喂回模型。这套机制是智能体操作真实世界的基础。

函数调用的基本流程

一次完整的函数调用包含四个步骤:

定义工具:开发者用JSON Schema描述可用函数的名称、参数和用途。
模型决策:模型根据用户意图,判断是否需要调用工具,以及调用哪个、传什么参数。
执行函数:开发者代码接收模型输出的函数名和参数,实际执行(查数据库、调API等)。
结果回传:将执行结果以特定格式返回给模型,模型基于结果生成最终回复。

整个过程中,模型本身不执行任何代码,它只负责"决策"。真正的执行权在开发者手中,这也是函数调用安全可控的原因。

工具定义的规范写法

大多数主流模型API采用类似的工具定义格式。以"查询天气"为例:

{
  "name": "get_weather",
  "description": "查询指定城市的实时天气信息",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "城市名称,如'北京'、'上海'"
      },
      "unit": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "温度单位,默认摄氏度"
      }
    },
    "required": ["city"]
  }
}

几个要点:

description 是写给模型看的,务必写清楚函数做什么、什么时候该用。模型靠这段文字决定是否调用。
参数的 description 同样重要,模型据此填充参数值。描述越准确,参数填错的概率越低。
required 字段明确哪些参数必须有值,可选参数不要放进去。
enum 限定取值范围,适合枚举类型的参数,能有效减少模型的"创造性填写"。

工具数量的权衡

给智能体配备工具时,工具数量并非越多越好。实践中的经验值:

工具数量	效果	适用场景
1-5个	调用准确率高,模型选择困难少	单一功能智能体
6-15个	需要清晰的描述区分,偶有误调用	中等复杂度工作流
15个以上	误调用率明显上升,需要分组或路由	复杂平台型智能体

当工具超过15个时,建议引入"工具路由"机制:先用一个轻量模型判断用户意图属于哪个类别,再只加载该类别的工具列表给主模型。

常见的工具类型

构建智能体时,以下几类工具覆盖了大部分需求:

信息获取类:搜索、查询数据库、读取文件、获取天气/汇率等外部数据。
内容生成类:调用TTS生成语音、调用图片API生成图片、发送邮件/消息。
状态操作类:更新数据库记录、修改文件、创建任务、设置提醒。
分析计算类:执行代码、运行统计模型、数据清洗。

信息获取类工具风险最低,适合作为第一批上线的工具。状态操作类工具涉及数据修改,需要加入确认机制。

参数校验与错误处理

模型输出的参数并非总是正确的。开发者代码中必须做参数校验:

类型检查:确保字符串就是字符串,数字就是数字。
值域检查:日期是否合理?ID是否存在于数据库中?
权限检查:当前用户是否有权限执行这个操作?

执行失败时,错误信息要"对模型友好"。不要返回堆栈trace,而是返回结构化的错误提示,比如:

{
  "error": "city_not_found",
  "message": "未找到城市'火星',请输入有效的城市名称"
}

模型读到这样的错误信息后,通常能自动向用户解释问题并建议正确做法。

从单工具到多工具编排

当智能体需要连续调用多个工具时,就进入了"多步工具调用"的范畴。比如用户问"帮我查北京明天的天气,然后发邮件提醒我带伞",智能体需要先调天气查询,拿到结果后再调发邮件工具。

这种场景下,系统提示词中需要明确告知智能体可以按顺序调用多个工具,以及工具之间的依赖关系。大多数现代模型支持在单次对话中多次往返调用工具,开发者只需把每一轮的工具结果正确回传即可。

函数调用是智能体从"聊天机器人"升级为"工作助手"的分水岭。掌握工具定义规范、做好参数校验和错误处理,就能让智能体安全地操作真实系统。