Resumo Técnico: Plover – Direcionando Agentes de GUI através da Interação Centrada em Planos

1. Declaração do Problema

A automação de Interfaces Gráficas do Usuário (GUI) em ambientes do mundo real enfrenta desafios significativos devido a layouts dinâmicos, diálogos inesperados e estados de interface em evolução. Embora agentes multimodais baseados em visão recentes (usando capturas de tela e linguagem natural) ofereçam maior flexibilidade do que scripts tradicionais baseados em regras ou ferramentas de RPA (Automação de Processos Robóticos), eles sofrem de uma lacuna de design crítica: a execução de autonomia em primeiro lugar.

Nos sistemas atuais, o planejamento e o replanejamento ocorrem internamente no modelo. Uma vez iniciada a execução, o agente pode reinterpretar silenciosamente a intenção do usuário, regenerar etapas ou perseguir ações incorretas sem manter uma consciência situacional compartilhada com o usuário. Isso cria várias limitações específicas:

• Planejamento Opaco: Planos de tarefas são frequentemente saídas de etapa única, em vez de artefatos persistentes e editáveis.
• Fundamentação Fraca para Correção: Correções de linguagem natural de alto nível são frequentemente insuficientes para erros de GUI situados espacialmente (por exemplo, distinguir entre elementos visualmente semelhantes).
• Recuperação de Tudo ou Nada: Quando ocorrem erros, os agentes frequentemente regeneram todo o fluxo de trabalho de forma ampla, descartando o progresso anterior válido em vez de realizar reparos localizados.
• Falta de Visibilidade: Os usuários não podem inspecionar, supervisionar ou intervir facilmente no raciocínio ou nos processos de adaptação do agente quando a execução desvia do curso.

O artigo argumenta que a automação robusta de GUI deve ser tratada não apenas como um problema de modelagem, mas como um problema de interação, onde o objetivo é tornar os momentos necessários de supervisão precisos, localizados e recuperáveis.

2. Metodologia: O Sistema Plover

O Plover é um sistema de iniciativa mista projetado para externalizar planos de tarefas como artefatos persistentes, inspecionáveis e revisáveis. Ele emprega uma arquitetura de planejador–executor rodando dentro de máquinas virtuais de nível de SO, separando o planejamento de alto nível da atuação de baixo nível.

2.1 Arquitetura Central

• Interface Agêntica: A superfície de interação primária onde os usuários inspecionam planos, monitoram a execução e direcionam a adaptação. Apresenta um Espaço de Trabalho de Plano Compartilhado (exibindo artefatos de plano editáveis), um Painel de Execução (mostrando capturas de tela ao vivo, feeds de atividade semântica e linhas do tempo de etapas) e uma Linha do Tempo de Execução (visualizando o histórico de execução e revisões de ramificação de planos).
• Serviço de Planejador: Sintetiza e revisa planos estruturados. Ele trata os planos como um estado persistente ($P_t = (C_t, U_t)$), onde $C_t$ representa o histórico executado imutável e $U_t$ é o sufixo editável de etapas pendentes. O planejador garante que os reparos operem apenas no sufixo restante, preservando a proveniência.
• Serviço de Executor: Traduz etapas de planos estruturados em interações concretas de GUI (mouse, teclado, observação). Mantém uma separação estrita entre raciocínio e atuação, reportando o estado de execução de volta para a interface.

2.2 Replanejamento Inteligente (IR)

Um mecanismo central no Plover é o Replanejamento Inteligente, um processo visível de adaptação de plano que revisa as etapas pendentes enquanto preserva o histórico executado. O IR opera em dois modos:

1. IR Dirigido pelo Usuário: Acionado por intervenções do usuário. Os usuários podem fornecer:
   • Orientação por Linguagem Natural: Correções de intenção de alto nível (ex: "selecione a segunda opção").
   • Anotação Multimodal: Marcação baseada em captura de tela (traços, formas, texto) para resolver ambiguidades espaciais. Isso ancora o reparo a regiões de pixels específicas, restringindo o escopo da atualização.
   • Edições de Plano: Modificação direta da sequência de etapas no artefato de plano editável.
2. IR Dirigido pelo Sistema: Acionado pela detecção de não-progresso pelo sistema. O sistema combina Detecção de Loop Comportamental (ações semânticas repetidas) e Verificação de Não-Progresso Visual (hashing perceptual de capturas de tela) para identificar quando um agente está travado. Ao detectar, o sistema interrompe a execução e propõe uma etapa de recuperação localizada para aprovação do usuário.

2.3 Objetivos de Design

O sistema é guiado por cinco objetivos de design derivados de um estudo formativo com seis participantes:

• DG1 Planos Interpretáveis: Planos devem ser inspecionáveis e revisáveis com versionamento claro.
• DG2 Consciência de Execução: O sistema deve comunicar progresso, falha e transições de estado claramente.
• DG3 Reparo Local Fundamentado: As intervenções devem ser precisas e visualmente fundamentadas, restringindo as atualizações aos segmentos de plano relevantes.
• DG4 Recuperação Ciente de Falhas: O sistema deve identificar o não-progresso e propor um replanejamento explícito em vez de adaptação silenciosa.
• DG5 Continuidade através do Reparo: As intervenções devem preservar o histórico executado e manter a continuidade da tarefa.

3. Avaliação

Os autores avaliaram o Plover através de três análises complementares:

3.1 Análise de Reparo de Casos de Falha de Benchmark

• Configuração: 38 tarefas do benchmark OSWorld-Verified (previamente relatadas como falhas para agentes autônomos) foram reexecutadas em um ambiente de iniciativa mista.
• Método: Um especialista forneceu intervenções direcionadas (Linguagem Natural, Anotação Multimodal, Edições de Plano) quando o Plover detectou desvio ou quando o agente falhou.
• Resultados:
  • Dos 26 casos de não-sucesso autônomos, 23 foram melhorados através de interação de iniciativa mista.
  • 17 tornaram-se sucessos completos, e 6 tornaram-se sucessos parciais.
  • Apenas 3 casos permaneceram como falhas (todos erros compostos onde o desvio se propagou através de etapas dependentes).
  • A recuperação exigiu uma média de 2,04 intervenções por tarefa.
  • Todos os 10 sucessos parciais autônomos foram convertidos em sucessos completos.
  • As taxas de recuperação foram mais altas em tarefas de navegador (100%) e menores em fluxos de trabalho de múltiplas aplicações (80%).

3.2 Análise de Estabilidade Baseada em Cenários

• Configuração: A execução autônoma foi testada em 25 trajetórias diversas através de ambientes de navegador e desktop (LibreOffice) sem intervenção humana.
• Métricas: Fidelidade visual (SSIM, MSE, dHash) e Alinhamento de Plano (Cobertura, Ordem, Redundância, Capacidade de Ação).
• Resultados:
  • Fidelidade Visual: Fluxos de trabalho de navegador mostraram alta estabilidade (SSSS > 0,98), enquanto fluxos de trabalho de desktop mostraram variação significativa (SSIM 0,61–0,69), indicando maior sensibilidade a diferenças de estado intermediário.
  • Alinhamento de Plano: Embora a capacidade de ação tenha permanecido alta (0,97), a cobertura (0,62) e o alinhamento de ordem (0,41) foram moderados. Isso indica que, embora os agentes consigam executar etapas individuais, eles frequentemente lutam com o alinhamento global do fluxo de trabalho, criando oportunidades para intervenção do usuário antes que o desvio se torne terminal.

3.3 Caracterização de Falhas Reparáveis

• Descobertas: A reparabilidade está fortemente ligada à localidade da falha.
  • Falhas Localizadas: Desvio de execução, erros de percepção e interpretações errôneas de estado foram amplamente recuperáveis através de intervenções direcionadas.
  • Falhas Compostas: Quando os erros se propagaram através de etapas dependentes (46% dos casos, sendo 1/3 falhas compostas), a recuperação tornou-se significativamente mais difícil. Nesses casos, a divergência acumulada era grande demais para que edições localizadas restaurassem o alinhamento estrutural.
  • Tipos de Intervenção: A Orientação por Linguagem Natural foi o canal de recuperação mais frequente, seguida pelo IR Dirigido pelo Sistema e Anotação Multimodal.

4. Principais Contribuições

O artigo reivindica as seguintes contribuições:

1. Um Design de Interação Centrado no Plano: Um framework que externaliza planos de tarefas como artefatos persistentes, inspecionáveis e revisáveis, permitindo supervisão explícita, reparo localizado e replanejamento visível.
2. O Sistema Plover: Uma implementação apresentando artefatos de plano editáveis, Replanejamento Inteligente explícito e intervenções multimodais que suportam a correção direcionada enquanto preservam o histórico de execução.
3. Caracterização Empírica da Recuperabilidade: Evidência mostrando que muitas falhas de agentes de GUI são estruturalmente reparáveis quando os planos são expostos. O estudo identifica modos de falha específicos (ex: ambiguidade espacial, desvio de execução) que são suscetíveis ao reparo localizado versus aqueles (erros compostos) que exigem intervenção precoce.

5. Significância e Alegações

O artigo postula que muitas falhas de agentes de GUI autônomos não são erros terminais, mas quebras estruturalmente reparáveis que se tornam recuperáveis quando os planos são visíveis e as intervenções são localizadas.

• Mudança de Paradigma: O trabalho defende uma mudança de "delegação de etapa única" para "alinhamento contínuo", onde a automação é vista como um processo colaborativo e reparável, em vez de uma caixa preta totalmente autônoma.
• Redução da Carga de Supervisão: Ao tornar explícitos o intento intermediário e o estado de execução, o Plover reduz a carga cognitiva dos usuários, permitindo que foquem no segmento específico do fluxo de trabalho que desviou, em vez de reconstruir todo o estado da tarefa.
• Transparência e Controle: O sistema demonstra que expor o plano transforma o replanejamento de um mecanismo de recuperação oculto em um processo de interação auditável, tornando a automação de GUI mais transparente, controlável e adaptável.

Os autores notam modestamente que, embora a interação centrada no plano seja altamente eficaz para tarefas de longo horizonte e propensas a desvios, ela pode introduzir sobrecarga para fluxos de trabalho curtos e rotineiros. Além disso, a abordagem assume que os usuários possuem conhecimento suficiente para corrigir o agente; trabalhos futuros são necessários para abordar cenários onde a própria estrutura da tarefa é incerta.