Observabilidad para agentes locales
Si no puedes reconstruir qué pensó, qué herramienta llamó y por qué falló, no tienes un agente: tienes una caja negra con permisos. La observabilidad convierte una demo en sistema mantenible.
Objetivos de aprendizaje
- Definir trazas útiles para agentes con tools y RAG.
- Separar logs técnicos, decisiones y evidencias.
- Detectar loops, latencia, errores repetidos y falta de grounding.
En cristiano: traza. Es el recorrido completo de una petición: entrada, pasos del agente, llamadas a herramientas, contexto recuperado, respuesta, coste y errores.
Terminal
trace:
request_id: "support-1042"
user_id: "u_123"
model: "local-qwen"
route: "local"
steps:
- tool: "search_qdrant"
latency_ms: 182
chunks: 5
- tool: "draft_reply"
latency_ms: 4210
guardrails:
repeated_tool_calls: 0
human_approval_required: true
outcome: "draft_created" Idea clave. Para agentes locales, coste no es solo euros: también es tiempo, GPU ocupada, RAM, bloqueo de cola y fatiga de revisión humana.
Qué registrar siempre
- Modelo, runtime y ruta elegida.
- Tools llamadas, argumentos y resultado resumido.
- Chunks RAG usados y fuente.
- Errores repetidos y cambios de estrategia.
- Si hubo aprobación humana o corte automático.
Cuidado. No guardes datos sensibles completos en trazas por defecto. Registra identificadores, hashes o extractos mínimos cuando sea suficiente.
Comprueba que funciona. Toma una respuesta mala y reconstruye la causa solo con logs. Si no puedes saber si falló recuperación, modelo, tool o permisos, falta observabilidad.
Guardar y reabrir el proyecto.
Observabilidad no es decoración. Es la diferencia entre mejorar un agente y discutir con una anécdota.