Antigravity 2.0 también proporciona capacidades de administración de subagentes, ganchos, tareas programadas y agentes.
Abrirlos todos no mejorará automáticamente la eficiencia, pero permitirá que varios agentes modifiquen fácilmente el mismo archivo.
¿De qué son responsables las cuatro habilidades?
El subagente es adecuado para subtareas que se pueden aceptar de forma independiente.
Los ganchos son adecuados para ejecutar reglas breves cuando ocurren ciertos eventos.
La tarea programada es adecuada para tareas recurrentes activadas por el tiempo.
El Agent Manager es responsable de observar e intervenir en la ejecución de las tareas.
No utilice tareas programadas para reemplazar los reintentos fallidos y no utilice Hooks para alojar compilaciones a largo plazo.
Delimitar propiedad con un almacén
Digamos que el repositorio contiene la interfaz, la API y la documentación.
Establezca la propiedad de la ruta para tres tipos de tareas:
|
|
Los archivos de bloqueo compartidos, la configuración de CI y las migraciones de bases de datos no se asignan al subagente normal.
Requieren agente maestro o procesamiento en serie manual.
Cada Subagente utiliza un árbol de trabajo independiente
|
|
El árbol de trabajo permite aislar las modificaciones, pero no puede resolver conflictos de bases de datos, puertos y caché.
Asigne diferentes puertos y directorios temporales a cada tarea.
|
|
No permita que tres Agentes compartan un .env.local.
La descripción de la tarea del Agente principal debe incluir condiciones de salida
Una tarea de calificación debe indicar claramente:
-
Directorio que permite modificación.
-
Archivos cuya modificación está prohibida.
-
Pruebas que se deben ejecutar.
-
Presentación final.
-
Cuándo detenerse y solicitar el juicio humano.
“Hacer bien la interfaz” no es una tarea aceptable.
“Reparar la navegación con el teclado del formulario de inicio de sesión y pasar tres pruebas específicas” es.
Hook solo realiza comprobaciones rápidas y deterministas
Acciones adecuadas para Hook: verificación de formato, escaneo secreto, git diff --check.
Acciones no adecuadas para Hooks: pruebas de un extremo a otro, implementación, fusión automatizada y actualizaciones de bases de datos.
Los ganchos deben tener un tiempo de espera.
La falla del enlace debería impedir el siguiente paso y entregar el código de salida original al Administrador de agentes.
No permita que el agente adivine el éxito basándose en el texto del error.
Las tareas programadas deben evitar la superposición de ejecuciones
Al generar informes de dependencia todos los días, primero adquiera el bloqueo.
Si ya hay una instancia en ejecución, omítala en lugar de iniciar otro Agente.
El resultado de la tarea se escribe en directorios separados por fechas.
Mantenga el modelo, la versión de solicitud y el compromiso de almacén utilizados esta vez.
Las ejecuciones repetidas el mismo día también deberían generar un ID de ejecución único.
El orden de fusión está determinado por las dependencias.
Cuando un documento depende de un campo API, primero combine la API.
Cuando la interfaz se basa en el mismo campo, rebase después de la fusión de API.
|
|
No dejes que los conflictos los resuelvan dos agentes al mismo tiempo.
Designe a un propietario, el otro solo proporciona la explicación.
Agent Manager ¿En qué deberías concentrarte?
En lugar de mirar cada token, observe las señales de excepción:
-
La misma herramienta se repite continuamente.
-
La modificación excede el rango de ruta.
-
El número de pruebas disminuyó repentinamente.
-
El tiempo de ejecución excede la línea base histórica.
-
Solicitando nuevas credenciales o permisos de red.
Si aparece alguno de estos elementos, se debe suspender la tarea en lugar de continuar agregando indicaciones.
Separación de tareas del navegador y tareas de código
Antigravity puede controlar el navegador, pero las cuentas de prueba no pueden reutilizar cuentas personales.
Prepare inquilinos de prueba independientes y datos reiniciables.
El agente del navegador solo puede acceder al nombre de dominio de prueba.
El administrador de producción debe excluirse de la lista de permitidos.
Las capturas de pantalla y los videos también pueden contener información personal y el período de retención debe ser claro.
Un simulacro completo
Primero, deje que el agente frontend modifique un componente.
Formato de ejecución de gancho y comprobaciones secretas.
El agente backend también agrega una prueba unitaria libre de conflictos.
El agente maestro espera a que se completen ambas ramas y lee la diferencia.
Fusione y ejecute pruebas de integración en orden de dependencia.
El agente de documentos finalmente actualiza la documentación basándose en la interfaz real.
Hacer que un Hook devuelva deliberadamente un código de salida distinto de cero confirma que el flujo de trabajo se detendrá.
Luego, cree deliberadamente conflictos con el mismo archivo para confirmar que solo hay un solucionador.
No automatizar la pieza
No entregue la aprobación de la implementación de producción a tareas programadas.
La rotación de claves no debe realizarla el subagente normal.
Los cambios de licencia y las migraciones destructivas de bases de datos requieren una revisión manual.
Conserve las diferencias, los resultados de las pruebas y los registros de tareas antes de eliminar el árbol de trabajo.
Indicador de revisión
Registre si el consumo de tiempo total disminuye después de la paralelización.
Registre el número de conflictos e intervención manual.
Registre la tasa de aprobación de cada Agente.
Si el paralelismo ahorra 10 minutos pero agrega 30 minutos a los costos de fusión, debe reducir la cantidad de subagentes.
El objetivo correcto del multiagente es acortar la ruta crítica, no crear más ventanas que puedan ejecutarse simultáneamente.
Información del flujo de trabajo antigravedad
Utilice gráficos de dependencia para determinar el paralelismo en lugar de dividir las tareas de manera uniforme
Primero escriba las tareas en nodos: definición de interfaz, implementación de back-end, llamada de front-end, prueba de integración y documentación. Solo se inician al mismo tiempo los nodos sin dependencias previas.
|
|
Si la interfaz aún está cambiando, iniciar el agente de documentos antes solo generará reelaboración. El agente maestro debe guardar el SHA de confirmación después de que se complete cada nodo y luego entregar esta versión final al proceso descendente.
Dependencia y aislamiento de puertos en Worktree
Los proyectos de nodo no deben permitir que varios árboles de trabajo compartan node_modules grabable. La caché del paquete se puede compartir, pero el directorio de instalación no se puede compartir. La base de datos crea un esquema o contenedor independiente para cada Agente.
|
|
El otro agente utiliza un puerto, un nombre de base de datos y un directorio temporal diferentes. De esta forma, cuando la prueba falla, el registro puede corresponder a la única tarea.
Generar notas de entrega legibles por máquina antes de fusionar
Cuando se completa cada subagente, devuelve ramas, confirmaciones iniciales, confirmaciones finales, archivos modificados, comandos de prueba y problemas no resueltos.
|
|
El agente maestro verifica estos campos desde Git y los registros de prueba. El lenguaje natural afirma que “pasar todo” no puede cubrir códigos de salida distintos de cero.
Crear un conflicto real
Deje que dos árboles de trabajo modifiquen la misma definición de tipo respectivamente, uno para agregar campos y el otro para cambiar el nombre de los campos. Después de fusionar la primera rama, realice una rebase en la segunda rama.
|
|
El solucionador de conflictos debe volver a ejecutar las pruebas para ambas ramas en lugar de simplemente ejecutar sus propias pruebas. Una vez aprobada la verificación de tipo, deje que el agente de revisión de solo lectura compare el resultado combinado con las descripciones de las dos tareas.
Desactivar cambio de tareas programadas
Cada tarea programada debe tener una entrada de desactivación que no requiera modificación del código. Cuando un desencadenante se sale de control, primero se desactiva la programación y luego se procesa la instancia iniciada.
Registre el tiempo de ejecución siguiente, el tiempo del último éxito, el número de fallas consecutivas y el titular de bloqueo actual. Deje de programar y notifique a los humanos cuando las fallas consecutivas alcancen un umbral. No dejes que el Agente repare los errores que genera indefinidamente.
Contrato de salida de ganchos
El valor de retorno del Hook permite que tanto el humano como el Agente juzguen el resultado. Se recomienda generar el nombre de la verificación, la confirmación de destino, el código de salida, la cantidad de hallazgos y la ruta del informe.
|
|
No imprima el texto clave sospechoso en la salida estándar. El informe se localiza utilizando la huella digital, la ruta del archivo y el número de línea. Ver el texto original requiere permisos superiores.
Limpieza de datos de prueba del agente del navegador
Las cuentas, los pedidos y los archivos cargados creados automáticamente tienen ID de ejecución. La tarea de limpieza solo elimina datos con ese ID que se encuentran en el inquilino de prueba y no puede usar condiciones amplias como “eliminar todos los objetos creados hoy”.
Una limpieza fallida no debería provocar que la prueba principal sea exitosa. Los resultados de las pruebas comerciales y los resultados de la limpieza se registran en el informe respectivamente, lo que facilita que el personal de turno descubra que el entorno de prueba está acumulando datos.
Determinar si se debe reducir el número de paralelismo
Tres rondas consecutivas de estadísticas sobre tiempo de espera, tasa de conflicto, repetición fallida y tiempo de revisión manual. Si el agente espera mucho en la misma interfaz o en un entorno de prueba compartido, suele ser más rápido reducir el número de paralelismo de tres a dos.
No vale la pena configurar procesos adicionales de ramificación, portabilidad y fusión para la paralelización cuando la tarea se puede completar secuencialmente en diez minutos con un único árbol de trabajo.