Cómo entrenar a un agente LLM de infraestructura para que no mienta

Se construyó un agente LLM interno de solo lectura para responder preguntas de infraestructura como '¿por qué el servicio devuelve un 502?'. Usaba Go, sin LangChain, y llamaba a los modelos DeepSeek-V4-Flash y Qwen3.6-27B-FP8 a través de una API compatible con OpenAI. La primera versión utilizaba un bucle ReAct gratuito y producía respuestas formalmente correctas pero a menudo engañosas. Por ejemplo, cuando un error 502 era causado por un encabezado de respuesta sobredimensionado en el proxy, el agente concluía 'no hay error a nivel de aplicación', perdiendo la causa real. Se identificaron cinco clases de errores: alcance incorrecto, semántica temporal incorrecta, conclusiones negativas incorrectas, pérdida de evidencia y replanificación no controlada. La solución fue incrustar el LLM dentro de un marco de aplicación estricto. Las llamadas a herramientas se rigen por un contrato extendido x-agent que define evidencia, tipo de salida, frescura, semántica negativa y estado de solo lectura. El planificador primero construye objetivos (por ejemplo, symptom.http_502, route.edge_to_ingress) y una condición de parada: cada objetivo requerido debe estar resuelto o explícitamente no disponible. Un guardia de evidencia evita que el finalizador concluya antes de que se cumplan todos los objetivos. La selección de herramientas se realiza por etapas: filtro de políticas, prefiltro léxico, reranking mediante LLM (top 8) y luego puerta de relevancia de objetivos. Los intents riesgosos tienen rutas previas deterministas. En la evaluación final, 44 de 45 escenarios pasaron (29 de 29 obligatorios), ejecutándose dos veces cada uno. La única prueba fallida fue un informe de formato de capacidad opcional. El agente sigue siendo de solo lectura; los humanos deciden sobre los cambios en producción.