Evaluación del comportamiento del agente: resultados, trayectorias y retroalimentación sobre la producción
Cómo evaluar los sistemas agentes más allá de la respuesta final: asociar LangChain, LangGraph y LangSmith a roles, analizar las trayectorias de puntuación y el contexto, e incorporar los fallos en la producción a las evaluaciones.
Fuentes: Building Better Agentic AI Systems: What I Learned About Deep Agents, LangSmith Engine & Evals
Con los modelos y frameworks actuales, hacer que un agente de IA funcione en una demostración requiere toda una tarde. La parte difícil comienza cuando ese agente se integra en un producto real: elige la herramienta incorrecta, recibe poca información de contexto, toma un camino que nadie planeó o devuelve una respuesta que suena correcta pero no lo es. Este artículo analiza el ciclo de vida de ingeniería que hace que tales sistemas sean fiables, con énfasis en la evaluación: qué medir, a qué nivel y cómo convertir cada fallo en producción en una verificación que impida que se repita. Los ejemplos utilizan el ecosistema LangChain (LangChain, LangGraph, LangSmith y Deep Agents), pero las ideas son aplicables a cualquier stack.
De una sola llamada al LLM a un sistema agente
Es fácil imaginar una función básica de un LLM: se ingresa una solicitud, se realiza una llamada al modelo y se obtiene una respuesta.
User → Prompt → LLM → Response
Un agente es un ente distinto. Ante un objetivo, puede dividir el trabajo en tareas, recuperar documentos, llamar a APIs, ejecutar herramientas, mantener el estado, asignar parte del trabajo a otro agente, examinar resultados intermedios, recuperarse de errores y luego elegir su siguiente movimiento. Una visión simplificada de ese flujo de control:
USER GOAL
│
▼
AGENT
│
PLAN
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
TOOLS MEMORY SUBAGENT
│ │ │
└──────────────┼──────────────┘
│
▼
DECIDE / ACT
│
More work needed?
↙ ↘
YES NO
│ │
└── LOOP ▼
RESULT
Observe el bucle en la parte inferior: el agente sigue decidiendo si se necesita más trabajo, y cada iteración puede interactuar con herramientas, la memoria o subagentes. En ese punto ya no se está enviando una respuesta del modelo; se está ejecutando un sistema. Esto es importante para la calidad, ya que la respuesta final solo es tan buena como la cadena de decisiones que la generaron. Un modelo correcto con un paso de recuperación deficiente, o un buen plan ejecutado con la herramienta inadecuada, sigue produciendo un resultado deficiente.
Asignación de roles: LangChain, LangGraph y LangSmith
Una forma práctica de diferenciar los tres productos principales de LangChain es relacionar cada uno con la pregunta de ingeniería a la que responde.
- LangChain ofrece funcionalidades relacionadas con el modelo: integraciones de modelos, herramientas, recuperación de información y conectores a datos externos. Su pregunta es: ¿qué necesita hacer la aplicación para funcionar?
- LangGraph se encarga de la orquestación cuando los flujos de trabajo pasan a ser autónomos, gestionando el estado, ramas condicionales, bucles, llamadas a herramientas, pasos de aprobación humana y coordinación entre múltiples agentes. Su pregunta es: ¿cómo debería ejecutarse el flujo de trabajo?
- LangSmith aborda lo que ocurre después de que el sistema esté en funcionamiento: qué herramientas se utilizaron, qué contexto vio el modelo, dónde aumentó la latencia, qué paso falló, por qué se tomó una decisión y si la nueva versión es realmente mejor que la anterior. Su pregunta es: ¿qué sucedió realmente, y fue algo positivo?
Al acumularse, el flujo va desde un objetivo empresarial, pasando por las capacidades y la orquestación, hasta llegar a un resultado que luego se observa y evalúa para que el equipo pueda aprender de él.
BUSINESS GOAL
│
▼
LANGCHAIN
Models • Tools • Data
│
▼
LANGGRAPH
State • Flow • Decisions
│
▼
AGENT SYSTEM
│
▼
RESULT
│
▼
LANGSMITH
Observe • Trace • Eval
│
▼
LEARN
La última flecha es la importante. La observación no constituye un estado final; sirve para fomentar el aprendizaje. Si la distinción entre LangChain y LangGraph sigue siendo poco clara, nuestra comparación de cadenas y grafos con estado la aborda en profundidad.
Uso de agentes para mejorar otros agentes: Motor LangSmith
El rastreo te indica con precisión qué hizo un agente, pero un registro por sí solo no soluciona nada. Alguien todavía tiene que leerlo, determinar qué salió mal, verificar si el mismo problema aparece en otros lugares, encontrar la causa raíz, modificar el sistema y confirmar que ese cambio no dañó algo más. Esto es manejable para un pequeño número de ejecuciones, pero imposible con miles de registros de producción.
LangSmith Engine, una funcionalidad más reciente de LangSmith en el momento de redactar este texto, aplica un agente a dicho análisis. Escanea los registros de producción en busca de patrones y fallos recurrentes, agrupa los problemas relacionados, ayuda a diagnosticarlos y propone mejoras. Lo crucial es que los fallos que detecta pueden ser sometidos a evaluación, de modo que un problema descubierto hoy se convierte en una verificación explícita al día siguiente. Conceptualmente, el flujo es el siguiente:
PRODUCTION AGENT
│
▼
TRACES
│
▼
LANGSMITH ENGINE
│
▼
Detect Patterns
│
▼
Diagnose Issues
│
▼
Suggest Improvement
│
▼
Add Evals
│
▼
Regression Testing
│
▼
Review / Deploy
│
└────────► Observe Again
Cada etapa reduce el problema: las trazas en bruto se convierten en patrones, los patrones en diagnósticos, los diagnósticos en soluciones candidatas, y estas soluciones pasan por nuevas evaluaciones y pruebas de regresión antes de que un humano las revise e implemente. Luego el ciclo comienza de nuevo con nuevas trazas.
El cambio aquí radica en cómo se tratan las trazas. En lugar de ser algo que solo se examina durante un incidente, se convierten en la materia prima para la mejora continua. Así es exactamente como funciona ya la ingeniería de calidad en el software convencional: un error en producción no debería resolverse con un parche, sino con una prueba que impida que el mismo tipo de defecto reaparezca silenciosamente. Sin embargo, el diagnóstico automático no elimina la necesidad de revisión. Las soluciones propuestas para los prompts o las definiciones de herramientas pueden tener efectos secundarios, por lo que las etapas de revisión y regresión siguen formando parte del proceso.
Agentes avanzados para tareas a largo plazo
Algunas solicitudes implican una gran cantidad de trabajo. Considere una solicitud de ingeniería de calidad de este tipo: ante un nuevo requisito del producto, el agente debe revisar los documentos relacionados, identificar los flujos de usuario más riesgosos, redactar escenarios de prueba para ellos, analizar el código que implementa dichos flujos y documentar sus hallazgos.
Para completarlo, el agente debe planificar, leer archivos, recuperar conocimiento, utilizar herramientas, posiblemente ejecutar código, guardar hallazgos intermedios, delegar tareas especializadas y recordar lo que ya ha aprendido. La estructura de dicho trabajo es la siguiente:
Understand Goal
│
▼
Create Plan
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Read Files Use Tools Search Knowledge
│ │ │
└─────────────┼─────────────┘
│
Delegate Work
│
▼
SUBAGENTS
│
▼
Combine Findings
│
▼
RESULT
Deep Agents es la herramienta de agentes de LangChain diseñada para este tipo de tareas a largo plazo. Reúne en un solo conjunto las funciones de planificación, manejo de herramientas, gestión de archivos, administración de contexto, habilidades, memoria y subagentes, por lo que no es necesario armar cada uno de estos componentes por separado.
Lo interesante no es que el agente pueda hacer más, sino cómo está estructurada su autonomía. Entregarle a un agente veinte herramientas no lo hace mejor; con frecuencia empeora la selección de herramientas. Dividir cada tarea entre cinco subagentes tampoco mejora automáticamente la arquitectura, ya que cada transferencia consume tokens y puede hacer que se pierda el contexto. Cuanto más capaces sean los componentes básicos, mayor importancia adquieren las decisiones de diseño relacionadas con ellos. Una opción útil por defecto es añadir un subagente solo cuando una subtarea necesita un contexto aislado o un conjunto de herramientas diferente, y mantener la lista de herramientas de cada agente tan pequeña como lo permita la tarea.
Operar agentes es un problema aparte: Agentes Profundos Gestionados
Crear un agente capaz y hacer que funcione de manera fiable en producción son dos tareas de ingeniería distintas. Un agente que opera durante mucho tiempo puede necesitar sobrevivir a las interrupciones, mantener su estado, trabajar con archivos, ejecutar código de forma segura, transmitir el progreso a la interfaz de usuario, conservar la memoria y generar suficiente telemetría para que los ingenieros puedan reconstruir lo sucedido.
Managed Deep Agents, una oferta alojada en el mismo ecosistema en el momento de redactar este texto, está dirigida a esa capa operativa. La relación entre ambos puede representarse como el comportamiento en la parte superior y la infraestructura de tiempo de ejecución en la inferior:
DEEP AGENT
Planning • Tools • Files • Subagents
│
▼
Agent Behavior
│
▼
MANAGED DEEP AGENTS Durable Execution
Persistence
Sandboxes
Memory
Streaming
Identity
Tracing / Evaluation
El agente define su comportamiento a través de la planificación, herramientas, archivos y subagentes. La capa gestionada proporciona ejecución duradera, persistencia, entornos aislados, memoria, transmisión en tiempo real, identidad y seguimiento con posibilidad de evaluación. La lección general es válida tanto si se utiliza un servicio gestionado como si se ejecuta uno propio: la inteligencia del modelo es un componente de una arquitectura de IA en producción, y la infraestructura que lo rodea merece la misma atención. Nuestra comparación de runtime harnesses y frameworks compuestos analiza el equilibrio entre desarrollar algo desde cero o adoptar soluciones existentes.
Por qué los agentes rompen con las pruebas tradicionales
Las pruebas convencionales se basan en el determinismo. Se proporciona a una función una entrada conocida, se obtiene una salida y luego se verifica esta.
Input → Function → Output → Assertion
Al llamar a una API con una solicitud fija, se puede verificar el código de estado, el esquema de respuesta, la carga útil, los encabezados y las reglas comerciales. Los agentes no se ajustan a este patrón. Pídale a uno que investigue un incidente en producción y encuentre la causa raíz probable. En una ejecución, primero lee los registros y luego consulta una base de datos; en otra, revisa la documentación, llama a una API y solo después lee los registros. Los procedimientos difieren, pero ambos podrían llegar a una conclusión sólida.
También es posible lo contrario, y es más peligroso: una respuesta final que parece correcta aunque el agente se basó en una fuente poco fiable, utilizó una herramienta inadecuada o llegó a la conclusión correcta por razones equivocadas. Una afirmación de coincidencia exacta en la salida no puede distinguir estos casos. Ese es el vacío que llenan las evaluaciones.
Qué mide una evaluación
Definición práctica: una evaluación mide qué tan bien ha rendido un sistema de IA frente a los estándares importantes para una tarea específica. Los criterios provienen de la tarea, no del marco.
Tomemos un agente que genera escenarios de prueba a partir de un requisito. Saber que devolvió diez casos de prueba en JSON válido no dice casi nada. Las señales significativas se refieren a la calidad:
GENERATED TESTS
│
▼
EVALUATE
│
┌────────────────┼────────────────┐
│ │ │
Coverage Correctness Relevance
│ │ │
├──────── Hallucination ──────────┤
│ │
└──────────── Duplication ─────────┘
│
▼
QUALITY SIGNAL
En la práctica, esas dimensiones se convierten en preguntas concretas:
- ¿Los tests cubren realmente el requisito?
- ¿Cada uno de ellos es relevante para él?
- ¿El agente inventó un comportamiento que el producto no tiene?
- ¿Omitió algún escenario negativo o de caso límite importante?
- ¿Varios de los diez son en realidad duplicados?
Cada pregunta puede convertirse en un criterio de evaluación: algunas son deterministas (detección de duplicados mediante texto normalizado o embeddings), otras necesitan un conjunto de datos de referencia (verificación contra requisitos conocidos) y algunas suelen requerir un LLM como juez o etiquetas humanas (funcionalidades generadas por alucinaciones). Las verificaciones estructurales como la validez del esquema siguen siendo útiles, pero deben considerarse como un punto de referencia y no como la definición del éxito.
Tres aspectos de evaluación: respuesta, paso y trayectoria
Con los agentes no es necesario evaluar solo la salida final. Existen al menos tres objetivos útiles:
- La respuesta final: ¿es la respuesta correcta, completa y relevante?
- Un solo paso: por ejemplo, ¿el agente eligió la herramienta adecuada para este subproblema, con argumentos razonables?
A continuación se muestra una trayectoria típica para un agente de respuesta a preguntas:
User Goal
│
▼
Agent
│
├── Search Documentation
│
├── Query Database
│
├── Call API
│
└── Generate Answer
La respuesta final es simplemente el último nodo. Para muchas aplicaciones, la ruta es tan importante como el destino; por ejemplo, si el agente consultó documentación antes de consultar datos en producción, o si realizó una llamada a API para la cual no tenía motivo. La evaluación de la trayectoria se vuelve esencial una vez que los agentes pueden modificar datos, abrir tickets, ejecutar código, activar flujos de trabajo o actuar dentro de sistemas empresariales, ya que una acción intermedia dañina constituye un fallo incluso si el mensaje final parece correcto. Las verificaciones de trayectoria pueden ser estrictas (una secuencia esperada exacta), indulgentes (los pasos requeridos presentes en cualquier orden, sin pasos prohibidos) o evaluadas por un modelo; las verificaciones indulgentes suelen ser el punto de partida adecuado dada la variabilidad en los caminos descrita anteriormente.
Evaluaciones offline y online como un único bucle
La evaluación se divide naturalmente en dos modos que se corresponden con prácticas de software conocidas.
Offline: liberación de versiones en casos conocidos
La evaluación offline se realiza con conjuntos de datos y escenarios seleccionados antes de la liberación. Se ejecutan casos representativos con la versión candidata del agente, se les asigna una puntuación, se comparan con la versión actual y se decide si proceder con su lanzamiento.
Known Dataset
│
▼
Agent Version
│
▼
Run Evals
│
▼
Compare Results
│
▼
Release Decision
Esto es el equivalente en agentes de un conjunto de pruebas de regresión en CI. Dado que las salidas del modelo varían entre ejecuciones, es útil realizar cada caso más de una vez y comparar las distribuciones de puntuaciones en lugar de los resultados individuales.
Online: aprender del tráfico real
La evaluación online mide lo que ocurre en producción, y es allí donde surgen las sorpresas. Los usuarios plantean preguntas que nadie anticipó, las herramientas externas fallan, el contexto llega incompleto, los datos cambian bajo nuestros pies y los agentes siguen trayectorias que ningún conjunto de datos contiene. Evaluar una muestra de registros en tiempo real permite identificar estos casos.
Cerrar el ciclo
Los dos modos se vuelven mucho más valiosos cuando están conectados: cada fallo de producción significativo detectado en línea se agrega al conjunto de datos sin conexión, para que la próxima versión se pruebe contra él.
OFFLINE EVALS
│
▼
BUILD
│
▼
DEPLOY
│
▼
PRODUCTION TRACES
│
▼
ONLINE EVALS
│
▼
DISCOVER FAILURE
│
▼
ADD FAILURE TO DATASET
│
└────────► OFFLINE EVALS
Con el tiempo, el conjunto de herramientas sin conexión deja de reflejar lo que el equipo imaginaba que harían los usuarios y comienza a reflejar lo que realmente hacen. Sea deliberado con respecto a la privacidad al copiar datos de producción a los conjuntos de datos; elimine o sintetice los campos sensibles antes de que se conviertan en datos de prueba permanentes.
El comportamiento del agente como una nueva dimensión de calidad
Nada de esto reemplaza las pruebas tradicionales. Las pruebas de interfaz de usuario, API, integración, validación de datos, rendimiento y seguridad siguen siendo necesarias para cualquier producto fiable. Los sistemas agentes añaden otra capa: la calidad del comportamiento del agente. Esa capa plantea sus propias preguntas:
- ¿Fue la herramienta que eligió la adecuada?
Organizadas como un modelo, estas preguntas se diferencian bastante de la pirámide de pruebas clásica:
AGENT QUALITY
│
┌─────────────────┼─────────────────┐
│ │ │
OUTCOME TRAJECTORY CONTEXT
QUALITY QUALITY QUALITY
│ │ │
▼ ▼ ▼
Correctness Tool Usage Groundedness
Relevance Decisions Relevance
Completeness Efficiency Freshness
│
┌────────┴────────┐
│ │
MEMORY RECOVERY
│ │
▼ ▼
Accuracy Failure Handling
Relevance Retry Behavior
La calidad del resultado abarca la corrección, relevancia y completitud. La calidad de la trayectoria incluye el uso de herramientas, las decisiones tomadas y la eficiencia, y se divide en aspectos relacionados con la memoria (precisión y relevancia de lo que se recupera) y la recuperación (gestión de fallos y comportamiento al intentar nuevamente). La calidad del contexto comprende el fundamento, la relevancia y la actualidad de la información. Cada elemento puede asociarse a uno o más evaluadores, y juntos ofrecen una visión mucho más completa que un simple resultado de aprobado/rechazado. Desarrollar este enfoque requiere nuevas prácticas en pruebas de agentes, observabilidad, evaluación de trayectorias, conjuntos de pruebas para regresión en IA, puntuación en entornos de producción y mejora continua, áreas donde los ingenieros de calidad e ingenieros de IA cada vez más colaboran. Para conocer aspectos relacionados con la seguridad en el mismo contexto, consulte nuestra guía sobre las medidas de seguridad y middleware de LangChain.
Cambios prácticos para tus propios proyectos de agentes
La lección de todo esto es no adoptar todas las nuevas funcionalidades. Es más bien lo contrario: ser más deliberado con la arquitectura.
- Define criterios de evaluación al diseñar el agente, no después de que se lance.
- Considera la observabilidad como parte de la arquitectura inicial y no como un complemento posterior.
- Dirige los registros de producción al equipo de ingeniería como retroalimentación, no solo como evidencia de incidentes.
- Asegúrate de que cada fallo importante en producción quede cubierto por una evaluación futura.
- Ajusta la complejidad al problema. A veces un agente simple es suficiente; otras veces está justificada la orquestación con LangGraph; en ocasiones una tarea realmente se beneficia de subagentes, contexto persistente o un agente completo.
La tecnología debe seguir al problema, nunca al revés.
El ciclo de mejora
Los frameworks van y vienen; la idea duradera es un bucle.
LEARN
│
▼
BUILD
│
▼
OBSERVE
│
▼
EVALUATE
│
▼
IMPROVE
│
└──────────► LEARN AGAIN
Aprendes un concepto y construyes con él. La construcción revela lo que no comprendiste. Ejecutarlo muestra problemas que no previste. La evaluación reemplaza las suposiciones por evidencias, las evidencias impulsan la mejora, y la mejora suele revelar lo siguiente que hay que aprender.
Puntos clave
- Un agente es un sistema de decisiones; juzga las decisiones, no solo el texto final.
- Asigna a cada herramienta una tarea clara: LangChain para capacidades, LangGraph para orquestación, LangSmith para observación y evaluación.
- Evalúa en tres niveles: respuesta, paso y trayectoria, y prefiere verificaciones de trayectoria más flexibles cuando existen rutas válidas diferentes.
- Conecta las evaluaciones en línea y fuera de línea para que los fallos en producción se conviertan en casos de regresión.
Los modelos, marcos y productos alojados en esta área cambian rápidamente, por lo que consulte la documentación actual para conocer características como LangSmith Engine y Managed Deep Agents. La disciplina de observar, medir e incorporar las lecciones aprendidas al sistema es lo que mantendrá a sus agentes fiables a medida que todo a su alrededor evoluciona.