CodeTeam: An LLM-Powered Multi-Agent Framework for Repository-Level Code Generation
CodeTeam ist ein durch LLMs gestütztes Multi-Agenten-Framework, das die Herausforderungen der Generierung von Repositories aus natürlicher Sprache adressiert, indem es Planung, Entscheidungsfindung und Implementierung in koordinierte Phasen unterteilt und so eine Spitzenleistung sowohl in der Designqualität als auch in der funktionalen Korrektheit bei Benchmark-Tests erzielt.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Das große Problem: Eine ganze Stadt aus einer Skizze bauen
Stellen Sie sich vor, Sie bitten einen sehr klugen, aber etwas zerstreuten Architekten (eine KI), eine ganze Stadt aus einem einzigen Satz zu bauen: "Ich brauche einen Ort, an dem Menschen Schuhe kaufen können."
Wenn Sie die KI einfach nur bitten, "den Code zu schreiben", baut sie vielleicht einen wunderschönen Schuhladen, vergisst aber, die Straßen, das Kraftwerk oder das Abwassersystem zu bauen. Oder sie baut den Schuhladen mit einer Tür, die direkt in eine Ziegelwand führt, weil sie nicht mit der "Straßenbau"-KI gesprochen hat.
Dies ist die Herausforderung von NL2Repo (Natural Language to Repository). Es geht nicht nur darum, eine einzelne Funktion zu schreiben (wie ein einzelnes Zimmer); es geht darum, ein ganzes Softwareprojekt zu generieren (eine ganze Stadt) mit vielen Dateien, die perfekt miteinander kommunizieren müssen. Aktuelle KI-Modelle verlieren sich oft in den Details, vergessen das große Ganze oder erzeugen "Cross-File"-Chaos, bei dem Datei A etwas erwartet, das Datei B nicht gebaut hat.
Die Lösung: CodeTeam (Die Baustelle)
Die Autoren schlagen CodeTeam vor, ein System, das sich nicht auf einen einzelnen, einsamen KI-Genie verlassen muss. Stattdessen fungiert es wie eine gut organisierte Baustelle mit spezialisierten Rollen. Sie unterteilen die Arbeit in drei klare Phasen: Planung, Entscheidungsfindung und Bau.
So arbeitet das Team Schritt für Schritt:
1. Die Architekten (Die Träumer)
Anstatt dass eine Person die Baupläne zeichnet, stellt das System vier verschiedene Architekten-Agenten ein.
- Was sie tun: Jeder von ihnen skizziert ein anderes Design für die Software. Der eine sagt vielleicht: "Lass uns ein modulares Design verwenden!" Ein anderer sagt: "Nein, lass uns es einfach und flach halten!"
- Die Geheimwaffe: Manchmal dürfen diese Architekten in eine Bibliothek erfolgreicher vergangener Projekte schauen (Retrieval-Augmented Generation), um zu sehen, wie andere ähnliche Probleme gelöst haben. Dies hilft ihnen, das Rad nicht neu zu erfinden.
- Das Ziel: Erstellung verschiedener "Software Design Sketches" (SDS). Denken Sie an dies als detaillierte Blaupausen, die jedes Zimmer, jedes Rohr und die Zuständigkeiten auflisten.
2. Der CTO (Der oberste Entscheider)
Sobald die vier Architekten ihre Entwürfe präsentiert haben, tritt ein CTO-Agent (Chief Technical Officer) auf den Plan.
- Was er tut: Der CTO überprüft alle Skizzen, wählt die beste aus und wandelt sie in einen maschinenprüfbaren Vertrag um.
- Der Vertrag: Dies ist nicht nur eine Zeichnung, sondern ein strenges Dokument für den Computer. Es besagt: "Datei A muss diese spezifische Funktion haben. Datei B muss von Datei A abhängen. Entwickler 1 ist für die Küche zuständig; Entwickler 2 ist für das Schlafzimmer zuständig."
- Warum das wichtig ist: Dieser Vertrag verhindert, dass die Erbauer vom Weg abkommen und eine Garage bauen, wo eigentlich die Küche sein sollte. Er legt die Regeln fest, bevor der erste Stein gelegt wird.
3. Die Entwickler (Die Erbauer)
Nun beginnt die eigentliche Codierung. Das System stellt eine bestimmte Anzahl an Entwickler-Agenten ein, basierend auf dem Vertrag des CTOs.
- Spezialisierung: Im Gegensatz zu einer generischen KI, die versucht, alles zu machen, sind diese Entwickler spezifischen Dateien zugewiesen. Entwickler 1 baut nur die Login-Seite. Entwickler 2 baut nur die Datenbank.
- Die Git-Koordination (Der Vorarbeiter): Während sie bauen, nutzen sie eine leichtgewichtige Version von Git (ein Werkzeug, das Entwickler zur Verfolgung von Änderungen nutzen). Wenn Entwickler 1 die Login-Seite ändert, hinterlässt er eine "Commit-Nachricht" (eine Notiz), die besagt: "Ich habe den Passwort-Button geändert." Entwickler 2 liest diese Notiz und aktualisiert seinen eigenen Code entsprechend.
- Abhängigkeitsbewusstsein: Das System weiß, dass man die Wände nicht streichen kann, bevor man das Gerüst gebaut hat. Es plant die Arbeit so, dass die Dateien in der richtigen Reihenfolge gebaut werden.
4. Der QA-Agent (Der Inspektor)
Während das Team baut, fungiert ein QA-Agent (Quality Assurance) wie ein Bauinspektor.
- Was er tut: Er führt Tests durch, um zu sehen, ob das Gebäude stabil steht. Wenn eine Tür nicht aufgeht oder ein Rohr leckt, sagt der QA-Agent nicht einfach nur "Fehler". Er findet heraus, wer es kaputt gemacht hat, und schickt ein Reparatur-Ticket an diesen spezifischen Entwickler zurück.
- Die Schleife: Der Entwickler behebt das Problem, der Inspektor prüft erneut, und dieser Prozess wiederholt sich, bis das Gebäude perfekt ist.
Was haben sie herausgefunden? (Die Ergebnisse)
Die Forscher haben CodeTeam gegen andere Methoden getestet (wie eine einzelne KI, die alles allein versucht, oder andere Multi-Agenten-Teams) anhand von zwei Haupt-"Prüfungen":
Die Blaupausen-Prüfung (SketchEval): Sie überprüften, ob der generierte Code strukturell korrekt im Vergleich zu realen Beispielen war.
- Ergebnis: CodeTeam gewann. Es baute Strukturen, die realer Software viel ähnlicher sahen. Die Schritte "Architekten" und "CTO" halfen dabei, das Layout richtig hinzubekommen, während die "QA"-Schritte die kleinen Risse behoben.
- Wichtige Erkenntnis: Die "dynamische Entwickler-Zuweisung" (das Einstellen der richtigen Anzahl an Erbauern für den spezifischen Job) war der größte Erfolgsfaktor. Wenn man zu wenige oder zu viele Leute einstellt oder die falschen Personen den falschen Räumen zuweist, scheitert der Bau.
Der Live-Test (NL2Repo-Bench): Sie ließen die generierte Software tatsächlich laufen, um zu sehen, ob sie funktioniert.
- Ergebnis: CodeTeam hatte die höchste Erfolgsquote. Es sah nicht nur auf dem Papier gut aus; es funktionierte tatsächlich.
- Wichtige Erkenntnis: Durch das frühzeitige Beheben struktureller Fehler (wie fehlende Dateien oder unterbrochene Verbindungen) war das Endprodukt viel wahrscheinlicher in der Lage, die "Live-Tests" zu bestehen.
Das Fazit
Das Paper argumentiert, dass das Erstellen von Software von Grund auf nicht nur eine "Schreibaufgabe" ist, sondern eine Managementaufgabe.
- Der alte Weg: Man bittet eine KI, ein ganzes Buch zu schreiben. Sie vergisst oft Handlungspunkte oder schreibt Charaktere, die nicht zusammenpassen.
- Der CodeTeam-Weg: Man stellt ein Team ein. Man lässt eine Person den Plot planen, eine Person die Kapitel editieren und eine Person die Tippfehler prüfen.
Indem man Planung (Architekten/CTO) von der Ausführung (Entwickler) trennt und eine Prüfung (QA) hinzufügt, erschafft CodeTeam Software, die nicht nur intelligenter, sondern auch zuverlässiger ist. Es beweist, dass für komplexe Aufgaben ein koordiniertes Team von KI-Agenten weita Much besser ist als eine einzelne, superintelligente KI, die alleine arbeitet.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.