让 AI 自己当数据工程师：从零自主策划训练数据，把学生模型涨了 57.29%

核心摘要

模型专业化这件事，绕不开一个老大难——高质量领域数据。过去我们怎么做的？人去定 schema、人去写 prompt、人去清洗、人去配比。这篇论文问了一个挺直接也挺刺激的问题：能不能让 LLM 自己把这一套端到端跑下来？不是辅助人，而是真的自己当数据工程师。

作者把这事儿正式定义成一个新任务——Autonomous Agentic Data Engineering，给了一个干净的执行+评估环境，让 agent 自己 plan、自己写代码调教师模型生成数据、自己拿学生模型跑后训练、自己看反馈再迭代。结果是 GPT-5.2 在不给任何种子数据的情况下，从零跑出了 57.29% 的相对性能增益，在 Science 任务上甚至能超越人工策划的数据。

但这篇论文真正值钱的地方不是那个 57.29%——是它清清楚楚把 LLM 当数据工程师时的能力边界、典型崩盘姿势、能力维度都拆开给你看。我读完最大的感受是：这套思路对工业界做小模型蒸馏的同学，启发非常实用。

arXiv 2605.30407 | 代码：github.com/zjunlp/DataAgent

为什么要让 AI 自己做数据工程

先聊一个我自己踩过的坑。

之前给一个垂直业务做小模型蒸馏，整套流程是这样的：业务专家提需求 → 算法同学设计 prompt 模板 → 调大模型批量生成 → 人工抽检筛掉一波 → 训练 → 上评测 → 发现某个子能力不行 → 回过头改 prompt → 再生成一批……反复几轮，时间和人力都耗在"调数据"上。

整个过程里，唯一不在循环里的是反馈信号。我们靠经验判断"这批数据可能不够多样"、"这个分布偏了"，但其实没人能保证判断准。真正客观的反馈——学生模型跑完之后的评测分——拿到的时候已经是几天后了，再回头改也是凭感觉。

所以一直有一个朴素的想法：能不能让这个 loop 自己转起来？让一个 agent 来 plan、生成、根据评测分自己改？

这篇论文就是把这个朴素想法做成了一个标准任务。它的关键贡献不是"做出了一个超强的数据工程系统"，而是第一次把这个问题形式化为可测量的能力——给定固定的教师模型、固定的学生模型、固定的目标领域，agent 能不能自主把数据这件事做到底。

图 1：整个范式很简洁——LLM 当数据工程师，自己跑完一整圈数据策划，靠学生模型训完之后的评测反馈来推动下一轮迭代

形式化讲是这样的：

工程视角翻译一下：固定学生模型 \(\mathcal{M}_S\) 和教师模型 \(\mathcal{M}_T\)，agent 输出一套数据策划方案 \(\mathcal{P}_{\mathcal{A}}\)，目标是让学生模型在目标领域上的评测分 \(\mathcal{E}\) 最高。

这个目标函数挺漂亮——它把"数据"当成一个可优化变量，而不是一个静态的人工产出物。

框架长什么样：一次过 vs 闭环优化

整套系统的设计很克制，没有花里胡哨的组件，就两套 agent 流程对照来看。

图 2：(a) 环境层覆盖 Science、Code、Finance 三个领域，agent 拿到任务设置和过程反馈；(b) agent workflow 有两种——One-Shot 一次过提交，Iterative 多轮自我改进

环境层：把数据策划当成一个"沙盒任务"

这个设计我觉得挺关键的。整个数据工程被装在一个隔离的、预算受限的执行环境里： - agent 只能读到任务描述、几条数据示例、教师模型 API - agent 不能直接写数据进文件，所有数据必须通过调用教师模型生成——这是为了防止 agent 偷懒直接编内容 - agent 提交的产物是 submission.json（1000 条训练数据）和 code.py（生成代码） - 学生模型 LLaMA-3.1-8B-Instruct 在这 1000 条上做后训练，在私有测试集上跑评测，分数返回给 agent

这套约束的精髓在于"教师模型固定 + 学生模型固定"——所有差异都来自 agent 怎么策划数据。变量被压到最小，对比就干净。

Iterative Agent 的四个动作

闭环里 agent 的行为被拆成四个原子操作，每个都对应一类失败模式：

这四个动作的设计其实暗藏一个判断——LLM 写代码的失败模式和工程师不一样。它特别容易在"格式约束"和"数据数量"上栽跟头，所以 Debug 和 Repair 必须分开处理。后面看错误分析的时候会再聊这一点。

核心实验：57.29% 这个数到底意味着什么

主表先看一眼

Table 1 关键数据（GPT-5.2 作为 agent，Qwen3-30B-A3B 作为教师，LLaMA-3.1-8B-Instruct 作为学生）

几个值得停下来咂摸的点：

第一，Iterative 比 One-Shot 多涨了 16.56 个百分点。这其实是反馈循环本身的价值——同样的 agent，同样的教师学生，唯一区别是有没有"看一眼评测分再改"，效果差了一截。

第二，from Scratch 居然比 with Seed 还高一点（57.29 vs 56.01）。这事我盯着看了一会儿——理论上有种子数据应该更稳，但 from Scratch 在 Code 和 Finance 上反而更好。我的理解是：种子数据可能给了 agent 一个先验，反而让它在某些领域少做了探索。这是个挺有意思的现象，值得后续工作细究。

第三，跨领域的不均衡。Science 涨幅惊人（基线 16.74% → 70.58%），Code 中等（21.18% → 50.68%），Finance 看起来涨幅最小（39.93% → 50.60%）——但其实 Finance 基线就高，进一步提升空间小。这个分布告诉我们：LLM 当数据工程师的能力，和领域形式化程度强相关。Science 有清晰的题目结构，agent 容易把握；Finance 偏文本理解，反馈信号噪声大。

不同 agent 的表现差异

这表里有个特别值得说的发现——弱 agent 从迭代框架里获益更大。DeepSeek-V3.1 单轮只有 12.5%，但加上闭环迭代直接干到 57.65%，提升超过 45 个点。Claude-4-Sonnet 也类似。

这事的含义其实挺深的：反馈循环本身比 agent 单点能力更重要。这跟我们做工程的直觉一致——一个能"试错→看结果→改"的笨工程师，长期效果通常优于一个"一锤子买卖"的聪明工程师。

迭代到底优化了什么：一个有点反直觉的发现

图 3：迭代曲线——前 8-15 轮拿走主要收益，之后基本走平；公开分作为贪心选择信号能保住整体上升趋势

迭代的形态是先快速上涨，10 轮左右接近平台期。这个数对工程实践很有参考价值——如果你也想搭这种 loop，第一次实验跑 15 轮足够看清趋势，不用上来就跑 50 轮浪费算力。

但更有意思的是 Figure 4 揭示的——迭代到底改的是数据的什么属性？

图 4：六个内在指标的雷达图——指令难度 LLM 已经能匹配人工，但指令多样性差距明显；迭代主要在拉响应多样性，对响应质量改进有限

这张图给了一个挺反直觉的答案：

LLM 生成的数据"质量"够高，但"多样性"是真不行。

具体来说： - 指令难度：LLM 一上来就能匹配人工水平。这件事其实不意外——大模型本来就见过海量难题 - 指令多样性：LLM 生成的题目高度雷同，重复率明显高于人工 - 响应质量：迭代之后只有边际改进 - 响应多样性：迭代后稳定上升，是主要受益维度

我盯着这个结论想了一会儿——它其实在说，自动化数据工程的瓶颈不在难题本身，而在如何换着花样做难题。这跟人写题库的经验高度一致：让一个老师出 100 道题不难，难的是让这 100 道题覆盖 100 个不同的解题套路。

这个洞察对工程上有直接指导意义：如果你在做数据合成，与其卷 prompt 让模型出更难的题，不如想办法把多样性撑起来。比如显式枚举子主题、强制覆盖不同解题模式、用聚类去重等。

LLM 当数据工程师，最容易在哪儿翻车

这部分是我读这篇论文最享受的——作者很坦诚地把 agent 的失败模式拆给你看。

图 5：失败类型分布——缺乏数量保证意识占主导，Science/Code 这种格式约束严的领域格式处理失败率高；Claude-4-Sonnet 在 Code/Finance 上过度工程现象尤其明显

第一类：数量数不清

这是占比最大的失败类型，听起来傻，但其实是 LLM 的本质短板。agent 会写一段过滤逻辑——"如果这条数据不符合某某标准就丢掉"——然后丢着丢着，1000 条变成了 600 条，过不了数量检查。它没有动态补数据的意识。

我看到这一类失败的时候笑出声了——这跟我之前调试一个 RAG 流水线碰到的情况一模一样。你让 LLM 写一段 chunking 代码，它会写得很认真，但你问"如果某些段落被过滤掉了你会怎么办"，它要么答不上来，要么补一段看起来合理但实际跑不通的兜底逻辑。

这背后的根本问题是：LLM 的代码思维偏"线性流程"，缺乏"集合保证"的概念。它能写出"对每条数据做 X"，但写不好"确保最终集合大小为 N"。

第二类：格式处理弱

Science（LaTeX）、Code（可执行代码）这种格式约束严的领域，agent 经常在格式上掉链子。生成的题目 LaTeX 解析失败、生成的代码没法跑，就被环境拒绝了。

第三类：过度工程

这条特别针对 Claude-4-Sonnet——它在 Code 和 Finance 上的过度工程错误率高达 52.63% 和 59.31%。具体表现是：写一套又长又复杂的策划流程，结果输出被截断，submission 直接挂掉。

读到这儿我有点想笑——这其实和 Claude 的人格特征一致，它本来就喜欢"做完整、做漂亮"，在这种约束受限的任务里反而是个累赘。

还有两个更深层的失败

除了表层的提交失败，作者还分析了两个"提交成功但训练效果烂"的失败：

分布偏移：Science 任务里，agent 硬编码了一段逻辑，把 50% 的数据预算砸在 5 个特定主题上，结果学生模型严重过拟合，丧失了泛化能力。这是一个典型的"agent 自作聪明"——它觉得"集中火力打几个高分领域更划算"，但完全忽略了灾难性遗忘。

朴素规则增强：Code 任务里，agent 用正则表达式无差别替换数值搞数据增强。问题是数值在控制流里有不同语义角色（边界条件、循环计数、阈值），无差别扰动直接破坏了语义一致性。

这两个失败让我意识到一件事——当前的 LLM agent 还不太理解数据是有结构语义的这件事。它会用工程师的工具（正则、过滤、采样），但用得没有工程师的判断力。

自主代理 vs 人工：超越的可能性

这是论文里我觉得最有冲击力的一组对比。

Table 2 数据：在 Science 任务上，自主 agent 加种子数据已经超过了人工

这个结果挺值得停下来想想的。带种子数据的自主 agent 比人工策划还高 8 个点。

但我得给这个结论降一下温——

第一，对比的"Human"是固定的人工数据集，是死的。而 agent 是在每一轮根据评测分调整的，是活的。这其实是把"一次性人工"vs"迭代式自动化"对比，对人工不太公平。

第二，Science 任务的私有测试集有特定分布，agent 通过迭代实质上在做某种 test-time adaptation——它一直在向测试集靠拢。这是不是真正的"超越人工"，还是在 overfit 到 evaluation distribution，需要更严谨的留出实验。

第三，作者也明确说了，整个评估只覆盖 QA 类任务（因为反馈信号好拿），开放式生成、多轮对话这些场景没碰。所以结论的适用范围是有限的。

但即便这样，这个数据点足够让人兴奋——自动化数据工程的天花板，可能不止"接近人工"，是真的有机会超过。

几个值得深挖的点

关于"反馈循环 > agent 智能"这件事

我前面提到弱 agent 在迭代框架下涨幅更大。这其实是一个很普适的现象，对工业实践有直接指导意义：

如果你的 base model 不是最强的，优先把 evaluation loop 做扎实，比研究怎么 prompt 更重要。一个能跑 20 轮的笨 agent，远胜于一个跑 1 轮的聪明 agent。

关于种子数据的角色

论文显示种子数据在某些设置下反而拖累，这事还挺值得想的。我猜想是这样：种子数据给了 agent 一个"基准答案"，反而压抑了它的探索范围。Code 和 Finance 这种需要多样性的领域，agent 可能更需要从零摸索。

工程上的启示是：做数据 bootstrap 的时候，与其给 agent 一堆样本让它模仿，不如给它一个清晰的评测函数让它探索。

关于 agent 本质上不擅长的事

读完这篇我对 LLM agent 的能力边界有了更清晰的体感： - ✅ 把握任务整体结构、写代码生成数据、根据反馈调策略 - ❌ 数集合大小、严格遵守格式约束、理解数据的语义结构

如果要把这套方法工业化，最该补的不是 agent 智能，而是 agent 周边的工程脚手架——比如显式的数量监控、格式校验器、语义结构感知工具。

我的判断

先说价值：

这篇论文最核心的贡献不是"做出了 SOTA 的数据生成系统"，而是把"自主数据工程"这件事从模糊的工程实践，变成了一个可测量、可对比、可演进的研究任务。它的环境定义（固定教师固定学生、隔离执行、统一评测）很干净，是这个方向后续工作的好基线。

57.29% 的数确实漂亮，但更值钱的是 Figure 4 和 Figure 5——它告诉你 agent 现在能做什么、卡在哪里、应该往哪儿改。这种诊断性贡献对工业界比 SOTA 数据更有用。

再说局限：

第一，只覆盖 QA 类任务。开放式生成、长上下文、多轮对话、Agent 训练数据，这些更难评估的场景没被纳入。论文里提到的"57% 提升"在这些场景下会不会复现，是个问号。

第二，算力门槛不低。每个完整迭代周期（合成 1000 条 → SFT LLaMA-8B → 跑评测）需要 1-2 小时。要跑出有意义的迭代曲线，单个领域至少 15 轮，这是真金白银的算力。

第三，与同期工作的差异化。市面上类似方向（如各种 self-instruct 变种、自动 prompt 优化）已经不少，这篇的独特性主要在"端到端 + 反馈驱动 + 多领域"的组合，而不是某个单点突破。如果你已经在做类似的事，这篇的环境设计值得借鉴，但不要期待方法上有颠覆。

工程启发：

如果你也在做小模型蒸馏或者垂直领域适配，这篇值得花时间细读。几个直接可借鉴的点—— 1. 把"评测分"作为数据策划的反馈信号闭环，而不是事后审查 2. 数量保证、格式校验、语义结构 这三个脚手架要显式写进流程，别指望 agent 自己想到 3. 多样性比难度更难做对，与其卷 prompt 升级题目难度，不如显式扩展子主题分布 4. 优先做 Iterative，from-scratch 起手，给 agent 探索空间往往优于给种子数据约束它

写在最后

读完最大的感受是——自主数据工程这件事，已经从"理论上可行"进入了"工程上可比较"的阶段。它离能直接工业化还有距离，但已经清晰到可以给后续工作画路线图了。

下一个值得追的方向我猜是这几个： - 把 QA 之外的开放式任务纳入进来 - 把"agent 如何理解数据语义结构"这个能力短板单独研究 - 把整个 loop 在更小的 student model 上跑（让算力门槛降下来）

我会持续盯一下这块。如果你们团队也在做类似的方向，欢迎留言聊聊。

论文标题：Exploring Autonomous Agentic Data Engineering for Model Specialization arXiv 编号：2605.30407 代码：https://github.com/zjunlp/DataAgent

觉得有启发的话，欢迎点赞、在看、转发。跟进最新 AI 前沿，关注我