Qwen elige un paso cada vez y el runtime lo verifica: así funciona un agente de IA supervisado

Conectar un agente a herramientas es sencillo. Lo difícil es decidir qué hacer cuando una respuesta segura del modelo no basta. Si un agente propone devolver a la normalidad un servicio degradado, ¿quién comprueba que la infraestructura soportará el cambio de tráfico y que el servicio realmente se ha recuperado? El autor de un análisis publicado en Habr decidió ponerlo a prueba y construyó un entorno específico.

El modelo propone, el runtime decide

El entorno de pruebas se llama Governed Agent Runtime. Simula un servicio de pagos: versiones y réplicas, carga en RPS, métricas de dependencias, restricciones de capacidad y tolerancia a fallos N-1. Una Qwen local actúa como agente; el artículo especifica Qwen3.8:27b Q4_K_M. El modelo elige el siguiente paso, mientras que el código determinista controla qué operaciones están permitidas y cómo se ejecutan. Comprueba las precondiciones, solicita aprobación humana antes de cualquier cambio de estado y lleva el control de los presupuestos de consultas al modelo y llamadas a herramientas.

Un detalle clave es que el runtime distingue estados que se confunden fácilmente. «Se han solicitado 8 réplicas» no significa que haya 8 réplicas en buen estado. «Se ha transferido el tráfico» no significa que el servicio se haya recuperado. «La operación está autorizada» no significa que se haya ejecutado. «El modelo considera terminada la tarea» no significa que se haya verificado el estado final.

Cuando el problema estaba en el evaluador

En cinco escenarios de un solo paso, con tres ejecuciones cada uno, Qwen obtuvo 12 de 15, mientras que los controles del runtime superaron 15 de 15. Falló el escenario S12, la preparación de un plan de reversión: el modelo añadió umbrales como «5xx por encima del 5%» y «recuperación con 5xx por debajo del 1% durante 5 minutos». Esas cifras no figuraban en su contexto.

Tras añadir al contexto los cálculos de la plataforma —con 820 RPS, seis réplicas son insuficientes, siete no cumplen el requisito N-1 y ocho bastan—, el modelo volvió a recibir una evaluación negativa. El autor comparó tres elementos: lo que el modelo había recibido como entrada, lo que exigía el evaluador y lo que había respondido el modelo. Descubrió que parte de los requisitos del evaluador carecía de fundamento en los datos de entrada. El resultado pasó de «negativo» a «indeterminado».

De ahí surgió Evaluation Traceability Gate. Cada criterio sustancial de evaluación debe remitir a un hecho del contexto del modelo o contar con una derivación documentada, y una persona confirma la decisión. El criterio que exigía comprobar la recuperación antes de eliminar la versión antigua seguía sin tener fundamento, por lo que el gate lo bloqueó. En una nueva ejecución, Qwen sí cometió un error real: cambió el tráfico antes de confirmar que las ocho réplicas estaban listas.

Un paso cada vez

El autor cambió entonces el planteamiento. En cada llamada, el modelo propone exactamente una acción o STOP y, después de ese paso, recibe observaciones actualizadas. En la ejecución satisfactoria, Qwen siguió esta secuencia: escalar a 8 réplicas, realizar una comprobación de estado independiente, transferir 820 RPS, comprobar la recuperación y completar la reversión. Fueron cinco llamadas al modelo, nueve operaciones con herramientas y tres aprobaciones humanas. Antes de los pasos que dependían de otros, el propio modelo solicitó observaciones recientes y no confundió una operación autorizada con una ejecutada.

En el escenario negativo, la plataforma devolvió FAIL durante la comprobación de recuperación. En lugar de completar la reversión, Qwen eligió STOP, el runtime registró SAFE_FALLBACK y las instancias degradadas permanecieron en su sitio.

Lecciones prácticas

Primero: no otorgar al modelo autoridad para ejecutar. Que proponga acciones y que el código compruebe las precondiciones y el estado final. Segundo: distinguir «solicitado», «autorizado», «ejecutado» y «verificado» como estados separados en los registros y los contratos de las herramientas. Tercero: el evaluador también es un artefacto que puede estar desalineado con el contexto de entrada. Si se evalúa a un agente con criterios que no podía conocer, se está midiendo el propio proceso, no el modelo.

Las limitaciones son evidentes. El entorno es sintético y deliberadamente simplificado, hay pocas ejecuciones y parte de las conclusiones se basa en un análisis semántico manual. Pero el enfoque es aplicable a cualquier agente que interactúe con sistemas en producción: hay que comprobar tanto la respuesta del modelo como las relaciones entre la especificación, el contexto y el evaluador.