Der erste Long-Range-Doc2Repo-Trainingsdatensatz: Code-Agenten gehen über das Beheben von Fehlern hinaus und beginnen, Repositorys von Grund auf neu zu erstellen

Mit der ständigen Verbesserung der Fähigkeiten von LLM Code Agenten haben immer mehr Forscher erkannt, dass es an der Zeit ist, in die nächste Phase zu gehen, in der es um Langzeitaufgaben geht, die den Anforderungen realer Szenarien näher kommen. Daher sind einige Benchmarks für die Bewertung von Langzeitaufgaben wie NL2RepoBench und BeyondSWE aufgetaucht. Die Erwartungen an die Rolle, die Code Agenten übernehmen sollen, haben sich allmählich von Repositoriumswartungen hin zu Architekturen gewandelt. Sie sollen in der Lage sein, Planungen zu machen und Langzeitaufgaben für den gesamten Code eines Repositoriums zu erledigen.

Kürzlich hat die Gaoling School of Artificial Intelligence der Renmin University of China eine entsprechende Studie abgeschlossen und das DeNovoSWE-Datensatzpaket veröffentlicht. Dieses Dataset konzentriert sich auf Langzeit-Softwareentwicklungsprojekte, insbesondere auf die Aufgabe, Code auf Repositoriumsebene von Grund auf zu generieren.

Link zur Studie: https://arxiv.org/pdf/2606.10728

Link zum Repositorium: https://github.com/AweAI-Team/DeNovoSWE

Link zu den Daten: https://huggingface.co/collections/AweAI-Team/denovoswe

Durch die Mechanismen von Divide & Conquer und Critic & Repair wurde ein hochwertiger Datensatz erstellt, und es gelang, die Skalierbarkeit von Langzeit-SWE-Aufgaben zu realisieren. Ein Open-Source-Datensatz mit 4.818 echten Daten für Langzeit-SWE-Aufgaben wurde aufgebaut. Dieses Ergebnis bietet eine große Menge von Daten für das Training der Langzeitfähigkeiten von Code Agenten und verbessert die Fähigkeiten von Code Agenten bei Langzeitaufgaben erheblich.

In der Studie wird auch ein Verfahren zur Bewertung und Filterung von Aufgaben nach Schwierigkeitsgrad vorgestellt, das das Problem des Gleichgewichts zwischen dem Anteil schwieriger Aufgaben und der Qualität der Trajektorien effektiv löst.

Die Experimente zeigen, dass das auf DeNovoSWE trainierte Qwen3-30B-A3B-Instruct auf BeyondSWE-Doc2Repo von 5,8 % auf 47,2 % und auf NL2RepoBench von 4,3 % auf 23,0 % verbessert wurde. Dies zeigt die signifikante Verbesserung der Fähigkeiten zur Generierung von Code auf Repositoriumsebene durch Langzeitdaten.

Das gesamte Repositorium aus einem Dokument neu aufbauen

In den letzten 12 Monaten hat sich die Fähigkeit von Code Agenten bei realen Softwareentwicklungsprojekten wie SWE-bench dank der Skalierung von großen Mengen an SWE-Daten, wie in Projekten wie Scale-SWE, schnell verbessert. Aber nachdem die Modelle immer besser darin geworden sind, "ein Issue zu beheben" oder "ein paar Zeilen Bug zu reparieren", taucht ein entscheidenderes Problem auf: Haben die Agenten wirklich Langzeit-Softwareentwicklungskompetenzen? Die Ergebnisse der Spitzenmodelle in BeyondSWE-Doc2Repo und NL2RepoBench lassen dies bezweifeln.

In der realen Welt der Softwareentwicklung geht es nicht nur darum, eine Funktion zu ändern oder eine bedingte Anweisung hinzuzufügen, sondern auch, die Anforderungen zu verstehen, die Architektur zu planen, Dateien zu erstellen, APIs zu entwerfen, Abhängigkeiten zu verwalten, Module zu verbinden und schließlich das gesamte Repositorium so zu bringen, dass es in den Tests funktioniert.

Mit anderen Worten, die Herausforderung liegt in der langfristigen Generierung auf Repositoriumsebene: Aus einem Aufgaben-Dokument ein vollständiges, ausführbares und verifizierbares Software-Repositorium zu generieren. Dies ist das Problem, das DeNovoSWE lösen will.

Hochwertige Aufgaben-Dokumente für die "Neugenerierung eines Repositoriums"

Beim "Dokument-zu-Repositorium-Generieren" ist das Dokument nicht nur eine README-Datei oder eine einfache API-Liste. Es ist im Wesentlichen der einzige Zugangspunkt für den Agenten, um das gesamte Repositorium neu aufzubauen.

Ein hochwertiges Aufgaben-Dokument muss mindestens zwei Kernkriterien erfüllen.

Erstens, es muss gut strukturiert sein.

Aufgaben auf Repositoriumsebene sind von Natur aus komplex und umfassen mehrere Module, Schnittstellen, Konfigurationen, Datenstrukturen und Interaktionsabläufe. Wenn das Dokument nur Funktionsbeschreibungen zusammenstellt, wird der Agent leicht in den fragmentierten Informationen verirrt. Daher sollte das Dokument zunächst eine klare Übersicht über das Repositorium geben und dann in Kapitel aufgeteilt werden, die nach Fähigkeiten oder Arbeitsabläufen organisiert sind, so dass jeder Teil eine eindeutige Funktionsgrenze hat.

Zweitens, es muss von der Perspektive einer zuverlässigen Bewertung ausgehen.

Das Dokument darf nicht zu kurz sein, sonst wird die Aufgabe zu undefiniert, und das Modell muss möglicherweise raten, um die Bewertung zu bestehen. Andererseits darf es auch nicht zu lang sein, sonst werden die Implementierungsdetails preisgegeben, und die Aufgabe verliert ihre Herausforderung.

Ein wirklich hochwertiges Dokument sollte die Schlüsselverhaltensweisen beschreiben, auf die die Bewertung angewiesen ist: Dies umfasst Importpfade, öffentliche APIs, Eingaben und Ausgaben, Standardparameter, Ausnahmeverhaltensweisen, Konfigurationsoptionen, Musterzeichenfolgen, Rückgabefelder usw. Es sollte auch die Funktionen beschreiben, die im Großen und Ganzen zu erfüllen sind. Das heißt, das Dokument sollte ausreichen, damit der Agent die testbaren Verhaltensweisen reproduzieren kann, aber es darf nicht eine Kopie des Implementierungscodes werden.

Dies ist auch der Kerngedanke von DeNovoSWE: Das Dokument soll lesbar, implementierbar und verifizierbar sein.

Die DeNovoSWE-Methode

DeNovoSWE formuliert die Aufgabe, "aus einem Dokument ein vollständiges Repositorium zu generieren", als eine große, verifizierbare Langzeit-Softwareentwicklungsprojekt. Es werden keine manuellen Dokumente geschrieben, sondern es wird ein sandbasiertes Multi-Agenten-Arbeitsablaufsystem verwendet, um hochwertige Beispiele automatisch zu erstellen. Die gesamte Methode kann in zwei Schritte zusammengefasst werden: Divide und Conquer.

Im Divide-Schritt analysiert das System zunächst das Zielrepositorium und zerlegt es in mehrere Repositoriumsfähigkeiten.

Jede Fähigkeit entspricht einer Kernfähigkeit oder einem Arbeitsablauf im Repositorium, wie z. B. Authentifizierung und Verbindung, Datenlesen und -schreiben, Batchverarbeitung, Exportabläufe usw. Auf diese Weise wird das ursprünglich große Problem der Repositoriumsgenerierung in mehrere gut strukturierte Dokumentkapitel aufgeteilt.

Gleichzeitig führt DeNovoSWE die ursprünglichen Unittests aus und sammelt die Ausführungsverläufe, um zu erkennen, welche Funktionen, Klassen und Schnittstellen die Bewertung wirklich beeinflussen. Es werden dann direkte Komponenten, Kernindirekte Komponenten und Nicht-Kernindirekte Komponenten unterschieden: Schnittstellen, die direkt von den Tests aufgerufen werden, müssen detailliert aufgezeichnet werden; Kernindirekte Komponenten, die das beobachtbare Verhalten beeinflussen, müssen ebenfalls abgedeckt werden; Nicht-Kerninterne Implementierungen können dagegen dem Agenten überlassen werden.

Im Conquer-Schritt verwendet DeNovoSWE den Draft-Critic-Repair-Mechanismus, um Kapitel für jede Fähigkeit zu generieren. Der Draft-Agent schreibt zunächst einen ersten Entwurf; der Critic-Agent prüft, ob das Dokument wichtige APIs, Verhaltensvereinbarungen oder Strukturinformationen verfehlt; der Repair-Agent repariert dann das Dokument basierend auf dem Feedback. Dieser Zyklus wird wiederholt, bis jedes Kapitel zu einer Fähigkeit klar, vollständig und mit der Bewertung übereinstimmt.

Schließlich werden die Dokumente zu verschiedenen Fähigkeiten zu einem vollständigen Aufgaben-Dokument zusammengeführt, das der Agent als einzige Grundlage für die Neugenerierung des Repositoriums verwendet.

Schwierigkeit: Warum ist dies eine Langzeitaufgabe?

Die Schwierigkeit der DeNovoSWE-Aufgabe ergibt sich aus einer grundlegenden Veränderung: Es geht nicht mehr um die Behebung von Problemen auf Issue-Ebene, sondern um die Generierung eines gesamten Repositoriums.

In herkömmlichen SWE-Aufgaben steht der Agent normalerweise vor einem bestehenden Repositorium und muss nur die Fehler lokalisieren, den lokalen Code ändern und die Tests bestehen.

In DeNovoSWE steht der Agent vor einer bereinigten Umgebung: Der ursprüngliche Quellcode und die Tests werden entfernt, die Git-Historie wird zurückgesetzt, und potenzielle Informationsquellen wie Caches, site-packages-Reste, Pip-Wheels und temporäre Kompilierungsprodukte werden ebenfalls gelöscht. Dies bedeutet, dass der Agent sich wirklich auf das Dokument verlassen muss, um das gesamte Repositorium neu aufzubauen. Er muss die Projektstruktur planen, Moduldateien erstellen, öffentliche Schnittstellen definieren, die Interaktion zwischen Dateien implementieren, Abhängigkeiten und Konfigurationen verwalten und in mehreren Runden von Bearbeitungen und Testrückmeldungen die Fehler kontinuierlich beheben.

Jede Abweichung in einer API-Signatur, einem Rückgabefeld, einem Ausnahmetyp oder einem Standardverhalten kann dazu führen, dass die Tests fehlschlagen. Fehler akkumulieren sich auch im Laufe des Prozesses: Ein frühzeitig schlecht entworfenes Modul kann mehrere nachfolgende Dateien und Aufruflisten beeinflussen.

Um die Schwierigkeitsunterschiede zwischen verschiedenen Repositorien zu berücksichtigen, schlägt DeNovoSWE auch die Schwierigkeitsgrad-bewusste Trajektorienfilterung vor. Einfach ausgedrückt, sollten einfache Aufgaben eine höhere Passrate erfordern, und schwere Aufgaben sollten nicht nur deshalb verworfen werden, weil sie nicht die perfekte Punktzahl erreicht haben. DeNovoSWE setzt basierend auf der strukturellen Komplexität und der Schwierigkeit für das LLM verschiedene Filterungsschwellen für verschiedene Schwierigkeitsbereiche fest, um ein Gleichgewicht zwischen Qualität und Vielfalt zu erzielen.

Dies ist besonders wichtig für Langzeitaufgaben: Je komplexer ein Repositorium ist, desto schwieriger ist es, alle Tests auf einmal zu bestehen. Aber auch die Trajektorien von schwierigen Repositorien, niedrigen Punktzahlen und teilweise erfolgreichen Versuchen enthalten wertvolle Fähigkeiten für die Langzeitplanung und -implementierung.

Experimentelle Ergebnisse

DeNovoSWE hat schließlich 4.818 hochwertige Beispiele für die Aufgabe "Dokument-zu-Repositorium-Generieren" erstellt. Es ist eine ausführbare, bewertbare und trainierbare Umgebung für Langzeit-Softwareentwicklungsprojekte.

Die experimentellen Ergebnisse zeigen, dass DeNovoSWE die Fähigkeiten des Modells zur Langzeitgenerierung von Repositorien erheblich verbessert. Beim Qwen3-30B-A3B-Instruct lag die Leistung des ursprünglichen Modells auf BeyondSWE-Doc2Repo nur bei 5,8 % und auf NL2RepoBench nur bei 4,3 %. Das mit herkömmlichen SWE-Daten auf Issue-Ebene trainierte Scale-SWE-Agent konnte dies auf 29,2 % und 18,3 % verbessern, was zeigt, dass gewöhnliche SWE-Daten tatsächlich einen Transfer-Effekt haben. Aber nachdem das Modell mit DeNovoSWE trainiert wurde, stieg die Leistung weiter auf 47,2 % und 23,0 %.

Dies zeigt, dass Daten, die auf die "Bugbehebung" ausgerichtet sind, die Langzeitdaten, die auf die "Generierung eines vollständigen Repositoriums" ausgerichtet sind, nicht vollständig ersetzen können. Um zu ermöglichen, dass der Agent wirklich die Fähigkeiten für die Repositoriumsebene erlernt, muss eine Trainingsumgebung speziell für Langzeitaufgaben aufgebaut werden.

Auf dem stärkeren Qwen3.5-35B-A3B-Grundmodell bringt DeNovoSWE ebenfalls stabile Verbesserungen: Auf BeyondSWE-Doc2Repo steigt die Leistung von 43,8 % auf 50,0 % und auf NL2RepoBench von 23,5 % auf 27,1 %. Dies zeigt weiter, dass die Verbesserungen durch DeNovoSWE nicht zufällig auf ein bestimmtes Modell zugeschnitten sind, sondern auf den hochwertigen Langzeitdaten selbst beruhen.

Fazit

Die nächste Phase der Code-Agenten besteht nicht nur darin, einzelne Issues schneller zu beheben, sondern auch, Dokumente zu verstehen, Architekturen zu planen, Module zu organisieren, Schnittstellen zu implementieren und schließlich ein vollständiges, ausführbares Software-Repositorium zu generieren.

DeNovoSWE hat dieses Ziel systematisch in einen trainierbaren, verifizierbaren und erweiterbaren Datensatz umgesetzt. Es beantwortet