大模型工具使用能力的训练方法

可视化演示

展示Function Calling参数抽取流程、多轮工具调用依赖链与结果整合、以及SFT到RL强化学习优化策略，通过多模式交互理解工具使用训练全流程。

工具定义与类型

小林入职第一天，人事部递给他一本《部门职能手册》：财务部管报销、IT部管电脑、行政部管订票，每个部门后面还写着对接人、办公地点和需要的表单。经理告诉他：“你不必什么都会，但你必须背熟这本手册——遇到什么事，知道该找谁。”大模型训练工具使用的第一步，同样是让模型“认识工具”：模型不需要内化每个工具的实现细节，但必须清楚“有哪些外部能力可用、各自负责什么、接口长什么样”。

工具的本质是外部函数或 API。在训练和推理时，我们把这些工具定义写入模型的上下文，让模型“看到”它们。典型工具包括：查天气、计算器、搜索引擎、发邮件、数据库查询、代码解释器等，它们统称为外部函数服务。与人类助理一样，模型看到的不是工具源码，而是三要素：工具名称与用途描述（让模型理解何时该用）、参数列表与类型（让模型生成正确调用）、返回格式说明（让模型解析结果）。工程上，这些定义会被维护成一份结构化的工具清单，每个工具对应一份 JSON Schema 格式的接口定义，随着业务变化不断增删版本。

$$T = \{ t_1, t_2, \dots, t_n \}$$

1. T（工具集合）：T 代表当前 Agent 可调用的全部外部能力的集合，对应“部门手册”本身。

$$T$$

2. t₁, t₂, …, tₙ（具体工具）：t₁、t₂ 是具体工具实例，例如查天气函数、计算器函数；tₙ 表示可以有任意多个工具。

$$t_1, t_2, \dots, t_n$$

3. 集合的构建（工具清单维护）：大括号把所有可用工具收拢成一个整体，模型每次决策都从这个集合里做选择。

$$\{ \cdot \}$$

小林发现，手册背得越熟，处理需求时脑子里浮现“这事归谁管”的速度就越快。对大模型而言，工具清单就是它心中的部门手册：清单描述得越清楚，模型在关键时刻的“求助”就越精准。这也是为什么工具使用训练的第一步，永远是先搭好一份高质量的工具清单。

调用时机判断

第二周，总经理开始给小林派活：“帮我订个会议室”“报销单在哪”“今天心情如何”。小林慢慢发现，不是每句话都要惊动各部门：闲聊可以自己接，涉及事实查询或操作才需要转给专业部门。有一次他直接把“晚上吃什么”转给财务部，财务部一脸茫然。这就是时机判断没学好——用技术语言说，就是工具触发（Tool Trigger）的意图识别出了问题。

时机判断的核心是让模型学会一个二元决策：当前这个问题，需不需要调用工具？如果需要，调用哪个？工程上的常见做法是让模型输出特殊的调用标记（如 tool_call），或者让模型先在内部推理“这个问题我自己答不了，必须借助外部”，然后再输出调用块。许多开源模型则在训练时加入一个独立的分类头，让模型在解码早期就决定是否进入工具分支。

实践中，这个判断被建模为一个概率问题：

$$P(\text{use\_tool} \mid x) = \sigma(w^\top f(x) + b)$$

1. P(use_tool | x)（触发概率）：给定用户输入 x，模型认为需要调用工具的概率，介于 0 到 1 之间。

$$P(\text{use\_tool} \mid x)$$

2. σ(u)（Sigmoid 压缩）：把一个任意实数压缩到 (0,1) 区间的函数，让输出可以当作概率来解读。

$$\sigma(u) = \frac{1}{1 + e^{-u}}$$

3. w^⊤ f(x) + b（线性打分）：f(x) 是对输入 x 提取的语义特征向量，w 是特征权重，b 是偏置；三者共同完成“这个请求需要工具的成色打分”。

$$w^\top f(x) + b$$

必须强调“拒绝调用”的重要性：能直接回答的问题不要画蛇添足去调工具。这就像小林被批评三次后终于学会“闲聊自己接，办事找部门”。训练时如果只给正样本（该调用时调用），模型就会养成“事事都调工具”的坏习惯，既增加延迟又提高出错率；只有加入大量“不该调用”的负样本，模型才能真正学会克制。

参数抽取与格式

总经理对小林说：“帮我查查上海下周三的天气。”小林给行政部发了条微信：“查天气，上海，下周三。”行政部回了个问号——因为正式工单必须填 city 和 date 两个字段，微信口语没法直接录入系统。小林这才意识到：把一句口语翻译成标准工单，是助理的基本功。对应到 Function Calling，这个基本功就叫参数抽取与格式控制。

参数抽取是从用户自由文本中识别出工具每个字段所需的值；格式控制是保证输出严格符合接口定义的 JSON 结构。这两件事通常拆成两步：先做实体识别，找出“上海”“下周三”这些片段，再做参数映射，把片段对应到 schema 里的 city/date 字段，并转换成标准格式（如日期转为 ISO 8601）。格式控制层面，工程上常用 JSON Schema 校验模型输出、用受限解码（constrained decoding）限制模型只能生成合法 JSON、以及在后处理中用类型转换和枚举校验兜底。

$$S(a, x) = \sum_{j=1}^{m} \lambda_j \phi_j(a, x)$$

1. S(a, x)（参数匹配得分）：在用户语句 x 下，候选参数 a（如“上海”“大年初三”）被抽中的匹配分数。

$$S(a, x)$$

2. φ_j(a, x)（特征函数）：第 j 个匹配特征，比如词面是否重合、语义向量是否接近、实体类型是否符合 schema 要求。

$$\phi_j(a, x)$$

3. λ_j 与求和（加权融合）：每个特征各有权重 λ_j，把所有特征的加权和算出来，就是该候选参数的最终得分。

$$\sum_{j=1}^{m} \lambda_j \phi_j(a, x)$$

小林的工单从“口语化微信”进化成“标准化表单”后，行政部处理效率直接翻倍。对模型而言，参数规范得越好，工具调用成功率越高——一个把 city: "上海" 写成 city: "上海？" 的模型，就像填错工单的助理，会让整个下游流程卡壳。

训练数据构建

小林工作半年后，公司决定把他的成长经验变成可复制的方法论。他们从系统日志里导出小林处理过的所有工单，让资深主管逐条标注哪些是优秀示范、哪些是错误示范，又让小林自己生成一批“碰到这种情况我会怎么处理”的模拟工单。这些素材最终汇集成一本《新助理培训手册》——新来的助理照着学，事半功倍。

这本“培训手册”对应大模型的工具使用训练数据集。一条标准样本长这样：用户输入 x → 应该调用的工具编号和参数 → 工具返回的结果 r → 最终回答 y。数据来源主要有三条。第一，人工标注的真实轨迹，成本高但质量最可靠，作为种子数据；第二，真实系统日志，量大但噪声多，需要清洗掉调用失败或参数格式错误的轨迹；第三，模型合成数据，用大模型按模板生成候选，再用规则和人工抽检做质量校验。

$$D_{\text{train}} = \{ (x_i, y_i) \mid i = 1, 2, \dots, N \}, \quad y_i = (\text{tool}_i, \text{params}_i, \text{result}_i)$$

1. D_train（训练集）：全体训练样本的集合，相当于整本《新助理培训手册》。

$$D_{\text{train}}$$

2. (x_i, y_i)（输入-动作对）：第 i 条样本由用户输入 x_i 和标准动作 y_i 组成，代表“看到这句话，助理应当这样应对”。

$$(x_i, y_i)$$

3. y_i 的三元组结构（动作内容）：tool_i 是工具名，params_i 是调用参数，result_i 是工具返回结果；这三元组完整描述了一次工具调用轨迹。

$$y_i = (\text{tool}_i, \text{params}_i, \text{result}_i)$$

数据构建最容易被忽略的是负样本：该拒绝调用的样本、工具报错后如何恢复的样本、参数填错被纠正的样本。这些“错题”决定了模型在实际使用中的鲁棒性。最后还要做去重、格式一致性检查（所有 JSON 必须通过 schema 校验）和难度分布检查。正如培训手册里既有标准答案也有错题集，工具训练数据的质量直接决定模型调用能力的天花板。

多轮工具调用

有一天总经理说：“帮我安排去上海的出差，避开雨天，订最早的航班。”小林意识到这不是一个部门能干完的：先找行政查上海天气，再找票务订最早的机票，最后还要看总经理日历有没有冲突。而且第二步的“最早航班”依赖第一步的“天气预报”，后一个工单要等前一个结果出来才能填。这就是多轮工具调用的典型场景。

多轮工具调用要解决三个核心问题：依赖关系、状态追踪、上下文衔接。依赖关系指工具之间存在输入输出依赖，工程上通常把前一个工具的输出作为上下文追加到模型输入中，而不是让模型凭空想象；状态追踪指模型要在多步流程中记住“已完成了什么、还差什么”，实践中会维护一个 JSON 格式的结构化状态表；上下文衔接则要求模型面对工具返回的长文本时先做摘要再继续下一步，避免把所有原文都拼进 prompt。

$$s_t = \text{Update}(s_{t-1}, u_t, r_{t-1})$$

1. s_t（当前状态）：第 t 轮时整个任务的状态，相当于小林手里的“接力笔记本”。

$$s_t$$

2. s_{t-1}, u_t, r_{t-1}（三个输入信号）：上一轮的状态、用户本轮的新指令、上一轮工具返回的结果，三者共同决定下一步怎么走。

$$s_{t-1}, \quad u_t, \quad r_{t-1}$$

3. Update(·)（状态更新函数）：把旧的笔记、新的指令和最新的工具反馈融合成新状态的函数，既不丢历史信息，又能反映最新进展。

$$\text{Update}(s_{t-1}, u_t, r_{t-1})$$

另外必须设置最大调用轮数（如 8 轮），超限后优雅终止，向用户说明“这个问题超出我能处理的范围”。这就像小林从不会让三个部门无限接力下去，而是在确认信息足够后立刻收束成结论。多轮调用做得好的模型，能像经验丰富的助理一样，把复杂任务拆解成有序的行动链。

结果整合

各部门把结果发给了小林：行政部发来一张天气数据表，票务部发来航班号，日历显示周三下午 2 点有例会。小林不会直接把表格转发给总经理，而是先检查数据有没有异常（比如气温 999 度这种明显错误），再把三份材料融成一段话：“周三上海小雨，最早的航班是 7:05 起飞，但您 2 点有例会，建议改乘 9:30 的航班。”

这个“检查 + 融合 + 表达”的过程，对应工具使用中的结果整合。模型拿到工具返回的原始输出后，通常不能直接拼接——既不可读，也不一定正确。整合分为三步：解析阶段，把 JSON 或文本结果转换成结构化内部表示；校验阶段，检查结果是否为空、是否有错误码、数值是否合理，异常时可以触发重试，也可以直接向用户澄清；回答生成阶段，把用户原始问题与校验后的工具结果一起作为上下文，生成自然简洁、可追溯来源的回答。

$$P(\text{answer} \mid x, r_1, r_2, \dots, r_k)$$

1. answer（最终回答）：模型整合所有信息后生成的自然语言答复，即交给总经理的简报。

$$\text{answer}$$

2. x（原始问题）：用户最初的需求，是简报必须围绕的主题。

$$x$$

3. r₁, r₂, …, r_k（工具结果集合）：k 个工具先后返回的原始结果，是简报的全部素材来源。

$$r_1, r_2, \dots, r_k$$

4. P(·) 整体含义（条件生成目标）：整条公式表示“在已知问题和全部素材的前提下，回答有多合理”；训练时就是让这个概率尽量大。

$$P(\text{answer} \mid x, r_1, r_2, \dots, r_k)$$

训练数据中要特别加入“结果异常时模型应如何表现”的样本，避免两种毛病：一是把错误信息原封不动抛给用户，二是无视错误结果强行编造答案。总经理对小林评价最高的一句话是“他给我的不是数据，是结论”——结果整合的本质，就是让大模型从“传话筒”升级成“参谋长”。

强化学习优化

季度考核时，总经理给小林打了三项分：任务办没办成（核心指标）、有没有白跑腿（不必要的部门转接）、遇到问题有没有及时上报（该求助时不能硬扛）。小林发现，光靠背培训手册还不够，于是他把每次考核反馈记下来，慢慢调整自己的工作习惯——这正是“强化学习”的雏形。

在工具使用领域，监督微调只能教会模型“输出格式长得像优秀助理”，但没法教会它“在真实环境里把事做成”——因为模型写出的工具调用是否真的有效，必须放到外部环境里执行才知道。强化学习（RL）把“模型 → 工具 → 真实结果 → 奖励”的闭环打通：模型先按当前策略产生工具调用序列，工具执行后返回真实结果，由奖励函数给这一整条轨迹打分，再用策略梯度算法更新模型权重。

$$R = R_{\text{task}} + \lambda_1 R_{\text{acc}} - \lambda_2 R_{\text{overuse}}$$

1. R（总奖励）：一条工具调用轨迹的最终得分，数值越高代表这次调用越优秀。

$$R$$

2. R_task（任务成功奖励）：最终回答是否达成用户目标，是考核的核心指标，占比最高。

$$R_{\text{task}}$$

3. R_acc（结果使用奖励）：工具返回的结果是否被正确、真实地引用进最终回答，防止模型“查了不用、宁可编造”。

$$R_{\text{acc}}$$

4. -λ₂ R_overuse（效率惩罚）：对不必要或重复的工具调用的负向惩罚，λ₂ 控制惩罚力度，鼓励模型“少跑冤枉路”。

$$- \lambda_2 R_{\text{overuse}}$$

实践中要注意两点：一是 RL 训练初期模型容易坍缩到少数高奖励动作上，所以通常先用 SFT 数据做预热，再逐步放开真实环境探索；二是要持续监控工具调用分布，防止模型永远只选同一个工具。小林靠一次次考核反馈迭代成长为大公司首席助理，大模型也靠强化学习在真实环境中不断进化工具使用策略——这就是工具使用训练的最后一环，也是最接近“真实世界智慧”的一环。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""极简 Function Calling 演示：意图识别 -> 参数抽取 -> 工具调用 -> 结果整合""" import jsonimport re  def search_weather(city, date):    """模拟天气查询工具的返回结果。"""    return json.dumps(        {"city": city, "date": date, "condition": "晴", "temp": 25},        ensure_ascii=False    )  def calc(expr):    """模拟计算器工具，只支持加减乘除。"""    return str(eval(expr, {"__builtins__": {}}, {}))  TOOL_SCHEMAS = {    "search_weather": {"desc": "查询天气", "params": ["city", "date"]},    "calc": {"desc": "计算数学表达式", "params": ["expr"]}}  def parse_intent(query):    """用关键词规则模拟模型的意图识别。"""    if any(w in query for w in ["天气", "气温", "下雨"]):        return "search_weather"    if any(w in query for w in ["计算", "多少", "加", "乘"]):        return "calc"    return None  def extract_params(query, tool_name):    """用正则模拟参数抽取。"""    if tool_name == "search_weather":        city = re.search(r"([\u4e00-\u9fa5]{2,5}市?)", query)        date = re.search(r"(今天|明天|后天)", query)        return {            "city": city.group(1) if city else "北京",            "date": date.group(1) if date else "今天"        }    if tool_name == "calc":        m = re.search(r"(\d+)\s*[+\-*/x]\s*(\d+)", query)        if m:            return {"expr": m.group(1) + "*" + m.group(2)}        m2 = re.search(r"(\d+)\s*乘以\s*(\d+)", query)        if m2:            return {"expr": m2.group(1) + "*" + m2.group(2)}        return {"expr": "1+1"}    return {}  def call_tool(tool_name, params):    """执行工具调用，真实项目中这里是 HTTP/API 请求。"""    if tool_name == "search_weather":        return search_weather(**params)    if tool_name == "calc":        return calc(**params)    return "未知工具"  def agent(query):    """主流程：意图识别 -> 参数抽取 -> 工具调用 -> 结果整合。"""    tool_name = parse_intent(query)    if tool_name is None:        return "无需调用工具，直接回答：" + query    params = extract_params(query, tool_name)    result = call_tool(tool_name, params)    desc = TOOL_SCHEMAS[tool_name]["desc"]    return "我调用了工具[{}]，参数 {}，结果为 {}".format(desc, params, result)  if __name__ == "__main__":    print(agent("北京明天天气怎么样？"))    print(agent("帮我算一下 23乘以47 等于多少？"))    print(agent("你好呀！"))

1. def parse_intent(query):模拟时机判断：根据关键词判断用户问题是否需要使用工具、调用哪个工具。
2. if any(w in query for w in ["天气", "气温", "下雨"]):对应“触发条件”，只要语句命中领域词就触发对应工具。
3. def extract_params(query, tool_name):模拟参数抽取：用正则从口语中抽出城市、日期、表达式等结构化参数。
4. city.group(1) if city else "北京"模拟参数缺省时的兜底策略：没识别到城市就用默认值。
5. {"expr": m.group(1) + "*" + m.group(2)}把“23乘以47”转换成标准数学表达式 "23*47"，即参数映射与格式化。
6. def call_tool(tool_name, params):模拟工具执行层，真实项目中这里会发起 HTTP 请求调用外部 API。
7. return "无需调用工具，直接回答：" + query模拟拒绝调用分支，体现“能直接回答就不调工具”的原则。
8. if __name__ == "__main__":可执行入口，运行脚本就能看到三种典型路径的完整输出。

常见误区

面试题