O projeto OpenGCUA, do grupo Tongyi, publica a primeira versão de um stack aberto para agentes que operam o computador de forma genérica. O grupo é assinado por Hanzhang Zhou, Long Li, Quyu Kong, Lei Wang e colegas, com Steven Hoi e Yue Wang entre os autores.
O sistema combina interface gráfica, terminal e APIs sob decisão do próprio modelo. O relatório formaliza o que seria um generalist computer-use agent (GCUA).
No benchmark OSWorld-v2, o trabalho relata ganho médio de 19,6 pontos no score parcial. Também aponta queda de 53,0% no número de passos por tarefa em oito modelos de fronteira.
A tese central é que decisões hoje fixadas por regras do harness devem migrar para o modelo. Um exemplo é tirar screenshot a cada passo.
O que os autores propõem
O artigo é o primeiro release de um projeto contínuo, organizado em cinco frentes. A primeira é um modelo que unifique uso de computador e navegador.
A segunda é um sistema composto por harness de dispositivo real e um SDK cross-device. A terceira é a liberação das trajetórias de avaliação.
A quarta frente é o estudo sistemático de eficiência de execução. A quinta são ambientes de avaliação em máquinas reais, com ênfase em macOS.
A contribuição conceitual é a definição. Em vez de classificar um agente pelos componentes que ele tem, os autores o definem pelas decisões que o modelo toma a cada passo: o que observar, como agir e como organizar o trabalho ao longo dos passos.
Com isso, agentes puramente GUI, agentes de linha de comando, híbridos multiagente e o próprio Qwen-UI-Agent (Zhou et al., 2026) passam a ser casos particulares de GCUA. O Qwen-UI-Agent é trabalho anterior do grupo.
Cada um deles fixa previamente parte dessas decisões.
Junto com a definição vem a crítica ao estado da arte. Sistemas de fronteira como o computer use do GPT-6 Astra, da OpenAI, são fechados.
Pesos, prompts completos, harness de dispositivo real, SDK de controle e trajetórias de execução não estão disponíveis. Isso impede reprodução, comparação de designs alternativos e análise de custo em condições reais.
Contexto: qual problema está sendo atacado
A literatura de agentes de uso de computador tratou o problema, em grande parte, como uma questão de GUI. O agente observa screenshots e emite cliques e teclas (Qin et al., 2025; Lu et al., 2026, conforme citados pelos autores).
Sistemas de fronteira, porém, já combinam GUI com comandos de shell, acesso à árvore de acessibilidade e outras ferramentas. A própria OpenAI passou a recomendar execução de código, escrevendo operações de GUI como programa e misturando-as a operações programáticas numa única saída do modelo.
Segundo os autores, a pergunta mudou. Não é mais "quão bem o modelo opera uma interface gráfica", mas "quão bem o sistema conclui trabalho num computador real, por qualquer meio que funcione".
Nessa formulação entram desafios que benchmarks dificilmente capturam. Dividir a máquina com o usuário humano, agir sobre janelas em segundo plano e lidar com pedidos que evoluem durante a execução.
O texto dialoga com a visão sistêmica de Agents' Last Exam (Sun et al., 2026). Esse trabalho decompõe um agente em cinco camadas: modelo, percepção de GUI, orquestração, ferramentas e runtime.
Os autores argumentam que ter as cinco camadas não garante saber escolher entre elas a cada passo.
Como funciona
O agente descrito no relatório decide, a cada passo, entre quatro interfaces. Cada uma oferece um modo de observar e um modo de agir.
A GUI usa screenshot e cliques em coordenadas. A árvore de acessibilidade traz elementos com papéis, nomes e valores, operáveis sem mover o ponteiro do usuário.
A CLI usa comandos de shell e sua saída. A API cobre serviços externos, como busca.
A decisão de "como agir" é expressa como um programa. A saída do modelo pode conter loops, condicionais e variáveis que chamam primitivas dessas quatro interfaces.
Um clique, uma operação de acessibilidade, um comando de shell e uma chamada de API tornam-se apenas quatro tipos de instrução dentro do mesmo programa. É aí que entra a execução de código.
Resultados intermediários podem determinar a próxima operação sem uma nova chamada ao modelo. O modelo aplica diretamente suas habilidades de programação à interação com o computador.
O segundo mecanismo é a harness-to-model decision transfer. Regras fixas do harness passam a ser decisões do modelo.
Um exemplo é tirar screenshot depois de cada passo.
Na implementação atual, o modelo escolhe quando pedir screenshots e como registrar o estado da tarefa. Também declara a finalidade de cada programa antes de executá-lo.
Os autores mostram que o Qwen-UI-Agent, com espaço de ação GUI+CLI e ações em lote, é o caso restrito. Nele, a observação é fixa (últimos screenshots) e o estado de trabalho é mantido por regra.
Completa o pacote um harness preliminar para máquinas reais e um SDK cross-device. O SDK amarra cada operação a um dispositivo, aplicação, janela ou aba explícitos.
Ele mantém acessibilidade e visão como caminhos separados e permite que um único programa coordene vários dispositivos.
Resultados reportados
No conjunto offline do OSWorld-v2, a configuração completa de GCUA melhora o score parcial em todos os oito modelos avaliados. A lista inclui GPT-6 Astra e Claude Opus 5.
A média é de +19,6 pontos e 53,0% menos passos por tarefa frente à execução GUI-only em lote. Os autores também relatam que a diferença de score entre o modelo mais forte e o mais fraco cai mais da metade.
Isolando o efeito da execução de código: com o mesmo acesso a GUI e shell, escrever operações de GUI como código acrescenta 6,1 pontos à média. A abordagem também reduz 14,8% dos passos em relação à linha de base GUI+CLI.
A observação sob demanda, sozinha, eleva a taxa de acerto de cache em 10,5 e 14,4 pontos percentuais em dois modelos, sem derrubar os scores.
No harness de dispositivo real, com quatro tarefas em macOS e o harness mantido fixo, os autores apontam um contraste. Execuções selecionadas de Qwen3.8-Max gastam 19,4 vezes mais tokens de raciocínio que o GPT-6 Astra.
No total, são 5,7 vezes mais tokens de saída. Os estudos de caso atribuem a diferença a comportamento de modelo: raciocínio excessivo para operações simples, dificuldade de adaptação a condições de máquina real e lacuna em capacidade de execução de código.
Limitações e o que não foi provado
O release não inclui um modelo treinado. Harness de dispositivo real e SDK cross-device são versões preliminares.
Os próprios autores enquadram o trabalho como projeto em andamento, com roadmap no artigo. Os números de OSWorld-v2 vêm do conjunto offline do benchmark, não de implantação em produção.
A evidência em máquina real é estreita: quatro tarefas de macOS, com destaque para um par de modelos. O contraste de 19,4 vezes em tokens de raciocínio é apresentado como observação sobre execuções selecionadas, não como medição exaustiva.
Como se trata de relatório técnico divulgado no arXiv, sem venue informado, os resultados não passaram por revisão por pares. Devem ser lidos como alegações dos autores.
Há também uma questão conceitual em aberto. Transferir decisões do harness para o modelo pode aumentar a variância de comportamento e o custo por passo.
A métrica agregada de score parcial e de passos por tarefa não resolve isso sozinha.
Por que isso importa para quem constrói com IA
Três lições práticas emergem do texto. A primeira é que política de observação é uma alavanca de custo.
Solicitar screenshot a cada passo é caro e prejudica cache. Deixar o modelo pedir a imagem quando precisar melhorou a taxa de acerto de cache em dois dígitos percentuais sem perda de score.
A segunda é que execução de código não é sinônimo de acesso ao shell. O ganho de 6,1 pontos aparece justamente quando o modelo pode encadear operações e usar resultados intermediários dentro de um mesmo programa, evitando idas e voltas ao modelo.
A terceira é que eficiência em dispositivo real é problema de modelo, não só de infraestrutura. Com o harness fixo, a diferença de 19,4 vezes em tokens de raciocínio entre Qwen3.8-Max e GPT-6 Astra mostra o peso da escolha do modelo.
Para automação de desktop, escolher o modelo certo pode pesar mais no orçamento do que otimizar o orquestrador. Para quem integra agentes a produtos, vale acompanhar o que o projeto libera em seguida.
Trajetórias, prompts e SDK são exatamente os artefatos que faltavam para comparar designs com método.
Referências
- OpenGCUA: Toward a Fully Open Stack for Generalist Computer Use — Hanzhang Zhou, Long Li, Quyu Kong, Lei Wang, Panrong Tong, Long Chen, Tianyu Xia, Gongjie Zhang, Xu Zhang, Chen Liu, Jianan Zhang, Chenglin Cai, Zhengwen Zeng, Steven Hoi, Yue Wang. arXiv:2610.22200. https://arxiv.org/abs/2610.22200
- Página do projeto OpenGCUA (código, prompts, trajetórias e SDK preliminar): https://tongyi-mai.github.io/OpenGCUA/
- Zhou et al. (2026), Qwen-UI-Agent, trabalho anterior do grupo sobre espaço de ação unificado GUI+CLI, citado pelos autores.
- Sun et al. (2026), Agents' Last Exam, visão sistêmica em cinco camadas, citada pelos autores.
- OpenAI (2026b, 2026c), recomendações sobre execução de código em computer use e divulgação do GPT-6 Astra, citadas pelos autores.
