Como Testar Seus Agentes em Tarefas Reais com o Harbor - Xander Song, Arize AI

하이라이트

• O Harbor isola a execução de agentes em contêineres Docker independentes para avaliar resultados por meio de scripts verificadores que geram pontuações binárias.

• A execução de oráculos antes dos agentes valida o ambiente, os dados e os verificadores sem consumir tokens de LLM.

• A integração com provedores de sandbox como Daytona permite paralelizar até 200 trabalhadores concorrentes para calcular métricas como pass@k.

• O formato ATIF baseado em JSON rastreia chamadas de ferramentas e passos internos do agente para fins de depuração e conversão em OpenInference.

• Um ajuste no prompt do servidor MCP para priorizar consultas SQL em agregações reduziu chamadas a endpoints GraphQL e diminuiu turnos operacionais.

타임라인

1. 00:00 - 03:35

   Conceito fundamental e funcionamento do Harbor

   Desenvolvedores enfrentam dificuldades ao iterar sobre agentes sem métricas objetivas. O Harbor resolve esse gargalo ao padronizar tarefas com arquivos markdown de instruções e dados em sandbox. Ao isolar a verificação dos efeitos pretendidos, a equipe identifica melhorias ou regressões imediatamente após qualquer alteração de código ou prompt.

   • O Harbor fornece tarefas em linguagem natural para agentes dentro de sandboxes com dados reais.
   • Scripts verificadores avaliam apenas os efeitos colaterais deixados no ambiente e produzem recompensas binárias de sucesso ou falha.
   • Manter tarefas e verificadores fixos viabiliza testar alterações na implementação do agente com base em evidências numéricas.
2. 03:35 - 14:20

   Arquitetura técnica, verificadores e uso de oráculos

   O framework opera de maneira agnóstica em relação a linguagens e tipos de dados utilizados. Em cenários de correção de código ou migração de banco de dados, o verificador checa tabelas e índices criados sem inspecionar a implementação interna do agente. Esse desacoplamento permite refatorações seguras no estilo de testes de integração convencionais.

   • Cada tarefa define um Dockerfile com dados em formatos como SQLite ou repositórios Git.
   • Os verificadores rodam apenas após o término do agente para impedir trapaças durante a execução.
   • Soluções determinísticas chamadas oráculos testam o pipeline sem custos de inferência de modelos de linguagem.
3. 14:20 - 20:37

   Escalabilidade horizontal e conexão com Phoenix e OpenInference

   Modelos de linguagem apresentam comportamento estocástico, exigindo múltiplas tentativas idênticas para a mesma tarefa. O Phoenix ingere os rastreamentos OTLP para versionar conjuntos de dados, registrar execuções e exibir gráficos de recompensas ao longo do tempo. Isso substitui logs brutos por interfaces dedicadas à análise de chamadas de LLMs e ferramentas.

   • A independência dos contêineres viabiliza execuções paralelas distribuídas em provedores como Daytona com 200 workers.
   • As trajetórias ATIF são convertidas no padrão semântico OpenInference suportado pelo projeto Phoenix.
   • A interface visual calcula métricas agregadas como pass@k em múltiplos testes estocásticos.
4. 20:37 - 33:23

   Implementação prática e infraestrutura de nós únicos

   Projetos centralizados em nó único facilitam o empacotamento completo de serviços e dados reais em contêineres Docker. Sistemas distribuídos maiores demandam isolamento modularizado por meio de APIs estáveis para evitar a complexidade de mocks manuais. A conformidade com o Harbor exige apenas posicionar scripts de inicialização, verificação e oráculos nos diretórios esperados.

   • O Phoenix consolida backend, banco de dados SQLite e interfaces em um único contêiner Docker para simplificar os testes.
   • O Harbor atua como orquestrador a partir da máquina host ou CI, acionando scripts definidos na imagem.
   • Três interfaces de agentes são suportadas: CLI, servidor MCP e o agente interno Pixie.
5. 33:23 - 44:15

   Otimização de consultas agregadas via SQL e MCP

   Consultas volumosas como apuração de custos por modelo causavam desperdício de chamadas de ferramentas e latência. A solução envolveu criar uma ferramenta SQL dedicada e ajustar o prompt do sistema para guiar o agente em contagens e agrupamentos. A validação no Harbor confirmou a redução drástica de passos sem comprometer a exatidão das respostas.

   • Agentes consumiam chamadas excessivas paginando dados via REST e GraphQL para perguntas analíticas.
   • A adição de uma ferramenta de SQL somente leitura e um ajuste de prompt instruíram o agente a priorizar SQL em agregações.
   • Perguntas sintéticas geradas por modelos com respostas oráculos serviram como dataset de validação.
6. 44:15 - 55:54

   Análise comparativa de tarefas e testes de habilidades

   Painéis comparativos no Phoenix mostram a substituição de comandos bash e chamadas GraphQL por consultas diretas ao banco de dados. Embora verificadores agnósticos sejam ideais para testes de regressão funcionais, inspecionar trajetórias resolve gargalos de acionamento de ferramentas. O maior desafio prático reside na curadoria e limpeza contínua de bases de dados realistas.

   • A comparação direta entre execuções isola o impacto de mudanças de prompt no volume de chamadas e turnos.
   • Verificadores podem inspecionar trajetórias internas quando o objetivo é otimização de métricas ou disparo de habilidades.
   • A unidade avaliada compreende o sistema híbrido completo, incluindo modelo, servidor MCP, CLI e prompts.