💻 computer science

Phoenix: Safe GitHub Issue Resolution via Multi-Agent LLMs

Phoenix es un sistema de LLM multi-agente que resuelve de forma segura problemas de GitHub desde el triaje hasta la creación de pull-requests mediante el empleo de siete controles de seguridad por capas y una estrategia de evaluación consciente de la línea base, logrando una tasa de resolución de oráculo del 75% en una porción curada de SWE-bench Lite mientras mantiene una preservación de corrección del 100% en problemas del mundo real.

Autores originales: Kipngeno Koech, Muhammad Adam, Baimam Boukar Jean Jacques, Joao Barros

Publicado 2026-06-19

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Kipngeno Koech, Muhammad Adam, Baimam Boukar Jean Jacques, Joao Barros

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina una biblioteca masiva y bulliciosa llamada GitHub, donde millones de personas dejan notas adhesivas en los libros pidiendo arreglos, nuevas funciones o señalando errores tipográficos. Estas notas se llaman "issues" (problemas). Normalmente, un bibliotecario humano tiene que leer la nota, encontrar la página exacta en el libro, averiguar qué está mal, reescribir el texto y luego pedir a un bibliotecario sénior que lo revise antes de que vuelva al estante. Esto es lento y agotador.

Phoenix es un nuevo equipo de robots de IA diseñados para hacer este trabajo, pero con una regla muy estricta: No hacer daño.

Así es como funciona Phoenix, desglosado en conceptos simples:

1. El equipo de especialistas (Los seis agentes)

En lugar de un único robot superinteligente intentando hacer todo a la vez (lo que a menudo conduce a errores), Phoenix utiliza un equipo de seis trabajadores especializados, como una línea de montaje bien aceitada:

El Planificador: Lee la nota adhesiva y dibuja un mapa. Decide qué páginas deben cambiarse y cómo arreglarlas.
El Reproductor (El Detective): Antes de arreglar nada, este robot intenta recrear el problema. Dice: "Bien, si hago X, ¿se rompe el libro?". Si puede demostrar que el libro está roto, continúa. Si no, se salta este paso para que el equipo no se quede estancado.
El Programador: El escritor. Toma el mapa del Planificador y realmente reescribe el texto de las páginas.
El Probador: El inspector de calidad. Pasa el libro por una máquina para ver si el nuevo texto causa nuevos errores.
El Analista de Fallos: El médico. Si el Probador encuentra un nuevo error, este robot diagnostica por qué ocurrió y le dice al Programador cómo arreglarlo. Tienen dos intentos para arreglarlo; si fallan dos veces, se detienen y piden ayuda humana.
El Agente de PR: El mensajero. Una vez que el arreglo está listo, empaqueta todo y lo entrega a un bibliotecario humano para su aprobación final.

2. La "Red de Seguridad" (Siete capas de protección)

El documento enfatiza que la IA puede ser peligrosa si simplemente empieza a reescribir libros al azar. Phoenix tiene siete "guardias de seguridad" para evitar desastres:

La Valla: No permite que los robots escriban fuera de los muros de la biblioteca (evitando que borren archivos que no deberían tocar).
La Credencial: Comprueba que los robots tengan llaves (tokens) válidas para que no se queden bloqueados a mitad del trabajo.
El Equipo de Limpieza: Elimina las partes desordenadas y confusas de las notas adhesivas antes de mostrárselas a los robots, para que no se confundan con un mal formato.
La Zona Prohibida: Se niega a tocar los archivos del sistema de seguridad de la biblioteca (archivos de workflow) porque alterar esos archivos podría dejar a todos fuera.
El Botón de Parada: Si los robots se quedan atrapados en un bucle o siguen cometiendo el mismo error, el sistema desconecta la corriente.
El Trabajador Solitario: Solo se trabaja en un libro a la vez para evitar que los robots se tropiecen entre sí.
La Llave Fresca: Actualiza automáticamente sus credenciales antes de que caduquen, para que el trabajo nunca se detenga debido a un tiempo de espera agotado.

3. La prueba de "Antes y Después" (Conciencia de la línea base)

Este es el truco más ingenioso de Phoenix. A veces, un libro de la biblioteca ya está roto antes de que el robot lo toque.

Forma Antigua: Un robot arregla una errata, pero el libro sigue fallando porque ya estaba roto. El robot es culpado por el fallo.
Forma de Phoenix: Antes de que el robot realice cualquier cambio, toma una "instantánea" del estado actual del libro. Después de que el robot realiza los cambios, compara el nuevo estado con la instantánea.
- Si el libro ya estaba roto y sigue roto (pero no se rompen cosas nuevas), Phoenix dice: "¡Éxito! No lo hemos empeorado".
- Si el libro funcionaba y ahora está roto, Phoenix dice: "¡Alto! Hemos introducido una regresión".

4. Qué muestran los resultados

Los investigadores probaron Phoenix de dos maneras:

El Ensayo General (SWE-bench Lite): Le dieron a Phoenix 24 problemas específicos y predefinidos. Phoenix resolvió el 75% de ellos perfectamente sin romper nada que ya estuviera funcionando.
La Prueba del Mundo Real (42 Problemas Reales): Dejaron que Phoenix actuara sobre 42 problemas reales de 14 proyectos diferentes del mundo real.
- Seguridad: Phoenix logró un 100% de "Preservación de la Corrección". Esto significa que nunca rompió una prueba que previamente estaba pasando. Fue increíblemente seguro.
- Tasa de Éxito: Sin embargo, solo la mitad de los arreglos fueron realmente el arreglo correcto. La otra mitad fueron "alucinaciones" donde el robot escribió código en el lugar equivocado (como escribir un manual de reparación en la sección de ficción). El robot sabía cómo arreglarlo, pero a veces no podía encontrar dónde estaba el problema.

Conclusión

Phoenix es como un aprendiz de bibliotecario muy cauteloso y altamente entrenado. Es excelente en no empeorar las cosas y muy bueno siguiendo un proceso estricto. Sin embargo, a veces le cuesta encontrar la ubicación exacta de un problema si la descripción no coincide perfectamente con los nombres de los archivos.

El documento concluye que, para que la IA sea útil en el mundo real, la seguridad debe ir antes que la velocidad. Phoenix demuestra que, mediante el uso de un equipo de agentes especializados y estrictas salvaguardas de seguridad, se puede automatizar la corrección de software sin romper accidentalmente el software. El principal aspecto a mejorar es ayudar al robot "Planificador" a encontrar la página correcta en el libro con más frecuencia.

Resumen Técnico: Phoenix – Resolución Segura de Issues de GitHub mediante LLMs Multi-Agente

Declaración del Problema

Los repositorios de código abierto en GitHub acumulan miles de problemas (issues) sin resolver, lo que crea un cuello de botella persistente en el mantenimiento. Aunque los Modelos de Lenguaje de Gran Escala (LLMs) han demostrado potencial para automatizar tareas de ingeniería de software (por ejemplo, Devin, SWE-Agent, AutoCodeRover), optimizar únicamente para las tasas de resolución de issues puede comprometer la seguridad. Los sistemas que resuelven una parte de los issues pero introducen regresiones en otros ofrecen un valor neto incierto en entornos de producción. Además, los benchmarks existentes suelen centrarse en el rendimiento offline, ignorando las complejidades del despliegue en producción, tales como el filtrado de la puerta de enlace de API (API gateway), la expiración de tokens y las suites de pruebas preexistentes que ya están rotas.

Metodología

Phoenix es un sistema de LLM multi-agente diseñado para resolver issues de GitHub desde el triaje hasta la creación de pull-requests (PR), priorizando la preservación de la corrección sobre las tasas de resolución bruta. El sistema opera mediante un pipeline de bucle cerrado coordinado por un Orquestador central y una máquina de estados basada en etiquetas (labels) de GitHub.

Arquitectura del Sistema

El pipeline descompone el flujo de trabajo en seis agentes especializados, cada uno correspondiente a una etapa de un proceso convencional de resolución de issues:

Agente Planificador (Planner Agent): Recibe el texto sanitizado del issue, los árboles de archivos del repositorio y fragmentos relevantes. Genera un plan estructurado en JSON que detalla el enfoque, los archivos a modificar, los pasos de implementación y la estrategia de prueba. Utiliza una puntuación de superposición de palabras clave para determinar la relevancia de los archivos.
Agente Reproductor (Reproducer Agent - Opcional): Intenta generar una prueba sintética que falle en la rama base para demostrar el error. El fallo en este paso no es bloqueante, permitiendo que el pipeline proceda a la codificación incluso si no se puede generar automáticamente un entorno de pruebas.
Agente Programador (Coder Agent): Genera contenidos de archivos completos para los archivos modificados basándose en el plan y cualquier feedback de fallos previos. Fuerza la autoverificación y se adhiere a los estilos de código existentes.
Agente de Pruebas (Tester Agent): Ejecuta la suite de pruebas del proyecto. Crucialmente, emplea una estrategia de evaluación de pruebas consciente de la línea base (baseline-aware):
- Almacena temporalmente (stashes) los cambios de Phoenix y ejecuta la suite en la rama base no modificada para recolectar fallos de la línea base ( $B$ ).
- Restaura los cambios y vuelve a ejecutar para recolectar fallos post-cambio ( $P$ ).
- La corrección se preserva si $P \setminus B = \emptyset$ (ninguna prueba que antes pasaba ahora falla). Esto permite la evaluación en repositorios con pipelines de CI rotos.
Agente de Análisis de Fallos (Failure Analyst Agent): Si se detectan nuevos fallos, este agente analiza la salida y proporciona feedback estructurado al Agente Programador durante hasta dos ciclos de reintento.
Agente de PR (PR Agent): Compone y abre un pull request haciendo referencia al issue, transicionando el estado a ai:review para la inspección humana.

Mecanismos de Seguridad

Se derivaron siete controles de seguridad por capas a partir de los modos de fallo empíricos observados durante el desarrollo y despliegue:

Prevención de salto de directorio (path-traversal): Valida que las escrituras de archivos no escapen de la raíz del repositorio.
Exclusividad de estado de etiquetas: Asegura transiciones de estado atómicas para evitar la acumulación de etiquetas obsoletas.
Salvaguarda de archivos de flujo de trabajo: Descarta silenciosamente las escrituras en .github/workflows/ para evitar errores de permisos.
Sanitización de contenido: Trunca los cuerpos de los issues y elimina los stack traces para evitar respuestas 403 de la puerta de enlace de API (WAF).
Límite de ciclo de reintento: Limita el feedback del Agente de Análisis de Fallos a dos rondas; un detector de falta de progreso termina los bucles si los cambios son idénticos.
Serialización de concurrencia: Un bloqueo por instalación asegura que se procesa un solo issue a la vez en clones compartidos.
Actualización de tokens de instalación: Actualiza proactivamente los tokens de la aplicación de GitHub antes de su expiración para evitar fallos de autenticación durante ejecuciones largas.

Contribuciones Clave

Arquitectura: Un pipeline de seis agentes con un Reproductor opcional, una máquina de estados impulsada por etiquetas y una justificación de diseño explícita para la descomposición, lo que permite pruebas aisladas y atribución de fallos.
Evaluación Consciente de la Línea Base: Una estrategia de prueba que distingue los fallos preexistentes de las regresiones introducidas por Phoenix, permitiendo la evaluación en repositorios con CI roto.
Lecciones de Despliegue: Una caracterización de los peligros del mundo real (filtrado WAF, expiración de tokens, límites de permisos) y los mecanismos específicos desarrollados para abordar estos problemas.

Resultados

El artículo presenta resultados de dos entornos de evaluación:

1. SWE-bench Lite (24 Instancias)

Evaluado en una selección curada de 24 instancias en 12 repositorios (3 instancias cada uno).

Resolución Oracle: Phoenix alcanzó una tasa de resolución oracle del 75% (18/24 instancias).
Seguridad de Regresión: En todas las ejecuciones que pasaron el oracle, no hubo regresiones de paso-a-paso.
Modos de Fallo: Los fallos se debieron principalmente a estados terminales ai:failed o tiempos de espera del evaluador, no a violaciones de seguridad.
Nota: Los autores declaran explícitamente que esta selección curada no es directamente comparable con los resultados del leaderboard de split completo debido al uso de la ruta de webhook de producción.

2. Piloto en 42 Issues Reales (14 Repositorios)

Evaluado en 14 repositorios que abarcan niveles de dificultad Fácil, Medio y Difícil.

Preservación de la Corrección (CP): Phoenix logró un 100% de CP (42/42 issues). No se introdujeron nuevos fallos de prueba en relación con la línea base.
Tiempo de Resolución: En repositorios de nivel "Difícil", el tiempo medio de resolución end-to-end fue de 122 segundos.
Inspección Cualitativa: La revisión manual reveló una dicotomía en la calidad de la salida:
- ~50% de los PR fueron correcciones bien dirigidas que modificaron módulos existentes.
- ~50% de los PR colocaron código en rutas inventadas e incorrectas (ej. src/core/config.py). Estos pasaron la CP porque no introdujeron regresiones, pero no solucionaron el bug reportado. Esta limitación se atribuye al ranking léxico de archivos del Planificador más que a las capacidades de síntesis de código.

Significancia y Reivindicaciones

El artículo posiciona a Phoenix no como un sistema que maximiza el número de issues resueltos, sino como un sistema que prioriza la preservación de la corrección y la seguridad en entornos de producción.

La Seguridad como Requisito de Primera Clase: Los autores argumentan que la modificación autónoma de código fiable requiere tratar la seguridad como un requisito de ingeniería derivado de modos de fallo empíricos, en lugar de un diseño especulativo.
Reivindicaciones Modestas sobre la Resolución: El artículo reconoce que la preservación del 100% de la corrección no equivale a la resolución del 100% de los issues. La brecha es impulsada por limitaciones de localización (la incapacidad del Planificador para mapear el vocabulario del issue con las rutas de archivos sin recuperación semántica), no por la generación de código.
Preparación para Producción: A diferencia de trabajos previos centrados en benchmarks offline, Phoenix está diseñado para webhooks reales, ramas reales y PR reales, con mecanismos específicamente ajustados para manejar la fricción del despliegue en producción (ej. expiración de tokens, puertas de enlace de API).

Los autores concluyen que, si bien la recuperación semántica es el siguiente paso necesario para abordar los fallos de localización, la arquitectura multi-agente actual demuestra con éxito que la resolución de issues segura y de extremo a extremo es alcanzable con controles de seguridad rigurosos y pruebas conscientes de la línea base.