Agent-Diff: Benchmarking LLM Agents on Enterprise API Tasks via Code Execution with State-Diff-Based Evaluation

Resumo Técnico: Agent-Diff

1. O Problema

A avaliação de Agentes de Grandes Modelos de Linguagem (LLMs) que interagem com softwares do mundo real enfrenta um dilema fundamental entre fidelidade ecológica e reprodutibilidade:

• Ambientes Sintéticos/Mockados: Oferecem controle total e reprodutibilidade, mas frequentemente simplificam demais o comportamento das APIs reais, falhando em capturar complexidades de sistemas corporativos.
• Serviços ao Vivo (Live Services): Aumentam a realismo, mas introduzem instabilidade temporal (dados mudam entre execuções), dificultando a comparação justa entre modelos e a definição de um "ground truth" estático.
• Métodos de Avaliação Atuais: Muitos benchmarks avaliam apenas a sequência de chamadas de ferramentas (traces) ou usam "julgadores" baseados em LLMs, que podem ser não determinísticos e enviesados. Eles frequentemente falham em verificar se o estado final do sistema foi alterado corretamente ou se ações não intencionais (efeitos colaterais) ocorreram.

O objetivo é criar um framework que permita que agentes escrevam e executem código para interagir com APIs reais de produtividade empresarial, mantendo ao mesmo tempo o controle rigoroso necessário para uma avaliação científica.

2. Metodologia e Arquitetura

O Agent-Diff resolve esses problemas através de uma arquitetura inovadora baseada em três pilares:

A. Ambientes Sandbox com Réplicas de API (Containerização)

• O framework utiliza réplicas containerizadas de APIs empresariais reais (Slack, Box, Linear e Google Calendar).
• Equivalência Comportamental: As réplicas não precisam replicar a implementação interna (backend), mas devem ser comportamentalmente equivalentes para o conjunto de requisições do benchmark. Elas são construídas a partir de especificações públicas (OpenAPI, GraphQL) e validadas contra as APIs de produção.
• Isolamento Determinístico: Cada execução ocorre em um ambiente isolado com um banco de dados PostgreSQL dedicado (schema isolation). Isso garante que todos os modelos comecem do mesmo estado inicial ($S_0$) e que não haja contaminação cruzada entre execuções.

B. Contrato de Diferença de Estado (State-Diff Contract)

• Em vez de avaliar se o agente seguiu o caminho correto (trace matching), o sucesso é definido pela diferença de estado entre o início e o fim da tarefa.
• O sistema tira "snapshots" do banco de dados antes ($T_{before}$) e depois ($T_{after}$) da execução.
• Calcula-se a diferença ($\Delta$):
  • Adições ($\Delta_{add}$): Entidades inseridas.
  • Deleções ($\Delta_{del}$): Entidades removidas.
  • Modificações ($\Delta_{mod}$): Entidades atualizadas.
• Invariante de Mundo Fechado: Qualquer mudança no estado que não seja explicada pelas asserções declarativas da tarefa (ou campos ignorados não determinísticos, como timestamps) é considerada um efeito colateral indesejado, resultando em falha da tarefa. Isso previne que o agente "quebre" recursos não relacionados.

C. Geração de Tarefas e Taxonomia

• O benchmark consiste em 224 tarefas complexas que cobrem fluxos de trabalho de múltiplos passos.
• As tarefas são geradas proceduralmente e curadas manualmente, variando em:
  • Horizonte da Tarefa: Número mínimo de chamadas de API (média de 5.3, indo até 24).
  • Perfil de Operação: Busca, Criação, Leitura, Atualização, Deleção.
  • Escopo de Entidade: Alterações em uma única entidade vs. coordenação entre múltiplas entidades.
  • Disponibilidade de Informação: O agente deve descobrir identificadores via API (implícito) ou eles são fornecidos no prompt (explícito).
  • Ambiguidade: Graus variados de especificação do objetivo pelo usuário.

3. Principais Contribuições

1. Framework Híbrido: Une a fidelidade de APIs reais com a reprodutibilidade de ambientes sandbox, permitindo avaliação rigorosa de agentes que escrevem código (Bash/Python) para interagir com serviços SaaS.
2. Método de Avaliação Baseado em Estado: Substitui a verificação de traces ou julgadores subjetivos por uma verificação declarativa e determinística baseada na diferença de estado do banco de dados, detectando tanto o sucesso do objetivo quanto falhas por efeitos colaterais.
3. Benchmark Abrangente: Um conjunto de dados de 224 tarefas sobre 4 serviços corporativos principais, cobrindo cenários de gerenciamento de arquivos, mensagens, agendamento e projetos.
4. Análise de Robustez: Avaliação detalhada do impacto da documentação de API e análise de estratégias de recuperação de erros.

4. Resultados Experimentais

O estudo avaliou 9 modelos de LLM (incluindo DeepSeek-v3.2, Devstral, Qwen, Claude, Llama, etc.) em 224 tarefas.

• Desempenho Geral:

  • O DeepSeek-v3.2 liderou com uma pontuação geral de 88.1, seguido pelo Devstral-2512 (86.0).
  • Modelos de ponta (Top Tier) superaram significativamente modelos menores (Bottom Tier), como o Llama-4-Scout (38.0) e Claude-Haiku-4.5 (49.3).
  • Não há um serviço universalmente "mais fácil"; o Linear (gerenciamento de projetos) foi geralmente mais fácil devido a convenções CRUD previsíveis, enquanto o Google Calendar apresentou desafios significativos de raciocínio temporal.

• Impacto da Documentação (Ablation Study):

  • Fornecer documentação relevante aumentou a taxa de aprovação (pass rate) em +7.0 pontos percentuais, especialmente em tarefas com APIs novas (ex: Box Hubs API, lançada após o corte de treinamento de muitos modelos).
  • No entanto, a pontuação ponderada (que penaliza efeitos colaterais) não melhorou significativamente, sugerindo que a documentação ajuda a completar tarefas simples, mas não necessariamente a evitar erros complexos em tarefas multi-etapa.
  • Fornecer toda a documentação (todos os serviços) não trouxe benefícios e, em alguns casos (como no Linear), degradou o desempenho devido à diluição do contexto.

• Análise de Erros e Recuperação:

  • Erros Comuns: Falhas de raciocínio (53.6%) e erros de parâmetros (43.3%) foram os mais prevalentes.
  • Estratégias de Recuperação: Modelos de alto desempenho diferem dos de baixo desempenho não apenas pelo conhecimento da API, mas pela qualidade do planejamento.
    • Modelos top usam estratégias adaptativas como lookup_correct_value (buscar o valor correto) e break_into_steps (decompor tarefas).
    • Modelos de baixo desempenho tendem a usar retry_same (tentar a mesma ação falha repetidamente), o que é altamente correlacionado com falhas.
  • Hallucinação: A documentação reduziu significativamente alucinações e erros de raciocínio, mas não eliminou completamente a falha em tarefas onde o agente não tenta sub-tarefas (incomplete execution).

• Eficiência de Custo:

  • O Grok-4.1-Fast demonstrou a melhor eficiência de custo (Score/$), superando modelos muito mais caros em até 33x em termos de custo-benefício.

5. Significado e Conclusão

O Agent-Diff estabelece um novo padrão para a avaliação de agentes LLM em ambientes empresariais. Ao focar na alteração do estado do sistema em vez da sequência de ações, o benchmark oferece uma métrica de sucesso mais robusta e alinhada com o objetivo real de produtividade: "a tarefa foi concluída corretamente sem quebrar nada?".

Os resultados indicam que, embora o conhecimento da API seja importante (especialmente para APIs novas), a capacidade de planejamento, decomposição de tarefas e recuperação adaptativa de erros são os fatores diferenciadores mais críticos entre modelos de alto e baixo desempenho. O framework é de código aberto, permitindo que a comunidade avance na criação de agentes mais confiáveis para automação corporativa.