💻 computer science

Phoenix: Safe GitHub Issue Resolution via Multi-Agent LLMs

Phoenix ist ein Multi-Agenten-LLM-System, das GitHub-Issues von der Triage bis zur Erstellung von Pull-Requests sicher löst, indem es sieben geschichtete Sicherheitskontrollen und eine Baseline-bewusste Evaluierungsstrategie einsetzt und dabei eine Oracle-Lösungsrate von 75 % auf einem kuratierten SWE-bench Lite Slice erreicht, während es gleichzeitig eine 100-prozentige Korrektheitserhaltung bei realen Issues beibehält.

Ursprüngliche Autoren: Kipngeno Koech, Muhammad Adam, Baimam Boukar Jean Jacques, Joao Barros

Veröffentlicht 2026-06-19

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Kipngeno Koech, Muhammad Adam, Baimam Boukar Jean Jacques, Joao Barros

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

Stellen Sie sich eine riesige, belebte Bibliothek namens GitHub vor, in der Millionen von Menschen Klebezettel an Büchern hinterlassen, um nach Korrekturen, neuen Funktionen oder Tippfehlern zu fragen. Diese Notizen werden „Issues“ genannt. Normalerweise muss ein menschlicher Bibliothekar die Notiz lesen, die exakte Seite im Buch finden, herausfinden, was falsch ist, den Text umschreiben und dann einen leitenden Bibliothekar bitten, alles zu prüfen, bevor es zurück ins Regal geht. Das ist langsam und ermüdend.

Phoenix ist ein neues Team von KI-Robotern, die genau diesen Job erledigen sollen, aber mit einer sehr strengen Regel: Verursache keinen Schaden.

So funktioniert Phoenix, aufgeschlüsselt in einfache Konzepte:

1. Das Team der Spezialisten (Die sechs Agenten)

Anstatt eines einzigen superintelligenten Roboters, der versucht, alles gleichzeitig zu machen (was oft zu Fehlern führt), nutzt Phoenix ein Team aus sechs spezialisierten Arbeitern, wie ein gut geöltes Fließband:

Der Planer (The Planner): Liest den Klebezettel und zeichnet eine Karte. Er entscheidet, welche Seiten geändert werden müssen und wie sie zu reparieren sind.
Der Reproduzierer (The Reproducer – Der Detektiv): Bevor er irgendetwas repariert, versucht dieser Roboter, das Problem nachzustellen. Er sagt: „Okay, wenn ich X mache, geht das Buch kaputt?“ Wenn er beweisen kann, dass das Buch defekt ist, macht er weiter. Wenn nicht, überspringt er diesen Schritt, damit das Team nicht stecken bleibt.
Der Programmierer (The Coder): Der Schreiber. Er nimmt die Karte des Planers und schreibt den Text auf den Seiten tatsächlich um.
Der Tester (The Tester): Der Qualitätskontrolleur. Er lässt das Buch durch eine Maschine laufen, um zu sehen, ob der neue Text neue Fehler verursacht.
Der Fehleranalyst (The Failure Analyst): Der Arzt. Wenn der Tester einen neuen Fehler findet, diagnostiziert dieser Roboter, warum das passiert ist, und sagt dem Programmierer, wie er es beheben kann. Sie haben zwei Versuche, um es zu beheben; wenn sie zweimal scheitern, halten sie an und bitten um menschliche Hilfe.
Der PR-Agent (The PR Agent): Der Bote. Sobald die Reparatur fertig ist, verpackt er alles und übergibt es einem menschlichen Bibliothekar zur endgültigen Genehmigung.

2. Das „Sicherheitsnetz“ (Sieben Ebenen des Schutzes)

Das Papier betont, dass KI gefährlich sein kann, wenn sie einfach anfängt, Bücher wahllos umzuschreiben. Phoenix besitzt sieben „Sicherheitswächter“, um Katastrophen zu verhindern:

Der Zaun (The Fence): Er lässt die Roboter nicht außerhalb der Bibliotheksmauern schreiben (um zu verhindern, dass sie Dateien löschen, die sie nicht anfassen sollten).
Der Ausweis (The ID Badge): Er prüft, ob die Roboter gültige Schlüssel (Tokens) haben, damit sie nicht mitten in der Arbeit ausgesperrt werden.
Die Aufräumcrew (The Clean-Up Crew): Sie entfernt unordentliche, verwirrende Teile aus den Klebezetteln, bevor sie den Robotern gezeigt werden, damit diese nicht durch schlechte Formatierung verwirrt werden.
Die „No-Go“-Zone (The "No-Go" Zone): Sie weigert sich, die Sicherheitssysteme der Bibliothek (Workflow-Dateien) anzufassen, da das Manipulieren dieser Dateien dazu führen könnte, dass sich alle ausgesperrt fühlen.
Der Stopp-Knopf (The Stop Button): Wenn die Roboter in einer Schleife feststecken oder immer wieder denselben Fehler machen, zieht das System den Stecker.
Der Einzelarbeiter (The Solo Worker): Es wird immer nur an einem Buch gleichzeitig gearbeitet, um zu verhindern, dass sich die Roboter gegenseitig behindern.
Der frische Schlüssel (The Fresh Key): Er aktualisiert die Ausweise automatisch, bevor sie ablaufen, damit die Arbeit nicht wegen eines Timeouts unterbrochen wird.

3. Der „Vorher-Nachher“-Test (Baseline-Bewusstsein)

Dies ist der cleverste Trick von Phoenix. Manchmal ist ein Bibliotheksbuch schon kaputt, bevor der Roboter es berührt.

Der alte Weg: Ein Roboter behebt einen Tippfehler, aber das Buch schlägt trotzdem fehl, weil es bereits vorher defekt war. Der Roboter bekommt die Schuld für das Scheitern.
Der Phoenix-Weg: Bevor der Roboter etwas ändert, macht er eine „Momentaufnahme“ (Snapshot) des aktuellen Zustands des Buches. Nachdem der Roboter Änderungen vorgenommen hat, vergleicht er den neuen Zustand mit der Momentaufnahme.
- Wenn das Buch bereits kaputt war und weiterhin kaputt ist (aber keine neuen Dinge kaputt gehen), sagt Phoenix: „Erfolg! Wir haben es nicht schlimmer gemacht.“
- Wenn das Buch funktionierte und nun kaputt ist, sagt Phoenix: „Stopp! Wir haben eine Regression eingeführt.“

4. Was die Ergebnisse zeigen

Die Forscher haben Phoenix auf zwei Arten getestet:

Die Übungsrunde (SWE-bench Lite): Sie gaben Phoenix 24 spezifische, vordefinierte Probleme. Phoenix löste 75 % davon perfekt, ohne etwas zu beschädigen, das bereits funktionierte.
Der Realwelt-Test (42 echte Issues): Sie ließen Phoenix an 42 tatsächlichen Problemen aus 14 verschiedenen realen Projekten arbeiten.
- Sicherheit: Phoenix erreichte eine „Korrektheitserhaltung“ (Correctness Preservation) von 100 %. Das bedeutet, es hat nie einen Test kaputt gemacht, der zuvor erfolgreich war. Es war unglaublich sicher.
- Erfolgsrate: Allerdings waren nur etwa die Hälfte der Korrekturen auch tatsächlich die richtige Lösung. Bei der anderen Hälfte handelte es sich um „Halluzinationen“, bei denen der Roboter Code an der falschen Stelle schrieb (wie zum Beispiel eine Bedienungsanleitung im Bereich der Belletristik zu schreiben). Der Roboter wusste zwar, wie man es repariert, konnte aber manchmal nicht das richtige Wo finden.

Das Fazit

Phoenix ist wie ein sehr vorsichtiger, hochtrainierter Lehrlingsbibliothekar. Es ist hervorragend darin, nichts schlimmer zu machen und sehr gut darin, einem strengen Prozess zu folgen. Es hat jedoch manchmal Schwierigkeiten, den genauen Ort eines Problems zu finden, wenn die Beschreibung nicht exakt mit den Dateinamen übereinstimmt.

Das Papier kommt zu dem Schluss, dass für KI im echten Einsatz Sicherheit vor Geschwindigkeit gehen muss. Phoenix beweist, dass man durch den Einsatz eines Teams spezialisierter Agenten und strenger Sicherheitsvorkehrungen Softwarefehler automatisieren kann, ohne versehentlich die Software zu beschädigen. Die wichtigste Aufgabe, die es noch zu lösen gilt, ist, dem „Planer“-Roboter dabei zu helfen, die richtige Seite im Buch häufiger zu finden.

Technisches Resümee: Phoenix – Sichere GitHub-Issue-Lösung mittels Multi-Agenten-LLMs

Problemstellung

Open-Source-Repositories auf GitHub sammeln tausende ungelöste Issues an, was einen anhaltenden Wartungsengpass schafft. Während Large Language Models (LLMs) das Potenzial zur Automatisierung von Software-Engineering-Aufgaben demonstriert haben (z. B. Devin, SWE-Agent, AutoCodeRover), führt eine reine Optimierung auf die Lösungsrate oft zu Lasten der Sicherheit. Systeme, die einen Teil der Issues lösen, aber in anderen Regressionen einführen, bieten in Produktionsumgebungen keinen gesicherten Netto-Nutzen. Darüber hinaus konzentrieren sich bestehende Benchmarks oft auf Offline-Performance und vernachlässigen dabei die Komplexität des Produktionseinsatzes, wie etwa API-Gateway-Filterung, Token-Ablauf und bereits bestehende fehlerhafte Test-Suites.

Methodik

Phoenix ist ein Multi-Agenten-LLM-System, das darauf ausgelegt ist, GitHub-Issues von der Triage bis zur Erstellung eines Pull-Requests (PR) zu lösen, wobei die Erhaltung der Korrektheit gegenüber der reinen Lösungsrate priorisiert wird. Das System arbeitet über eine geschlossene Pipeline, die durch einen zentralen Orchestrator und eine Label-basierte GitHub-Webhook-State-Maschine koordiniert wird.

Systemarchitektur

Die Pipeline zerlegt den Workflow in sechs spezialisierte Agenten, die jeweils einer Phase eines konventionellen Issue-Resolution-Prozesses entsprechen:

Planner Agent: Erhält sanitisierten Issue-Text, Repository-Dateibäume und relevante Auszüge. Er gibt einen strukturierten JSON-Plan aus, der den Ansatz, zu ändernde Dateien, Implementierungsschritte und die Teststrategie detailliert. Er verwendet Keyword-Overlap-Scoring, um die Relevanz von Dateien zu bestimmen.
Reproducer Agent (Optional): Versucht, einen synthetischen Test zu generieren, der auf dem Base-Branch fehlschlägt, um den Bug zu demonstrieren. Ein Scheitern in diesem Schritt ist nicht blockierend und erlaubt der Pipeline, mit der Codierung fortzufahren, selbst wenn kein Test-Harness automatisch generiert werden kann.
Coder Agent: Generiert vollständige Dateiinhalte für geänderte Dateien basierend auf dem Plan und etwaigem Feedback vorangegangener Fehler. Er erzwingt Selbstverifizierung und hält sich an bestehende Codestile.
Tester Agent: Führt die Test-Suite des Projekts aus. Entscheidend ist hierbei eine baseline-bewusste Test-Evaluationsstrategie:
- Er stasht die Änderungen von Phoenix und führt die Suite auf dem unveränderten Base-Branch aus, um Baseline-Fehler ( $B$ ) zu sammeln.
- Er stellt die Änderungen wieder her und führt sie erneut aus, um Post-Change-Fehler ( $P$ ) zu sammeln.
- Die Korrektheit ist gewahrt, wenn $P \setminus B = \emptyset$ (kein zuvor passender Test schlägt nun fehl). Dies ermöglicht die Evaluierung auf Repositories mit defekten CI-Pipelines.
Failure Analyst Agent: Falls neue Fehler erkannt werden, analysiert dieser Agent die Ausgabe und liefert strukturiertes Feedback an den Coder für bis zu zwei Retry-Zyklen.
PR Agent: Erstellt und öffnet einen Pull-Request, der auf den Issue verweist, und überführt den Status in ai:review zur menschlichen Inspektion.

Sicherheitsmechanismen

Sieben geschichtete Sicherheitskontrollen wurden aus empirisch beobachteten Fehlermodi während der Entwicklung und des Einsatzes abgeleitet:

Verhinderung von Path-Traversal: Validiert, dass Dateischreibvorgänge das Repository-Root nicht verlassen.
Label-Status-Exklusivität: Gewährleistet atomare Zustandsübergänge, um die Akkumulation veralteter Labels zu verhindern.
Workflow-Datei-Guardrail: Verhindert stillschweigend Schreibzugriffe auf .github/workflows/, um Berechtigungsfehler zu vermeiden.
Content-Sanitierung: Trunkiert Issue-Bodies und entfernt Stack-Traces, um 403-Antworten von API-Gateways (WAF) zu vermeiden.
Retry-Zyklus-Limit: Begrenzt das Feedback des Failure Analyst auf zwei Runden; ein No-Progress-Detektor terminiert Schleifen, wenn Änderungen identisch sind.
Konkurrenz-Serialisierung: Ein pro-Installation-Lock stellt sicher, dass auf geteilten Clones jeweils nur ein Issue gleichzeitig bearbeitet wird.
Installation-Token-Refresh: Erneuert GitHub-App-Tokens proaktiv vor deren Ablauf, um Authentifizierungsfehler während langer Durchläufe zu verhindern.

Zentrale Beiträge

Architektur: Eine sechs-Agenten-Pipeline mit einem optionalen Reproducer, einer Label-gesteuerten State-Maschine und einer expliziten Design-Rationale für die Dekomposition, was isoliertes Testen und Fehlerattribution ermöglicht.
Baseline-Bewusste Evaluierung: Eine Teststrategie, die präexistente Fehler von durch Phoenix eingeführten Regressionen unterscheidet und so die Bewertung auf Repositories mit defekten CI ermöglicht.
Deployment-Erkenntnisse: Eine Charakterisierung von realen Gefahren (WAF-Filterung, Token-Ablauf, Berechtigungsgrenzen) und der spezifischen Mechanismen, die zur Adressierung dieser entwickelt wurden.

Ergebnisse

Das Paper präsentiert Ergebnisse aus zwei Evaluierungsszenarien:

1. SWE-bench Lite (24 Instanzen)

Evaluiert auf einem kuratierten Ausschnitt von 24 Instanzen über 12 Repositories (je 3 Instanzen).

Oracle Resolution: Phoenix erreichte eine Oracle-Lösungsrate von 75 % (18/24 Instanzen).
Regressionssicherheit: Bei allen Oracle-Passing-Durchläufen traten keine Pass-to-Pass-Regressionen auf.
Fehlermodi: Fehler waren primär auf terminale ai:failed-Zustände oder Evaluator-Timeouts zurückzuführen, nicht auf Sicherheitsverletzungen.
Hinweis: Die Autoren geben explizit an, dass dieser kuratierte Ausschnitt aufgrund der Nutzung des Produktions-Webhook-Pfades nicht direkt mit den Full-Split-Leaderboard-Ergebnissen vergleichbar ist.

2. Pilotprojekt mit 42 realen Issues (14 Repositories)

Evaluiert über 14 Repositories, unterteilt in die Schwierigkeitsgrade Easy, Medium und Hard.

Korrektheitserhaltung (CP): Phoenix erreichte 100 % CP (42/42 Issues). Es wurden keine neuen Testfehler im Vergleich zur Baseline eingeführt.
Lösungszeit: Bei Repositories des „Hard“-Tiers betrug die mittlere End-to-End-Lösungszeit 122 Sekunden.
Qualitative Inspektion: Eine manuelle Überprüfung ergab eine Dichotomie in der Output-Qualität:
- ~50 % der PRs waren gut gezielte Fixes, die bestehende Module modifizierten.
- ~50 % der PRs platzierten Code an falschen, erfundenen Pfaden (z. B. src/core/config.py). Diese bestanden die CP, da sie keine Regressionen einführten, lösten aber nicht den gemeldeten Bug. Diese Einschränkung wird dem lexikalischen File-Ranking des Planners zugeschrieben, nicht den Code-Synthese-Fähigkeiten.

Bedeutung und Ansprüche

Das Paper positioniert Phoenix nicht als ein System, das die Anzahl der gelösten Issues maximiert, sondern als ein System, das die Erhaltung der Korrektheit und die Sicherheit in Produktionsumgebungen priorisiert.

Sicherheit als Primäranforderung: Die Autoren argumentieren, dass eine zuverlässige autonome Code-Modifikation erfordert, Sicherheit als eine technische Anforderung zu behandeln, die aus empirischen Fehlermodi abgeleitet wird, statt aus spekulativen Designs.
Bescheidene Ansprüche auf Lösung: Das Paper räumt ein, dass 100 % Korrektheitserhaltung nicht 100 % Issue-Lösung bedeutet. Die Lücke wird durch Lokalisierungseinschränkungen (die Unfähigkeit des Planners, die Issue-Vokabeln ohne semantische Suche auf Dateipfade abzubilden) getrieben, nicht durch die Code-Generierung.
Produktionsreife: Im Gegensatz zu früheren Arbeiten, die auf Offline-Benchmarks fokussiert sind, ist Phoenix für echte Webhooks, echte Branches und echte PRs konzipiert, inklusive Mechanismen, die speziell auf die Reibungsverluste im Produktionseinsatz (z. B. Token-Ablauf, API-Gateways) abgestimmt sind.

Die Autoren kommen zu dem Schluss, dass, obwohl die semantische Suche der notwendige nächste Schritt ist, um Lokalisierungsfehler zu beheben, die aktuelle Multi-Agenten-Architektur erfolgreich demonstriert, dass eine sichere, End-to-End-Issue-Lösung mit rigorosen Sicherheitskontrollen und baseline-bewusstem Testen erreichbar ist.