但凡尝试过用 AI 搭 RAG 知识库，或者搞过数据清洗、数据合成的，一定经历过这样的崩溃：
花了好几个小时，让 LLM 跑数据处理流水线，眼看快跑完了，突然发现某个环节的字段名写错了。一个字母的差别，前面几百块钱的 API 费用、几小时的 GPU 时间，全白费了。
尤其是现在大家都爱聊 Skills，让 Agent 来写代码，执行任务。但用它来处理数据，很难。目前市场上的 Skills 大多数都集中在写组件、写脚本、出报告等轻任务上，这类任务成本低，有足够的试错空间。而在高质量数据清洗与合成这个场景下，Agent 用不好就会变成一台烧钱机器，一次流水线跑下来，几十上百美元秒没。
那怎么办？北大 DCAI 团队近日开源的 DataFlow-Skills，专门给 Agent 装上了防烧钱的安全带。
它把 DataFlow 这个成熟的数据处理系统里的工程经验，如静态校验、断点续传、字段依赖检查等全部打包成了 Agent 能听懂、能执行的规则。只要在 WebUI 里像聊天一样说需求，Agent 就会先想清楚再动手，先验证后再大规模执行任务。
2026 年，影响 LLM 团队迭代速度的，已经不再只是算力和算法，而是谁能更快、更低成本地生产高质量训练数据。问题在于，训练数据处理往往会吞掉整个 AI 项目 80% 以上的工程精力，清洗脏数据、反复验证……大量团队仍在重复造轮子。
DataFlow 的目标就是解决这个痛点，通过自动化流水线，将原始数据如 PDF、代码、杂乱对话清洗成大模型训练，以及 RAG 知识库搭建中直接可用的训练数据，如 SFT、RL、CoT、QA 对等等；也可基于少量种子数据，大批量合成高质量训练数据，进而支持高质量的模型训练、RAG 系统搭建。
DataFlow 开源仓库：https://github.com/OpenDCAI/DataFlow
▍一套懂数据、懂 AI、会省钱的 Skills
先看一条典型的数据准备流水线长什么样：解析 PDF → 切分文本块 → 用 LLM 生成问答对 → 评估质量 → 过滤低分 → 精炼表述。每一步都可能踩坑：
让 LLM 生成的字段名叫
question，下一步过滤算子却去找query——找不到，流水线炸了忘了过滤掉空回答，结果训练时模型学了一堆“嗯…啊…”
用的通用生成器根本不适合多跳 QA，生成的问题质量一塌糊涂
……
面对高试错成本的数据流水线，普通 Agent 只会盲目烧钱，而装备了 DataFlow-Skills 的 Agent 懂得先规划、再执行、严格遵循字段契约。
开发者可以直接在 DataFlow WebUI 页面右侧的 “DataFlow 助手” 对话框中，使用自然语言对话，让 Agent 基于 DataFlow-Skills 自动生成、修改和调试数据处理工作流，同时还能直观看到整条 Pipeline 的拓扑结构与算子编排过程，节省人力与时间成本，实现数据工作流的自动化高效构建。
Skills 分工：一个搭流水线，一个开发，一个查资料
DataFlow-Skills 目前有三个，一个负责搭流水线，一个当资深工程师，一个提供底层知识。
generating-dataflow-pipeline —— 流水线生成器。给定任务目标和 JSONL 样本文件，自动推理应该使用哪些算子、以什么顺序串接、字段如何流转，最终输出完整可运行的 Pipeline 代码。
dataflow-dev —— 开发专家助手，一个多合一的路由型 Skill，能根据开发者意图自动切换到对应工作流，包括新建算子、新建 Pipeline、新建 Prompt、诊断报错、代码规范审查、知识库同步，像一个熟悉 DataFlow 全部架构的高级工程师一样提供支持。
core_text —— 算子级 API 参考，包含 8 个 generator、3 个 filter、2 个 refiner、5 个 evaluator。当 pipeline skill 需要超出 6 个核心算子之外的扩展算子时会查阅它。不直接调用，是供其他 skill 阅读的资料。
DataFlow-Skills 之间的协作逻辑很清晰，大多数时候，用generating-dataflow-pipeline直接生成流水线就够了。需要定制算子时，dataflow-dev会负责生成新的 Operator、补全 Prompt、修复报错，再由core_text提供底层规则与能力参考，形成“规划 → 开发 → 检索知识”的闭环。
三条铁律，让 Agent 更好用
DataFlow-Skills 之所以有效，核心在于三个关键的设计决策。
决策一：先推理，再生成。所有 DataFlow-Skills 都要求 Agent 执行两阶段输出：
第一阶段，输出一份中间决策——选了哪些算子、为什么选它们、字段如何流转、每一步的依据是什么。这是一份结构化的推理记录。第二阶段才输出最终的代码和集成说明。
因为在高成本场景下，可审计性和可追溯性比生成速度更重要。 如果 Agent 直接甩出一段代码，用户很难判断它的决策是否合理。但如果先看到推理过程，就能在消耗任何资源之前发现潜在问题。
这跟 DataFlow 底层 compile() 的理念完全一致：在烧钱之前，先验证。 只不过 compile() 验证的是字段贯通性，两阶段输出验证的是 Agent 的决策逻辑。
决策二：专用优先，通用兜底。DataFlow Skills 内部维护了一套强制性的算子选择策略：当任务可以被专用算子覆盖时，必须使用专用算子。通用算子，如 PromptedGenerator只在没有更好选择时才启用。
举个例子，如果用户说"从这段文本中生成问答对"，Skill 不会让 Agent 用通用生成器加一段 QA 提示词来凑合，而是强制使用专门为多跳 QA 设计的 Text2MultiHopQAGenerator。因为这个算子内部有文本长度校验、句子密度检查、嵌套输出结构处理等一系列通用生成器不具备的逻辑。
这条规则的本质是：Skill 不应该只告诉 Agent "你能用什么"，还必须告诉它 "在什么情况下你不能用什么"。 负面约束往往比正面指引更有价值。
决策三：字段依赖是一等公民。数据流水线中最常见的 bug 不是算法错误，而是字段不匹配——上一步输出的列叫 cleaned_text，下一步期望的输入叫 clean_text，一个字母的差异就能让整条流水线白跑。
DataFlow Skills 在 Skill 层面就把字段依赖链条嵌入了生成规则：每个算子的输入字段必须在样本数据中已存在，或由前序步骤显式生成；不允许引用尚未创建的字段；不允许覆盖用户的原始字段，除非显式要求。这意味着 Agent 在生成代码的过程中，就在执行一次心智 compile，构思阶段就被约束住了。
支持自定义 Skill
当然，再强的内置 Skill，也不可能覆盖所有行业里的数据处理需求。真正能长期演化的 Skill 系统，一定允许开发者把自己的领域经验继续沉淀进去。
DataFlow-Skills 的设计目标之一，就是让新增一个领域能力这件事，尽可能接近加一份规则文档。增加自定义算子可以在 core_text/<分类>/<你的算子>/ 下放 SKILL.md + examples/{good,bad}.md。在 generating-dataflow-pipeline/SKILL.md 的 "Extended Operator Reference" 对应分类表格里加一行，不加这行 pipeline 规划器就发现不了你的算子。
如果这个算子高频到该升为核心原语，再去同一份 SKILL.md 的 "Operator Selection Priority Rule"、"Operator Parameter Signature Rule"、"Correct Import Paths"、（如涉及新数据类型）"Input File Content Analysis Rule" 几节里补上对应条目。
▍自动化流水线，解决造数据和洗数据的难题
前面说的 DataFlow-Skills 能起作用，靠的不仅是 Prompt 写得好，更是底层的 DataFlow 系统。它的核心目标很简单：把造数据、洗数据这些最耗时耗力的脏活累活，变成一条条标准化、自动化、能跑通的流水线。
因此，DataFlow 重点做了三件事：算子设计、语法约束，以及异构算力调度。
算子设计：把数据工程沉淀成可复用原语
DataFlow 对算子采用了两层分类。第一层是“核心算子”与“领域算子”。核心算子服务于通用数据处理；领域算子则是在核心能力上的特化扩展，比如专门面向强推理、多跳 QA、数学 CoT 的数据生成算子。第二层则按数据行为划分为四类：
Generate：生成新字段
Evaluation：对数据打分
Filter：过滤低质量数据
Refine：增强或改写已有字段
一条典型流水线，本质上就是：
Generate 生成数据 → Evaluation 打分 → Filter 筛选 → Refine 优化
这种设计的目的，是把数据处理经验沉淀为可复用模块，而不是每次从零拼 Prompt。基于这套体系，DataFlow 内置了多种数据生成、改写与过滤算子。实验结果显示，经过生成与过滤后的数据，不仅质量评分更高，最终训练出的模型表现也会进一步提升。
语法限制：在烧 GPU 前先发现问题
LLM 数据工程里常见的一个烧钱问题是，流水线跑了几个小时后才发现字段名写错，跑不通。
为了避免浪费，DataFlow 在算子层面加入了强约束，比如init() 会预先定义好所有参数 ，run() 只处理字段流转 。也就是说，参数定义与数据依赖被强制拆开。基于这种结构，DataFlow 可以在运行前构建整条 Pipeline 的计算图，并通过 Compile 机制提前检查：
字段是否存在
上下游 Key 是否匹配
输出是否能被后续算子消费
是否存在字段覆盖或未定义引用
如果字段链路无法贯通，系统会直接在编译阶段报错，而不是等 GPU 跑完才失败。某种意义上，Compile 更像数据工作流里的类型检查器，验证数据能不能真正流过去。
异构算力调度：把算子铺满所有资源
DataFlow 的另一层核心能力，是基于 Ray 的异构算力调度。当下的数据处理流水线，底层通常混合了三类算子：
LLM 算子：如 QA 生成、数据改写、推理扩展
小模型算子：如分类、Embedding、质量过滤
CPU 算子：如 PDF 解析、文本切分、规则清洗
LLM 算子通常通过 API、vLLM 或 SGLang 调用即可。但在预训练与后训练中，大量时间其实耗在 PDF 解析、质量过滤、Embedding 等“小步骤”上。如果 CPU 和小模型算力无法充分并行，再强的 GPU 也会陷入等待。
DataFlow 直接把“算子”映射为 Ray 的分布式任务。开发者只需在 Operator 外包一层 ray.remote，并声明 CPU/GPU 资源需求，Ray 就会自动完成任务拆分、资源调度与集群并行执行。
最终效果也已经过验证。FlashMineru 基于 8 张 GPU 部署，实现了接近 7.6 倍加速；预训练质量过滤算子，通过 Ray 并行化后，实现约 6 倍提速。
▍典型应用：VQA 教材数据转化、强推理数据合成
除了通用的数据处理能力之外，DataFlow 还沉淀了多条面向高价值数据场景的特色 Pipeline，这些 Pipeline 本质上是在不同数据模态与场景下，对“生成—对齐—验证”这一链路的工程化实现。
在教育和学术研究领域中华，一个常见的任务是将教材、试题、学术文献等真实的、尚未被系统化提炼的专业知识转换为 LLM 可用的结构化数据。
真实教材中，题目、配图与答案往往是天然分离的，题目出现在正文中，配图嵌入在不同页码位置，而标准答案通常集中在书籍末尾或独立答案册中。这种物理位置割裂导致数据无法直接用于训练。
DataFlow 的 VQA（视觉问答）数据转化 Pipeline，可将教材与题库中的视觉问答内容，对分散信息进行跨页对齐与语义绑定，将题目文本、对应图像以及最终标准答案进行精准拼接与结构化重组。最终得到的数据可以直接用于多模态模型训练，形成完整的 VQA 训练样本。
另一个典型场景，则是强推理训练数据的构建。
在数学、代码、科学推理等任务中，真正决定模型能力上限的，往往不只是最终答案，而是中间推理过程Trajectory 是否正确、完整且可验证。但现实中的高质量推理数据极其稀缺，大量公开数据集存在推理跳步、逻辑断裂、答案正确但过程错误等问题，难以直接用于高质量后训练。
DataFlow 的强推理数据合成 Pipeline，会先基于种子问题生成候选推理路径，再对推理过程中的中间步骤进行结构化校验，包括公式推导、符号一致性、计算正确性以及最终答案匹配等；最后通过多轮过滤与质量评估，剔除存在逻辑错误或不可验证的样本，从而得到高密度、高一致性的推理训练数据。
基于该 Pipeline 构建的数据，曾在多个推理任务与竞赛场景中取得较好效果。实验结果也表明，在相同数据规模下，相较于部分主流开源推理数据集，该 Pipeline 生成的数据在模型训练效果上具备更高的数据效率。
使用仅 10K 的多领域合成样本（DataFlow-Instruct-10K），模型在数学和代码领域的表现已接近官方 Instruct 版本，且通用知识能力（MMLU）未出现退化，证明了高质量合成数据对大规模指令数据的替代潜力。
现在，这些 DataFlow 内部的数据工程能力，也已经被进一步抽象为可直接调用的 DataFlow-Skills。
过去半年大家对 Skills 的理解，大多仍停留在让 Agent 更会写代码，或是具备某个单点技能。但在 LLM 驱动的数据工程场景里，仅仅会写远远不够。每一次生成，都对应着真实的 GPU 消耗、API 成本，以及数小时级别的数据处理任务。
Agent 一旦写错字段、选错算子、拼错流水线，消耗掉的不是 token，而是真金白银。这也是为什么，DataFlow-Skills 的设计方向是让 Agent 更受约束：先推理，再生成；先 compile，再运行；先验证字段，再消耗算力。
而随着后训练、Agent、企业私有数据系统继续发展，这类“防烧钱”的基础设施，可能会比模型本身变得更重要。
有任何使用问题，欢迎查看 DataFlow GitHub 仓库中的「Community & Support」板块，与我们进行技术交流。
关于作者
梁昊
北京大学大数据科学研究中心博士，曾获北京大学校长奖学金，第一作者发表10+篇CCF-A论文/期刊。
主导 Data-Centric AI 系列开源项目设计开发，项目累计获得 5000+ Github Star，其中 DataFlow 项目荣获 ICML SeePhy 比赛冠军，智源 LIC 挑战赛冠军。同时带领团队负责 Camel，LLaMAFactory 项目的数据模块设计开发，分别获得16k+和65k+ stars。
北京大学 DCAI 团队
专注于大模型数据系统研究与 Data-Centric AI 基础设施建设，开源 DataFlow、DataFlex、One-Eval、OpenWorldLib 等多个项目。
开源项目：
DataFlow (3k+ Stars) ：一站式 LLM 训练数据准备系统 🌟
DataFlow-Skills:
DataFlex：LLM 动态数据训练框架 🌟
One-Eval：基于 Agent 的自动化大型语言模型评估框架 🌟
OpenWorldLib：统一世界模型的通用推理与交互框架 🌟
更多开源项目可查看
✦ 最新活动 ✦
5 月 19 日- 21 日，赤道象限「AI 创新峰会」强势来袭。三天四大前沿论坛火力全开，深度聚焦 AI 全球突围、硬件创新与产业融合；更有 OPC 优质项目路演、年度行业权威榜单重磅发布，洞悉未来趋势。
现场不仅有月之暗面Kimi、虎博科技、FancyTech、珀乐互动、Energent.ai、像素绽放、FaceMind、MyShell等近百家顶尖AI新锐与突破企业坐镇分享，还有真格基金、锦秋基金、常垒资本、小苗朗程、耀途资本、阿米巴资本、峰瑞资本、华泰创新投资等一线投资机构的合伙人/高管亲临现场，论道资本新机遇。
最后席位，即刻锁定你的AI时代入场券👇
✦ 精选服务 ✦
「新探计划」由有新 Newin 联合探奇资本发起，我们关注 AI 大浪潮中持续解决真实问题的创业团队，为优质项目匹配合适的创业资源，不限于融资、宣传、产品设计以及商业化探索等。
✦ 精选内容 ✦
后键盘时代，SpeakON 们想要抢回被打字偷走的生产力
前字节产品高管拿到数千万元 Pre-Seed 轮融资，锦秋、百度风投押注 Life Agent
部署一批 7×24 小时在线，自主写代码、做报告的 AI 同事
Agent 终于有了自己的社交网络——FloatlM 发布
让 Kimi K2.6 当了一天打工人，它交了三份作业
