Mejores herramientas de evaluación de AI agents: Phoenix, LangSmith y DeepEval

Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Ninguna herramienta de evaluación de agents puede sustituir un buen diseño de tests. Empieza por los fallos que el producto debe detectar: una respuesta final incorrecta, una mala elección de herramienta, argumentos no válidos, un efecto secundario inseguro, una trayectoria ineficiente o una regresión en latencia y coste. Después, elige la herramienta que encaje con el entorno donde deban ejecutarse esos tests.

Usa Phoenix cuando sean importantes el tracing abierto y el self-hosting. Usa LangSmith cuando datasets, traces, anotaciones y experimentos deban compartir un único workflow gestionado. Usa DeepEval cuando la evaluación deba integrarse como tests en un pipeline de CI de Python. Añade Promptfoo para disponer de una CLI local, matrix tests y casos de red team.

Última revisión: 2026-08-10. La comparación prioriza la profundidad de los traces, la evaluación de trayectorias y respuestas finales, el workflow de datasets, la ergonomía en CI, el self-hosting y la portabilidad entre proveedores.

Tabla de decisión

NecesidadMejor punto de partidaMotivo
Traces de OpenTelemetry y self-hostingPhoenixEl tracing open source, las evaluaciones, los datasets y los experimentos usan las convenciones de OpenTelemetry y OpenInference.
Traces, datasets y revisión gestionadosLangSmithEvalúa trayectorias y respuestas finales, y puede trabajar con agents ajenos a LangChain.
Tests de Python y CI gatesDeepEvalLa evaluación de agents, tanto end-to-end como a nivel de componente, encaja en un workflow orientado a tests.
Matrix tests locales y red teamingPromptfooLa CLI y la librería open source ejecutan evaluaciones repetibles y casos de seguridad en CI.
Comprobaciones de políticas o herramientas específicas del productoEvaluadores personalizadosLos jueces genéricos no conocen tus permisos, acciones irreversibles, presupuestos ni invariantes de negocio.

Evalúa la trayectoria y el resultado

Una respuesta final correcta puede ocultar un recorrido defectuoso. Un agent puede llamar a la herramienta equivocada, reintentar sin necesidad, exponer argumentos sensibles o llegar a una respuesta plausible sin pruebas. Del mismo modo, una secuencia de herramientas distinta pero válida no debería fallar simplemente porque difiere de un trace de referencia.

Mantén comprobaciones separadas para:

  • corrección de la respuesta final y respaldo mediante evidencias
  • selección de herramientas y validez de los argumentos
  • acciones obligatorias, prohibidas o repetidas
  • decisiones de política y límites de aprobación
  • eficiencia de la trayectoria, latencia y coste
  • recuperación tras errores de herramientas o resultados parciales

Usa aserciones deterministas siempre que sea posible. Reserva los jueces basados en modelos para las cuestiones semánticas, calibra sus resultados con ejemplos revisados y guarda el modelo juez y el prompt con cada resultado.

Un stack inicial práctico

  1. Instrumenta el harness con campos estables para los traces y los tool calls.
  2. Convierte los fallos de producción en un pequeño dataset de regresión.
  3. Añade comprobaciones deterministas para schemas, acciones prohibidas, presupuestos y evidencias obligatorias.
  4. Añade un juez semántico calibrado para los resultados que las reglas no puedan puntuar.
  5. Ejecuta los casos rápidos con cada cambio y una suite más amplia antes de cada release.
  6. Muestrea traces de producción para detectar nuevos modos de fallo y conviértelos en tests.

Lecturas recomendadas

Referencias