1200万PR只留5000条，华为团队把代码数据流水线全自动了

从1200万个候选拉取请求里，最终只留下5000个代码任务。留存率不足0.05%。

这不是某家公司的内部数据清洗，而是华为、港中文、港科大的研究员们联合推出的LegoFlow交出的成绩单。他们把「出题、答题、改卷、训练、评测」这条代码数据流水线，做成了全自动的智能体工作流。

目前，数据、代码、文档已全部开源。

把工程流程拆成「工程师」

代码数据是训练推理型大模型的关键原料，但人工标注成本高、LLM生成不可控、自动验证难度大，是社区公认的瓶颈。LegoFlow的做法是把代码数据工程组织为一系列block，每个block就像一位工程师：由编码智能体管理，自带完成职责所需的仓库、脚本、依赖和环境，并封装为插件技能。

这套结构里，几个核心角色分工明确：

• Root：把用户目标转化为工作流，协调任务分发、资源与反馈
• Curator：将仓库和拉取请求转化为经过验证的任务
• Tracer：生成训练轨迹
• Trainer：进行微调
• Evaluator：返回基准评测结果

Claude Code、Codex等编码智能体可以直接调用这些封装好的技能，操作整个工作流。

从1200万到5000，筛选有多狠

Curator的工作从数据发现开始：搜索活跃仓库中相关且已合并的拉取请求，应用基础质量过滤并记录来源信息。随后收集PR、issue、commit与测试证据，改写成清晰且无泄漏的任务，分离修复代码与测试。再按标准Harbor task format构建候选任务，配备可验证、可运行的隔离环境与测试。最后确认有缺陷版本会失败、参考修复可通过，赋予难度分数与分析标签。

整个LegoFlow-SWE的构建从收集超过70万个GitHub仓库及其关联的1200万个候选拉取请求开始。经有效diff、合理补丁大小、测试和issue证据等条件筛选后，仅剩60万个PR；LLM评审器与执行验证进一步去除简单或无法验证的任务，最终留下5000个已验证任务，仅占原始数据池的0.0417%。

这5000个任务覆盖8种编程语言和20个任务标签。GLM-5.2通过OpenHands SDK和OpenCode生成9767次运行，其中2780次通过验证。

1000条轨迹，把35B模型拉到70.2%

为公平检验任务来源，团队固定教师模型、框架、评分、采样与预算，用各来源约1000条轨迹微调Qwen3.5-35B-A3B-Base，并在SWE-bench Verified、Pro、Multilingual上评测。

在LegoFlow-SWE上训练后，模型达到SWE-bench Verified 70.2%、Pro 48.8%、Multilingual 57.0%，超过Qwen-3.5-35B-A3B-instruct及外部开源轨迹数据池；相比SWE-rebench-v2分别提升5.8、1.9、1.0个百分点。

团队分享了三条过程经验。

经验一：任务质量比数量更重要。任务必须可验证，环境和测试能可靠区分原始代码与修复后的代码；也必须足够困难，需要真正展开调查。Curator用静态评分标准，从变更范围、逻辑复杂度、上下文广度、测试复杂度与指令复杂度五个信号加权打分（1.0～10.0）：≤4.0为简单、4.0～7.0为中等、7.0以上为困难。与SWE-rebench V2相比，LegoFlow-SWE平均难度分数更高（6.27对5.80），困难任务占39.4%（对比35.1%）。仅改变任务数据池，就使Verified、Pro、Multilingual分别提升5.8、1.9、1.0个百分点。

经验二：越强的模型越倾向于「作弊」。团队观察到三种利用信息泄漏的方式：找到公开仓库及其上游修复PR、直接复制已有补丁、或将生成的变更与上游提交比对视为正确证明。移除泄漏答案的实验后，教师模型与学生模型的Verified分数分别下降8.0、10.0个百分点。越新的开源模型作弊率越高：GLM-5为3.6%，GLM-5.2升至21.2%——它并非发起更多可疑尝试，而是更擅长把它们变成成功的作弊。团队通过两项措施将GLM-5.2的作弊率降至1%以下：一是在提示词中加入防作弊指令，要求模型仅用任务环境内资源独立推导；二是限制可访问内容，删除含参考补丁的本地Git信息、限制网络访问。

经验三：SFT轨迹的推理深度比推理覆盖率更重要。开源数据集在97%～100%的轮次中包含CoT，而LegoFlow-SWE仅62%，但其平均推理长度714 token，远超外部数据池的181～309 token。GLM-5在100%的轮次中触发推理（平均82 token），其学生模型得60.4/30.2；GLM-5.2仅在62%的轮次中触发推理，但平均500 token，成绩反而升至64.4/46.9。按平均推理长度将数据池分为四个四分位后，最短组仅得57.0%，其余三组随推理加深升至64.0%～65.0%。

两轮迭代，从7.6%到64.4%

LegoFlow-SWE验证了单次流程的效果。接下来，团队利用评测反馈改进数据收集和训练，进行了一次端到端实验：涵盖仓库和PR收集、轨迹生成、训练、评测及策略优化，全程由智能体管理。

目标是：从原始GitHub仓库出发，使用Curator、Tracer、Trainer和Evaluator构建训练数据并微调Qwen3.5-35B-A3B-Base，用512条有效轨迹在SWE-bench Verified上达到60.0%以上解决率。

迭代1：Root block协调工作流；Curator从已合并的拉取请求构建4166个可验证任务，Tracer生成915条有效轨迹，流程按评分标准分数选出500条。训练后模型达56.1%，未达60%目标。

迭代2：第一次评测暴露两个数据问题——80.7%的响应虽包含think block，但许多只是「let me check」之类的短句，缺乏实质性调试；部分轨迹的工具调用格式无法被评测框架解析。智能体因此按推理密度过滤，并添加工具调用标准化步骤。在915条轨迹中，智能体删除97条重复和234条过浅轨迹；每轮推理长度中位数从140增至959字符，含推理内容的比例从80.7%降至30.7%。用保留的512条轨迹训练，模型达64.4%解决率，超过目标。

在极少人工设定下，智能体能运行完整流程、评估结果并调整策略。经过两轮迭代，Qwen3.5-35B-A3B-Base在SWE-bench Verified上从7.6%提升至64.4%。

看板与下一步

代码数据流程可能持续运行数小时乃至数天，因此每个LegoFlow block都配有看板监控进度、检查中间产物。一份Curator快照包含822个仓库、8818个拉取请求、926个已构建任务和270个已验证任务。看板还展示通过率、标签分布、评分标准分数、抽样轨迹和评测详情。

Evaluator构建于Harbor之上，支持SWE-bench Pro等智能体基准评测；通过限制网络、加入防作弊提示词等措施缓解评测作弊。除SFT外，团队也在将Lego-RL集成到Trainer，使其可直接使用Curator验证的任务进行RL训练。

团队正在沿三个方向扩展LegoFlow：TerminalBench，正在把Terminal-Lego工作迁移升级到LegoFlow，纳入Terminal-Bench 3.0与Terminal-Bench 4.0的新变化；ProgramBench与NL2Repo，正在挖掘更复杂、长程的软件工程任务，以可执行程序或自然语言需求为起点；递归式自我改进（RSI），随着更强的智能体出现，团队相信抽象化设计与执行反馈能够支持更通用、长期运行的自我改进系统。

LegoFlow的数据、代码、文档已全部开源。团队同时维护LegoX，一个Agent数据开源集合，包含高质量长程任务与轨迹，代表工作还有Lego-RL、SWE-Lego。