EvoArena Benchmark Revela Colapso de Agentes em Ambientes em Evolução

Agentes atualmente têm uma média de 39,6% de precisão em ambientes de terminal, software e sociais em evolução, de acordo com o benchmark EvoArena introduzido por um grupo liderado pela NUS, incluindo Salesforce AI Research e MIT. Esta é a primeira suite para modelar a deriva do mundo real como atualizações progressivas em versões em vez de instantâneos estáticos. O benchmark consiste em três sub-tarefas: Terminal-Bench-Evo para fluxos de trabalho CLI em mudança, SWE-Chain-Evo para bases de código em evolução e PersonaMem-Evo para preferências de usuário em deriva. Ao contrário de WebArena, SWE-Bench ou GAIA, EvoArena sequencia mudanças consecutivas e testa se um agente pode lidar com uma cadeia de subtarefas evolutivas relacionadas sem descartar restrições que permanecem válidas de versões anteriores.

O principal modo de falha é o "colapso de estado", onde agentes padrão construídos sobre arquiteturas de banco de memória ou loja episódica mantêm um único estado mais recente. Quando uma permissão de fluxo de trabalho ou esquema de API é atualizada, a nova regra sobrescreve a antiga, fazendo com que o agente perca tanto o comportamento anterior quanto o limite contextual de quando foi aplicado. EvoArena descobre que esse colapso é a norma em todos os três domínios e que as verificações de compatibilidade de versão são particularmente letais para sistemas de linha de base.

Para contrariar o colapso, os autores propõem EvoMem, um complemento leve que adiciona um log de patch somente-acréscimo a sistemas de memória existentes em vez de reescrevê-los. Cada mudança ambiental é armazenada como uma diff estruturada, permitindo que o agente reconstrua qualquer estado anterior ao reproduzir a sequência. No EvoArena, EvoMem melhora a precisão média em 1,5 pontos percentuais sobre linhas de base colapsadas, com ganhos maiores de 6,1% no GAIA e 4,8% no LoCoMo. A precisão a nível de cadeia melhora em 3,7% com EvoMem.

No entanto, o artigo não relata o custo de serviço, a latência de relógio de parede para reprodução de patch, o gasto de token por reconstrução ou as horas de GPU. A proposta de valor é a complexidade de recuperação: reconstruir o estado a partir de um log de diffs é algoritmicamente mais caro do que ler um único snapshot. Código e conjuntos de dados estão disponíveis no GitHub e HuggingFace, mas ainda não há evidência de produção. Arquitetos avaliando EvoMem para agentes de longa duração precisariam ver as distribuições de latência em profundidades de log de patch de milhares de versões, o multiplicador de custo de token versus recuperação de memória plana e se o método sobrevive sob limites de taxa e limites de janela de contexto.

Um aumento de 1,5 pontos em uma linha de base de 39,6% significa que o fracasso permanece o resultado modal e a sobrevivência a nível de cadeia ainda está longe de ser alcançada pelos modelos atuais. Capturar a história não é o mesmo que raciocinar corretamente sobre ela sob orçamentos de cálculo. Para equipes que executam bots CI, assistentes de codificação persistentes ou sistemas de concierge personalizados, o custo de integração implícito é não trivial: alguém deve definir esquemas de patch estruturados, conectá-los à loja de memória e promover o LLM a ler históricos de diff em vez de contexto de chave-valor simples. A questão aberta é se esses ganhos se mantêm uma vez que os logs de patch crescem além dos horizontes de algumas dúzias de etapas típicos em benchmarks acadêmicos e se o overhead de memória de armazenar todas as diffs eventualmente força uma etapa de compressão ou resumo que reintroduz o risco de perda de estado que o EvoMem foi destinado a resolver.