AOS-Bench testa agentes de IA: desempenho cai 13-23 pontos em tarefas paralelas

A pergunta prática por trás do AOS-Bench

Uma equipe de pesquisadores quis responder a uma pergunta prática: o quanto os agentes de IA que escrevem código e operam um computador estão preparados para trabalhar não com uma tarefa por vez, mas com um fluxo de tarefas — como acontece de fato no dia a dia, quando, enquanto um projeto está sendo compilado, chega uma solicitação para processar dados e, em seguida, outra para corrigir um bug. Todos os benchmarks existentes para esse tipo de agente (como Terminal-Bench e OSWorld) avaliam as tarefas isoladamente, então ninguém havia medido antes se um agente consegue equilibrar várias demandas ao mesmo tempo com recursos computacionais limitados. Para resolver essa lacuna, foi criado o AOS-Bench, um benchmark que trata o agente como uma espécie de "sistema operacional em linguagem natural", que precisa decidir por conta própria quando assumir uma nova tarefa, como dividir o trabalho entre subtarefas e como não exceder a CPU e a memória disponíveis.

Como o experimento foi montado

Foram testadas cinco combinações de "modelo + ambiente de agente": Claude Opus 5, GPT-5.6-sol, DeepSeek-V4-Pro, GLM-5.3 e Kimi-K3. Cada sistema recebeu um limite de 4 núcleos de CPU e 8 gigabytes de memória. Em um cenário, as tarefas chegavam estritamente uma a uma (servindo de referência para o desempenho "individual"); no outro, várias tarefas chegavam em sequência, em intervalos, simulando um fluxo de trabalho real ("stream"). Foram usados dois níveis de dificuldade: médio (10 tarefas por execução) e pesado (20 tarefas).

O que os números mostraram

Sob carga pesada, cada um dos cinco sistemas perdeu entre 13 e 23 pontos percentuais de soluções bem-sucedidas em comparação com o próprio desempenho nas mesmas tarefas resolvidas uma a uma. O Claude Opus 5 teve o melhor desempenho: sua taxa de sucesso caiu de 75,5% em tarefas individuais para 62,5% no modo de fluxo — ou seja, manteve cerca de 83% de sua capacidade básica. Os outros quatro sistemas mantiveram apenas entre 61% e 75% do nível básico.

Em carga média, os resultados foram ainda mais reveladores: o quão bem um sistema resolve tarefas individuais praticamente não prevê o quão bem ele vai se sair em um fluxo de tarefas. O GPT-5.6-sol teve o maior resultado em tarefas individuais, 85,3%, mas perde 14,5 pontos no modo de fluxo. Já o Kimi-K3, com um resultado básico 11 pontos mais baixo, perde apenas 6,3 pontos no fluxo. O exemplo mais marcante: dois sistemas cujo desempenho em tarefas individuais difere em apenas 0,6 ponto (74,9% contra 74,3%) terminam em 68,1% e 53,9% no modo de fluxo — uma diferença de quase 15 pontos que não deveria existir.

Por que isso acontece

A causa principal não é que os agentes resolvam piores as tarefas em si. Os autores decompuseram cada ponto perdido por causa e descobriram que a maior parte da diferença sob carga pesada — entre 16 e 26 dos 16-23 pontos perdidos por quatro dos sistemas — vem de tarefas que o agente nunca chegou a assumir, não terminou antes do tempo esgotar, ou terminou depois que a memória já havia se esgotado. Os erros propriamente ditos na execução das tarefas assumidas representam uma perda de não mais que 1,3 ponto. Em termos simples: esses sistemas não tropeçam ao resolver as tarefas, mas sim ao não assumi-las a tempo.

O GLM-5.3 e o DeepSeek-V4-Pro são casos especialmente reveladores: em algumas execuções, simplesmente pararam de aceitar novas tarefas e voltaram a processá-las uma a uma, deixando 25% e 48% das tarefas recebidas sem atendimento, respectivamente (contra 0% do Claude Opus 5). Além disso, quando as mesmas tarefas eram entregues todas de uma vez, forçadamente (sem fila sequencial), os sistemas assumiam três quartos delas — o que indica que o problema não está na dificuldade das tarefas, mas especificamente na lógica de aceitação de trabalho novo.

A descoberta inesperada sobre o gerenciamento "inteligente"

Pareceria lógico pensar que a solução é ensinar o agente a planejar a concorrência de forma mais inteligente. Mas o experimento mostrou o contrário: a regra mais simples possível — "executar exatamente duas tarefas por vez, sem nenhuma análise" — fica a apenas 4 pontos das melhores estratégias em que o próprio agente decide o que executar e quando. Além disso, independentemente da estratégia de gerenciamento usada, enquanto as tarefas esperam na fila, a CPU é usada abaixo de 30% dos quatro núcleos alocados — os recursos ficam ociosos mesmo quando há trabalho de sobra.

Para equipes que planejam construir agentes de IA persistentes para trabalho real com múltiplas tarefas simultâneas, a conclusão é pragmática: não vale a pena investir de imediato em uma lógica complexa de planejamento de tarefas dentro do agente, já que uma simples limitação de concorrência produz resultados quase tão bons. O que de fato precisa ser corrigido primeiro é o mecanismo de aceitação e confirmação de novas tarefas, que é onde se perde a maior parte da eficiência.