Orquestación de agentes de codificación de IA: controle cada fusión mediante evidencia

Los agentes de codificación paralelos no deben fusionarse porque cada sesión dice "listo". El valor predeterminado razonable es más estricto: proporcione a cada agente mutante un árbol de trabajo y una rama aislados, declare lo que puede cambiar y admita su rama solo cuando las verificaciones, la revisión, la actualización de la base y un recibo de entrega se refieran al compromiso principal exacto. Ese es el núcleo operativo de la orquestación de agentes de codificación de IA . El orquestador puede programar el trabajo y mostrar la actividad, pero la preparación para la fusión es una decisión basada en evidencia. Una sucursal puede estar funcionando, esperando legítimamente, bloqueada, obsoleta, fuera de alcance o completa pero no verificada. Colapsar esos estados hasta convertirlos en algo acabado es cómo el paralelismo se convierte en un fracaso silencioso de la integración. Esta guía crea un recibo de fusión sin contenido y reproduce ocho casos en su contra. El resultado es deliberadamente inconveniente: sólo un caso está listo. Los demás conservan el motivo para esperar o rechazar en lugar de ocultarlo detrás de una insignia de sesión verde. Orquestar para la admisión de fusión, no para la finalización de la sesión El panorama actual de herramientas facilita la ejecución paralela. ElEl equipo de VS Code describe los modos de agente local, en segundo plano y en la nube en la versión 1.109; sus agentes en segundo plano utilizan el aislamiento del árbol de trabajo, mientras que los subagentes paralelos mantienen la exploración fuera del contexto principal. El código abiertoProyecto del orquestador de agentesde manera similar, coloca las sesiones de codificación en árboles de trabajo aislados y enruta fallas de CI, revisa comentarios y fusiona conflictos a la sesión relevante. Esas son propiedades de ejecución útiles. No constituyen, por sí solos, un veredicto de fusión. Documentación git worktree de Gitexplica el importante límite. Los árboles de trabajo vinculados comparten datos del repositorio, pero cada uno tiene un estado por árbol de trabajo, como HEAD y el índice.GitTambién se niega a verificar una rama en múltiples árboles de trabajo a menos que se anulen las salvaguardas. Eso evita una clase de colisiones de índices y sistemas de archivos. No prueba que dos parches sean compatibles, que un agente haya permanecido dentro de su misión o que el resultado de la prueba de ayer se aplique a la cabeza de hoy. Utilice un recibo por sucursal candidata: Los identificadores son sintéticos. No se requiere ningún mensaje, archivo fuente, secreto, diferenciación o registro de prueba. El recibo incluye sólo los datos mínimos necesarios para decidir si el jefe de sucursal exacto puede avanzar. Cinco controles hacen que el valor predeterminado sea útil: 1. Aislamiento: el árbol de trabajo y la rama pertenecen a una sesión mutante activa. 2. Propiedad: cada ruta modificada está dentro de la asignación declarada. 3. Frescura: el candidato se basa en la base esperada y cada verificación se refiere a su cabeza actual. 4. Revisión: se aplica una aprobación al mismo jefe, sin ninguna solicitud de cambios sin resolver. 5. Resultado: un artefacto determinista demuestra el trabajo solicitado, no simplemente la finalización del comando. Documentación de rama protegida de GitHubrespalda la mitad de este contrato: las sucursales pueden requerir revisiones y verificaciones de estado exitosas, y las verificaciones estrictas pueden requerir que una sucursal esté al día con la base. La recepción de resultados amplía ese mecanismo. Una compilación exitosa demuestra que se aprobó un comando de compilación; no prueba necesariamente que la exportación solicitada exista, que el contrato API funcione o que el comportamiento visible para el usuario sea correcto. Ejecute la auditoría de preparación para la fusión de ocho casos Codifiqué el contrato en un pequeñoNode.jsclasificador y reprodujo ocho recibos de sucursales. El dispositivo utiliza una base actual, dos comprobaciones requeridas y ningún contenido del repositorio. Ejecútelo con: El clasificador aplica las puertas en este orden: El orden importa. Una espera legítima no debería convertirse en una compilación fallida simplemente porque no se han iniciado las comprobaciones. La desviación del alcance debería detener la sucursal antes de una evaluación costosa. La evidencia obsoleta no debe reinterpretarse como una falla actual: dice "volver a ejecutar contra este encabezado", no "el código no funciona". El experimento produjo un veredicto en cada categoría: Caso Veredicto Evidencia decisiva Sucursal completa merge ready Jefe actual, rutas de propiedad, comprobaciones recientes, aprobación, artefacto verificado Espacio de trabajo compartido isolation failed Otra sesión mutante es propietaria del espacio de trabajo. Edición de autenticación adicional scope drift src/auth.ts está fuera de la tarea de documentos Decisión de esquema waiting El revisor designado, el motivo y la fecha límite están presentes Antigua base de fusión stale base El candidato vio base 101 ; base actual es base 104 Nuevo compromiso después de CI stale evidence Los controles y revisiones pertenecen a cli 8 , no cli 9 Cambios solicitados review blocked La revisión se aplica a la cabeza pero no se aprueba. No hay prueba entregable outcome unverified La compilación y la prueba se aprobaron, pero el resultado solicitado no está verificado. Este es un resultado operativo más fuerte que “siete fracasos”. El caso del esquema no está fallando; está esperando una decisión explícita. El caso de verificación obsoleta puede contener código perfectamente bueno; su evidencia es sobre el compromiso incorrecto. El caso del resultado faltante puede haber pasado todas las pruebas genéricas y al mismo tiempo haber fracasado en la tarea que justificó la rama. La auditoría es falsificable. Si el clasificador marca algún caso incompleto como listo, la tesis fracasa. Si rechaza la recepción completa, el contrato es demasiado estricto o está mal ejecutado. En esta carrera, exactamente uno de ocho casos se convirtió en merge ready . Vincula cada señal verde a la cabeza del candidato. La regla más reutilizable del dispositivo es simple: Supongamos que un agente pasa CI en el compromiso cli 8 , luego hace un pequeño compromiso de “limpieza” cli 9 . Es posible que un panel aún muestre marcas verdes y una revisión aprobada. El estado correcto no es ni verde ni rojo. Es una evidencia obsoleta. Vuelva a ejecutar las comprobaciones afectadas y renueve la revisión o utilice un mecanismo de plataforma que invalide las aprobaciones cuando cambie la diferencia revisada. Aplique el mismo enlace de identidad al entregable. Los recibos útiles incluyen: una prueba de contrato que llama a la nueva API y valida su respuesta; un hash de artefacto generado más una verificación de decodificador o analizador; una afirmación del navegador contra la ruta integrada; un ensayo de migración contra una base de datos desechable; una importación de paquetes y una prueba de humo desde el paquete construido, no desde el árbol fuente; una búsqueda de destino que demuestra que un efecto externo alcanzó el registro deseado. Evite un resumen de LLM como único recibo de resultado cuando el resultado sea determinista. Un agente de codificación puede decir con confianza que creó un archivo que está ausente, ejecutó pruebas que luego fueron invalidadas o corrigió un comentario de revisión en una rama diferente. Prefiere la inspección directa. Utilice un juez modelo solo para propiedades que no se pueden verificar mecánicamente y registre la versión del juez, la rúbrica, la identidad de entrada y la incertidumbre. La espera también necesita identidad. Registre el propietario, el motivo, la fecha límite y la condición del currículum. "Esperando revisión" sin un propietario puede permanecer para siempre. "Esperando que el revisor de la plataforma hasta las 12:00 UTC apruebe la compatibilidad del esquema; reanudar en schema 3 ” es procesable y debe mantenerse fuera de la cola de fallas hasta que cambie la fecha límite o la evidencia. Sepa dónde se detiene la puerta La propiedad de la ruta es un filtro temprano, no una detección de conflictos semánticos. Dos ramas pueden editar archivos diferentes y aún así estar en desacuerdo sobre un tipo compartido, esquema de evento, cliente generado, orden de migración, indicador de característica o comportamiento de API. El aislamiento del árbol de trabajo evita colisiones simultáneas entre estados de archivos; no puede probar que se componen parches correctos de forma independiente. Por lo tanto, ejecute una puerta de integración final contra el candidato de fusión real: 1. actualizar o recrear el candidato a partir de la base prevista; 2. combinar los cambios aprobados sin evitar conflictos; 3. ejecutar las comprobaciones necesarias en el cabezal combinado; 4. repetir la verificación determinista del resultado; 5. adjuntar la evidencia resultante a ese encabezado combinado; 6. Requerir aprobación humana para la fusión o cualquier paso de recuperación irreversible. Esto suma trabajo. La frescura estricta de la base también puede provocar reconstrucciones repetidas mientras otras ramas aterrizan.GitHub documenta esa compensación: las estrictas comprobaciones requeridas mejoran la alineación de la base, pero pueden requerir más construcciones; Las comprobaciones sueltas reducen las reconstrucciones, pero pueden permitir que aparezca incompatibilidad después de la fusión. Elija la póliza por el costo del fracaso, no por el deseo de mantener ocupados a todos los agentes. El contrato de fusión tampoco reemplaza la revisión de código, la revisión de seguridad, los controles de implementación o la respuesta a incidentes. Les da a esos sistemas una identidad de candidato confiable y una razón clara cuando el trabajo no está listo. Sidewisp se encuentra actualmente en versión preliminar privada.La dirección de su producto es una capa de salud en torno a los tiempos de ejecución de agentes existentes, con evidencia de progreso útil, espera, herramientas y resultados manteniéndose diferenciados; Los adaptadores de recuperación y recopilación de estado del agente de producción generalmente no se envían. Si opera agentes de codificación paralelos, este recibo de fusión es el tipo de contrato de salud limitado que vale la pena probar ahora, antes de agregar una intervención autónoma. La regla final es intencionalmente conservadora: un agente que detiene es actividad; una rama dirigida, revisada y verificada por resultados es un progreso que puede aprobarse para su integración.