Cómo Probar tus Agentes en Tareas Reales con Harbor - Xander Song, Arize AI

하이라이트

• Harbor evalúa agentes de IA tratándolos como cajas negras dentro de contenedores Docker aislados, midiendo exclusivamente los efectos secundarios finales mediante scripts verificadores.

• Los oráculos resuelven tareas mediante scripts deterministas para validar el entorno y los verificadores antes de incurrir en costos de tokens de LLM.

• La ejecución distribuida en plataformas de sandboxing como Daytona permite correr hasta 200 trabajadores concurrentes en paralelo para calcular métricas estocásticas como pass@k.

• El ajuste de un prompt para priorizar consultas SQL directas en lugar de GraphQL reduce las llamadas a herramientas y turnos de interacción sin degradar la precisión del agente.

• Las trayectorias de agentes registradas en el formato JSON de Harbor (ATIF) se traducen al estándar Open Inference basado en OpenTelemetry para depurar llamadas a modelos y herramientas en Phoenix.

타임라인

1. 00:00 - 07:49

   Arquitectura y componentes esenciales de Harbor

   Una tarea en Harbor combina instrucciones en Markdown, un Dockerfile con datos reales y verificadores aislados que comprueban efectos secundarios en el sistema de archivos o bases de datos. Los contenedores nuevos se instancian por cada intento para gestionar la naturaleza estocástica de los modelos de lenguaje. Las trayectorias de ejecución pueden exportarse en formato ATIF para registrar y depurar cada llamada interna.

   • Harbor define tareas en lenguaje natural mediante archivos Markdown y las ejecuta en entornos aislados con Docker.
   • Los verificadores son scripts montados tras la ejecución del agente para calificar el resultado emitiendo recompensas en reward.txt.
   • Los oráculos proporcionan soluciones deterministas para comprobar la integridad del entorno antes de ejecutar modelos de lenguaje.
2. 07:50 - 14:20

   Aislamiento de verificadores y desacoplamiento de la implementación

   En una tarea de corrección de migraciones SQL, el verificador comprueba la presencia de columnas e índices y el código de salida cero de la migración en lugar de auditar el código fuente del agente. Tratar al agente como una caja negra facilita cambiar implementaciones de herramientas y dependencias sin romper las baterías de pruebas existentes. Esta separación garantiza que las suites de evaluación permanezcan estables durante refactorizaciones profundas.

   • Los verificadores se montan en el contenedor solo tras la ejecución del agente para evitar trampas en el código.
   • Las pruebas funcionan de manera análoga a pruebas de integración al evaluar efectos secundarios sin depender de la arquitectura interna del agente.
   • El desacoplamiento de verificadores permite refactorizar prompts, servidores MCP y habilidades manteniendo los criterios de evaluación constantes.
3. 14:21 - 20:37

   Escalabilidad horizontal e integración con Phoenix y Open Inference

   Cada intento de evaluación se procesa de forma autónoma, lo que habilita la ejecución en paralelo en plataformas de entornos aislados en la nube como Daytona o Modal. Phoenix ingesta las trazas transformadas desde ATIF hacia convenciones semánticas abiertas de OpenTelemetry, lo que permite visualizar llamadas a LLM, versionar conjuntos de datos y comparar recompensas entre experimentos. Harbor también ofrece interfaces web locales y servicios alojados de forma independiente a Phoenix.

   • La independencia de cada contenedor Docker permite paralelizar ejecuciones a escala con 200 trabajadores concurrentes en Daytona.
   • Las métricas agregadas como pass@k cuantifican la confiabilidad del agente ante la variabilidad estocástica.
   • Las trayectorias ATIF se mapean a Open Inference y OpenTelemetry para versionar datos y comparar experimentos en Phoenix.
4. 20:38 - 33:22

   Evaluación del sistema híbrido de Phoenix en entornos Docker

   La arquitectura de un solo nodo de Phoenix permite empaquetar toda la aplicación con una base de datos SQLite y clientes de prueba dentro del contenedor de evaluación. Los verificadores inspeccionan directamente las tuplas de SQLite o consultan endpoints locales para confirmar los cambios generados por el agente. La orquestación se gestiona desde el host o CI mediante convenciones estrictas de ubicación de scripts para el arranque, los oráculos y las verificaciones.

   • Phoenix encapsula su servidor de nodo único, bases de datos SQLite y endpoints REST/GraphQL dentro de un contenedor Docker para evaluación.
   • El sistema admite evaluación simultánea para CLI, servidores MCP y agentes del lado del servidor como Pixie.
   • Harbor opera como un orquestador CLI en la máquina host que interactúa con el entorno mediante contratos basados en scripts.
5. 33:23 - 44:11

   Optimización de consultas agregadas y reducción de llamadas a herramientas

   Ante preguntas analíticas como el cálculo de costos por modelo, los agentes tendían a paginar colecciones completas a través de GraphQL. Tras habilitar una herramienta SQL en el servidor MCP y refinar el prompt directivo, los experimentos reflejaron una caída en las llamadas a GraphQL y un aumento del uso directo de SQL. Phoenix comparó las recompensas y el volumen de pasos para confirmar la optimización sin alterar las tasas de aprobación.

   • La paginación manual en APIs REST y GraphQL causaba un exceso de llamadas a herramientas en consultas con agregaciones.
   • La introducción de una herramienta SQL de solo lectura combinada con un ajuste en el prompt redujo el promedio de llamadas y turnos.
   • Los oráculos de consultas sintéticas validaron la corrección de los datos deterministas antes de someter a prueba a los modelos.
6. 44:12 - 55:53

   Comparación granular de experimentos y verificación de habilidades

   La interfaz de Phoenix permite contrastar ejecuciones de modelos como Opus 5 antes y después de ajustar directivas, filtrando tareas con reducciones concretas de herramientas. Aunque los verificadores ideales examinan únicamente efectos finales, inspeccionar trayectorias resulta práctico para comprobar si una habilidad particular interfiere con otra o se activa correctamente. El desafío central reside en preparar datos de prueba realistas para alimentar los contenedores y medir la interacción combinada entre el modelo base y las herramientas personalizadas.

   • La comparación visual a nivel de tarea confirma descensos en el recuento de turnos cuando el agente resuelve problemas en un solo paso con SQL.
   • Los verificadores pueden inspeccionar trayectorias internas para evaluar de forma acoplada la activación de habilidades específicas.
   • El objetivo principal en entornos reales radica en evaluar la entidad híbrida completa compuesta por el modelo, MCP, CLI y herramientas.