Un enfoque de depuración unificado a través de la sinergia de múltiples agentes basada en LLM: verificar la reparación

Un enfoque de depuración unificado a través de la sinergia de múltiples agentes basada en LLM es útil sólo cuando sus agentes dejan evidencia que sobrevive a su propia conversación. Un localizador puede parecer seguro, un reparador puede emitir un parche y un revisor puede aprobarlo mientras que la falla original nunca se reprodujo o el caso límite decisivo nunca se probó. Por lo tanto, el valor predeterminado razonable es: dejar que los agentes especializados propongan y cuestionen una reparación, pero promuevan el parche solo después de que un recibo vinculado demuestre la reproducción, el linaje, la cobertura de la prueba, la calidad del oráculo y la revisión. Esa regla operativa sigue la arquitectura del artículo FixAgent sin confundir los resultados de la investigación con una garantía de producción. El documento separa la localización de fallas, la generación de parches y el análisis posterior al error entre agentes especializados. También distingue un parche plausible que pasa las pruebas disponibles de un parche correcto establecido mediante verificación manual. Esa distinción es el límite de la salud. Lo que demuestra el resultado FixAgent y lo que no demuestra El diseño publicado de FixAgent es más específico que "pedir a varios modelos que depuren". Su metodología utiliza un localizador, un reparador y un revisitor, además de un agente de elaboración de insumos para pruebas adicionales. Los agentes explican su razonamiento, rastrean variables importantes y transmiten los resultados de la etapa anterior. Si el parche generado falla, se puede volver a probar la etapa de reparación con comentarios de prueba. El artículo informa resultados sólidos en QuixBugs, Codeflaws y ConDefects. Esos son resultados de la investigación según los conjuntos de datos, modelos, indicaciones y procedimientos de verificación del artículo. No establecen que sea seguro fusionar un parche de repositorio arbitrario. Dos detalles de la fuente principal cambian la decisión operativa: 1. El documento define un parche plausible como aquel que pasa las pruebas escritas por humanos, mientras que la corrección requiere una verificación manual por separado. 2. Su sección de limitaciones dice que el agente de entrada de prueba adicional no puede calcular los resultados esperados por sí solo. Una entrada generada sin un oráculo confiable no es una prueba completa. La implementación Rudra publicada hace que el límite sea inspeccionable. Su corredor de múltiples rondas trata cero casos de falla observados como una reparación exitosa y devuelve esa bandera al lanzador. Esto es apropiado para el ciclo de prueba de un experimento. Un operador todavía necesita preguntar qué suites se ejecutaron, si su oráculo es confiable, si el resultado pertenece a este parche y si un revisor aceptó la diferencia real. La lección no es que la revisión de los agentes sea inútil. El desacuerdo de los especialistas puede exponer una mala localización o una zona débil. La lección es que el texto de un agente no debe ser la única evidencia consumida por el siguiente. Vincula cada etapa de depuración con un recibo de reparación Un recibo de reparación mínimo puede estar libre de contenido. No necesita indicaciones, código fuente, resultados de prueba ni razonamiento del modelo. Necesita identidades estables y veredictos que permitan a una puerta humana o determinista reconstruir la frontera: Límite Campos mínimos de recibo El fracaso lo atrapa Reproducción ID de ejecución, hash de comando, error original observado Un parche para un error que nunca fue reproducido Localización ID de ejecución, revisión de fuente, marca de tiempo de evidencia Un resultado de localizador reutilizado de otra revisión Parche hash de parche, revisión principal, recuento de líneas modificadas Una reparación vacía, obsoleta o no relacionada Validación ID de suite requeridas, ID de suite observadas, recuento fallido “Todas las pruebas pasan” cuando una suite requerida nunca se ejecutó Oráculo verificado, desconocido o cuestionado Casos generados sin resultado esperado confiable Revisión espera aprobada, rechazada o propia Acuerdo modelo confundido con autoridad de fusión Resultado reclamación de finalización y recibo de destino Una ejecución completada cuyo parche no fue verificado ni entregado El ID de ejecución es especialmente importante. Una respuesta de localización de run old no debe justificar silenciosamente un parche de run 42 . El hash del parche es igualmente importante: un registro de prueba verde para una diferencia no se puede adjuntar a una nueva muestra posterior. Este es un linaje común y corriente, pero los flujos de trabajo de los agentes a menudo lo pierden porque el contexto conversacional hace que los mensajes cercanos parezcan relacionados. Aquí está la forma utilizada por el dispositivo adjunto: Las cadenas son identificadores, no contenido almacenado. En un sistema real, los hashes deben calcularse a partir de entradas y artefactos canónicos, y el registro de prueba debe incluir la versión de la herramienta, la revisión de la configuración, la hora de inicio, la hora de finalización y el origen de la salida. Los secretos, las indicaciones, el contenido de los archivos y los argumentos sin procesar de las herramientas deben permanecer fuera del recibo de salud. Repita nueve estados inconvenientes antes de confiar en el verde El artefacto del artículo contiene nueve casos sintéticos y un clasificador Node.js ordenado por prioridad. Ejecútelo desde el directorio del informe del artículo: El resultado observado es: Los casos son deliberadamente inconvenientes: UNREPRODUCED detiene el flujo de trabajo antes de que un parche seguro pueda ocultar una línea base faltante. LOCALIZATION DRIFT captura un recibo de localizador de una ejecución diferente. NO EFFECTIVE PATCH rechaza un hash faltante o un cambio de línea cero. TEST GAP informa un conjunto de integración requerido que nunca se ejecutó, incluso cuando los conjuntos observados están en verde. ORACLE UNCERTAIN preserva la incertidumbre cuando las entradas generadas no tienen salidas esperadas verificadas. REVIEW REJECTED evita que un parche técnicamente verde se convierta en aprobado. WAITING representa una dependencia legítima solo cuando el recibo nombra un propietario y una fecha límite. FALSE COMPLETE supera a una afirmación de finalización cuando alguna prueba observada aún falla. VERIFIED REPAIR requiere que todos los límites anteriores estén de acuerdo. El orden importa. Un reclamo de finalización no puede anular una prueba fallida. Un contador de cero fallos no puede anular un conjunto faltante. Un caso límite generado no puede establecer la corrección sin un oráculo. Una espera de revisión no debe catalogarse como puesto cuando tiene dueño y fecha límite. Este experimento también muestra por qué una puntuación de salud única es un artefacto de depuración deficiente. Tanto el caso suite gap como el verified repair no reportan pruebas fallidas, pero sus estados operativos difieren porque uno nunca ejecutó el conjunto de integración requerido. La evidencia que falta es más importante que la ficha verde. Agregue la puerta a un flujo de trabajo de agente de codificación real Comience con un límite de promoción pequeño en lugar de reconstruir el marco del agente: 1. Congele la revisión de entrada. Registre la confirmación del repositorio o la instantánea del espacio de trabajo antes de la localización. 2. Reproduzca el error. Almacene un comando/hash de configuración y un resultado estructurado. Si la reproducción es irregular, etiquétela como incierta y no trate un posible tramo verde como prueba de reparación. 3. Vincular cada transferencia. Exija que los recibos del localizador, reparador y revisor hagan referencia a la misma ejecución y revisión principal. 4. Remuestreo vinculado. El ciclo de retroalimentación del documento FixAgent es útil, pero los reintentos consumen presupuesto y pueden cambiar el parche. Asigne a cada nuevo parche su propio hash, intentos de límite e invalide la evidencia de pruebas anteriores cuando cambie la diferencia. 5. Declare las suites requeridas antes de la ejecución. De lo contrario, un agente puede redefinir "todas las pruebas" después de ver los resultados. 6. Ejecución de prueba separada de la autoridad de Oracle. Las entradas generadas pueden mejorar la cobertura, pero una persona, especificación, implementación de referencia o regla determinista independiente debe proporcionar el resultado esperado. 7. Mantenga la autoridad de fusión o implementación controlada por humanos. Un recibo aprobado puede preparar la decisión; no debe ampliar el permiso del agente. 8. Verifique el destino. Si la tarea era abrir una solicitud de extracción, actualizar un problema o producir un artefacto de lanzamiento, verifique ese destino de forma independiente. Un parche local es actividad, no necesariamente el resultado solicitado. Para una pausa de aprobación, utilice un registro explícito: No llame simplemente porque el agente está en silencio mientras el registro está actualizado. Escalar cuando expire el plazo, el propietario esté desaparecido o la ejecución reanudada no produzca nuevas pruebas. La espera no se estanca; La actividad repetida sin un resultado delta no es progreso. El límite para Sidewisp La tesis sustentable es estrecha: la depuración de múltiples agentes se vuelve operacionalmente confiable cuando los resultados de los especialistas se unen a evidencia determinista de reparación, y el verde se retiene cuando falta evidencia de linaje, cobertura, calidad del oráculo, revisión o resultados. El acuerdo de nueve casos falsifica el atajo “cero fallas observadas significa reparación verificada” porque dos casos de cero fallas llegan a veredictos diferentes. Este es un patrón operativo, no una afirmación de que Sidewisp actualmente ejecuta FixAgent o monitorea las reparaciones del agente de codificación. Sidewisp se encuentra actualmente en versión preliminar privada. Es una plataforma de estado del agente de IA, pero el motor de monitoreo de producción, los adaptadores de tiempo de ejecución y el ejecutor de recuperación generalmente no se envían. La capa de salud prevista es relevante aquí porque distingue el progreso útil, la espera legítima, la finalización falsa y la evidencia incierta, al tiempo que permite fusionar la autoridad con lo humano. Utilice el recibo primero en un flujo de trabajo de depuración repetido. Si no puede distinguir una suite perdida de una reparación verificada sin leer la transcripción, el contrato de evidencia aún es demasiado débil.