总述:Agent 合成数据的整体流程与核心原则
在大模型 Agent 的训练中,一个被反复验证的共识是:蒸馏得到的原始轨迹(Trajectory)≠ 可直接使用的训练数据。即使使用 GPT-4o、Claude Opus 等 SOTA 模型进行蒸馏,产出的数据也必然包含工具调用失败、思考链断裂、返回内容噪声等问题。这些原始轨迹是"行为日志",而非"教学教材"。直接使用会让模型学到试错模式而非最优策略。
因此,Agent SFT 数据工程必须遵循 "先定能力范围 → 再设计数据配方 → 最后生产与验证" 的正向流程,而非"先蒸馏一堆数据再看能训出什么"的逆向碰运气。完整的流程包含以下六个步骤:
- 确定能力范围:基于业务场景,从 Agent 能力全景图中筛选 8-15 项核心能力。
- 定义评估标准:为每项能力设定 3-5 个可测试的行为指标。
- 设计数据配方:明确每项能力对应的数据量、噪声层级、Reasoning 要求和工具组合。
- 生产数据:通过蒸馏、AI 改写、人工构造、对抗生成等多种方式混合生产。
- 质量验证:自动检查 + AI 评审 + 人工抽检三级质检。
- 训练-评估-迭代:按能力维度分别评测,针对短板补充数据。
在这一流程中,有三个贯穿始终的核心原则:
- 数据服务于能力目标:不存在通用的"最佳编辑模板",保留多少噪声、精简到什么程度,完全取决于当前要训练的具体能力。
- 分层处理而非一刀切:工具返回内容、错误重试次数、思考深度都需要按训练目的分层设计,而非统一清洗。
- 二次编辑是必选项:所有蒸馏数据都必须经过结构化精简、Reasoning 增强、噪声控制等后处理,才能进入训练管线。
以下将围绕这一流程,分项详解每个环节的具体方法论与实操要点。
分述一:Agent 能力范围的全景定义与选择策略
1.1 六大类 25 项子能力全景图
Agent 的能力体系可以系统性地划分为六大类:
| 类别 | 子能力 | 核心说明 |
|---|---|---|
| 意图理解与任务规划 | 需求澄清、任务分解、动态重规划、目标追踪、优先级判断 | Agent 区别于普通 Chatbot 的核心,决定任务能否正确启动和调整 |
| 工具使用与编排 | 工具选择、参数构造、API 文档理解、多工具编排、结果解读、Skill 加载 | 通常是数据占比最大的部分(25-30%),直接决定执行效率 |
| 信息处理与推理 | 信息提取、信息整合、事实核验、数值计算/代码推理、摘要生成 | 连接工具执行与最终答案的桥梁 |
| 执行控制与鲁棒性 | 错误识别、错误恢复、超时/限流处理、循环检测与终止、状态管理、安全边界 | 最容易被忽视但决定生产可用性的关键能力 |
| 交互与对齐 | 进度汇报、结果呈现、置信度表达、拒绝与引导、风格适配 | 影响用户体验和信任度 |
| 领域专项能力 | 代码开发、数据分析、文档写作、客服/运维、研究分析 | 根据具体业务场景按需选择 |
1.2 能力选择的决策矩阵
并非所有项目都需要覆盖全部 25 项能力。推荐使用 频率 × 重要性矩阵 做取舍:
- 高频 + 核心差异化:重点投入,生产高质量专属数据。
- 低频 + 核心差异化:少量覆盖,保底数据即可。
- 高频 + 非核心:标准覆盖,使用通用模板数据。
- 低频 + 非核心:暂不做,避免分散资源。
例如,通用搜索 Agent 应全覆盖 1/2/3 类 + 重点投入 4 类;代码 Agent 则应重点投入 2/4 类和代码领域专项;内部运维 Agent 则以 4 类和运维专项为核心。
1.3 常见陷阱
- 由"有什么数据"反推能力范围:导致数据多的能力过拟合、缺的能力缺失。必须先定范围再找/造数据。
- 所有能力平均分配数据:核心能力训练不足。应按优先级加权配比。
- 能力定义过粗:如"工具使用"一项包含太多异质子能力,应拆到可独立评估的粒度。
- 忽略能力间的依赖关系:单项能力 OK 但组合起来不行,需设计跨能力的复合任务数据。
分述二:蒸馏数据的二次编辑与质量分级
2.1 为什么蒸馏数据不能直接用
以一条真实的 Agent 轨迹为例,一次任务中可能出现 8 次以上连续工具调用失败(函数未定义、语言错误、API 不存在、会话状态丢失等)。如果直接用于 SFT,模型会学到"盲目试错 → 报错 → 再试"的低效模式,而不是"先了解 API → 再精准调用"的高效模式。
2.2 三种后处理范式
| 范式 | 做法 | 适用场景 | 占比建议 |
|---|---|---|---|
| 完美轨迹构造 | 去除所有失败步骤,只保留成功路径;补全缺失的思考环节;精简工具返回 | 基础能力训练、冷启动阶段 | 40-60% |
| 鲁棒性轨迹构造 | 保留 1 次典型错误 + 正确的恢复动作;Reasoning 中显式写出错误原因分析 | 训练错误恢复能力 | 20-30% |
| 思考质量校准 | 补充任务分解和工具选择依据;压缩重复已知信息;对齐 Reasoning 与 Tool Calls | 全场景通用 | 贯穿所有数据 |
关键原则:不要保留连续 3 次以上同类错误;错误类型要有代表性;恢复动作必须是确定有效的。
2.3 Reasoning 内容的调整标准
| 问题类型 | 调整前 | 调整后 |
|---|---|---|
| 过于简单 | "让我用正确的 Python 语法来写 browser 代码" | "上次调用失败是因为使用了 JavaScript 语法。根据错误提示,这个工具要求 async Python。此外,我应该先通过 Skill 工具加载 browser 的完整 API 文档,确认哪些方法可用,避免再次调用不存在的方法。" |
| 缺少规划 | (无首轮规划) | "用户想找《武林外传》的合法免费观看渠道。我的计划:1. 先用 web_search 搜索可能的平台;2. 从结果中筛选正规平台;3. 用 browser 打开 1-2 个链接验证可访问性;4. 汇总结果给用户" |
| 与行动不一致 | Reasoning 说要用 A 工具,实际调用了 B | 对齐两者,确保推理链可追溯 |
2.4 AI 辅助编辑 vs 人工编辑
推荐的工业级流程是 AI 编辑 + 人工审核:
原始蒸馏轨迹 → AI自动清洗(去重、截断、格式修复)
→ AI辅助改写(精简错误、增强Reasoning、压缩返回)
→ 规则过滤(错误次数>3标记、Reasoning长度异常标记)
→ 人工审核/修正(抽样10-20%精审 + 边界Case全审)
→ 质量打分 & 分级入训
纯人工质量最高但不可扩展,纯 AI 可扩展但可能引入新错误。AI 编辑 + 人工审核是当前性价比最优的方案。
分述三:工具返回内容的分层处理策略
这是 Agent 数据工程中最微妙的问题。过干净会导致模型脆弱,过脏会干扰训练信号。核心原则是:噪声本身不是训练目标,抗噪能力才是。
3.1 三层处理框架
| 层级 | 占比 | 处理方式 | 训练目的 | Reasoning 要求 |
|---|---|---|---|---|
| Layer 1: 结构化精简版 | 60-70% | 提取 title、main_content、links、metadata,输出结构化 JSON/Markdown(500-2K chars) | 训练核心 Agent 能力(规划、工具选择、多步推理) | 标准推理即可 |
| Layer 2: 带噪声原始版 | 15-20% | 保留原始或半原始长文本 | 专门训练信息提取和抗噪能力 | 必须显式包含过滤过程:"忽略导航栏/广告 → 定位主内容区 → 提取关键信息 → 忽略评论区" |
| Layer 3: 渐进式噪声版 | 10-15% | 对同一任务构造 0%/30%/70%/100% 多个噪声梯度版本 | 训练不同噪声水平下的稳定性 | 共享相同最终答案和核心 Reasoning,仅输入端噪声程度不同 |
⚠️ 关键提醒:如果保留了噪声但 Reasoning 里没有体现过滤思考,模型只会学到"忽略噪声"的隐式行为,而不会学到"如何主动过滤"的显式能力。这等于白留噪声。
3.2 不同工具类型的差异化处理
| 工具类型 | 噪声特征 | 推荐处理 |
|---|---|---|
| Web Search | 结果列表,噪声中等 | 保留 top-5 结果的 title+snippet,去除广告/追踪参数 |
| Browser Snapshot | 极高噪声(DOM/广告/导航) | Layer1 为主,Layer2 需配过滤 Reasoning |
| API 调用 | 结构化 JSON,低噪声 | 几乎不需处理,保留原始即可 |
| Code Execution | 输出可能含 warning/deprecation | 保留 warning(真实场景常见),去除框架内部 stack trace |
| File Read | 取决于文件内容 | 长文件做分段摘要,短文件保留原文 |
| Database Query | 结构化结果集 | 保留完整结果,大结果集加 summary header |
3.3 验证方法
不要凭感觉定比例,用实验验证:
- 精简是否丢失关键信息:精简版 vs 完整版训练的模型,在相同测试集上任务完成率差异应 < 3%。
- 抗噪能力是否有效:用过 Layer2 训练的模型在含噪声测试集上应显著优于只用 Layer1 的模型。
- 噪声是否干扰核心能力:混入 Layer2 训练的模型在干净测试集上不应有显著退化。
- Reasoning 质量:人工抽检 Layer2 数据的过滤推理合理性应 > 85%。
分述四:数据生产后的质量验证与迭代闭环
4.1 三级质检体系
| 级别 | 方式 | 检查内容 | 覆盖率 |
|---|---|---|---|
| L1 自动检查 | 规则/脚本 | 格式合法性、工具名称有效性、JSON 解析、长度阈值 | 100% |
| L2 AI 评审 | LLM-as-Judge | Reasoning 质量、答案正确性、工具选择合理性、安全合规 | 100%(初筛) |
| L3 人工抽检 | 专家审核 | 边界 Case、AI 评审存疑样本、数据配方合理性 | 10-20% |
4.2 按能力维度的评估与迭代
训练完成后,不应只看整体指标,而应按能力维度分别评测:
| 能力维度 | 评估方式 | 迭代策略 |
|---|---|---|
| 工具调用准确率 | 工具选择 F1、参数正确率 | 低于阈值 → 补充工具选择对比数据 |
| 多步规划能力 | 计划完整性评分、重规划成功率 | 不足 → 增加首轮 Planning Reasoning 数据 |
| 错误恢复能力 | 错误后任务完成率 | 不足 → 补充精选的错误-恢复对数据 |
| 信息提取能力 | 噪声环境下的信息召回率 | 不足 → 增加 Layer2 抗噪数据比例 |
| 安全合规 | 对抗样本拒绝率 | 不足 → 补充安全边界和对齐数据 |
4.3 数据配方的动态调整
数据配方不是一成不变的。每一轮训练-评估循环后,应根据短板能力的评测结果调整下一轮的数据配比。这是一个持续迭代的过程,而非一次性工程。
结语
Agent SFT 数据工程的本质,是将模型的"行为日志"转化为"教学教材"。要求:
- 以终为始:先明确要训练什么能力,再决定做什么数据。
- 精细分层:对不同能力、不同工具、不同噪声水平采用差异化的处理策略。
- 持续迭代:数据配方随训练评估结果动态调整,形成闭环。
蒸馏只是起点,二次编辑和能力导向的数据设计才是决定 Agent SFT 成败的关键。

1893

被折叠的 条评论
为什么被折叠?



