💻 computer science

Phoenix: Safe GitHub Issue Resolution via Multi-Agent LLMs

Phoenix is een multi-agent LLM-systeem dat veilig GitHub-issues oplost van triage tot aan het aanmaken van een pull-request door zeven gelaagde veiligheidscontroles en een baseline-bewuste evaluatiestrategie te hanteren, waarmee een oracle-resolutiepercentage van 75% wordt bereikt op een gecureerde SWE-bench Lite-slice terwijl een correctheidspreservatie van 100% op real-world issues behouden blijft.

Oorspronkelijke auteurs: Kipngeno Koech, Muhammad Adam, Baimam Boukar Jean Jacques, Joao Barros

Gepubliceerd 2026-06-19

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Kipngeno Koech, Muhammad Adam, Baimam Boukar Jean Jacques, Joao Barros

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een enorme, bruisende bibliotheek voor genaamd GitHub, waar miljoenen mensen plaknotities achterlaten in boeken om te vragen om reparaties, nieuwe functies of om te wijzen op typefouten. Deze briefjes worden "issues" genoemd. Normaal gesproken moet een menselijke bibliothecaris het briefje lezen, de exacte pagina in het boek vinden, ontdekken wat er mis is, de tekst herschrijven en vervolgens aan een senior bibliothecaris vragen om te controleren voordat het terug in de kast gaat. Dit is traag en vermoeiend.

Phoenix is een nieuw team van AI-robots die ontworpen zijn voor dit werk, maar met een zeer strikte regel: Breng geen schade toe.

Hier is hoe Phoenix werkt, onderverdeeld in eenvoudige concepten:

1. Het Team van Specialisten (De Zes Agenten)

In plaats van één superintelligent robot die alles tegelijk probeert te doen (wat vaak tot fouten leidt), gebruikt Phoenix een team van zes gespecialiseerde werkers, als een goed geoliede lopende band:

De Planner: Leest het plaknotitie en tekent een kaart. Het besluit welke pagina's aangepast moeten worden en hoe ze gerepareerd moeten worden.
De Reproducer (De Detective): Voordat er iets wordt gerepareerd, probeert deze robot het probleem na te bootsen. Het zegt: "Oké, als ik X doe, gaat het boek dan kapot?" Als het kan bewijzen dat het boek kapot is, gaat het verder. Als niet, slaat het deze stap over zodat het team niet vastloopt.
De Coder: De schrijver. Het neemt de kaart van de Planner en herschrijft daadwerkelijk de tekst op de pagina's.
De Tester: De kwaliteitsinspecteur. Het haalt het boek door een machine om te zien of de nieuwe tekst nieuwe fouten veroorzaakt.
De Failure Analyst: De dokter. Als de Tester een nieuwe fout vindt, diagnosticeert deze robot waarom het gebeurde en vertelt de Coder hoe ze het kunnen oplossen. Ze krijgen twee pogingen om het te fixen; als ze twee keer falen, stoppen ze en vragen ze menselijke hulp.
De PR Agent: De boodschapper. Zodra de reparatie klaar is, verpakt deze alles en overhandigt het aan een menselijke bibliothecaris voor de uiteindelijke goedkeuring.

2. Het "Veiligheidsnet" (Zeven Lagen Bescherming)

Het artikel benadrukt dat AI gevaarlijk kan zijn als het zomaar willekeurig boeken begint te herschrijven. Phoenix heeft zeven "veiligheidsbewakers" om rampen te voorkomen:

Het Hek: Het laat de robots niet buiten de muren van de bibliotheek schrijven (om te voorkomen dat ze bestanden verwijderen die ze niet mogen aanraken).
De ID-Badge: Het controleert of de robots geldige sleutels (tokens) hebben, zodat ze niet halverwege de klus worden buitengesloten.
De Opruimploeg: Het verwijdert rommelige, verwarrende delen uit de plaknotities voordat ze aan de robots worden getoond, zodat ze niet in de war raken door slechte formattering.
De "Niet-Lopen" Zone: Het weigert de beveiligingsbestanden van de bibliotheek (workflow files) aan te raken, omdat het aanpassen van die bestanden iedereen buiten de deur kan zetten.
De Stopknop: Als de robots in een loop terechtkomen of steeds dezelfde fout maken, trekt het systeem de stekker eruit.
De Solo Werker: Er wordt slechts aan één boek tegelijk gewerkt om te voorkomen dat de robots tegen elkaar opbotsen.
De Verse Sleutel: Het ververst automatisch de ID-badges voordat ze verlopen, zodat de klus nooit stopt door een tijdingsprobleem.

3. De "Vóór en Na" Test (Baseline Bewustzijn)

Dit is de meest slimme truc van Phoenix. Soms is een bibliotheekboek al kapot voordat de robot eraan begint.

De Oude Manier: Een robot repareert een typefout, maar het boek faalt nog steeds voor een test omdat het al kapot was. De robot krijgt de schuld van de fout.
De Phoenix Manier: Voordat de robot iets verandert, maakt het een "snapshot" van de huidige staat van het boek. Nadat de robot wijzigingen heeft aangebracht, vergelijkt het de nieuwe staat met de snapshot.
- Als het boek al kapot was en ook na de wijziging kapot blijft (maar er zijn geen nieuwe dingen kapot), zegt Phoenix: "Succes! We hebben het niet erger gemaakt."
- Als het boek wel werkte en nu kapot is, zegt Phoenix: "Stop! We hebben een regressie geïntroduceerd."

4. Wat de Resultaten Laten Zien

De onderzoekers hebben Phoenix op twee manieren getest:

De Oefenronde (SWE-bench Lite): Ze gaven Phoenix 24 specifieke, vooraf gedefinieerde problemen. Phoenix loste 75% van hen perfect op zonder iets te breken dat al werkte.
De Test in de echte wereld (42 Echte Issues): Ze lieten Phoenix los op 42 werkelijke issues van 14 verschillende echte projecten.
- Veiligheid: Phoenix behaalde 100% "Correctness Preservation". Dit betekent dat het nooit een test brak die eerder wel slaagde. Het was ongelooflijk veilig.
- Succespercentage: Echter, slechts ongeveer de helft van de reparaties was daadwerkelijk de juiste reparatie. Bij de andere helft was er sprake van "hallucinaties", waarbij de robot code op de verkeerde plek schreef (zoals een reparatiehandleiding in de fictieafdeling schrijven). De robot wist hoe hij het moest repareren, maar kon soms niet vinden waar het probleem precies zat.

De Kernboodschap

Phoenix is als een zeer voorzichtige, hoogopgeleide leerling-bibliothecaris. Het is uitstekend in het niet erger maken van zaken en erg goed in het volgen van een strikt proces. Het worstelt echter soms met het vinden van de exacte locatie van een probleem als de beschrijving niet perfect overeenkomt met de bestandsnamen.

Het artikel concludeert dat voor AI om nuttig te zijn in de echte wereld, veiligheid voorrang moet hebben op snelheid. Phoenix bewijst dat je, door een team van gespecialiseerde agenten en strikte veiligheidsregels te gebruiken, software-reparaties kunt automatiseren zonder per ongeluk de software te breken. Het belangrijkste punt dat nog verbeterd moet worden, is het helpen van de "Planner"-robot om de juiste pagina in het boek vaker te vinden.

Technische Samenvatting: Phoenix – Veilige Resolutie van GitHub Issues via Multi-Agent LLM's

Probleemstelling

Open-source repositories op GitHub verzamelen duizenden onopgeloste issues, wat een hardnekkige onderhoudsbottleneck creëert. Hoewel Large Language Models (LLMs) potentieel hebben getoond bij het automatiseren van software engineering-taken (bijv. Devin, SWE-Agent, AutoCodeRover), brengt het optimaliseren voor enkel de resoltiegraad van issues vaak de veiligheid in gevaar. Systemen die een deel van de issues oplossen maar in andere regressies introduceren, bieden een onzekere netto waarde in productieomgevingen. Bovendien richten bestaande benchmarks zich vaak op offline prestaties, waarbij de complexiteit van productie-implementatie, zoals API gateway-filtering, tokenverloop en reeds bestaande defecte testsuites, wordt genegeerd.

Methodologie

Phoenix is een multi-agent LLM-systeem ontworpen om GitHub issues op te lossen van triage tot aan de creatie van een pull-request (PR), waarbij de prioriteit ligt bij het behoud van correctheid boven de ruwe resoltiegraad. Het systeem werkt via een closed-loop pipeline die wordt gecoördineerd door een centrale Orchestrator en een label-gebaseerde GitHub webhook state machine.

Systeemarchitectuur

De pipeline deelt de workflow op in zes gespecialiseerde agents, die elk overeenkomen met een fase in een conventioneel proces voor het oplossen van issues:

Planner Agent: Ontvangt gesaneerde issue-tekst, repository file trees en relevante fragmenten. Het genereert een gestructureerd JSON-plan met details over de aanpak, bestanden om te wijzigen, implementatiestappen en de teststrategie. Het gebruikt keyword overlap scoring om de relevantie van bestanden te bepalen.
Reproducer Agent (Optioneel): Probeert een synthetische test te genereren die faalt op de base branch om de bug te demonstreren. Falen in deze stap is niet-blokkerend, waardoor de pipeline kan doorgaan naar codering, zelfs als een testharnas niet automatisch gegenereerd kan worden.
Coder Agent: Genereert volledige bestandinhoud voor gewijzigde bestanden op basis van het plan en eventuele eerdere feedback over fouten. Het dwingt zelfverificatie af en houdt zich aan bestaande codestijlen.
Tester Agent: Voert de testsuite van het project uit. Cruciaal is dat het een baseline-bewuste testevaluatiestrategie hanteert:
- Het stasht de wijzigingen van Phoenix en draait de suite op de ongewijzigde base branch om baseline-fouten ( $B$ ) te verzamelen.
- Het herstelt de wijzigingen en draait de suite opnieuw om post-change fouten ( $P$ ) te verzamelen.
- Correctheid wordt behouden als $P \setminus B = \emptyset$ (geen eerder passerende test faalt nu). Dit maakt evaluatie mogelijk op repositories met defecte CI-pipelines.
Failure Analyst Agent: Als er nieuwe fouten worden gedetecteerd, analyseert deze agent de output en geeft gestructureerde feedback aan de Coder voor maximaal twee retry-cycli.
PR Agent: Stelt een pull request samen en opent deze, waarbij de status wordt overgezet naar ai:review voor menselijke inspectie.

Veiligheidsmechanismen

Zeven gelaagde veiligheidscontroles zijn afgeleid van empirische foutmodi waargenomen tijdens ontwikkeling en implementatie:

Path-traversal preventie: Valideert dat bestandsschrijfacties de repository root niet verlaten.
Label-state exclusiviteit: Zorgt voor atomaire statusovergangen om de accumulatie van verouderde labels te voorkomen.
Workflow file guardrail: Negeert stilletjes schrijfacties naar .github/workflows/ om permissiefouten te voorkomen.
Content sanitization: Truncateert issue-bodies en verwijdert stack traces om 403-responses van API gateways (WAF) te vermijden.
Retry cycle limit: Beperkt de feedback van de Failure Analyst tot twee rondes; een no-progress detector beëindigt loops als wijzigingen identiek zijn.
Concurrency serialisatie: Een per-installatie lock zorgt ervoor dat er één issue tegelijk wordt verwerkt op gedeelde clones.
Installatie token refresh: Ververst proactief GitHub App tokens vóór verlooptijd om authenticatiefouten tijdens lange runs te voorkomen.

Belangrijkste Bijdragen

Architectuur: Een zes-agent pipeline met een optionele Reproducer, een label-gestuurde state machine en een expliciete ontwerp-ratio voor decompositie, wat geïsoleerde testen en fouttoeschrijving mogelijk maakt.
Baseline-Bewuste Evaluatie: Een teststrategie die onderscheid maakt tussen pre-existente fouten en door Phoenix geïntroduceerde regressies, wat evaluatie op repositories met defecte CI mogelijk maakt.
Implementatie-lessen: Een karakterisering van real-world gevaren (WAF-filtering, tokenverloop, permissiegrenzen) en de specifieke mechanismen die zijn ontwikkeld om deze aan te pakken.

Resultaten

Het artikel presenteert resultaten uit twee evaluatie-settings:

1. SWE-bench Lite (24 Instanties)

Geëvalueerd op een gecureerde selectie van 24 instanties over 12 repositories (3 instanties elk).

Oracle Resolutie: Phoenix bereikte een oracle resolutiepercentage van 75% (18/24 instanties).
Regressie Veiligheid: Bij alle oracle-passende runs waren er geen pass-to-pass regressies.
Foutmodi: Fouten waren primair toe te schrijven aan terminale ai:failed statussen of evaluator time-outs, en niet aan veiligheidschendingen.
Noot: De auteurs geven expliciet aan dat deze gecureerde selectie niet direct vergelijkbaar is met de full-split leaderboard resultaten vanwege het gebruik van het productie webhook pad.

2. Pilot op 42 Real Issues (14 Repositories)

Geëvalueerd over 14 repositories verdeeld in Easy, Medium en Hard difficulty tiers.

Correctheid Behoud (CP): Phoenix bereikte 100% CP (42/42 issues). Er werden geen nieuwe testfouten geïntroduceerd ten opzichte van de baseline.
Resolutie Tijd: Bij "Hard" tier repositories was de gemiddelde end-to-end resolutie tijd 122 seconden.
Kwalitatieve Inspectie: Handmatige review onthulde een dichotomie in outputkwaliteit:
- ~50% van de PR's waren goed gerichte fixes die bestaande modules wijzigden.
- ~50% van de PR's plaatste code op onjuiste, verzonnen paden (bijv. src/core/config.py). Deze passeerden CP omdat ze geen regressies introduceerden, maar losten de gerapporteerde bug niet op. Deze beperking wordt toegeschreven aan de lexicale file ranking van de Planner in plaats van code synthese capaciteiten.

Betekenis en Claims

Het artikel positioneert Phoenix niet als een systeem dat het aantal opgeloste issues maximaliseert, maar als een systeem dat de prioriteit geeft aan correctheid behoud en veiligheid in productieomgevingen.

Veiligheid als Eerstelijns Vereiste: De auteurs stellen dat betrouwbare autonome code-modificatie vereist dat veiligheid wordt behandeld als een engineering-vereiste afgeleid van empirische foutmodi, in plaats van een speculatief ontwerp.
Bescheiden Claims over Resolutie: Het artikel erkent dat 100% correctheid behoud niet gelijkstaat aan 100% issue resolutie. Het gat wordt gedreven door lokalisatiebeperkingen (het onvermogen van de Planner om issue-vocabulaire te mappen naar file paths zonder semantische retrieval) in plaats van code generatie.
Productie Gereedheid: In tegenclus bij eerder werk dat gericht is op offline benchmarks, is Phoenix ontworpen voor echte webhooks, echte branches en echte PR's, met mechanismen die specifiek zijn afgestemd op het aanpakken van de frictie van productie-implementatie (bijv. tokenverloop, API gateways).

De auteurs concluderen dat hoewel semantische retrieval de noodzakelijke volgende stap is om lokalisatiefouten aan te pakken, de huidige multi-agent architectuur succesvol aantoont dat veilige, end-to-end issue resolutie haalbaar is met rigoureuze veiligheidscontroles en baseline-bewuste testen.