Propuestas y validación

Resumen

Cuando ElevenAgents Architect termina un cambio, te lo entrega como una propuesta: una rama que contiene el cambio, pruebas que demuestran que funciona y una propuesta de fusión para fusionar esa rama en main. Esta página explica cómo funciona cada parte, dónde encontrarla y cómo una propuesta pasa de una conversación al tráfico en producción.

Qué es una propuesta

Una propuesta se basa en el modelo de versionado existente:

La propuesta de fusión es una propuesta de fusión estándar de ElevenAgents, del mismo tipo que abriría manualmente un miembro del equipo. No es un tipo de objeto independiente.

Una propuesta de fusión abarca exactamente una rama de origen y una rama de destino, por lo que cada propuesta contiene una solución candidata. Para comparar alternativas, pide a Architect que coloque cada una en su propia rama. Así, cada rama tendrá su propia propuesta y podrás repartir el tráfico entre ellas como experimento.

Cómo se crea una propuesta

Architect crea una propuesta cuando le pides que corrija o mejore algo, o cuando le proporcionas una prueba que falla, un hallazgo de Spotlight o una incidencia. La secuencia completa, con las herramientas que usa Architect en cada paso, está en el ejemplo práctico. En resumen:

1. Architect investiga, crea una rama y prepara el cambio en tu borrador de esa rama.
2. Architect escribe pruebas y simulaciones para el cambio y las ejecuta en la conversación antes de mostrarte el resultado.
3. Architect abre el diálogo de publicación. Revisas el diff y seleccionas Publicar, lo que confirma el cambio como una nueva versión en la rama.
4. Architect abre una propuesta de fusión hacia main y redacta su descripción a partir de los commits y las ejecuciones de pruebas reales de la rama.
5. Architect te ofrece enviar una pequeña parte del tráfico en producción a la rama mientras se revisa la propuesta. Necesita tu aprobación.

Puedes detenerte en cualquier paso. Una rama con una versión publicada pero sin propuesta de fusión sigue siendo útil: puedes probarla tú mismo o abrir una propuesta más adelante.

Validación dentro de la conversación

Architect escribe y ejecuta pruebas como parte de la creación del cambio, no como un paso independiente que inicias después. Para una corrección, un patrón útil consiste en demostrar que las nuevas pruebas fallan sin el cambio y se superan con él. Architect puede ejecutar las mismas pruebas en la rama original y en el borrador que contiene el cambio.

Architect no realiza automáticamente esta comprobación de antes y después para todos los cambios. Pídela cuando sea importante; por ejemplo: “Muéstrame la nueva simulación fallando en main y superándose en la rama, y después abre una propuesta”.

Una prueba se supera cuando se cumplen todas las condiciones de éxito. En una prueba de LLM, la respuesta del agente cumple los criterios de éxito. En una prueba de llamada a herramienta, se llama a la herramienta esperada con los parámetros esperados. En una simulación, la conversación simulada cumple sus condiciones de éxito. Para comprobar si hay resultados inestables, pide a Architect que ejecute las pruebas varias veces. Puede repetir cada prueba hasta 50 veces e informar de la tasa de éxito.

Consulta Pruebas para saber cómo se define cada tipo de prueba.

Dónde encontrar propuestas

Abre el agente y ve a Control de versiones > Propuestas. Puedes filtrar la lista por estado, autor (Creado por) y revisor (A la espera de revisión de, Revisado por). Una propuesta que Architect haya abierto en tu conversación aparecerá con tu nombre como autor.

Architect también devuelve un enlace a la propuesta en la conversación en cuanto la crea.

Anatomía de una propuesta

La página de una propuesta muestra las ramas de origen y destino, su estado, si se puede fusionar y cuánto se encuentra la rama de origen por detrás o por delante de la de destino. Incluye estas pestañas:

Revisar y fusionar

Estados

Una propuesta de fusión tiene uno de estos estados:

Mientras una propuesta está abierta, la última revisión de cada revisor será Aprobada o Cambios solicitados. No hay estados separados de «probado» o «lista para revisar». Los resultados de las pruebas se muestran en la pestaña Ejecuciones de pruebas.

Las revisiones y los comentarios aparecen en la cronología de actividad de la pestaña Resumen, junto a cada nueva versión confirmada en la rama de origen.

Quién puede aprobar y fusionar

• Cualquier persona con acceso de editor al agente puede revisar una propuesta, excepto su autor. Como Architect actúa en tu nombre, no puedes aprobar una propuesta que Architect haya abierto en tu conversación. Debe hacerlo un miembro de tu equipo.
• Una propuesta se puede fusionar cuando cuenta con al menos una aprobación de alguien que no sea el autor y la última revisión de ningún revisor es Cambios solicitados. Los administradores del espacio de trabajo pueden fusionar sin aprobación.
• Fusionar en una rama protegida requiere permisos de administrador o la aprobación de un administrador.

Architect no puede aprobar, comentar, fusionar ni cerrar una propuesta de fusión. Estos pasos siempre los realizan personas. Consulta Propuestas de fusión para conocer todas las reglas de revisión.

Qué ocurre al fusionar

No hay un paso de publicación independiente después de una fusión. Al fusionar se crea una nueva versión en la rama de destino, y esa versión sirve tráfico en producción de inmediato según la parte de tráfico que reciba el destino. Cuando el destino es main y no hay ninguna división de tráfico configurada, eso significa todas las personas que llaman.

La fusión también:

• Mueve a la rama de destino cualquier parte de tráfico en producción que tuviera la rama de origen.
• Archiva la rama de origen de forma predeterminada.
• Cierra cualquier otra propuesta abierta de la misma rama.
• Resuelve la incidencia vinculada, si la hay.

Despliegue gradual

Antes de fusionar una propuesta, puedes enviar una parte del tráfico en producción a su rama para que las personas que llaman usen el cambio.

Las partes de tráfico siempre deben sumar el 100 %, y el enrutamiento es determinista por conversación. Cambiar la parte de una rama protegida, incluido retirar tráfico de un main protegido, requiere un administrador. Consulta Despliegue de tráfico.

Propuestas proactivas

Actualmente, el flujo proactivo es Spotlight seguido de una derivación. Spotlight supervisa continuamente las conversaciones de tu agente. Genera un resumen semanal con investigaciones sugeridas, emite alertas en tiempo real y recomienda cambios de configuración. Para convertir un hallazgo de Spotlight en una propuesta:

Las incidencias funcionan de la misma forma. Tu agente en producción puede marcar incidencias para revisión durante las conversaciones, y Comentar con Architect en una incidencia inicia su investigación.

Las automatizaciones programadas, con informes enviados a una bandeja de entrada de Architect, están en desarrollo. La pestaña Bandeja de entrada de la página de Architect es un marcador de posición para ellas.