Meta联合伊利诺伊大学和卡内基梅隆大学，让软件智能体在没有任何人类指导的沙盒中通过自我博弈实现了超越人类数据的进化。
研究者通过SSR框架，在完全隔绝人类标注数据的环境中，通过自主制造Bug、编写测试与修复代码的左右互搏，打破了依赖人类开发痕迹的训练天花板。
摆脱人类数据依赖实现自我进化
当前基于大语言模型的软件工程智能体虽然提升了开发效率，但它们的发展被一道隐形围墙挡住了。
这些智能体的训练极其依赖人类积累的数据，比如GitHub上的Issue描述、代码合并请求以及成对的测试用例。
这种依赖造成了一个逻辑上的死循环。
智能体只能学习人类已经解决的问题和已经写好的测试，它们主要是在回放和优化人类的开发痕迹，难以产生超越人类的超级智能。
这些经过人工清洗的数据集不仅昂贵，难以规模化扩展，且往往包含不可靠的训练信号。
为了解决这一核心痛点，研究团队提出了一种全新的训练范式。
这种范式被称为Self-play SWE-RL（简称SSR）。
SSR的核心理念非常直观且具有颠覆性，它不再需要任何带有人类标签的Issue或现成的测试套件。
它只需要一个最基础的输入，一个包含源代码和依赖环境的Docker沙盒。
在AlphaZero通过自我博弈在围棋领域达到超人类水平的启发下，研究人员思考软件工程领域是否也能实现类似的突破。
Absolute Zero曾展示了在完全没有任何外部数据的情况下，仅通过Python解释器进行自我博弈的可能性。
虽然这种方法能学会Python的语法细节，但无法习得现实世界代码库中蕴含的庞大知识。
SSR选择了介于两者之间的道路。它不从零开始发明语言，而是基于现实世界的代码库进行自我博弈。
SSR将同一个大语言模型分饰两角，展开了一场左右互搏的游戏。
一方是Bug注入者，负责制造问题并编写测试。
另一方是Bug修复者，负责解决问题。
通过这种不断的攻防演练，智能体在处理未见过的现实世界软件问题时，表现出了超越人类数据基线的卓越能力。
这种方法的一个关键设计原则是最小化对代码库的先验知识要求。这使得该方法可以广泛应用于各种不同类型的软件项目。
研究团队仅假设可以访问包含源代码和已安装依赖项的Docker镜像。这一设计摒弃了对特定测试解析器、现有测试套件、特定测试运行命令或编程语言框架的依赖。
Bug注入智能体必须完全通过环境交互来发现如何运行测试。
它需要自己创建测试解析器，并理解测试套件的结构。这种极简的假设确保了SSR可以被应用于任意代码库，只需极少的设置开销。
在实际操作中，每个输入到SSR系统的仅仅是一个预构建的Docker镜像。系统不需要知道这是一个Python项目还是Java项目，也不需要知道使用的是pytest还是unittest。
智能体像一个刚接手项目的新员工，完全靠自己去探索和搞清楚这一切。
这种能力本身就是迈向通用软件智能体的关键一步。
传统的训练方法需要人类精心准备数据，告诉模型什么是错的，什么是对的。
SSR则将这一过程内化为模型自身的探索。模型在探索中学会了代码库的结构，学会了如何破坏代码，更学会了如何验证代码的正确性。
构建代码沙盒中的双重博弈机制
在SSR的架构中，Bug不仅仅是一段错误的代码，它被定义为一个严密的Bug工件。
这个工件包含了一整套用于验证Bug存在和修复所需的文件集合。了解这个工件的构成，是理解整个自我博弈机制的关键。
第一个组件是test_script.sh。
这是一个Bash脚本，用于运行测试套件以检测Bug和验证修复。智能体必须自己编写这个脚本，并确保它能够在Linux环境中正确执行。这要求智能体不仅懂代码，还要懂系统操作。
第二个组件是test_files.txt。
这是一个列表，列出了所有被修改或涉及的测试文件。在验证过程中，系统会利用这个列表将测试文件重置为原始状态。无论智能体在过程中如何修改测试文件，最终的评估都基于原始的测试环境。这保证了评估的公正性，防止智能体通过篡改测试文件来作弊。
第三个组件是test_parser.py。
这是一个Python脚本，用于解析测试输出并生成一个详细的JSON映射。尽管解析器是用Python编写的，但它可以解析任何语言的测试输出。智能体需要编写这个解析器，将非结构化的终端文本流转化为结构化的数据，记录每个测试ID及其通过或失败的状态。
第四个组件是bug_inject.diff。
这是一个Git Diff格式的补丁，用于向现有的代码库中注入Bug。这是破坏的一步，也是创造问题的一步。
第五个组件是test_weaken.diff。
这是一个用于移除或削弱测试的补丁。它的目的是在测试套件中隐藏这个Bug。这模拟了现实世界中Bug逃逸出测试覆盖的情况。这个补丁的反向操作定义了修复后的期望行为，充当了修复者的规格说明。这种通过削弱测试来定义修复目标的逆向思维，巧妙地解决了在没有人类标注的情况下如何定义正确性的问题。
生成这些工件的过程是一个严密的智能体任务。
Bug注入智能体与执行环境交互，使用工具生成Bug工件。生成的工件必须经过一系列严格的一致性检查。只有通过了所有检查的工件才被认为是有效的。
测试文件必须存在于原始仓库中，且必须包含被测试削弱补丁触及的所有文件。
测试解析器必须能够可靠地将原始测试输出转换为JSON映射。
测试脚本在原始代码库上执行时，必须产生一系列通过的测试，且通过的测试总数必须超过设定的阈值。这确保了基础环境是健康的。
Bug注入补丁必须产生一定数量的更改文件。
更关键的是，在应用注入补丁后，原代码库中通过的测试中必须至少有一定数量的测试变为失败。这证明了Bug确实破坏了某些功能，而不是无关痛痒的修改。
在应用了测试削弱补丁之后，那些在Bug状态下失败的测试必须重新变为通过。这模拟了Bug被掩盖的状态，同时也验证了削弱补丁的逻辑正确性。
逆向变异测试是其中最精妙的一环。
它验证了Bug注入补丁中的每一个文件对于触发Bug都是必要的。
系统会尝试在保持其他文件为Bug状态的情况下，单独将某个文件恢复为修复版本。
如果恢复某个文件导致至少一个失败的测试通过，说明该文件对Bug有贡献。否则，该文件就是多余的修改。这种方法反转了传统的变异测试逻辑，确保了生成的Bug极其精简且具有针对性。
为了确保Bug注入方法具有可扩展性，并防止智能体陷入简单的模式，SSR引入了高阶Bug的概念。
当修复智能体初次尝试修复一个Bug失败时，这个失败的尝试并不会被丢弃。相反，这个失败的状态被视为一个新的、更复杂的Bug状态。
这个新的状态被反馈给修复智能体进行新一轮的尝试。
这种机制模拟了开发人员在解决问题时可能引入新Bug的自然过程。
通过这种方式，系统能够生成分层的、相互依赖的错误模式，迫使智能体处理多步骤的修复任务。这极大地丰富了训练数据的分布，使智能体能够学习处理更深层次的代码逻辑纠缠。
SSR的奖励函数设计体现了对抗与协作的平衡。
对于Bug修复智能体，奖励是一个二元信号。如果所有测试都通过，获得+1分；否则获得-1分。对于Bug注入智能体，奖励设计则更为复杂。
注入智能体的奖励基于生成Bug的质量和难度。
如果生成的一致性验证失败，直接惩罚-1.0分。如果生成的Bug太容易或太难，也会受到惩罚。只有当Bug处于理想难度区间时，注入智能体才能获得正向奖励。
这个公式不仅鼓励生成有效的Bug，还明确地激励生成那些修复者难以解决但并非不可解决的Bug。这创造了一种对抗压力，推动注入者不断寻找修复者能力的边界。
验证自我博弈的实战效果与演进
Meta团队使用了Code World Model (CWM) 作为基础模型。
这是一个当前最先进的32B开源代码大语言模型。实验在一个大规模的计算集群上进行，使用了大量的NVIDIA H100 GPU。
为了公平比较，基线模型和SSR模型都在相同的环境镜像集上进行训练。
主要的对比基线是人类数据基线。这个基线使用标准的强化学习方法，训练数据来自人类编写的Issue描述、Pull Requests以及相应的测试套件。
这是一个非常强有力的基线，代表了当前主流的训练方法。与之相对，SSR只能访问裸露的环境镜像，没有任何Issue描述或测试，完全依靠自我博弈来发现问题和验证方案。
评估基准选用了SWE-bench Verified和更复杂的SWE-Bench Pro。
前者包含500个经过人类验证的真实软件问题，后者包含731个公开的软件问题，旨在捕捉现实、复杂和企业级的任务。
实验结果表明，SSR在整个训练轨迹中始终优于人类数据基线。
在SWE-bench Verified上，SSR实现了10.4个百分点的自我提升。
在SWE-Bench Pro上，提升了7.8个百分点。
这说明大语言模型完全可以通过与原始代码库的交互来提升自己的软件工程能力，而不需要特定任务的训练数据。自我生成的任务不仅数量无限，而且能够提供比人类工程数据更丰富、更有效的学习信号。
SSR生成的训练课程是动态演进的。
随着智能体策略的更新，生成的Bug也随之变化，始终保持在适合当前能力的难度水平。
而基于静态数据集的训练则无法提供这种适应性的课程。
为了隔离自我博弈的贡献，研究团队进行了消融研究。
他们比较了全功能的SSR框架与仅有注入和仅有修复的变体。
仅有注入的训练导致性能下降，因为它没有从修复尝试中学习。
仅有修复的训练虽然使用了自我博弈早期产生的有效Bug，但缺乏随策略演进的任务分布，因此表现也不如完整版SSR。这证实了持续的、在线的Bug生成和修复过程对于持续改进至关重要。
Bug注入智能体不仅仅是在制造问题，它在构建Bug的过程中学会了识别通过的测试、以有意义的方式破坏功能以及通过削弱测试来隐藏Bug。
这些活动本身就包含了深刻的代码理解，并不断扩展训练信号，将模型暴露在新的故障模式下。
研究还发现，不同的Bug注入策略对下游性能有微妙但重要的影响。
最简单的直接注入策略，即直接提示模型引入Bug，效果最差。
这种策略倾向于产生琐碎的单行修改，提供的训练信号非常微弱。相比之下，移除代码策略生成的Bug更强，迫使修复者重构缺失的功能，从而加深对仓库结构的理解。
结合了移除和历史回滚的策略效果最好。这是因为利用Git历史记录能够引入更真实、更多样的Bug模式。这些模式反映了代码在实际演进过程中的变化。这强调了精心设计Bug注入机制对于构建具有挑战性和指导性的课程的重要性。
有趣的是，即使在Bug注入的奖励中去掉了修复者的反馈，系统的表现也只比完整版略差一点。
研究人员假设，这是因为修复率是一个充满噪声的信号，对于注入者来说很难从单一的数字中学习到影响修复率的众多因素。
即便如此，注入智能体仍然受益于共享的策略网络。由于该策略同时通过Bug生成和Bug修复进行更新，这种在线的联合学习使得注入者能够自然地生成反映当前策略能力的课程。
尽管SSR取得了显著的成果，但它仍处于早期阶段。
目前的验证完全依赖于单元测试，这只是软件正确性的一个子集。
未来的迭代应考虑将测试集划分为公开和私有两部分，以防止智能体过拟合测试。
此外，目前的实验仅使用了单一的模型配置，未来可以探索混合专家模型，甚至为不同的角色使用独立的策略网络。
研究团队曾尝试在自我博弈中合成自然语言的Issue描述，但并未成功。
生成的描述往往逻辑不连贯，且容易退化为直接复制测试补丁。
这表明目前的32B模型在生成高质量自然语言描述方面仍有欠缺。这恰恰反证了SSR这种不依赖自然语言描述、专注于代码和测试本身的路径的有效性。
SSR展示了一条通往自主进化的清晰道路。
智能体不再是被动的学习者，而是主动的探索者和创造者。
通过在沙盒中不断的自我博弈，它们正在逐步掌握软件工程的本质。这不仅是对现有开发流程的优化，更是对未来软件开发范式的重构。
参考资料：
https://arxiv.org/pdf/2512.18552
