问模型「北京现在多少度」，它只会抱歉地说自己连不了网——因为模型天生只会「说」，不会「做」。要让它真正查天气、读数据库、发邮件，靠的就是 Function Calling（函数调用）。上一篇聊 MCP 时提过它的身影，这篇把它本身的原理一次讲透。
Function Calling 是什么？给 AI 配一个「对讲机」
你可以把模型想象成一个很聪明、但被关在房间里的顾问：它只能隔窗喊话。Function Calling 就是在墙上装一部对讲机——你先告诉它「有哪几部设备可以用」（工具定义），它遇到需要动手的问题时，不会瞎编答案，而是通过对讲机喊一句「帮我调天气查询，参数是北京」。真正去执行代码的是你的程序，模型只负责「决定调什么、填什么参数」。
一次完整调用，其实就五步
整个流程像点外卖：用户下单 → 平台派单 → 商家做好 → 骑手送回 → 用户收货。对应到技术上：
- 声明工具：在请求的 tools 字段里列出工具名、用途描述和参数表，随消息一起发给模型
- 模型决策：模型判断这个问题需不需要用工具；需要的话不直接回答，而是返回一个 tool_calls，带上工具名和 JSON 参数
- 你的代码执行：程序解析参数，真实调用天气 API、数据库或任何本地函数，拿到结果
- 结果回填：把执行结果以 role=tool 消息追加回对话，再请求模型续写
- 组织回答：模型把生硬的接口数据翻译成一句人话——「北京今天 22℃，晴，适合出门」
整个过程模型可以连续多轮调用多个工具，比如先查日历、再查天气、最后帮你拟一份出行提醒——这就是 Agent 的雏形。
工具定义写得好不好，决定成功率
模型选工具全靠读你的「说明书」。说明书含糊，它就会拿错零件。三个写法要点：
- 名字见名知义：get_weather 远好于 func_1；描述里写清「什么时候该用我」，比如「查询指定城市未来 3 天的天气」
- 参数逐个标注：每个参数都要有类型和说明，必填的标 required，枚举值直接列出来，别让模型猜
- 结果要友好：回填的执行结果尽量精简、带单位，模型翻译起来才不容易跑偏
一个容易踩的认知坑：模型永远不会真的执行你的函数。它只是「点菜」，做菜和上菜始终是你的代码的事——所以参数校验、异常处理、超时控制都得自己做。
常见问题
哪些模型支持 Function Calling？
主流对话模型基本都支持，比如 glm-5.3、kimi-k3、deepseek-v4-flash 等。在模型列表里挑一个，把请求发到 https://api.aigcbreeze.cn/v1/chat/completions，加上 tools 字段即可，用法与 OpenAI 接口兼容。
它和 MCP 是什么关系？
Function Calling 是模型 API 层面的基础能力——「一次调用怎么走」；MCP 则是在它之上的一套标准协议，解决「工具从哪来、怎么统一接入」的问题。很多 MCP 客户端底层正是把 MCP 工具翻译成 Function Calling 再喂给模型。
模型总是乱填参数怎么办？
三个办法：把参数说明写得更具体并在描述里给例子；收窄参数类型，能用枚举就别用自由文本；代码侧加一层校验，不合法就带着错误信息回填给模型，让它自己修正后再试一次。