Serie Agent Gateway (parte 7 de 7) | Agent DevOps: implementaciones de CI/CD, evaluaciones y canarias

En el mundo de los microservicios, hemos perfeccionado el arte de la CI/CD. Las pruebas unitarias son deterministas: assert (2 + 2 == 4). Si las pruebas se aprueban, es seguro implementar el código.

En el mundo de IA de agencia, las «pruebas unitarias» no existen de la misma manera.

• Código: 2 + 2 es siempre 4.
• Agente: «Sé útil» puede significar «Escribe un poema» hoy y «Elimina la base de datos» mañana, según la versión del modelo o un ligero cambio en el mensaje.

No puede simplemente implementar un agente porque el código se compila. El mensaje es un Hiperparámetro de comportamiento. Un pequeño ajuste en el mensaje del sistema («Sea más conciso») puede provocar una regresión masiva en la capacidad de razonamiento («El agente dejó de comprobar si había errores porque quería ser conciso»).

Para resolver esto, TrueFoundry Agent Gateway admite Agente DevOps: una capa especializada de gestión del ciclo de vida que incorpora «Shadow Mode», «Online Evals» y «Canary Rollouts» a la pila cognitiva.

El problema: el incidente del «cambio de tono»

Veamos un ejemplo concreto de por qué la CI/CD estándar falla para los agentes.

El escenario: Tienes un Agente de atención al cliente en producción. Es educado y útil. El gerente de producto quiere que sea más eficiente. El cambio: Actualiza el indicador del sistema desde «Eres un asistente útil» a «Eres un asistente directo y conciso. No desperdicies palabras».

La implementación estándar:

1. Confirma el cambio inmediato a Git.
2. La tubería construye el contenedor.
3. kubectl apply actualiza el servicio.

La catástrofe: El agente interpreta «directo» como «grosero».

• Cliente: «Mi paquete se ha perdido, ¡estoy muy preocupada!»
• Agente (v2): «El seguimiento dice entregado. Revisa tu porche. Adiós».

La puntuación de satisfacción del cliente (CSAT) se bloquea. Has mancillado tu marca porque has tratado a un cognitivo cambia como un código cambiar.

La solución: modo sombra (lanzamiento oscuro)

El TrueFoundry Gateway admite Reflejo de tráfico (Modo sombra). En lugar de reemplazar la v1 por la v2, implementamos la v2 junto con la v1.

• Tráfico real de usuarios: Va a la v1. El usuario ve la respuesta de la versión 1.
• Tráfico en la sombra: La puerta de enlace duplica la solicitud en la versión 2 de forma invisible.

A continuación, la puerta de enlace compara las salidas de forma asíncrona. Puede realizar una «evaluación automática» (utilizando un modelo de juez) para marcar la diferencia.

• Salida v1: «Comprendo su preocupación. Déjeme comprobar el seguimiento...» (Puntuación de empatía: 9/10)
• Salida v2: «El seguimiento dice que se entregó». (Puntuación de empatía: 2/10)

El panel de control le avisa: «Se detectó una regresión de empatía v2». Revierte la implementación antes de que un solo cliente vea el mensaje grosero.

‍

La puerta de la «evaluación»: CI para la cognición

Antes de que un agente llegue al Modo Sombra, debe pasar el Canalización de evaluación. Del mismo modo que ejecutas pytest para el código, debes ejecutar deepeval o ragas para la cognición.

El Registro de TrueFoundry trata a los «conjuntos de datos de evaluación» como ciudadanos de primera clase.

• Conjunto de datos: 500 consultas históricas de clientes + «Respuestas doradas».
• Métrico: «Fidelidad», «Relevancia de las respuestas», «Precisión en el uso de las herramientas».

Cuando se envía una solicitud de extracción, el sistema de CI activa el agente y ejecuta las 500 consultas. Criterios de aprobación:

• Fidelidad > 0.9
• Latencia < 2 s
• Regresión: La puntuación no puede ser más de un 5% inferior a la de la sucursal principal.

Si el «Mensaje conciso» hace que la puntuación de «Fidelidad» baje un 10%, la compilación fallará. «Fusión bloqueada: el agente crea alucinaciones».

‍

Canary Rollouts: Progressive Trust

Cuando el agente pase por CI y Shadow Mode, estarás listo para el mundo real. Pero no hay que poner el interruptor al 100%. Tú usas Ruta de Canarias.

La puerta de enlace crea un «servicio virtual» que divide el tráfico en función de los pesos.

• Fase 1: El 1% de los usuarios obtiene la versión 2. (Empleados internos o usuarios beta).
• Supervisar: Consulta la tarifa de «Valoración positiva o negativa».
• Fase 2: 10% de los usuarios.
• Supervisar: Compruebe la «Tasa de errores de la herramienta» (¿El nuevo mensaje interrumpió la salida de JSON?).
• Fase 3: 50%... 100%.

El Gateway automatiza esto. Si la «tasa de errores» alcanza su punto máximo en la fase del 10%, el Gateway puede ayudar revertir automáticamente a la versión 1 y envía una página al ingeniero de guardia.

‍

Figura 1: Un ejemplo de implementación de Canary

Versionado rápido frente a control de versiones de código

Uno de los principales desafíos de Agent DevOps es que el mensaje y el código suelen estar en lugares diferentes.

• Código: main.py (Git).
• Rápido: system_prompt.txt (a menudo en una base de datos o una interfaz de usuario).

La verdadera fundición Registro de agentes hace cumplir Artefacto inmutable. Cuando lo implementas, incluimos: Artifact ID = Hash (Code + Prompt + Model Config + Dependencies)

No puede cambiar el indicador de la versión 1 en producción. Debe crear la versión 1.1. Este estricto control de versiones garantiza Reproducibilidad. Si ocurre un incidente, sabes exactamente qué combinación de código y mensaje lo causó.

Conclusión

Agent DevOps es la disciplina que consiste en aplicar el rigor de ingeniería al software probabilístico. Al pasar de la «implementación basada en vibraciones» (parece que es más rápida) a la «implementación basada en métricas» (el modo sombra confirmó una precisión un 5% mayor), TrueFoundry permite a las empresas innovar rápidamente según sus necesidades sin perder la confianza de los usuarios.

‍