Control de versiones del agente
Experimenta de forma segura con configuraciones de agentes mediante ramas, versiones y despliegue de tráfico
El control de versiones del agente te permite experimentar con distintas configuraciones sin poner en riesgo tu configuración de producción. Crea ramas aisladas, prueba los cambios y despliega actualizaciones de forma gradual mediante la distribución porcentual del tráfico.
¿Quieres realizar pruebas A/B? Consulta Experimentos para conocer el workflow recomendado para probar cambios en agentes con tráfico real.
Resumen
El sistema de control de versiones ofrece:
- Instantáneas inmutables de la configuración de tu agente en cualquier momento
- Ramas aisladas para probar cambios antes de pasar a producción
- División del tráfico para desplegar cambios gradualmente a un porcentaje de usuarios
- Fusión para incorporar cambios de cualquier rama a cualquier otra rama
- Rebase para incorporar en una rama los últimos cambios de la rama principal
Una vez activado el control de versiones en un agente, no se puede desactivar. Tenlo en cuenta antes de activar el control de versiones en agentes existentes.
Conceptos básicos
Versiones
Una versión es una instantánea inmutable de la configuración de un agente en un momento concreto. Cada versión tiene un ID único (formato: agtvrsn_xxxx) y contiene:
conversation_config- Prompt del sistema, ajustes del LLM, configuración de voz, herramientas y base de conocimientosplatform_settings- Subconjunto versionado que incluye ajustes de evaluación, widget, recopilación de datos y seguridadworkflow- Definición completa del workflow con nodos y conexiones
Las versiones se crean automáticamente cuando guardas cambios en un agente con control de versiones. Una vez creada, una versión no se puede modificar.
Ramas
Las ramas son líneas de desarrollo con nombre, similares a las ramas de git. Te permiten trabajar en cambios de forma aislada antes de fusionarlos de nuevo con la rama principal.
- Cada agente con control de versiones tiene una rama Principal que no se puede eliminar ni archivar
- Se pueden crear ramas adicionales desde cualquier versión de cualquier rama existente, no solo desde la principal
- Las ramas se pueden fusionar en cualquier otra rama, y las ramas que no son la principal pueden hacer rebase sobre la principal para incorporar sus últimos cambios
- Cada rama tiene: ID (
agtbrch_xxxx), nombre, descripción y una lista de versiones - Los nombres de las ramas pueden contener: letras, números y
() [] {} - / .(máximo 140 caracteres)
Despliegue de tráfico
El tráfico puede dividirse porcentualmente entre varias ramas, lo que permite despliegues graduales y pruebas A/B.
- Los porcentajes siempre deben sumar exactamente 100 %
- El enrutamiento del tráfico es determinista según el ID de conversación (el mismo usuario siempre se dirige a la misma rama)
- Solo se pueden archivar las ramas no archivadas con un 0 % de tráfico
Borradores
Los cambios sin guardar se almacenan como borradores, lo que te permite trabajar en cambios sin crear inmediatamente una versión nueva.
- Los borradores son por usuario y por rama (cada miembro del equipo tiene su propio borrador)
- Los borradores se descartan automáticamente al confirmar una versión nueva
- Los borradores también se descartan al fusionar en una rama
Activar el control de versiones
El control de versiones es opcional y debe activarse explícitamente. Puedes activarlo al crear un agente nuevo o en un agente existente.
Una vez activado, el control de versiones no se puede desactivar. Es un cambio permanente en tu agente.
Activar al crear un agente
Activar desde el panel
Activar mediante la API
Abre tu agente en el panel, ve a Configuración y activa el control de versiones. Una vez activado, la pestaña Control de versiones estará disponible para gestionar ramas, borradores, versiones y el despliegue de tráfico.
Activar en un agente existente
Activar desde el panel
Activar mediante la API
Abre tu agente en el panel, ve a Configuración y activa el control de versiones.
Al activar el control de versiones, se crea la rama inicial «Principal» con la primera versión, que contiene la configuración actual del agente.
Trabajar con ramas
Crear una rama
Las ramas se pueden crear desde cualquier versión de cualquier rama, no solo desde la principal. Opcionalmente, puedes incluir cambios de configuración que se aplicarán a la versión inicial de la nueva rama.
Enumerar ramas
Obtener detalles de una rama
Confirmar cambios
Cuando actualices un agente con el control de versiones activado, especifica branch_id para crear una versión nueva en esa rama.
Actualizar desde el panel de control
Actualizar mediante la CLI
Actualizar mediante la API
Abre la pestaña Control de versiones de tu agente, cambia a la rama de destino, edita la configuración y guarda los cambios para crear una versión nueva.
Se crea automáticamente una versión nueva en la rama especificada y se descarta cualquier borrador existente de ese usuario en esa rama.
Distribuir tráfico
Usa la ruta de API de implementaciones para distribuir el tráfico entre ramas. Esto permite lanzamientos graduales y pruebas A/B.
El enrutamiento del tráfico es determinista según el ID de conversación, lo que garantiza que el mismo usuario llegue siempre a la misma rama en todas las sesiones.
Fusionar ramas
Cuando estés satisfecho con los cambios de una rama, fusiónalos en otra rama. Puedes fusionar cualquier rama no archivada en cualquier otra rama no archivada, no solo en la principal.
Para que revisen los cambios de una rama antes de fusionarlos, o para acceder a una rama en la que no tienes permisos de escritura, abre una propuesta de fusión en lugar de fusionar directamente.
Al fusionar:
- Se crea una versión nueva en la rama de destino con la configuración de la rama de origen.
- Opcionalmente, se archiva la rama de origen (comportamiento predeterminado).
- El tráfico se transfiere automáticamente de la rama de origen a la rama de destino.
La fusión falla con no_new_changes_to_merge si la rama de origen se creó a partir de la rama de destino
(y no tiene confirmaciones nuevas posteriores), y con branch_already_merged si ya se fusionó
en ese destino.
Resolver conflictos de fusión
Si un ajuste ha cambiado tanto en la rama de origen como en la de destino desde que se separaron, de forma predeterminada se conserva el valor de la rama actualizada más recientemente. Establece force=True para usar siempre el valor de la rama de origen, independientemente de las marcas de tiempo.
Previsualiza el resultado de una fusión, incluidos los campos que se sobrescribirían, antes de confirmarla:
Rebasar ramas sobre main
El rebase incorpora los cambios más recientes de la rama principal a otra rama, de forma similar a un rebase de git. Esto mantiene actualizada con main una rama de larga duración sin fusionar todavía los cambios propios de esa rama.
Al rebasar:
- Se crea una versión nueva en la rama que incorpora los últimos cambios de main.
- Se conservan los cambios propios de la rama: si un ajuste se editó tanto en la rama como en main, siempre se conserva el valor de la rama.
- Se produce un error
branch_already_up_to_datesi la rama ya incluye todos los cambios de main.
Solo puedes rebasar ramas que no sean main, y únicamente sobre main. Rebasar la propia rama main
devuelve un error cannot_rebase_main.
Previsualiza el resultado de un rebase antes de confirmarlo:
Archivar ramas
Archiva las ramas que ya no necesites. Así mantendrás organizada la lista de ramas.
No puedes archivar una rama a la que se haya asignado tráfico. Elimina todo el tráfico antes de archivarla.
Puedes desarchivar ramas archivadas estableciendo archived=False.
Recuperar versiones específicas
Puedes recuperar un agente en una versión específica o en la punta de una rama.
Obtener un agente en una versión específica
Obtener un agente en la punta de una rama
Incluir cambios de borrador
Referencia de ajustes
Ajustes versionados
Estos ajustes pueden variar entre versiones y ramas:
Ajustes por agente
Estos ajustes se comparten entre todas las versiones:
Los cambios en el nombre y las etiquetas de ramas que no son main no se aplican al agente hasta fusionarlos con main.
Buenas prácticas
Crea pruebas antes de crear una rama
Configura pruebas automatizadas que reflejen el comportamiento esperado antes de crear una rama nueva. Esto establece una referencia y ayuda a detectar regresiones pronto mientras iteras en tu experimento.
Usa nombres de rama descriptivos
Elige nombres de rama que comuniquen claramente el objetivo del experimento. Incluye el nombre de la función,
la hipótesis o el número de incidencia para consultarlos fácilmente (por ejemplo, feature/new-greeting-flow o
experiment/shorter-responses).
Documenta el propósito de las ramas
Usa el campo de descripción de la rama para explicar qué hipótesis estás probando, qué métricas definen el éxito y cualquier dependencia o consideración. Esto ayuda a los miembros del equipo a comprender los experimentos activos.
Usa borradores para el trabajo en curso
Guarda borradores con frecuencia mientras iteras en los cambios. Así conservas tu trabajo sin crear versiones innecesarias. Confirma los cambios solo cuando estés listo para probar o implementar.
Empieza con porcentajes de tráfico bajos
Al implementar una rama nueva, empieza con el 5-10 % del tráfico. Esto limita la exposición si surgen problemas y, a la vez, proporciona datos significativos.
Supervisa las métricas clave antes de aumentar el tráfico
Usa el panel de analítica para comparar el rendimiento de las ramas. Consulta las tasas de finalización de llamadas, la duración media de las conversaciones, las puntuaciones de evaluación del éxito y las tasas de ejecución de herramientas. Aumenta el tráfico solo cuando las métricas alcancen o superen la referencia de tu rama main.
Aumenta el tráfico gradualmente
Escala el tráfico por incrementos (10 % → 25 % → 50 % → 100 %) a medida que ganes confianza. Este enfoque minimiza el riesgo mientras valida el rendimiento en cada etapa.
Mantén las ramas activas durante poco tiempo
Fusiona los experimentos exitosos cuanto antes para evitar desviaciones en la configuración. En el caso de ramas que necesiten permanecer abiertas más tiempo, rebásalas periódicamente sobre main para que no se alejen demasiado y sean más difíciles de fusionar.