> This is a page from the ElevenLabs documentation. For a complete page index, fetch https://elevenlabs.io/docs/llms.txt. For the full documentation in a single file, fetch https://elevenlabs.io/docs/llms-full.txt. # 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](/docs/es/eleven-agents/operate/merge-proposals) 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 existente de [versionado](/docs/es/eleven-agents/operate/versioning): | Parte | Qué es | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Rama | Una rama que Architect ha creado para el cambio, de modo que `main` y las llamadas en producción no se vean afectados mientras trabajas. | | Borrador | Las modificaciones de Architect, preparadas en tu borrador no publicado de esa rama. | | Versión | Al publicar el borrador, se convierte en una nueva versión de la rama. | | Pruebas | Las pruebas que Architect ha escrito para el cambio, asociadas al agente y ejecutadas en la rama. | | Propuesta de fusión | Una solicitud para fusionar la rama con `main` (u otra rama que elijas), con una descripción del cambio, las pruebas ejecutadas y lo que deben revisar los revisores. | La propuesta de fusión es una propuesta de fusión estándar de ElevenAgents, del mismo tipo que abre manualmente un compañero. No es un tipo de objeto independiente. Una propuesta de fusión abarca exactamente una rama de origen y una 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. Cada rama tendrá entonces su propia propuesta, y podrás dividir el tráfico entre ellas como [experimento](/docs/es/eleven-agents/operate/experiments). > **Note** > > Architect actúa en tu nombre, por lo que una propuesta de fusión que abra se registra con tu nombre como autor. No hay ningún > campo que indique que Architect la creó. Menciónalo en la descripción de la propuesta si tu equipo necesita > saberlo. ## Cómo se crea una propuesta Architect crea una propuesta cuando le pides que corrija o mejore algo, o cuando le entregas una prueba que falla, un hallazgo de Spotlight o un ticket de triaje. La secuencia completa, con las herramientas que Architect usa en cada paso, está en el [ejemplo detallado](/docs/es/eleven-agents/operate/architect/how-it-works#worked-example-improving-refund-resolutions). 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 cuadro de diálogo de publicación. Revisas el diff y seleccionas **Publicar**, lo que confirma el cambio como una nueva versión de 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 ofrece 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 por tu cuenta 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 tanto en la rama original como en el borrador que contiene el cambio. Architect no ejecuta automáticamente esta comprobación de antes y después en todos los cambios. Pídesela 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](/docs/es/eleven-agents/customization/agent-testing) para saber cómo se define cada tipo de prueba. ## Dónde encontrar las propuestas Abre el agente y ve a **Control de versiones** > **Propuestas**. Puedes filtrar la lista por estado, autor (**Creado por**) y revisor (**Pendiente de revisión por**, **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. ![Lista de propuestas en la página Ramas](/docs/_fern-img/bfdb23ad1edb31c89c2ff2a137fa3028bf3f9fbcf31e236de142e207b5d54cd0.webp) ## 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: #### Resumen La descripción, una cronología de actividad de los commits de la rama de origen, revisiones y comentarios, además de un cuadro de comentarios. La barra lateral muestra revisores, revisores recomendados y cualquier ticket de triaje vinculado. Una descripción escrita por Architect siempre tiene tres secciones: **Resumen** (cada cambio relevante y el motivo), **Pruebas** (qué pruebas se ejecutaron y sus resultados, o una indicación de que no se ejecutó ninguna) y **Cómo revisar** (en qué centrarse y una prueba que ejecutar o conversación que probar). ![Pestaña Resumen de una propuesta de fusión](/docs/_fern-img/569eccd1750f90cd5ec8121411e8effd3a38e924e0f03f06f6216a9fcc160e08.webp) #### Cambios El diff de configuración: cómo quedará la rama de destino después de la fusión, en comparación con su estado actual. Si ambas ramas han modificado el mismo campo, una vista de **Conflictos** muestra cada conflicto y qué lado prevalece. Tras fusionar la propuesta, esta pestaña muestra la rama de destino antes y después de la fusión. ![Pestaña Cambios de una propuesta de fusión](/docs/_fern-img/cd06c0f93240d7c973101b896599542290437a6dcbfa6d288a25db0c1bfcd566.webp) #### Ejecuciones de pruebas La tasa de éxito y el historial de ejecuciones de pruebas de la rama de origen, incluidas las ejecuciones que Architect inició en la conversación. Cambia a la rama de destino para comparar su tasa de éxito. Selecciona **Ejecutar pruebas** para volver a ejecutar todas las pruebas asociadas en cualquiera de las dos ramas, opcionalmente varias veces cada una. Las ejecuciones de pruebas están vinculadas a la rama, no a la propuesta. La fusión no requiere que las pruebas se superen. Los revisores deciden según lo que muestra la pestaña. ![Pestaña Ejecuciones de pruebas de una propuesta de fusión](/docs/_fern-img/58e28b31cb3408fe5bf8e9193f4a4edb5e716e6023c56f29d5a4f924c70a0f7a.webp) #### Conversaciones Todas las conversaciones que se ejecutaron en la rama de origen, incluido el tráfico en producción enviado allí mediante una división de tráfico. Selecciona una conversación para abrir su transcripción. Mientras una rama está en un lanzamiento gradual, aquí puedes ver cómo los llamantes reales usan el cambio. ![Pestaña Conversaciones de una propuesta de fusión](/docs/_fern-img/f6345ff5beaee9a22732c7322995a7e889245cda7901682ab390790ef3849690.webp) ## Revisar y fusionar ### Estados Una propuesta de fusión tiene uno de estos estados: | Estado | Significado | | --------- | ------------------------------------------------------------------------------------------------------------------------------------ | | Abierta | Pendiente de revisión o fusión. | | Fusionada | La rama se ha fusionado con la de destino. | | Cerrada | Retirada por su autor, rechazada por otra persona o cerrada porque su rama se archivó. Las propuestas cerradas no se pueden reabrir. | 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 revisión". 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. ![Cronología de actividad de una propuesta de fusión](/docs/_fern-img/522012341d0089ff418032a34bae6653d2b883934b64a0b6a12de887646b2f5f.webp) ### Quién puede aprobar y fusionar * Cualquier persona con acceso de editor al agente puede revisar una propuesta, salvo 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 se puede fusionar cuando tiene al menos una aprobación de alguien distinto del autor y la última revisión de ningún revisor es **Cambios solicitados**. Los administradores del espacio de trabajo pueden fusionar sin una aprobación. * Fusionar con una [rama protegida](/docs/es/eleven-agents/operate/versioning) requiere permisos de administrador o la aprobación de un administrador. Architect no puede aprobar, comentar, fusionar ni cerrar una propuesta de fusión. Esos pasos siempre los realizan personas. Consulta [Propuestas de fusión](/docs/es/eleven-agents/operate/merge-proposals) para conocer todas las reglas de revisión. > **Warning** > > Architect puede fusionar una rama directamente, sin propuesta, cuando se lo pides y tu rol permite > la fusión. En el modo **Aprobación obligatoria**, primero te lo pregunta. En el modo **Aprobación automática**, no lo hace. Usa > protección de ramas en `main` si todos los cambios deben pasar por una propuesta revisada. ### 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 una división de tráfico configurada, eso significa todas las llamadas. La fusión también: * Transfiere a la rama de destino toda 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. ## Lanzamiento gradual Antes de fusionar una propuesta, puedes enviar una parte del tráfico en producción a su rama para que los llamantes reales prueben el cambio. #### Inicia la división Pide a Architect, por ejemplo: "Envía el 5 % del tráfico a esta rama". Architect te indica la división resultante completa, incluida la parte de `main`, y te pide aprobación antes de aplicarla. También puedes configurarla tú: en **Control de versiones** > **Ramas**, selecciona **Desplegar** en la rama. #### Observa los resultados Abre la pestaña **Conversaciones** de la propuesta para leer las conversaciones de la rama, o pide a Architect que compare los resultados de la rama con los de `main`. #### Promociona o revierte Para promocionar, fusiona la propuesta. La parte de tráfico de la rama se transfiere con ella a `main`. Para revertir, pide a Architect que establezca la parte de la rama en el 0 %, o edita tú mismo el despliegue. El tráfico en producción vuelve a `main` inmediatamente. Las partes de tráfico siempre deben sumar un 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](/docs/es/eleven-agents/operate/versioning#traffic-deployment). ## Propuestas proactivas > **Note** > > Architect genera propuestas cuando se lo pides o cuando le entregas una prueba que falla, un hallazgo de Spotlight, > una alerta o un ticket de triaje. Aún no analiza tus agentes según una programación ni abre > propuestas por sí solo. Actualmente, el flujo proactivo es [Spotlight](/docs/es/eleven-agents/dashboard/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: #### Abre Spotlight Abre el agente. Su página de resumen es Spotlight. #### Elige un hallazgo Abre el resumen semanal y revisa los **Siguientes pasos sugeridos**, o abre una alerta en tiempo real. #### Pásalo a ElevenAgents Architect Selecciona **Abrir en Architect** en una sugerencia, **Analizar con Architect** en el resumen o **Investigar con Architect** en una alerta. Architect recibe el hallazgo y recibe instrucciones para verificarlo con conversaciones reales e identificar qué rama está afectada antes de sugerir un cambio. #### Pide una propuesta Revisa los hallazgos de Architect. Si estás de acuerdo con la causa raíz, pídele que corrija el problema en una rama, pruebe la corrección y abra una propuesta. Los tickets de triaje funcionan igual. Tu agente en producción puede [marcar problemas para revisión](/docs/es/eleven-agents/customization/tools/system-tools/flag-issue-for-review) durante las conversaciones, y **Hablar con Architect** en un ticket inicia una investigación sobre él. Las automatizaciones programadas, con informes entregados 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.