让SLM学会调用工具：函数调用能力实现

可视化演示

动态展示2PC协议的Prepare和Commit两阶段执行流程，呈现协调者与参与者之间的投票与提交消息交互机制。

函数调用概述

餐厅里新来的服务员小张，口才极好，客人说“来碗牛肉面，不要辣”，他能一字不差地复述，然后站在原地。客人等了半小时，面没来。问题出在哪？小张只会“说话”，不会“下单”——他没有把需求写成一张标准订单送到后厨。对 SLM 来说，函数调用就是“下单”这项技能。没有这项技能，模型再能聊，也改变不了现实世界的一分一毫。

纯文本聊天就像复述，能理解却无法行动。要让 SLM 成为真正的 Agent（智能体），它必须学会输出一种结构化指令，也就是函数调用：一个函数名加一组参数。例如用户问“北京天气怎么样”，模型输出 get_weather("北京")，系统便调用真实天气 API 拿回数据。这样一来，模型的能力就从“嘴甜”升级为“手勤”，从聊天机器人变成能办事的助手。

那么，函数调用在数学上是什么？本质上是一个条件概率问题：给定用户请求 $x$ 和当前可用的函数列表 $F$，模型选择调用第 $i$ 个函数的概率：

$$\displaystyle P(f_i \mid x, F)$$

这个概率越大，说明模型越擅长“在合适的时机点合适的菜”。训练函数调用能力，就是要最大化这个概率——让模型在“该点菜”时准确报出菜名和口味，在“不用点菜”时安静地陪聊。

1. 条件概率符号：$P(f_i \mid x, F)$ 表示在“用户请求为 $x$、函数列表为 $F$”这两个条件下，模型认为应该调用第 $i$ 个函数的概率。

$$\displaystyle P(f_i \mid x, F)$$

2. 用户请求：$x$ 是用户输入的自然语言，比如“帮我查一下北京的天气”，相当于客人说的话。

$$x = \text{用户自然语言输入}$$

3. 函数列表：$F$ 是所有可用工具的集合，相当于餐厅的菜单，列出了后厨能做的所有菜。

$$F = \{f_1, f_2, \dots, f_n\}$$

4. 选择含义：$f_i$ 是第 $i$ 个函数，$P$ 值最高的那个函数就是模型准备“下单”的目标。

$$f_i = \text{待调用的第 } i \text{ 个函数}$$

就像新服务员上岗必须先认识后厨有哪些灶台、能做什么菜，SLM 也要先“知道”有哪些工具、各自负责什么。认识工具、理解需求、生成标准订单，这就是函数调用能力的三板斧。接下来我们逐个拆解，先从最重要的“菜单”讲起。

函数描述格式

小张上岗第一天，老板丢给他一本厚厚的菜单。如果菜单上只写“菜一”“菜二”，不写口味、不写食材，小张永远不知道“菜一”是红烧肉还是青菜豆腐。菜单必须写明：菜名、做法、用什么料。函数的“菜单”也是同理——模型只能根据你给它的描述来理解每个工具是干什么的。

在工程实践中，我们通常用 JSON Schema 来写这份“菜单”。每个函数包含三要素：函数名 name、用途描述 description、参数定义 parameters。比如 get_weather 的 description 写“查询指定城市的实时天气”，模型看到“北京天气怎么样”，自然就联想到它；而 set_alarm 的描述写“设定某个时间的提醒闹钟”，模型听到“明早 7 点叫我”就会找到它。

形式上，整个函数列表是一个结构化集合，每个函数又是一个包含名字、描述和参数的三元组：

$$\displaystyle F = \{f_1, f_2, \dots, f_n\},\qquad f_i = (\mathrm{name}_i,\ \mathrm{desc}_i,\ \mathrm{params}_i)$$

其中 $\mathrm{params}_i$ 内部还要用 JSON Schema 定义每个参数的类型、是否必填、取值范围。写 description 时要用“模型的话”：写清楚触发场景和输入含义，少用“等等”“之类”这种模糊词，否则模型会在两个相似工具之间摇摆，就像客人说“来份荤菜”，服务员不知道是点红烧肉还是点烤鸭。

1. 函数集合：$F$ 是所有可用工具的清单，集合里装着 $n$ 个函数，相当于餐厅里可供点选的 $n$ 道菜。

$$\displaystyle F = \{f_1, f_2, \dots, f_n\}$$

2. 单个函数：$f_i$ 是第 $i$ 个工具，每个工具对应一段可执行的真实代码，就像一道菜对应一个灶台流程。

$$f_i = \text{第 } i \text{ 个可调用工具}$$

3. 函数名：$\mathrm{name}_i$ 是函数名，模型生成的调用里必须用它来指路，相当于点菜单上的菜名编号。

$$\mathrm{name}_i = \text{函数唯一标识符}$$

4. 描述与参数：$\mathrm{desc}_i$ 说明工具的使用场景，$\mathrm{params}_i$ 用 JSON Schema 约束参数类型与必填项。

$$\mathrm{params}_i = \text{JSON Schema 参数定义}$$

一份好菜单，是服务员准确点单的前提；一份好的函数描述，是模型准确调用的前提。菜单写得好，前台和后厨都省心。写完菜单，下一步就是教模型读懂客人的话、写出标准订单——这就是调用解析逻辑要解决的问题。

调用解析逻辑

小张记性不错，但习惯用自己发明的“密语”记单：“那碗面，那个啥，辣的不要，加个蛋。”后厨看了直翻白眼。于是餐厅规定：所有订单必须写成统一格式——菜名、辣度、数量，逐项填写。对模型输出也是如此：如果模型随意发挥，系统就没法稳定地执行。所以我们要训练模型输出一种“标准订单”，再用解析器去读懂它。

SLM 输出的是一段文本，比如 <tool_call>{"name":"get_weather","arguments":{"city":"北京"}}</tool_call>。解析器要做的，就像收银员核对订单：先定位 <tool_call> 标签包围的区域，再从中抽取函数名和参数对象，最后把参数传给对应的工具执行。这一步看似简单，却是工程里最容易翻车的地方——模型偶尔会多打一个空格、把一个引号写弯、甚至参数值里混进多余字符。

从概率角度看，模型生成调用文本的过程，就是在所有可能的输出序列中挑选概率最高的那个：

$$\displaystyle \hat{y} = \arg\max_{y \in \mathcal{Y}}\, P_\theta(y \mid x, F)$$

在实际解析时，我们要做“格式规范化”：容忍多余空白，尝试修复不完整的 JSON，对参数值做类型强制转换（比如把数字字符串转成整数），校验必填参数是否齐全。如果解析失败，系统应返回“无法解析”并触发重试或询问用户，而不是直接崩溃——就像收银员看不清订单时会再问客人一遍，而不是随便报个菜名进后厨。

1. 候选输出空间：$\mathcal{Y}$ 是所有可能输出文本的集合，范围极大，包含普通回答和函数调用。

$$y \in \mathcal{Y}$$

2. 模型概率：$P_\theta(y \mid x, F)$ 中的 $P_\theta$ 表示模型在参数 $\theta$ 下生成文本 $y$ 的概率。

$$P_\theta(y \mid x, F)$$

3. 条件输入：$x$ 是用户请求，$F$ 是函数列表，两者共同决定输出分布，就像客人和菜单共同决定订单内容。

$$x,\ F = \text{条件输入}$$

4. 最优输出：$\hat{y}$ 是概率最高的输出序列，也就是模型最终“写”下的标准订单。

$$\hat{y} = \arg\max_{y \in \mathcal{Y}}\, P_\theta(y \mid x, F)$$

一张写错格式的订单会毁掉一桌好菜；一段格式不规范的输出也会让 Agent 空转甚至报错。因此训练时我们会刻意把模型“调教”成稳定输出标准格式的服务员。而“调教”需要的教材，就是我们下一节要讲的训练数据。

训练数据构造

要让小张学会写标准订单，光背菜谱不够，还得给他看大量“客人说了什么 → 服务员写了什么”的师徒案例。这些案例就是训练数据。案例越真实，小张面对陌生客人时越从容；案例里有各种刁钻场景，他才不会在高峰期手忙脚乱。

每组训练数据包含三部分：用户请求 $x$、可用的函数列表 $F$、标准答案 $y$。注意 $y$ 有两种形态：需要工具时，它是一个标准函数调用；不需要工具时（比如用户只是问好），它就是一句普通回复。数据来源主要有三个：清洗后的真实用户日志、让大模型（如 GPT 系列）蒸馏生成的样例、以及人工编写的高质量模板。三者混合，既保证真实度，又保证多样性。

训练时，我们用监督学习的方式最大化标准答案的概率，也就是最小化交叉熵损失：

$$\displaystyle \mathcal{L} = -\frac{1}{N} \sum_{i=1}^{N} \log P_\theta(y_i \mid x_i, F_i)$$

这里特别要强调负样本的设计。如果训练集里每个问题都调用工具，模型就会变成“乱下单”的服务员——用户问“你好”，它也调个搜索工具。所以必须混入大量“不需要调用工具”的样本，标准答案就是自然语言回复，让模型学会判断边界：能直接答的就直接答，答不了才下单。

1. 训练集规模：$N$ 是训练样本总数，样本由“用户请求、函数列表、标准答案”三元组构成。

$$\displaystyle N = \text{样本总数}$$

2. 单样本对数似然：$\log P_\theta(y_i \mid x_i, F_i)$ 量化模型对第 $i$ 个样本答对的自信程度。

$$\log P_\theta(y_i \mid x_i, F_i)$$

3. 平均求和：$\frac{1}{N} \sum_{i=1}^{N}$ 把所有样本的损失求平均，让每个样本公平贡献。

$$\frac{1}{N} \sum_{i=1}^{N} (\cdot)$$

4. 负号求最小：$-$ 号把“最大化概率”翻转为“最小化损失”，方便梯度下降优化。

$$\mathcal{L} = -\frac{1}{N} \sum_{i=1}^{N} \log P_\theta(y_i \mid x_i, F_i)$$

师徒案例越真实、越多样，小张面对陌生客人时越从容。数据质量直接决定模型调用工具有多“靠谱”。教材备齐之后，接下来就是正式的“上岗集训”——微调。

微调训练策略

小张在厨师学校已经学会了听说读写，上岗集训不需要把学校重读一遍，只需要重点练两件事：认菜单、写订单。对 SLM 来说，这就是微调——在预训练的基础上，用小而精的数据“集训”函数调用技能。全量微调要更新所有参数，对端侧小模型来说成本太高，于是我们常用 LoRA。

LoRA 的核心思想是“冻结旧知识，只学新增量”。具体做法是：把原始权重矩阵 $W_0$ 冻住不动，在旁边加一个低秩的增量矩阵 $\Delta W$，训练时只更新这个增量。这就像老服务员已经会说话、会走路，集训时只需要换一本点单手册，不用重新培训整个人。

数学上，LoRA 把增量分解成两个小矩阵的乘积：

$$\displaystyle W' = W_0 + \Delta W = W_0 + B A,\qquad A \in \mathbb{R}^{r \times d},\ B \in \mathbb{R}^{d \times r},\ r \ll d$$

参数量从 $d \times d$ 骤降到 $2 \times r \times d$，训练开销大幅降低，普通消费级显卡甚至 CPU 都能跑。推理时把 $BA$ 合并回 $W_0$，不增加任何延迟。除 LoRA 外，解码参数也很关键：函数调用追求确定性，温度 $\tau$ 应设低（0.1～0.3），避免模型同一个订单每次写出来的格式都不一样。

1. 原始权重：$W_0$ 是预训练得到的基础权重矩阵，训练中保持冻结，相当于服务员原有的语言功底。

$$\displaystyle W_0 = \text{冻结的原始权重}$$

2. 低秩增量：$\Delta W = BA$ 是两个小矩阵相乘的结果，代表本次集训学到的“新技能”。

$$\Delta W = B A$$

3. 维度约束：$A \in \mathbb{R}^{r \times d}$、$B \in \mathbb{R}^{d \times r}$，$r \ll d$ 说明增量矩阵非常“瘦”。

$$r \ll d$$

4. 合并推理：$W' = W_0 + BA$，推理时先合并再使用，速度与原始模型完全一致。

$$W' = W_0 + \Delta W$$

集训结束，小张出师：认得菜单、写得规范、不乱点。LoRA 让这场集训又快又省，小本经营的餐厅（端侧设备）也请得起。不过，真正的大场面还在后面——客人办婚宴时，要学会统筹多个档口。

多工具编排

客人要办婚宴，需求一串：先看天气定场地，再订蛋糕，最后设提醒。小张不可能一个灶台跑到底，他要统筹凉菜、热菜、甜品多个档口，还得讲究先后顺序，遇到某道菜卖完了，要立刻换个备选方案。真实世界里的 Agent 也是如此——很少有任务只调一个工具就能完成。

多工具编排的第一步是“路由”：模型根据用户意图，把请求分发给正确的工具。第二步是“多步调用”：把上一步的结果作为下一步的输入，形成一条调用链。比如“导航到最近的充电站，顺便看看那边天气”就需要先调定位工具，再调导航工具和天气工具。模型要学会安排顺序，而不是一股脑全调一遍。

从概率上，一整条调用链可以看成每一步条件概率的乘积：

$$\displaystyle P(c_1, c_2, \dots, c_k \mid x, F) = \prod_{j=1}^{k} P(c_j \mid x, c_{<j}, F)$$

工程上还要重点处理异常：工具返回错误时先重试一次；重试失败就切换到功能类似的备用工具；实在不行就向用户说明并请求补充信息。同时要给整条链设定步数上限和超时时间，防止 Agent 陷入“死循环”——就像服务员不能因为甜品档口排队，就让整场婚宴的客人都干等着。

1. 调用序列：$(c_1, c_2, \dots, c_k)$ 是一个 Agent 在一轮任务中依次发起的 $k$ 次工具调用。

$$\displaystyle c_1, c_2, \dots, c_k$$

2. 链式法则：$\prod_{j=1}^{k}$ 表示把每一步的条件概率相乘，得到整条调用链出现的概率。

$$\prod_{j=1}^{k} (\cdot)$$

3. 历史依赖：$P(c_j \mid x, c_{<j}, F)$ 说明第 $j$ 步的选择依赖于之前所有调用的结果。

$$c_{<j} = \{c_1, c_2, \dots, c_{j-1}\}$$

4. 整体决策：整条链的概率越高，说明编排越合理，模型越有可能成功完成任务。

$$P(c_1, c_2, \dots, c_k \mid x, F)$$

优秀的服务员不是闷头跑腿，而是眼里有整场宴席；优秀的 Agent 也不只会调一个工具，而是懂得统筹规划。编排能力，决定了它能接多大的“活”。宴席方案定好了，最后还得看厨房装不装得下——这就是端侧落地的问题。

端侧落地优化

婚宴方案再完美，也得看厨房实力。端侧设备就像一个小厨房：灶台少、储物柜小、出菜要快。SLM 要在这里安家，必须精打细算。好在有三个优化方向：量化、延迟优化、离线部署。

量化是最立竿见影的手段。把权重从 FP16（16 位浮点）压缩成 INT8 甚至 INT4（整数），就像把大块食材提前切成小块，更省空间。延迟优化则靠缓存和预加载：重复的请求缓存结果，KV Cache 复用，模型提前预热，相当于后厨提前备好半成品，高峰期才能快速出菜。离线部署让模型和工具全部在本地运行，数据不出设备，既保护隐私又避免网络抖动。

量化带来的内存节省可以用一个简单的公式估算：

$$\displaystyle M_{\text{saved}} = P_{\text{params}} \times \left(1 - \frac{b_q}{b_0}\right)$$

以 1B 参数的模型为例：FP16 存储约需 2GB，量化到 INT4 只需约 500MB，内存直降 75%，手机、耳机、车载盒子都能跑。需要注意的是，量化可能带来少量精度损失，通常要在量化后用小规模函数调用数据做校准，把损失补回来——就像后厨换了新灶台，要先试炒几道菜调整火候。

1. 参数量：$P_{\text{params}}$ 是模型的总参数量，决定了内存占用的基本盘。

$$\displaystyle P_{\text{params}} = \text{模型参数量}$$

2. 原始位宽：$b_0$ 是量化前每个权重占用的比特数，通常为 16（FP16）。

$$b_0 = 16,\ b_q = 8\ \text{或}\ 4$$

3. 比例缩减：$\frac{b_q}{b_0}$ 是量化后权重体积占原始体积的比例，越小越省空间。

$$\frac{b_q}{b_0} \in (0, 1)$$

4. 节省总量：$M_{\text{saved}}$ 是减少的内存字节数，量化到 INT4 时约为原始内存的 75%。

$$M_{\text{saved}} = P_{\text{params}} \times \left(1 - \frac{b_q}{b_0}\right)$$

小厨房也能端出满汉全席——只要菜谱精简、备菜到位、流程顺畅。端侧 SLM 加上函数调用，就是那个在手机、手表、车上随时待命的“贴身服务员”：反应快、不联网、懂规矩、能办事。

AI 应用场景

Python 演示

import jsonimport re TOOLS = [    {        "name": "get_weather",        "description": "查询指定城市的实时天气",        "parameters": {"city": {"type": "string", "required": True}},    },    {        "name": "set_alarm",        "description": "设定某个时间的提醒闹钟",        "parameters": {            "time": {"type": "string", "required": True},            "note": {"type": "string"},        },    },    {        "name": "search_web",        "description": "搜索互联网上的最新信息",        "parameters": {"query": {"type": "string", "required": True}},    },] CALL_RE = re.compile(r"<tool_call>\s*(.*?)\s*</tool_call>", re.S)  def parse_tool_call(text):    """从模型输出中提取函数名与参数，返回 dict 或 None"""    m = CALL_RE.search(text)    if not m:        return None    try:        data = json.loads(m.group(1))        return {"name": data["name"], "arguments": data.get("arguments", {})}    except (json.JSONDecodeError, KeyError):        return None  def execute_tool(call):    """根据函数名分发到对应的具体实现"""    name = call["name"]    args = call["arguments"]    if name == "get_weather":        return {"result": "{} 晴 气温 25 度".format(args["city"])}    if name == "set_alarm":        return {"result": "已设定 {} 闹钟 {}".format(args["time"], args.get("note", ""))}    if name == "search_web":        return {"result": "找到关于 {} 的最新资讯 3 条".format(args["query"])}    return {"error": "未知工具 {}".format(name)}  def mock_slm(user_msg):    """模拟微调后 SLM 的输出，真实场景中由模型推理生成"""    if "天气" in user_msg:        return '<tool_call>{"name": "get_weather", "arguments": {"city": "北京"}}</tool_call>'    if "提醒" in user_msg or "闹钟" in user_msg:        return '<tool_call>{"name": "set_alarm", "arguments": {"time": "07:00", "note": "起床"}}</tool_call>'    return '<tool_call>{"name": "search_web", "arguments": {"query": "端侧大模型"}}</tool_call>'  def agent_loop(user_msg):    """一次完整的工具调用流程：生成 -> 解析 -> 执行 -> 返回"""    raw = mock_slm(user_msg)    call = parse_tool_call(raw)    if call is None:        return "模型未生成合法调用，直接回复：我无法完成这个任务。"    result = execute_tool(call)    if "error" in result:        return "调用失败：{}".format(result["error"])    return "已调用 {}，{}".format(call["name"], result["result"])  if __name__ == "__main__":    for msg in ["帮我查一下北京的天气", "明早七点提醒我起床"]:        print("用户：{}".format(msg))        print("助手：{}".format(agent_loop(msg)))

1. CALL_RE = re.compile(r"<tool_call>\s*(.*?)\s*</tool_call>", re.S)用正则定位 <tool_call> 标签包裹的调用区域，相当于收银员先找到订单上“点菜栏”在哪。
2. data = json.loads(m.group(1))把调用文本解析成 Python 字典，这一步必须容错，捕获 JSON 解析异常。
3. data.get("arguments", {})参数缺省时给空字典，避免取不到参数直接崩溃，体现“订单少写一行也别掀桌”的容错思想。
4. def execute_tool(call)工具分发器，按函数名把请求送到对应的“档口”，对应真实系统的 API 路由。
5. raw = mock_slm(user_msg)模拟微调后 SLM 的输出，真实场景中这一行替换为模型推理代码。
6. if call is None:解析失败时的兜底分支，直接回复用户而不是抛异常，就像看不清订单时礼貌地再问一遍。
7. if __name__ == "__main__":程序入口，遍历两条测试指令，打印完整的“用户 → 助手”对话链路。

常见误区

面试题