Blog

Recomendação direta: antes de aceitar qualquer número de benchmark de agente, pergunte qual métrica ele representa. O mesmo agente, na mesma execução, pontua 54,8 ou 20,6 dependendo de você medir "quanto do caminho ele andou" ou "quantas tarefas ele realmente terminou".

Existe uma pergunta que todo gestor faz quando vê uma demonstração de agente de IA operando um computador sozinho: isso funciona de verdade ou é vídeo bem editado?

Até junho de 2026 era difícil responder com honestidade. Os testes disponíveis mediam tarefas curtas, do tipo "abra esse arquivo e mude essa configuração", que levam trinta ações e dois minutos. Agentes iam bem, todo mundo publicava número alto e ninguém entendia por que, na empresa real, o piloto travava.

Então saiu o OSWorld 2.0, e a resposta ficou desconfortável.

Resumo rápido para quem tem pressa

Pergunta	Resposta curta
O que o OSWorld 2.0 mede?	108 fluxos de trabalho reais que levam 1,6 hora para um humano concluir
Quantas ações uma tarefa exige?	Cerca de 318 chamadas de ferramenta, contra ~30 na versão anterior
Qual era o melhor resultado no lançamento?	Claude Opus 4.8 terminou 20,6% das tarefas
Por que se vê o número 54,8 então?	É a pontuação parcial, quanto do fluxo foi percorrido, não quanto foi concluído
Quem lidera hoje?	Claude Opus 5, com 70,6% divulgados
Dá para rodar local?	Sim, com modelos como o Holo3.1, mas medidos em outro benchmark
O que mais derruba os agentes?	Não é clicar errado. É esquecer restrição, chutar em vez de perguntar e não conferir o resultado

O que o OSWorld 2.0 faz de diferente

O OSWorld 2.0 foi publicado em 28 de junho de 2026 pelo XLANG Lab. Ele abandonou a tarefa curta e passou a medir fluxo de trabalho longo, do tipo que uma pessoa executa em uma tarde inteira.

São 108 fluxos distribuídos em sete domínios profissionais e 21 subcategorias: pesquisa, produção criativa, engenharia, serviços pessoais, negócios e finanças, administração e conformidade, e saúde.

Os números que definem a dificuldade:

• 1,6 hora é o tempo mediano que um humano leva para concluir uma tarefa;
• 318 chamadas de ferramenta em média, contra cerca de 30 no OSWorld 1.0;
• 500 passos é o limite dado ao agente;
• o estado persiste entre aplicações, ou seja, o que o agente fez no passo 12 afeta o passo 300.

Essa última característica é a que quebra tudo. Uma tarefa curta perdoa. Um fluxo de 300 ações não perdoa: um erro no começo contamina todo o resto, e o agente segue trabalhando com confiança sobre uma base errada.

O truque dos dois números

Aqui está a parte que mais gera confusão em apresentação comercial, e o motivo do título deste artigo.

O OSWorld 2.0 reporta duas métricas diferentes para a mesma execução:

• Conclusão binária: a tarefa foi terminada corretamente, sim ou não. É a métrica principal.
• Pontuação parcial: quanto do fluxo o agente conseguiu percorrer antes de errar ou parar.

No artigo original, o Claude Opus 4.8 com raciocínio máximo e chamadas de ferramenta em lote foi o melhor colocado. O resultado dele:

Métrica	Resultado
Pontuação parcial	54,8%
Tarefas efetivamente concluídas	20,6%

São 34 pontos de diferença na mesma execução, do mesmo modelo. Um número parece aprovação, o outro parece reprovação, e os dois são verdadeiros.

Para o seu negócio, a diferença é brutal. Pontuação parcial de 54,8% significa "o agente fez metade do caminho e parou". Se o processo é emitir uma nota fiscal, meio caminho não vale nada. Se o processo é preparar um relatório que um humano vai revisar de qualquer forma, meio caminho vale bastante.

A pergunta certa não é "qual a pontuação". É "essa tarefa aceita entrega parcial?".

O ranking de agosto de 2026

O quadro mudou rápido depois do lançamento. Este é o retrato atual da conclusão de tarefas no OSWorld 2.0:

Modelo	Resultado	Pesos
Claude Opus 5	70,6%	Fechado
GPT-5.6 Sol	62,6%	Fechado
GPT-5.6 Terra	50,2%	Fechado
GPT-5.6 Luna	45,6%	Fechado
Claude Opus 4.8	20,6%	Fechado
Qwen 3.8 Max	19,4%	Aberto
Claude Opus 4.7 (Adaptive)	18,2%	Fechado
Muse Spark 1.1	14,2%	Fechado
Claude Opus 4.7	13,9%	Fechado
GPT-5.5	13,0%	Fechado
Claude Sonnet 4.6	8,3%	Fechado
Kimi K2.6	4,6%	Aberto
MiniMax M3	4,6%	Aberto
Qwen 3.7 Plus	2,8%	Fechado

Três leituras importantes dessa tabela.

O salto é grande demais para não levantar a sobrancelha. Passar de 20,6% (Opus 4.8) para 70,6% (Opus 5) em poucas semanas é um avanço enorme. Vale registrar uma ressalva honesta: o número 70,6 circula amplamente sem que a métrica seja declarada na maioria das publicações. Se for conclusão binária, é um salto histórico. Se for pontuação parcial, é uma evolução importante sobre os 54,8 anteriores, porém bem menos espetacular do que parece. Trate os 70,6 como indicador de direção, não como promessa contratual, e verifique a métrica na fonte antes de usar isso em uma decisão de investimento.

A distância entre aberto e fechado é gigante aqui. No artigo anterior sobre inferência ultrarrápida e modelos abertos, a conclusão foi que modelos abertos alcançaram os proprietários para atendimento e conversação. Em uso de computador, essa conclusão não se aplica. O melhor modelo aberto da lista faz 19,4% contra 70,6% do topo fechado. São capacidades diferentes, e generalizar de uma para a outra é o erro mais caro que se comete hoje ao montar arquitetura de agentes.

Custo importa tanto quanto pontuação. O Opus 5 é reportado como superior a qualquer outro modelo em qualquer faixa de custo, superando o melhor resultado do Fable 5 por cerca de um terço do preço. A US$ 5 por milhão de tokens de entrada e US$ 25 de saída, contra US$ 10 e US$ 50 do Fable 5, a conta fecha a favor dele. Mas lembre que uma tarefa aqui consome centenas de chamadas.

Onde os agentes realmente falham

Esta é a parte mais útil do estudo, e a que quase ninguém comenta.

Os pesquisadores esperavam encontrar agentes travando em controle de interface: clique errado, botão não encontrado, elemento fora da tela. Não foi isso. Os agentes dominam a mecânica. Eles falham em outra camada:

• perdem restrições pelo caminho: a regra dada no início some do comportamento lá pelo passo 150;
• ignoram informação que chega no meio da tarefa: um aviso, um erro, uma mudança de estado que aparece depois do plano montado;
• chutam em vez de perguntar: diante de ambiguidade, escolhem uma interpretação e seguem, sem sinalizar a dúvida;
• não verificam o próprio trabalho: dão a tarefa por concluída sem conferir se o resultado bate com o pedido;
• se perdem com estado oculto: quando a informação necessária não está visível na tela e precisa ser recuperada.

Leia essa lista de novo trocando "agente" por "estagiário no primeiro mês". É exatamente a mesma lista.

E isso muda a natureza do problema. Essas não são falhas técnicas, são falhas de gestão. A solução não é um modelo maior. É a mesma coisa que se faz com uma pessoa nova na equipe: escopo menor, critério de aceite explícito, obrigação de perguntar quando houver dúvida e uma etapa de conferência antes de dar por pronto.

Quem já estruturou métricas, logs e avaliações de IA em produção sai na frente, porque o problema aqui é de instrumentação e processo, não de escolha de modelo.

Dá para rodar isso na sua própria máquina?

Pergunta natural: se o agente vai enxergar a minha tela e os meus arquivos, dá para manter tudo local?

Dá, com ressalvas importantes.

O caminho mais maduro hoje é a família Holo3.1, da H Company, a primeira linha de agentes de uso de computador com pesos abertos e checkpoints quantizados pensados para execução local. Ela vem em quatro tamanhos: 0,8B, 4B, 9B e 35B-A3B.

O modelo de topo, o Holo3.1-35B-A3B, é uma mistura de especialistas com 35 bilhões de parâmetros totais e apenas 3 bilhões ativos por passagem. Na prática, você tem precisão de um modelo de 35B pagando custo de inferência de um 3B, o que é justamente o que permite rodá-lo em hardware modesto. Ele é distribuído em FP8, NVFP4 e Q4 GGUF, e roda localmente em Windows e Mac, inclusive Apple Silicon.

Sobre os modelos gigantes de pesos abertos, esqueça a execução local. O Kimi K3 tem 2,8 trilhões de parâmetros totais. Mesmo quantizado em 4 bits, só os pesos ocupariam cerca de 1,4 TB, antes de contar cache de contexto, encoder de visão, ativações e o próprio agente. O fato de a arquitetura ativar poucos parâmetros por token não elimina a necessidade de manter todos os especialistas na memória. Em uma máquina de 96 GB, não cabe, e descarregar mais de 1 TB para SSD deixaria o agente lento demais para uso interativo.

A armadilha de comparar números de benchmarks diferentes

Aqui mora o erro mais comum de quem pesquisa esse assunto.

Os resultados de OSWorld divulgados para o Holo3.1 não foram medidos no OSWorld 2.0. Eles vêm de execuções próximas ao OSWorld original ou ao OSWorld-Verified, em implementação interna da própria empresa, e as cifras variam conforme a fonte e a configuração.

Então não existe comparação válida entre "o Holo faz mais de 70 no OSWorld" e "o Opus 5 faz 70,6 no OSWorld 2.0". São benchmarks diferentes, com tarefas diferentes, em harness diferente. O OSWorld 2.0 foi criado exatamente porque o anterior ficou fácil demais. Colocar os dois números lado a lado numa apresentação é, na melhor das hipóteses, desinformação involuntária.

A regra prática: só compare números que vieram da mesma versão do benchmark, na mesma métrica, com o mesmo limite de passos. Qualquer coisa fora disso é conversa de vendedor.

Uma arquitetura local que faz sentido

Para quem quer privacidade sem abrir mão de resultado, o desenho mais realista é híbrido e separa os papéis:

• controle visual e interface: Holo3.1-35B-A3B rodando local, que é o que ele faz bem;
• código, terminal e arquivos: um modelo de código local, que continua melhor nessa função;
• tarefa excepcionalmente difícil: escalonamento para Opus 5 ou GPT-5.6 Sol via API, apenas quando necessário.

Vale lembrar que carregar o modelo não cria um agente. É preciso um harness que rode o laço continuamente: capturar a tela, enviar imagem e estado ao modelo, receber uma ação estruturada, executar o clique ou a digitação, capturar o novo estado, verificar o resultado e repetir. A qualidade desse laço, especialmente da etapa de verificação, pesa tanto quanto o modelo escolhido.

A evidência disso está no próprio estudo: um mesmo modelo base que atinge 31,6 com um executor simples chega a 62,2 com um framework melhor. O benchmark mede o sistema inteiro, não só o modelo. É o mesmo princípio de tool calling bem implementado: a engenharia em volta decide o resultado.

O que fazer com isso na sua empresa

Cinco conclusões práticas, na ordem em que importam.

1. Escolha tarefas que aceitam entrega parcial. Enquanto a conclusão integral não for confiável, direcione os agentes para trabalho onde 60% pronto já economiza tempo: levantar dados, preencher rascunho, preparar relatório para revisão. Fuja de processo onde meio caminho gera prejuízo, como emissão fiscal, pagamento ou comunicação direta com cliente sem revisão.

2. Quebre o fluxo longo em etapas curtas com conferência. O OSWorld 2.0 mostra que a degradação vem do comprimento. Três tarefas de 100 ações com checagem entre elas rendem muito mais que uma de 300.

3. Force o agente a perguntar. Chutar diante de ambiguidade é uma das principais causas de falha. Instrua explicitamente a parar e perguntar, e trate a pergunta como sucesso, não como fracasso.

4. Exija verificação antes do "pronto". Uma etapa final de conferência contra o pedido original elimina uma classe inteira de erro. É barato e quase ninguém faz.

5. Meça o seu processo, não o benchmark. Ranking serve para escolher candidatos, não para prever resultado no seu contexto. Monte testes de regressão com as suas tarefas reais e acompanhe a taxa de conclusão do seu fluxo. E antes de dar a um agente acesso a sistema real, leia sobre proteção contra prompt injection, porque um agente que opera a sua máquina e lê conteúdo de terceiros é uma superfície de ataque nova.

Veredito

O OSWorld 2.0 fez ao mercado de agentes o mesmo favor que uma auditoria séria faz a uma empresa: tirou o número bonito da parede e mostrou a operação real.

A leitura madura dos dados é esta. Agentes de uso de computador já são úteis, e o progresso entre gerações é real e rápido. Mas eles ainda não são autônomos em fluxo longo, e a distância entre "andou metade do caminho" e "entregou a tarefa" continua sendo o buraco onde os pilotos caem.

Para 2026, a arquitetura vencedora não é a que entrega o computador ao agente e sai da sala. É a que dá a ele tarefas curtas, critério claro, permissão para perguntar e obrigação de conferir. Exatamente o que se faz com gente boa que acabou de chegar.

E se o assunto é decidir onde a IA entra no seu processo, o passo anterior a escolher modelo é decidir entre agente e sistema tradicional. Boa parte do que se tenta resolver com agente é, na verdade, integração bem feita.

E na sua operação?

Fica a pergunta para os comentários: você confiaria hoje um processo do seu negócio a um agente que conclui 7 de cada 10 tarefas sozinho, com revisão humana no final, ou prefere esperar chegar em 9 de cada 10 antes de tirar a mão?

A resposta muda conforme o custo do erro no seu caso, e é justamente essa conta que separa quem vai ganhar produtividade em 2026 de quem vai colecionar piloto abandonado.

Se quiser discutir isso aplicado ao seu processo, converse com o nosso time sobre agentes de IA para empresas.

---

Leia também:

• Velocidade é a nova inteligência: o que a Cerebras muda no custo da sua IA
• Agentes de IA ou sistemas: qual escolher
• LLMOps: métricas, logs e evals de IA em produção
• Projeto com IA sem arquitetura: por que tantos pilotos morrem

Dados verificados em agosto de 2026 a partir do artigo do OSWorld 2.0 e de rankings públicos. Resultados de benchmark de agentes mudam rápido e variam conforme harness, métrica e limite de passos. Confirme a métrica na fonte antes de usar qualquer número em decisão de investimento.