「Agent Tool」LLM 如何学会调用外部工具？

0 前言

本文内容整理自公众号「小林面试笔记」的文章 2. LLM 是如何学会调用外部工具的？，用于记录与总结 AI Agent 工具调用相关的核心面试知识点。

「LLM 是如何学会调用外部工具的？」，可以这样作答：

模型会调用工具不是天生的，而是训练出来的。这道题分两块答：先讲训练阶段模型怎么学会，再讲训练好之后运行时是怎么工作的。

训练靠两个阶段配合：SFT（监督微调） 负责「怎么调」——喂海量带完整工具调用流程的示范对话（工具说明书 → 提问 → 输出 tool_calls → 模拟返回结果 → 最终回答），让模型靠模仿学会整套流程；RLHF（基于人类反馈的强化学习） 负责「什么时候调」——收集人类对回答质量的好坏判断，训练一个奖励模型当裁判，再用强化学习反复调整主模型，让它学会「能直接回答就不调工具」的边界感。

运行时就是我们上一篇讲的 Function Calling 机制：应用代码把工具 schema 传给模型，模型判断需要工具时输出结构化的 tool_calls JSON，代码真正执行后把结果回填，模型再生成最终答案。核心认知始终只有一句话——模型全程只是「下指令」，真正执行工具的是宿主代码，模型决策、代码执行。

ChatGPT 网页版的联网搜索、Cursor 的 Agent 帮你跑命令、Claude Code 的各类工具调用，能稳定工作而不是「乱调一气」，靠的就是模型在出厂前被这样训过：先学会怎么调（SFT），再学会什么时候不该调（RLHF）。你眼里每一个靠谱的工具调用，背后都站着一个被「教过技能、练过分寸」的模型。

1 原始 LLM 的世界：为什么不会调工具

先看模型出厂、还没被「特训」时的状态。预训练完成的基础模型只活在文字世界里：它的全部训练目标就是预测下一个 token，它的全部本事是「文字接龙」。你问它「北京今天天气怎么样」，它能接出像模像样的文字，但它不知道世界上存在一个能真的查到天气的函数——它从没见过工具，更不知道怎么调用。

预训练模型只会续写文字、从没见过工具调用

这里藏着一个经典误区：有人觉得模型参数量够大、涌现能力够强，工具调用自然就会了。语言涌现和工具调用是两回事——预训练学的是「文字之间的关系」，工具调用要求模型输出特定格式的结构化 JSON，这属于「行为」而不是「语言」，预训练数据里根本没有这种示范，模型再大也学不出来。金句版：会写诗不等于会上网查天气，会接话不等于会干活。

所以模型要出厂干活，还得补课——补两门课，一门教技能，一门教分寸。

2 一前一后，两个训练阶段

补课方案是业界标准的两阶段训练：

第一阶段：SFT，解决「怎么调」——让模型见过、模仿一整套工具调用流程，学会输出规范的调用请求；
第二阶段：RLHF，解决「什么时候调」——让模型建立分寸感，分清哪些问题该调工具、哪些问题直接回答。

两阶段训练总览：SFT 教怎么调、RLHF 教什么时候调

顺序不能反：得先会调，才谈得上什么时候该调。就像教新员工，先让他学会走流程，再教他什么流程不用走。

3 第一阶段：SFT——让模型「见过」工具调用

SFT 的思路非常朴素：给模型看海量「标准答案」——人工构造或收集的、带完整工具调用流程的对话样本，让模型照着模仿。一条样本长这样，一共五段消息：

System：工具说明书（JSON schema），告诉模型有哪些工具、怎么用；
User：用户提问，比如「北京今天天气怎么样？」；

Assistant：不直接回答，而是输出结构化调用请求：

{
    "tool_calls": [{
        "name": "get_weather",
        "arguments": {"city": "北京"}
    }]
}

Tool：模拟工具返回的结果（真实的天气数据）；
Assistant：基于工具结果，给出最终回答「北京今天天气晴朗，气温 15°C……」。

SFT 训练样本结构：说明书、提问、调用请求、回填、最终回答

几十万上百万条这样的样本，反复训练下来，模型就学会了整套流程：看到工具描述 → 判断要不要调 → 输出规范的 JSON 请求 → 接住工具结果组织回答。这就像新员工进公司，师傅丢给他一摞历史工单，看多了，接单、处理、汇报的规矩自然就明白了——SFT 就是让模型看工单。

4 SFT 的短板：会了，但不知道「该不该调」

只看了工单的模型有个明显毛病：没有分寸感。它把「调用工具」当成了万能解题套路——你问它「1+1 等于几」，它也要先调一次 get_weather 再回答。因为在它见过的样本里，处处都是工具调用，它学会了「调」，却没学会「什么时候不该调」。

SFT 的短板：连 1+1 都要先调工具、行为边界感很弱

一句话概括：SFT 练出来的是肌肉记忆，而肌肉记忆没有分寸感。这个问题，就要交给第二阶段的 RLHF 解决。

5 第二阶段：RLHF——用反馈建立边界感

RLHF 的思路是引入「好坏标准」，让模型从反馈里学会判断。流程分四步：

生成多样回答：同一个问题，让模型生成多种回答——有先调工具的，有直接回答的；
人类打分：让人类判断哪些回答更符合预期——问「1+1」直接回答的受好评，先调工具再算的受差评；
训练奖励模型：把人类的打分喂给一个专门的模型进行训练，让它学会预测「哪种回答更受欢迎」——奖励模型就是那个「会打分的裁判」；
强化学习调整主模型：用奖励模型给出的分数当反馈，通过强化学习反复调整主模型，让高分回答越来越多、低分回答越来越少。

RLHF 四步流程：生成多样回答、人类打分、训练奖励模型、强化学习调整

这四步可以用公司场景类比：员工（主模型）干活 → 老板（人类）评价干得好不好 → 人事部门（奖励模型）把评价固化成一套打分标准 → 员工按标准调整自己的工作方式。标准越来越清晰，员工的判断也越来越有边界感。

奖励模型打分闭环：奖励模型打分、强化学习不断调整主模型

经过这个过程，模型逐渐学会了更微妙的判断：需要实时信息（天气、股价、订单状态）才调工具，能靠自身知识直接回答的就不调。这就是「该不该调」的边界感。

RLHF 训练整体闭环示意

顺带一提：RLHF 需要大量人类打分，成本不低，于是出现了 RLAIF（基于 AI 反馈的强化学习）——让更强的 AI 模型来当代打分员，替代人类评分。成本低、可规模化，是面试里的加分项。

6 运行时：训练好之后怎么用

训练只是出厂前的准备，真正干活靠的是运行时机制——也就是上一篇详讲的 Function Calling。每次应用调用模型时，流程是这样的：

应用代码把工具 schema（工具说明书）+ 用户问题一起传给模型；
模型判断需要工具时，不直接回答，而是输出一段结构化的 JSON；
你的代码解析这段 JSON，真正执行工具，把结果塞回对话；
模型拿到结果，生成最终答案。

运行时调用流程：应用传入工具 schema 与问题、模型输出 tool_calls JSON

运行时的核心是：模型在训练里学会的「调用能力」，落地的介质就是这一段结构化 JSON。训练决定模型会不会调、调得对不对，运行时决定代码能不能稳定地接住这个意图。

7 一个关键认知：模型只负责「决策」，不负责「执行」

把训练和运行串起来，最后剩下一个贯穿始终的认知：模型从头到尾只是在**「下指令」**。训练阶段，它学会的是输出规范调用请求的动作；运行阶段，它输出的还是调用请求——真正连数据库、调 API、访问网络的，始终是你的宿主代码。

模型只负责决策输出 JSON、代码负责真正执行

这个「模型决策、代码执行」的分工，是整套工具调用体系的地基：上一篇文章里的 Function Calling 机制、这篇文章的两阶段训练流程，最终都是在为这个简单的分工服务。

8 面试总结

回答这道题，先避开两个经典误区：

误区	正解
参数量够大、涌现能力够强就会调工具	语言涌现是「文字接龙」，工具调用要输出结构化 JSON，是行为不是语言，必须专项训练
有 SFT 就够了	SFT 解决「会不会调」，RLHF 解决「该不该调」，两个阶段缺一不可

再按这张框架组织答案：

层次	要点
SFT	大量带完整调用流程的示范对话，让模型学会「怎么调」；短板是行为边界感弱，简单问题也先调工具
RLHF	生成多样回答 → 人类打分 → 训练奖励模型 → 强化学习调整主模型，学会「什么时候调」，能直接回答就不调
运行时	Function Calling：schema 传入 → 模型输出 tool_calls JSON → 代码执行回填 → 再回答
加分项	RLAIF：让 AI 打分替代人类评分，低成本可规模化

追问预案：

「为什么预训练学不会工具调用？」——预训练的目标只是预测下一个 token，输出特定格式的调用动作属于行为塑造，预训练数据里没有结构化的调用示范，必须靠带标注的专项数据训练。
「SFT 的训练样本从哪来？」——通常是人工构造的对话模板 + 模型模拟工具结果自动生成，再人工抽查修正；规模化主要靠合成数据流水线。
「奖励模型是怎么训出来的？」——收集人类对同一问题多个回答的打分或排序，训练一个模型去预测分数，学的就是「人类偏好」本身。
「RLAIF 和 RLHF 有什么区别？」——打分者从人类换成更强的 AI 模型，省人力、可规模化；代价是 AI 裁判本身可能带偏见，质量上限取决于裁判模型。

参考