Propuestas y validación

Resumen

Cuando 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 que solicita fusionar esa rama con 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 control de versiones existente:

La propuesta de fusión es una propuesta de fusión estándar de ElevenAgents, del mismo tipo que un compañero abre manualmente. 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 ponga cada una en su propia rama. Cada rama tendrá entonces su propia propuesta y podrás dividir el tráfico entre ellas como un 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 fallida, un hallazgo de Spotlight o un ticket de triaje. La secuencia completa, con las herramientas que Architect utiliza 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 con main y redacta su descripción a partir de los commits y las ejecuciones de pruebas reales de la rama.
5. Architect te propone enviar una pequeña parte del tráfico en producción a la rama mientras se revisa la propuesta. Esto requiere 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ú 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 es 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 ejecuta automáticamente esta comprobación de antes y después en cada cambio. Pídela cuando sea importante; por ejemplo: “Muéstrame que la nueva simulación falla en main y se supera 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 herramientas, 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 (Creada por) y revisor (Pendiente de revisión por, Revisada 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 puede fusionarse y cuánto va la rama de origen por detrás o por delante de la de destino. Tiene 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 es Aprobada o Cambios solicitados. No hay estados independientes de “probado” o “listo 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 compañero.
• Una propuesta puede fusionarse cuando tiene al menos una aprobación de alguien que no sea su 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 con 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 atiende inmediatamente el tráfico en producción correspondiente a la parte de tráfico que recibe el destino. Cuando el destino es main y no hay ninguna división de tráfico configurada, esto significa todas las llamadas.

Fusionar 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 el ticket de triaje vinculado, si existe.

Despliegue gradual

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

Las partes de tráfico siempre deben sumar el 100 %, y el enrutamiento es determinista para cada 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 proceso proactivo es Spotlight seguido de una transferencia. 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:

Los tickets de triaje funcionan igual. Tu agente en producción puede marcar problemas para su revisión durante las conversaciones, y Hablar con Architect en un ticket inicia una 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.