daVinci-Env：大规模开放软件工程环境合成框架 daVinci-Env: Open SWE Environment Synthesis at Scale

OpenSWE的完整构建流程包含以下步骤。第一步，GitHub PR收集：通过REST和GraphQL API从大量Python仓库中收集PR元数据、关联Issue描述和完整代码差异。第二步，四级PR过滤：依次检查仓库星数（≥5）、主语言（Python）、关联Issue存在性和非测试代码变更，筛选出高质量候选。第三步，仓库探索：轻量级探索Agent通过browse、search、digest三个API接口收集仓库的依赖信息、测试命令和配置文件，采用成本感知策略——无失败反馈时仅做浅层检查，仅在测试分析Agent报告缺失上下文时才定向深入。第四步，Dockerfile构建：Dockerfile Agent基于探索结果生成容器定义，使用预构建的openswe-python基础镜像（覆盖Python 2.7和3.5-3.14）避免网络超时，通过本地仓库缓存注入代码避免GitHub API限流，并采用分层优化策略将稳定基础层置于前部以利用Docker缓存。第五步，评估脚本生成：评估脚本Agent生成结构化的bash脚本，包含选定和合成的测试用例、输出分隔标记和OPENSWE_EXIT_CODE退出码标记，模板化设计支持跨迭代修改。第六步，环境验证：对每个迭代执行双重验证——先应用仅测试补丁确认测试确实失败，再应用完整修复补丁确认测试通过，通过正则提取退出码标记判断验证结果。第七步，测试分析：测试分析Agent检查通过结果的真实性（防止硬编码退出码），诊断失败原因（Dockerfile配置错误、评估脚本问题或环境本身不可解），生成针对性反馈路由回相应Agent。第八步，分布式执行：在64个ECS实例上并行处理约57.2万个GitHub PR，使用文件系统消息队列实现数据并行，systemd服务实现进程管理，Prometheus+Grafana实现监控。整个构建在约两周内完成45320个验证环境。

OpenSWE在技术上有多方面新颖性。首先，它首次实现了完整的多Agent环境合成流水线的开源发布——此前的工作（SWE-Universe、SWE-Factory）虽然也实现了自动化，但基础设施不公开。其次，在Dockerfile构建方面，OpenSWE引入了预构建基础镜像策略和本地仓库缓存机制，解决了大规模合成中的两个常见失败模式：网络不稳定导致的构建超时和重复重建导致的资源浪费，实测实现5倍加速。第三，评估脚本设计突破了SWE-bench的静态fail2pass范式——由于Agent可能引入新的测试用例，OpenSWE采用从零构建的结构化脚本，包含退出码捕获、输出分隔标记和补丁注入的heredoc占位符，支持可靠的自动化提取。第四，难度感知过滤是最重要的概念创新：它不是简单地用规则过滤，而是通过实际执行轨迹来表征环境难度——如果一个环境在4次采样中有2次以上被正确解决，说明它可能过于简单；如果4次都失败且测试分析Agent判定为不可解，则过滤掉。第五，分布式合成架构的设计选择（数据并行+文件系统消息队列+systemd进程管理）在容错性和可扩展性之间取得了良好平衡，使得64节点集群能在两周内完成原本需要数月的工作。

从独立分析的角度，OpenSWE存在以下弱点。第一，环境合成的可扩展性瓶颈：当前流水线依赖于LLM API调用（DeepSeek-v3.2），每个环境的合成涉及多轮Agent交互，推理成本随环境数量线性增长。虽然论文报告了对数线性数据缩放趋势且无饱和，但这仅在当前预算范围内成立；继续扩大规模可能面临成本和时间的指数级增长。改进方向是探索更轻量级的环境合成方法，例如使用规则模板处理标准化仓库结构，仅对复杂情况调用LLM Agent。第二，PR过滤标准过于粗糙：仅使用仓库星数≥5作为质量代理，而星数与代码质量的相关性并不稳定——许多低星但结构清晰的仓库可能被错误过滤，而高星但依赖复杂的仓库可能产生大量不可解环境。改进方向是引入更精细的仓库特征（如依赖图复杂度、CI配置成熟度、历史PR合入率）作为过滤标准。第三，评估脚本的合成存在固有风险：论文提到测试分析Agent会检查通过结果的真实性以防止硬编码退出码，但未报告此类作弊行为的发生率。如果Agent学会了利用评估脚本的漏洞（而非真正解决问题），将导致训练数据质量下降。改进方向是引入对抗性评估，定期用不同版本的测试脚本验证Agent解决方案的鲁棒性。第四，训练轨迹的质量筛选仅基于正确性（4次采样中1-2次正确），未考虑轨迹效率——一个需要300步才解决的问题和一个需要50步解决的问题被同等对待，但后者的训练信号可能更有价值。改进方向是引入效率指标，优先保留简洁高效的轨迹。

基于OpenSWE的成果，未来研究可以沿多个方向展开。首先，作者观察到的对数线性缩放趋势且无饱和意味着进一步扩大环境合成规模是有价值的，未来可以将环境数量从45k扩展到100k甚至更多，特别是增加复杂度更高的跨仓库任务和领域特定任务（如BeyondSWE提出的跨仓库推理和依赖迁移）。其次，OpenSWE目前仅支持Python，将其扩展到JavaScript、TypeScript、Java、Go等语言是自然的下一步，SWE-rebench-v2已经在语言无关方向上做出了初步探索。第三，难度感知过滤可以进一步精细化——当前的方法是二元的（保留或过滤），但可以引入连续难度评分，实现课程学习（curriculum learning），让Agent先从简单环境学起逐步过渡到困难环境。第四，论文发现SWE训练对数学推理和科学知识有显著的正向迁移（最高+12分），这值得深入研究：SWE任务中的多步骤规划、调试和代码理解能力可能与通用推理能力存在更深层的联系，探索这种联系可能为训练通用推理Agent提供新思路。第五，环境合成流水线本身可以进化——当前使用固定的多Agent架构，未来可以让Agent自动学习合成策略，甚至让Agent自己设计新的评估指标和测试用例。

OpenSWE在可复现性方面做出了显著努力。所有环境的Dockerfile、评估脚本和分布式合成基础设施均已开源在GitHub（https://github.com/GAIR-NLP/OpenSWE），这是相比SWE-Universe等不公开基础设施的工作的重大进步。论文详细记录了64节点集群的硬件和软件配置（Table 1），以及近似的10天构建成本（Table 6），为想要复现的研究组提供了清晰的资源估算。然而，完全复现仍面临挑战：第一，147万美元的总成本（89.1万构建+57.6万策展）对大多数学术组来说不可承受；第二，环境构建使用了DeepSeek-v3.2（闭源API），训练轨迹采样使用了GLM-4.7，这些模型的版本和API行为可能随时间变化；第三，分布式合成的工程细节（如文件系统消息队列的实现、systemd服务配置）虽然在论文中有描述，但完整的运维脚本和配置是否包含在开源仓库中尚不确定。总体而言，OpenSWE的可复现性在同类工作中处于领先水平，但大规模分布式系统的完全复现仍需要显著的工程和资源投入。对于资源有限的研究组，更实际的选择是直接使用OpenSWE提供的已验证环境和训练轨迹，而非从头复现整个构建过程。