1. 问题分析做 Agent 的团队很多但真正动手微调过 Agent 能力的人并不多。大部分人停留在 Prompt 闭源 API 的阶段就基本上交差了只有当你真的需要在开源模型上把 Agent 跑起来、或者对工具调用的稳定性有极致要求时才会走到微调这一步。所以面试官抛出这道题本质上是在做一次筛选——你到底是用过 Agent还是改过 Agent 的底层能力。而后半句数据集如何收集才是真正的技术深水区因为 Agent 的训练数据和普通 SFT 数据有本质区别这个区别决定了整个微调工程的难度。1.1 什么情况下才需要微调并不是所有 Agent 项目都需要微调。GPT-4、Claude 这些闭源模型本身的 Function Calling 能力已经很强了配合精心设计的 System Prompt 和工具描述大部分场景够用。真正把你逼上微调这条路的往往是以下几种情况第一种是你在用开源模型做 Agent。Llama、Qwen、DeepSeek 这些模型的基座版本工具调用能力参差不齐。有些甚至没有原生的 Function Calling 支持你不得不通过微调来教会它理解工具定义、生成结构化的调用指令。第二种是格式遵从性达不到生产要求。Agent 场景对输出格式的要求极其严格——你需要模型每次都输出合法的 JSON、准确填写工具名和参数、在该停的时候停而不是自说自话。这种守规矩的能力光靠 Prompt 约束效果有限但通过微调让模型在训练阶段就反复练习正确格式效果提升非常显著。第三种是成本和延迟的硬约束。一个微调过的 7B 模型在你的特定场景下可能比用长 Prompt 驱动的 70B 模型又快又便宜又稳。在 B2C 场景下这个差距乘以请求量就是巨大的成本节省。如果你的项目不满足以上任何一种情况大概率不需要微调Prompt Engineering 加上工程优化就能搞定。在面试中能清楚地说出什么时候该微调、什么时候不该比我微调过本身更有说服力。1.2 Agent 微调的本质理解了什么时候该微调之后下一个关键问题是你到底在训练模型的什么能力普通的 SFT 是教模型怎么回答问题Agent 的微调则是教模型怎么思考、怎么行动、怎么应对变化——这是一整套行为范式而不只是一个输入输出的映射。拆解来看Agent 微调涉及的能力至少包括四个层面。底层是格式遵从模型要能稳定输出你规定的结构化格式比如{tool: xxx, params: {...}}这样的 JSON不能多字少字不能把工具名拼错。往上是工具选择与参数构造面对用户的请求和一组可用工具模型要能选对工具、填对参数。再往上是多步推理与规划复杂任务需要多轮 Thought → Action → Observation 循环模型要知道什么时候该继续调工具、什么时候已经可以给最终回复了。最顶层是异常处理与纠错工具返回了错误怎么办搜索结果为空怎么办上一步的判断有误怎么回退这四层能力不是孤立的——如果只训练了工具调用但没训练纠错模型在真实场景中一碰到异常就会傻掉。好的 Agent 微调数据集需要覆盖所有这四个层面。1.3 数据集收集终于到了这道题的核心。为什么说 Agent 的数据集收集特别难因为你要的不是简单的问答对而是完整的交互轨迹Trajectory。一条 Agent 训练样本长这样用户说了什么 → 模型思考了什么Thought→ 决定调哪个工具Action→ 工具返回了什么Observation→ 模型又思考了什么 → 最终给出回复。这整条链路都要记录下来而且每一步都必须是正确示范。这意味着你没法像搞文本分类那样随便标注几千条数据就开练——每一条数据都是一个多轮、多步骤、带工具交互的完整场景。数据的采集难度和普通 SFT 完全不在一个量级上。实践中数据收集主要走四条路线通常需要组合使用。路线一强模型蒸馏。这是冷启动阶段最常用也最高效的方式。做法很直接用 GPT-4 或 Claude 这样的强模型来扮演你的 Agent给它同样的 System Prompt、同样的工具定义然后批量灌入用户请求让它生成完整的 Trajectory。你可以把这理解为拜师学艺——先让能力强的模型做示范然后拿示范数据去教能力弱的模型。这条路线的关键在于输入请求的多样性。如果你只准备了 50 个模板化的用户请求训练出来的模型也只能应付这 50 种模式。正确的做法是先系统梳理你的业务场景中所有可能的用户意图类别再在每个类别下用 LLM 批量生成多样化的具体表述。比如查航班这个意图可以有帮我看看周三北京到上海的飞机下周有没有便宜的京沪航线3 月 15 号首都机场出发去虹桥的航班等几十种不同说法。意图覆盖面和表述多样性直接决定了最终数据集的质量上限。路线二线上日志挖掘。如果你的 Agent 已经在线上跑着哪怕是 Prompt 驱动的版本那线上日志就是最珍贵的数据来源。每一次用户交互都会产生完整的 Trajectory你要做的是从中筛选出高质量的成功案例。筛选标准通常包括任务是否成功完成、用户有没有给负面反馈、工具调用是否全部合法、推理步数是否合理太多步可能说明走了弯路。实际操作中一般先用规则做粗筛过滤掉工具调用报错的、超过最大步数的再做人工抽检确认质量。这条路线的数据最真实、最贴合你的业务场景但前提是你得有一个已经在跑的系统。路线三人工构造种子 LLM 扩写。对于一些关键能力特别是异常处理和纠错强模型的生成质量可能也不够好这时候就需要由熟悉业务的工程师手工编写训练样本。比如你想训练模型在API 返回超时时学会重试、在搜索结果为空时学会换个关键词再搜这类场景最好由人工精心构造几十条种子样本确保每一步的思考和行动都是最佳实践。然后用 LLM 对种子做变体扩充换一种用户问法、换一个工具返回的具体数值、把两步任务改成三步——快速把几十条种子扩展到几千条同时保持核心逻辑不变。这种人工打样 机器量产的模式在成本和质量之间取得了不错的平衡。路线四开源数据集做基础底座。社区有不少可以直接用的 Agent 训练数据集。ToolBench收录了上万个真实 API 的调用轨迹覆盖面很广glaive-function-calling是大规模的 Function Calling 数据AgentInstruct是微软出品的 Agent 指令数据集Gorilla专注于 API 调用准确性。这些数据集适合作为第一阶段的通用能力训练帮模型先掌握什么是工具调用的基本范式但通常不能直接用于你的特定业务——你还需要在此基础上混入自己的领域数据做第二阶段适配。1.4 训练数据的格式收集到原始数据后还需要组织成模型能训练的格式。Agent 训练数据和普通 SFT 最大的区别是多角色、多轮次、带结构化工具调用。一条典型样本包含这些部分System角色设定 工具列表→User任务请求→Assistant/Thought模型的思考过程→Assistant/Action工具调用 JSON→Tool工具返回结果→Assistant/Thought基于结果继续思考→Assistant最终回复这里有一个非常关键的训练细节Loss Mask。在计算训练损失时不是所有 token 都应该参与。User 的输入和 Tool 返回的结果是外部信息不应该让模型去学习生成它们——只对模型自己产出的 Thought、Action 和最终回复计算 loss。这个细节处理不当模型会学到奇怪的行为比如试图预测工具会返回什么而不是真正去调用工具。格式方案上业界主要有三种选择OpenAI 的 Function Calling 格式在 ChatML 中增加tool_calls和tool角色最为通用特殊 token 方案用tool_call.../tool_call标记界定工具调用边界灵活但需要扩展词表以及纯文本 ReAct 格式Thought: ... Action: ... Observation: ...最简单但解析不够可靠。选哪种取决于你的基座模型和推理框架。1.5 数据质量数据收集完不等于能直接用。Agent 数据的质量把控比普通 SFT 更复杂——你不光要看最终回复对不对还要检查整条推理链路每一步是否合理。几个必须做的质量校验环节。Schema 合法性每一次工具调用的参数是否符合定义必填字段有没有漏类型对不对这个可以写代码自动化检查。逻辑一致性模型说我要查航班结果调了酒店接口——这种思行不一致的样本必须剔除。冗余步骤有些轨迹里模型查了一次信息已经够了又原封不动地查了一遍这种冗余不光浪费 token还会教模型养成啰嗦的习惯。结果正确性最终回复和工具返回的数据是否一致有没有幻觉——工具明明返回价格 500模型却告诉用户 300。还有一个特别容易被忽略的点刻意构造负样本。如果训练集里全是一路顺畅的幸福路径模型在真实环境中碰到工具超时、返回空结果、用户需求模糊等异常情况就会手足无措。好的训练集应该包含 10-20% 的异常场景样本——工具报错了模型怎么重试、搜索没结果怎么换策略、用户说的不清楚怎么追问。这类数据通常需要刻意构造但对生产环境中的鲁棒性提升非常大。1.6 训练策略上的实战经验最后分享几个在实践中验证过有效的训练策略。分阶段训练效果好过一步到位。第一阶段用开源的通用 Agent 数据ToolBench、glaive-function-calling 等训练让模型先掌握什么是工具调用的基本范式和格式第二阶段再混入你自己业务领域的 Trajectory 数据做适配让模型学会你的特定工具集和交互逻辑。这种先通后专的策略比直接在领域数据上训练效果稳定得多——原因也好理解模型需要先建立一般性的Agent 行为模式再在这个基础上学习具体场景。数据配比要认真调。Agent 数据和通用对话数据必须混合训练否则模型会偏科——工具调用能力上去了日常对话能力却退化了。经验上 Agent 数据占 30-50%、通用对话数据占 50-70% 比较稳妥但最终比例需要靠评估结果来微调。建评估集比建训练集更重要。维护一个 100-200 条的评估集覆盖简单调用、多步推理、异常处理等各类场景每轮训练迭代后都跑一遍。核心指标包括四个工具选择准确率、参数合法率、任务完成率、平均推理步数。没有评估集的微调就是盲人摸象——你根本不知道改了什么、改好了还是改坏了。2. 参考回答我在之前的项目中确实微调过 Agent 能力主要是在开源模型上针对业务场景的工具调用和多步推理做增强。选择微调而不是纯 Prompt 驱动核心原因有两个一是我们用的开源基座模型 Agent 能力偏弱光靠 Prompt 达不到生产可用的水平二是对格式遵从性要求很高工具调用必须严格符合我们的 JSON Schema微调后这方面稳定性提升非常明显。数据集收集是整个过程中最花精力的部分我们多条路线并行。冷启动阶段主要靠 GPT-4 做蒸馏给它同样的工具集和系统提示词批量灌入我们梳理出的各类用户意图来生成 Trajectory 数据同时对线上已有的 Agent 日志做筛选按任务完成率和用户反馈挑出高质量的真实交互记录对于异常处理这类关键场景由工程师手工构造种子样本再用 LLM 做变体扩充。多源数据混合后要做严格的质量清洗——Schema 合法性校验、逻辑一致性检查、冗余步骤过滤还要刻意补充 15% 左右的异常场景样本来增强鲁棒性。训练策略上采用了两阶段方案先用 ToolBench 等开源数据打通用能力的底再用业务数据做适配Agent 数据和通用对话数据大概四六开防止偏科。另外 Loss Mask 是一个很影响效果的细节只对模型自己产出的 Thought、Action 和最终回复算 loss用户输入和工具返回不算。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。