腾讯二面：做了三个 Agent 项目，“大模型怎么学会调工具“都说不清，面试官直摇头

昨天一个读者给我发了条很长的消息说他腾讯二面挂了挂在一个他怎么也没想到会被问的问题上。他简历上写了三段 Agent 项目经历LangChain、Function Calling 用得很溜面试的时候项目拆解也讲得挺顺。面试官一直在点头他心想稳了。‍然后面试官突然问了一句“你天天在用 Function Calling那你能说说大模型这个能力是怎么来的吗它怎么就’学会’了看到工具描述之后输出一段 JSON”‍♂️他愣了一下说“应该是……微调出来的”‍面试官追问“微调分好几种SFT 和 RLHF 在工具调用这件事上分别解决了什么问题”‍♂️他支支吾吾说了句SFT 教格式RLHF 教质量就再也说不下去了。‍面试官最后说“你用了三个项目的 Function Calling但对它的训练原理一无所知。这就像一个司机开了五年车却不知道发动机怎么把油变成动力。能开但修不了车。”这件事我觉得特别有代表性。做 Agent 开发的人太多了但大部分人对工具调用的认知停留在调 API的层面 ——知道怎么定义 tools 列表、知道怎么解析 tool_calls 返回、知道怎么把结果塞回 messages。但往下追一层 ——模型为什么能这样做这个能力是怎么训练出来的能答上来的人少之又少。今天把这道题从头到尾讲透。简要回答大模型的工具调用能力不是天生的是后天训练出来的分两个阶段。第一个阶段是 SFT监督微调。简单说就是给模型看大量正确的工具调用示范——一条条精心构造的训练样本每条都完整展示了用户问了什么 → 有哪些工具可用 → 该不该调 → 调哪个 → 参数怎么填 → 结果回来之后怎么回答。模型在几十万条这样的样本上反复训练就学会了这一整套动作流程。第二个阶段是 RLHF基于人类反馈的强化学习。SFT 教会了模型怎么调但没教会它什么时候该调、什么时候不该调。RLHF 的作用就是通过人类的偏好反馈帮模型建立起判断边界——简单问题直接回答别画蛇添足去调工具需要外部数据的问题才去调。面试的时候如果被问到这个话题只说微调出来的等于什么都没说。能把 SFT 和 RLHF 各自解决什么问题讲清楚再点到训练数据的构造方式和运行时的调用流程才是一个完整的回答。详细解析先搞清楚原始大模型为什么不会调工具这个问题看起来很基础但它是理解后面所有内容的前提。大模型在预训练阶段做的事情本质上只有一件给一段文本预测下一个 token。它在互联网上几乎所有的公开文本上训练过——百科、新闻、论文、代码、论坛帖子……但整个训练过程都发生在纯文本的世界里。模型从来没有操作过任何外部系统也从来没有见过输出一段 JSON 触发一次 API 调用这种行为模式。你可以这样类比一个人从小到大只读书、不动手。他读过无数本关于烹饪的书知道热锅凉油四个字怎么写但从来没有摸过锅铲。你突然把他扔进厨房递给他一把铲子说炒个菜他是没法直接上手的——他对炒菜的认知还停留在文字描述层面没有变成可以执行的动作模式。原始大模型面对工具调用的处境也是一样的。你在 System Prompt 里告诉它你有一个查库存的工具它能理解这句话的意思甚至可能回复一句好的我来帮你查一下库存——但它不会输出一段结构化的 JSON 调用请求因为它的训练数据里从来没有这种格式的输出。所以工具调用能力必须靠后天专门的训练来注入。接下来就是 SFT 和 RLHF 各自登场的环节。SFT 阶段教模型看示范、学动作SFT 的全称是 Supervised Fine-Tuning监督微调。如果类比到职场SFT 就像新员工入职培训的第一周师傅领着你手把手演示流程——“遇到这种情况该填这个表走这个审批”你看十遍二十遍自然就学会了。具体到工具调用SFT 要做的就是构造大量标准示范给模型看。每条训练样本是一个完整的多轮对话里面至少包含五个部分第一部分是系统消息列出当前可用的工具清单。每个工具的名称、功能描述、参数定义都写得很详细——这就相当于给模型发了一份工具使用手册。第二部分是用户的提问。比如帮我查一下深圳明天会不会下雨。第三部分是模型应该输出的工具调用请求——注意这里不是自然语言回答而是一段格式规范的 JSON。类似于{tool_calls: [{name: check_weather, arguments: {city: 深圳, date: 明天}}]}。这段 JSON 就是模型需要学会输出的标准答案。第四部分是工具执行后的返回结果。训练时这一步是模拟出来的比如返回深圳明天小雨转多云22-28°C。第五部分是模型拿到工具结果后生成的最终回答。它需要把结构化的数据翻译成用户友好的自然语言“深圳明天有小雨建议带把伞气温在 22 到 28 度之间。”模型在几十万条甚至上百万条这样的样本上训练就能学会整套链路读懂工具说明 → 判断要不要调 → 选对工具 → 把参数填对 → 拿到结果后组织自然语言回答。训练数据从哪来主要两个渠道。一是人工标注——工程师构造问题和对应的工具调用标准答案质量最高但成本也高通常用于制作核心种子数据。二是用更强的模型比如 GPT-4自动批量生成——给它一批工具定义和问题让它生成对应的调用样本然后人工抽检质量。这是目前业界的主流做法效率高、成本低、可规模化。SFT 的一个关键短板SFT 教会了模型怎么调工具但它有一个明显的盲区模型不太会判断该不该调。这是因为 SFT 的训练数据绝大多数都是需要调工具的正样本——毕竟你要教模型学会调用工具当然得给它看调用工具的示范。但这导致了一个副作用模型训练之后会变得过度热衷调工具。你问它3 乘以 7 等于多少它不直接说 21反而去调一个计算器工具。你问它太阳从哪边升起它可能去调搜索引擎搜一下。这些问题它本来就知道答案完全不需要工具帮忙但它还是调了——因为在训练数据里调工具这个动作得到了太多正向强化模型形成了一种有工具就调的惯性。这个问题SFT 自己解决不了。需要第二阶段的 RLHF 来矫正。RLHF 阶段教模型什么时候该克制RLHF 的全称是 Reinforcement Learning from Human Feedback基于人类反馈的强化学习。如果 SFT 是新员工的入职培训RLHF 就是他工作了几个月之后主管根据他实际表现给的持续反馈这件事处理得好加分那件事过度操作了减分。时间一长他就知道了什么场景下该积极行动、什么场景下该保持克制。RLHF 的流程分四步。第一步让 SFT 之后的模型对同一个问题生成多种不同的处理方式。比如面对法国的首都是哪里这个问题模型可能生成三种回答直接回答巴黎、调搜索工具查一下再回答、调了工具但参数填错了。第二步让人类标注员给这些回答排序。这个例子里显然直接回答巴黎最好调工具但答对了次之调工具还填错参数最差。标注员的偏好数据记录了人类在不同场景下对该不该调工具的判断。第三步基于这批偏好数据训练一个专门打分的小模型叫奖励模型Reward Model。它不回答问题只负责评估——给一个回答打个分预测人类会不会喜欢这个回答。第四步用奖励模型的打分信号去持续优化主模型。简单来说就是让模型不断尝试不同的回答策略奖励模型打分高的策略被强化打分低的被削弱。经过几轮迭代模型就形成了更精细的判断力常识问题直接答、需要实时数据的才调工具、一个工具能搞定的不要调两个。值得一提的是现在业界也在用 RLAIFAI Feedback替代人类标注——用另一个大模型来充当标注员的角色做偏好判断。成本更低、速度更快效果和人工标注的差距越来越小。训练完之后运行时到底发生了什么理解了训练过程再来看运行时的调用流程就清晰了。当你的应用代码调用模型 API 时你会把两样东西一起传过去用户的问题以及当前可用的工具列表JSON Schema 格式的工具定义。模型收到之后做的第一个判断是这个问题需要工具吗如果不需要比如用户只是打了个招呼它直接输出自然语言回答完事。如果需要工具模型不会直接输出最终答案而是返回一段tool_callsJSON——告诉你我要调哪个工具、参数是什么。此时模型就停了。接下来轮到你的应用代码出场。你解析这段 JSON找到对应的真实函数执行它拿到结果。然后你把工具执行结果以role: tool的消息格式塞回对话历史再次调用模型。这一次模型有了工具返回的真实数据就能组织出一个基于事实的自然语言回答了。整个过程本质上是两轮对话加中间一步执行。模型全程只做决策不做执行。这个决策与执行分离的设计非常重要——它意味着你可以在执行层做权限控制、参数校验、沙箱隔离而不用担心模型直接操作系统资源带来的安全风险。举个代码层面的例子让你更直观地感受这个流程# 伪代码Function Calling 的运行时闭环import json# 第一轮把工具定义和用户问题一起传给模型response llm.chat( messages[{role: user, content: 帮我查一下杭州明天的天气}], toolsweather_tool_schema # 工具说明书)# 模型判断需要调工具返回 tool_callsif response.finish_reason tool_calls: call response.tool_calls[0] func_name call.name # get_weather func_args json.loads(call.arguments) # {city: 杭州, date: 明天} # 你的代码去真正执行 result execute_tool(func_name, func_args) # 第二轮把执行结果喂回模型 messages.append(response.message) messages.append({role: tool, tool_call_id: call.id, content: result}) final llm.chat(messagesmessages, toolsweather_tool_schema) print(final.content) # 杭州明天多云气温 18-25°C适合出行。注意这段代码里模型做了什么——它只是输出了一段 JSON 说我要调 get_weather参数是杭州和明天。它既没有访问网络也没有调用任何 API。真正干活的是你写的execute_tool函数。面试里为什么爱问这道题这道题的区分度极高因为它直接暴露了你对 Agent 技术栈的认知深度。会用 Function Calling 的人很多。但大多数人的认知链条是这样的定义 tools → 调 API → 解析 tool_calls → 执行 → 返回结果。这条链条是运行时的操作流程不涉及任何原理。面试官一追问这个能力怎么来的链条就断了。而真正理解原理的人脑子里的链条更深一层预训练阶段模型不具备工具调用能力 → SFT 阶段通过示范数据教会模型输出结构化调用请求 → RLHF 阶段通过偏好反馈教会模型判断什么时候该调什么时候不该调 → 运行时模型只做决策宿主代码做执行。这条链条从训练到推理是完整的。容易翻车的第一个点混淆 SFT 和 RLHF 的分工。有人说SFT 教格式RLHF 提升效果——这太模糊了。精确的说法是SFT 教的是工具调用的完整行为模式包括识别工具描述、判断是否需要调用、生成结构化 JSON 请求、根据返回结果生成最终回答RLHF 教的是在什么场景下应该调用、什么场景下不应该调用也就是建立调用的边界感。容易翻车的第二个点以为 Function Calling 是模型自己去执行。面试官问大模型是怎么查天气的如果你说它自己去调 API说明你对执行流程的理解是错的。模型不执行任何东西它只输出一段 JSON 指令。真正发起 HTTP 请求、访问数据库、执行代码的始终是你的应用程序。容易翻车的第三个点说不清训练数据是怎么来的。面试官可能追问SFT 的训练数据怎么构造如果你只说标注出来的就结束了会显得很浅。能补充说核心种子数据靠人工标注保证质量大规模数据靠更强的模型批量生成再人工抽检显得你对工业界的实践有了解。如果你在面试里能把上面这些点串起来讲清楚再加一句我在项目里实际遇到过模型过度调工具的问题后来我在 Prompt 里加了明确的指导规则让模型只在确实需要外部数据时才触发调用误调率降了不少——这种带实战经验的补充会让面试官觉得你不是在背概念。写在最后Function Calling 是当前 Agent 开发的基石技术几乎所有的工具调用、外部系统对接都建立在这套机制上。但太多人只把它当成一个API 的使用方式来学知道怎么传 tools 参数、怎么解析返回值就觉得自己掌握了。真正的理解应该再往下挖一层。模型为什么能在看到工具描述之后输出正确的 JSON因为 SFT 阶段看了几十万条标准示范。模型为什么不会对所有问题都傻乎乎地调工具因为 RLHF 阶段通过人类偏好建立了判断边界。模型为什么不直接执行工具而是输出 JSON因为架构设计上刻意做了决策与执行的分离安全性和灵活性都在这一层体现。这些东西不是你在 LangChain 文档里能读到的也不是 OpenAI 的 API 教程里会教的。但恰恰是面试官最喜欢问的——因为它能一眼区分出调过 API 的人和理解这套系统的人。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】