Resumo Técnico: Quando uma Avaliação de Agente Termina?

Declaração do Problema

Os atuais frameworks de avaliação de agentes tipicamente pontuam modelos com base no estado visível no momento em que uma execução é interrompida (o "endpoint"). Esta abordagem assume que o endpoint estabelece simultaneamente duas condições críticas: finalidade do resultado (o resultado está definido e não pode mudar) e separação entre unidades (a execução atual é independente de execuções anteriores ou futuras).

O artigo argumenta que estas duas condições são independentes e frequentemente não são atendidas no endpoint.

1. Finalidade do Resultado: Uma execução pode parar enquanto operações assíncronas (ex: escritas atrasadas, processos de segundo plano) ainda estão pendentes. Pontuar o estado antes que estas operações se completem pode levar a rótulos incorretos (ex: marcar uma tarefa como falha quando uma escrita atrasada teria tido sucesso, ou vice-versa).
2. Separação entre Unidades: Se o ambiente retém estado entre as execuções (ex: bancos de dados compartilhados, contas persistentes ou artefatos não limpos), uma execução anterior pode alterar as condições iniciais ou o resultado de uma execução subsequente. Isso viola a suposição de que os ensaios são independentes e identicamente distribuídos (i.i.d.), tornando inválidas as métricas agregadas (como $pass@k$).

As auditorias existentes muitas vezes verificam falhas de benchmark ou mecanismos de reset, mas falham em distinguir entre um resultado pontuado que está meramente "inacabado" versus um onde a conexão entre as execuções não foi contabilizada.

Metodologia

O autor emprega uma abordagem de três frentes para investigar estes problemas:

1. Estrutura Teórica (O Argumento da Conclusão):
   O artigo desenvolve uma estrutura lógica distinguindo entre o endpoint (quando a interação para) e a conclusão (quando o resultado está definido e as fronteiras estão seguras). Define a evidência necessária para justificar um rótulo final versus tratar as execuções como ensaios separados.

2. Experimento de Replay Controlado:
   Utilizando o AgentDojo 0.1.35, o autor construiu um sistema para isolar escolhas de fronteira.

   • Configuração: Um executor independente reproduziu chamadas de ferramentas e cronogramas de operações fixos. Um serviço HTTP local simulou atrasos assíncronos (0, 25, 100, 250 ms) e persistência de estado.
   • Variáveis: O estudo variou o tempo de pontuação (snapshot no endpoint vs. esperar pelo estado terminal) e o gerenciamento de estado (estado compartilhado vs. estado com namespace vs. reset verificado).
   • Métricas: O experimento mediu o desacordo entre os rótulos do endpoint e os rótulos terminais (finalidade) e a frequência de exposição entre execuções (separação).

3. Revisão de Documentação:
   O autor revisou a documentação pública e os artigos de dez benchmarks proeminentes de agentes: WebArena, WorkArena, OSWorld, SWE-bench, tau-bench, ToolSandbox, TheAgentCompany, RE-Bench, Cybench e AgentCanary.

   • Critérios: Eles codificaram declarações explícitas sobre definições de execução, regras de parada, persistência de estado, mecanismos de reset e evidências para tratar as execuções como ensaios separados.
   • Limitações: A revisão focou no que foi explicitamente relatado, não em inferir propriedades não declaradas.

Principais Contribuições

1. Distinção Conceitual: Finalidade do Resultado vs. Separação entre Unidades

O artigo estabelece que estas são exigências distintas que requerem evidências diferentes:

• Finalidade do Resultado: Requer que toda operação ou evento relevante que possa alterar o resultado seja resolvido, delimitado ou confirmado como cancelado.
• Separação entre Unidades: Requer que nenhuma rota relevante (estado compartilhado, credenciais, artefatos) permita que uma execução influencie as condições ou o resultado de outra.
• Implicação: É possível alcançar a finalidade sem separação (ex: esperar que uma escrita termine, mas deixar o arquivo acessível para a próxima execução) e a separação sem finalidade (ex: isolar as execuções, mas pontuar antes que uma operação atrasada se complete).

2. O Argumento da Conclusão

O autor propõe um framework de decisão para avaliadores:

• Para Rótulos Finais: Um rótulo de sucesso/falha só é justificado se todas as rotas que poderiam alterar o resultado forem bloqueadas, seguidas até a conclusão ou estritamente delimitadas. Caso contrário, o resultado deve ser reportado como não resolvido.
• Para Ensaios Separados: As execuções só podem ser contadas como unidades de análise separadas se todas as rotas entre elas forem bloqueadas ou comprovadamente incapazes de afetar o resultado. Se uma conexão permanecer, as execuções devem ser modeladas como uma unidade conectada ou agrupadas.

3. O Registro de Efeitos Abertos (Open-Effects Record)

O artigo propõe um novo padrão de relatório: um registro de efeitos abertos. Este registro deve listar operações ou recursos que permanecem relevantes após o endpoint, seu status atual e se eles poderiam alterar o resultado pontuado ou afetar outra execução.

Resultados Experimentais

Achados de Replay Controlado

• Finalidade: Em atrasos não nulos, os rótulos do endpoint discordaram dos rótulos terminais em 100% dos casos (150/150 ensaios). A pontuação por snapshot registrou 50 sucessos, enquanto a reconciliação (esperar pela conclusão) registrou 200 sucessos. O cancelamento verificado identificou corretamente as escritas pendentes como falhas.
• Separação: Sob estado compartilhado, 75% dos pares (150/200) mostraram exposição onde a Execução A alterou o resultado da Execução B. Esta exposição foi eliminada (0/200) sob estado com namespace, reset verificado ou quando a Execução B rodou antes da Execução A.
• Conclusão: O endpoint sozinho não pode justificar o rótulo final ou a unidade de análise. O tempo de pontuação e a política de gerenciamento de estado determinam diretamente a validade do resultado.

Achados da Revisão de Documentação

• Reset/Retenção: Explicitamente documentado em 8/10 protocolos; parcialmente em 2/10.
• Operações Inacabadas: Reportadas de forma muito menos consistente. 6/10 protocolos expuseram shells, navegadores ou serviços sem declarar se processos descendentes ou efeitos atrasados foram finalizados, cancelados ou verificados antes da pontuação.
• Evidência para Separação: Apenas 3/10 protocolos forneceram evidência explícita para tratar as execuções como observações separadas. Sete descreveram procedimentos de reset, mas falharam em declarar totalmente o escopo dos recursos cobertos ou como a restauração bem-sucedida foi verificada.
• Lacuna: Nenhum protocolo documentou consistentemente os períodos de tempo sobre os quais efeitos relevantes poderiam alterar o resultado.

Significância e Alegações

O artigo alega que as práticas de avaliação atuais frequentemente confundem o fim da interação com o fim da cadeia causal da tarefa. Sua significância reside em:

1. Corrigir a Validade das Métricas: Demonstra que, sem verificar a finalidade e a separação, as métricas agregadas (como taxas de sucesso) podem medir uma mistura de desempenho da tarefa e artefatos ambientais.
2. Refinar as Fronteiras de Avaliação: Argumenta que a "fronteira de avaliação" não é um único momento, mas um conjunto de decisões sobre quando parar, quando pontuar e como separar as execuções.
3. Propor um Padrão de Relatório: Ao introduzir o "registro de efeitos abertos", o artigo fornece um mecanismo concreto para que os avaliadores reportem de forma transparente estados não resolvidos e recursos persistentes, permitindo que os leitores avaliem a validade dos resultados alegados.

O autor mantém uma postura modesta, observando que sua revisão de documentação é limitada a dez protocolos e que suas contagens experimentais refletem condições construídas, não a frequência desses problemas no panorama mais amplo dos benchmarks publicados. O argumento central é que um rótulo final é justificado apenas quando tudo o que ainda poderia alterar o resultado alegado for resolvido, delimitado ou mantido como incerteza.