Resumo Técnico: PreAct – Agentes de Uso de Computador que se Tornam Mais Rápidos em Tarefas Repetidas

1. Definição do Problema

Agentes de uso de computador (CUAs) operam softwares observando telas e emitindo cliques ou teclas. Embora eficazes na resolução de tarefas, eles são inerentemente ineficientes para trabalhos repetitivos. Os agentes atuais tratam cada instância de tarefa como um novo problema: eles relêem a tela, raciocinam novamente sobre cada etapa e incorrem no custo total de inferência de visão e linguagem para cada execução, mesmo que a tarefa seja idêntica a uma resolvida anteriormente. Essa "re-derivação" impede que os agentes adquiram a fluência que os humanos desenvolvem através da prática, onde o raciocínio deliberado inicial é internalizado em rotinas automáticas. Além disso, as melhorias de eficiência existentes — como bibliotecas de habilidades ou sistemas de gravação e reprodução — frequentemente falham em equilibrar velocidade com confiabilidade. As bibliotecas de habilidades geralmente ainda exigem um modelo de linguagem (LLM) para executar comportamentos armazenados em tempo de execução, enquanto sistemas de gravação e reprodução ingênuos carecem de verificação, levando a uma execução "cega" que falha quando o ambiente muda ou quando o rastro armazenado é falho.

2. Metodologia: Arquitetura PreAct

O PreAct introduz um sistema que compila execuções bem-sucedidas de agentes em programas de máquina de estados diretamente executáveis. A inovação central é uma disciplina de "verificar-antes-de-armazenar" aplicada em duas escalas de tempo: verificação em tempo de execução durante a reprodução e verificação pré-armazenamento antes de um programa ser salvo.

2.1 O Artefato: Programas de Máquina de Estados

Em vez de armazenar scripts planos ou trechos de código parametrizados, o PreAct compila uma execução de tarefa bem-sucedida em uma pequena máquina de estados ($P = (S, T, M, V)$):

• Estados ($S$): Cada estado contém um predicado de verificação (por exemplo, um padrão XPath ou uma verificação de árvore de acessibilidade) que deve corresponder à tela ao vivo antes que o agente prossiga.
• Transições ($T$): Ações (cliques, digitação, navegações) que movem o agente de um estado para outro.
• Parâmetros ($M$): Valores concretos digitados durante o rastro (por exemplo, um nome específico ou número de telefone) são elevados a parâmetros, permitindo que o mesmo programa se generalize entre diferentes instâncias da mesma família de tarefas.
• Execução: Durante uma execução "quente" (warm run), o Replayer percorre o grafo. Antes de disparar uma transição, ele verifica a tela ao vivo contra o predicado do estado. Se a verificação passar, a ação é executada imediatamente sem uma chamada de LLM. Se falhar (por exemplo, um diálogo apareceu inesperadamente), o sistema interrompe e retorna ao CUA completo.

2.2 O Ciclo: Selecionar, Reproduzir, Recorrer, Verificar

O sistema opera via um ciclo de compilar-estender-substituir:

1. Selecionar: Um Seletor de Programas consulta o corpus em busca de um programa que corresponda ao objetivo atual.
2. Reproduzir: Se encontrado, o Replayer executa a máquina de estados com verificação por etapa.
3. Recorrer (Fall Back): Se um predicado falhar ou uma ação der erro, o controle é transferido para o CUA completo, que resolve a tarefa a partir do estado atual da tela e registra um novo rastro.
4. Verificar e Armazenar: Após o sucesso, o novo rastro é compilado em um candidato a programa $P'$. Crucialmente, $P'$ não é imediatamente armazenado. Ele passa por um Portão de Verificação-antes-do-Armazenamento.

2.3 O Portão de Verificação-antes-do-Armazenamento

Este é o principal mecanismo do sistema para garantir a melhoria monotônica. Antes de um programa entrar no corpus:

1. O ambiente é resetado para um estado inicial limpo.
2. O candidato a programa $P'$ é executado novamente do zero.
3. Um avaliador independente verifica se a tarefa foi realmente resolvida.
4. O programa é armazenado (ou substitui uma versão mais antiga com o mesmo sinal de deduplicação) apenas se a reprodução completar com sucesso e o avaliador confirmar que a tarefa foi resolvida.

Este portão captura especificamente programas "com perda" (lossy) que reproduzem com 100% de cobertura (todas as ações executam), mas falham em atingir o objetivo (por exemplo, um formulário de contato é preenchido e salvo, mas um campo obsoleto impede a criação do contato).

2.4 Mecanismo de Recuo (Fallback)

Quando o portão rejeita todos os programas candidatos para uma tarefa (deixando o corpus vazio para essa tarefa), o PreAct emprega um recuo: ele aciona uma nova exploração do CUA para a segunda execução. Isso garante que, mesmo que o sistema não consiga encontrar um programa verificado, ele não simplesmente desista, mantendo a paridade de desempenho com bases fortes de gravação e reprodução como o Muscle-Mem.

3. Contribuições Principais

• Execução Direta de Máquinas de Estados Verificadas: O PreAct altera o paradigma de execução de raciocínio baseado em LLM para execução de grafo determinística para tarefas repetidas, eliminando chamadas de LLM por etapa.
• Verificação de Duas Escalas de Tempo: O sistema aplica a mesma disciplina de "observar primeiro, depois agir" em tempo de execução (por etapa) e no tempo de armazenamento (re-execução pré-armazenamento). Isso evita a acumulação de programas falhos que, de outra forma, degradariam o desempenho ao longo do tempo.
• Corpus Autoextensível: Ao contrário dos caches de apenas adição (append-only), o corpus do PreAct é mutável. Novos programas podem substituir versões mais antigas se passarem pelo portão de verificação, permitindo que o sistema refine sua representação de tarefas ao longo do tempo.
• Validação Empírica de Eficiência: O artigo estabelece a "eficiência de tarefa repetida" como uma métrica de primeira classe, medindo não apenas as taxas de sucesso, mas também a redução no tempo de relógio (wall-clock time) e nos custos de tokens de LLM.

4. Resultados Experimentais

Os autores avaliaram o PreAct em três benchmarks: AndroidWorld (mobile), OSWorld (desktop) e WebArena (web).

• Velocidade e Custo: Execuções quentes (reproduzindo programas armazenados) são de 8,5 a 13 vezes mais rápidas em tempo de relógio do que execuções frias (re-derivando do zero) e incorrem em custo zero de LLM por etapa. O overhead único de compilar e verificar um programa é aproximadamente equivalente a uma resolução adicional (+162% no Android, +217% no OSWorld), mas isso é amortizado ao longo de execuções subsequentes.
• Melhoria Monotônica: Com o portão de verificação habilitado, as execuções repetidas melhoram consistentemente ou mantêm a taxa de sucesso.
  • AndroidWorld: Melhoria média de +1,33 tarefas (de 15) de frio para quente.
  • OSWorld: Melhoria média de +0,2 tarefas (de 6).
  • WebArena: Embora o portão cause uma regressão na taxa de sucesso bruta de execução quente (dev devido à alta rejeição de seletores web frágeis), o valor marginal do portão é positivo. Sem o portão, o desempenho degrada significativamente (ex: -5,8 tarefas no WebArena) conforme programas com perda se acumulam. Com o portão, a degradação é reduzida (-4,0 tarefas).
• A Necessidade do Portão: Estudos de ablação mostram que desabilitar o portão de verificação leva ao colapso do desempenho em todas as plataformas. O portão evita o modo de falha "executa, mas não funciona", onde um programa executa todas as etapas, mas falha na lógica da tarefa.
• Eficácia do Recuo (Fallback): No WebArena, onde o portão rejeita muitos programas, adicionar um fallback de "falha de cache para CUA" permite que o PreAct iguale o desempenho da base forte Muscle-Mem (estatisticamente indistinguível, $p \approx 0,84$), fechando a lacuna criada pela verificação agressiva.
• Robustez: Os resultados são robustos à escolha do LLM para compilação (Claude vs. Gemini) e à escolha do seletor (baseado em LLM vs. recuperador de embeddings). O mecanismo central, não o modelo específico, é o que impulsiona os resultados.

5. Significância e Alegações

O artigo afirma que o PreAct demonstra que agentes de uso de computador podem adquirir capacidades de aprendizado contínuo semelhantes às dos humanos: tornando-se mais rápidos e baratos em tarefas repetidas sem sacrificar a confiabilidade.

• Fluência vs. Cegueira: O PreAct alcança fluência não pela repetição cega, mas pela "predição com verificação". O agente age automaticamente quando a tela corresponde às expectativas, mas retorna imediatamente à deliberação quando elas não correspondem.
• Design sobre Ajuste (Tuning): Os autores enfatem que os ganhos de desempenho são impulsionados pela arquitetia do sistema (armazenar o programa que você executa, verificar antes de armazenar) e não por engenharia de prompt, salvaguardas de tempo de execução ou escolhas específicas de modelos.
• Uma Nova Dimensão de Avaliação: O artigo argumenta que o benchmarking deve ir além das simples taxas de sucesso para incluir o custo da execução repetida. Um agente que re-deriva cada tarefa é menos eficiente do que um que aprendeu a pular a deliberação, mesmo que ambos alcancem a mesma taxa de sucesso.

Em resumo, o PreAct fornece um framework onde os agentes constroem uma biblioteca de programas verificados e diretamente executáveis, permitindo que resolvam tarefas familiares com a velocidade de uma macro e a confiabilidade de um agente verificado, resolvendo efetivamente o "imposto de re-derivação" dos atuais agentes de uso de computador.