跳到正文

Function Calling:模型怎么学会「调工具」

工具 schema、模型出参、你来执行、回灌结果 —— Agent 岗高频考点

一句话:Function Calling 是「让只会输出文字的模型,变得能驱动真实世界」的关键一跃。Agent 岗高频考点,也是后面手写 Agent 的地基。 核心误区先纠正:模型并不执行工具 很多人以为「Function Calling = 模型自己去调用了函数」。不是。 模型只做一件事:根据你给的工具说明,决定要不要调、调哪个、传什么参数,然后吐出一个结构化的调用请求。真正执行的,永远是你的代码。 这个分工很重要,面试常考:模型负责「决策」,你负责「执行」,再把结果喂回去让它「继续决策」。 三步走 ① 把函数描述成「工具 schema」 模型看不到你的代码,只能看到一段 JSON 描述。description 写得好不好,直接决定模型调得准不准: ② 模型返回「要调用的请求」 把 tools 一起发给模型,如果它决定调用,返回的 message.tool calls 里就有函数名和参数(JSON 字符串): ③ 你执行,再把结果回灌 「调用 → 执行 → 回灌 → 再调用」这个循环重复起来,就是 Agent(见第 7 篇)。 训练数据怎么造(面试加分点) 面试官常追问「Function Calling 的数据怎么来」。标准做法: 准备工具集和真实/构造的用户问题; 标注「该问题应触发哪个工具、什么参数」的正样本; 配难负例:语义相近但不该调工具的问题(避免模型见啥都调),以及该调却调错工具/错参数的对比样本; 覆盖「需要多步调用」「参数要从上下文里抽」等复杂情形。 常见坑 description 太含糊:模型不知道何时该调 → 漏调或乱调。把触发条件写进描述。 不处理「模型不调工具」的情况:它可能直接回答,tool calls 为空,要判空。 参数没校验就执行:模型给的参数可能不合法,执行前做 schema 校验 + 兜底。 多工具时不按名字分发:tools 里多个函数时,要按 call.function.name 路由到对应实现。 关联面试题 「Function Calling 在 Agent 里是怎么落地的?数据怎么构造?」 「怎么避免模型该调工具时不调、不该调时乱调?」 👉 去 题库 搜 Function Calling / 工具调用 / Agent。 训练营延伸 训练营会把 Function Calling 延伸为「业务 → 数据 → 训练 → 评估」练习。只有亲自完成、能说明评测方法并留有证据的部分,才适合写进个人简历。