Resumo Técnico: StructAgent

Declaração do Problema

Avanços recentes em Grandes Modelos de Linguagem (LLMs) e Modelos de Linguagem-Visão (VLMs) permitiram que agentes digitais realizem tarefas de uso de computador. No entanto, tarefas do mundo real são frequentemente de longo horizonte, envolvendo fluxos de trabalho complexos com contextos em evolução. À medida que os agentes executam essas tarefas, eles acumulam um histórico de interação bruto contendo informações factuais, edições intermediárias, tentativas falhas e execuções parcialmente concluídas.

O desafio central identificado é que os agentes existentes operam tipicamente sobre esse histórico bruto e não estruturado. Conforme o contexto cresce, informações críticas tornam-se ocultas e o estado atual da tarefa torna-se ambíguo. Essa falta de estrutura torna difícil para os agentes:

• Manter uma compreensão causal clara do progresso da tarefa.
• Detectar prontamente estados anormais ou erros intermediários.
• Realizar planejamento e execução precisos.
• Recuperar-se de falhas sem reproduzir todo o histórico.

Consequentemente, a execução confiável de longo horizonte é limitada porque os agentes têm dificuldade em distinguir o progresso válido de ruído ou de alegações de conclusão auto-relatadas, mas não verificadas.

Metodologia: StructAgent

Para enfrentar esses desafios, os autores propõem o StructAgent, um framework centrado no estado que estrutura explicitamente tanto o estado do agente quanto o fluxo de trabalho em torno de uma representação causal unificada do progresso da tarefa. O framework consiste em dois componentes complementares:

1. Estado Unificado do Agente

Em vez de inferir o progresso a partir de trajetórias brutas, o StructAgent mantém um estado $s_t$ compacto, tipado e auditável que serve como uma interface compartilhada para todos os módulos. O estado é definido como:
$$s_t = (s_t^{req}, s_t^{val}, s_t^{ver})$$

• $s_t^{req}$ (Requisitos): Armazena os requisitos do subobjetivo atual, especificando o que deve ser alcançado e o que o verificador deve checar.
• $s_t^{val}$ (Valores Úteis): Armazena valores persistentes e úteis descobertos durante a execução (ex: caminhos de arquivos, URLs, entidades selecionadas).
• $s_t^{ver}$ (Evidências Verificadas): Armazena evidências coletadas pelo verificador durante o processo de sondagem, permitindo auditoria e reutilização.

Transições Orientadas à Causalidade: As transições de estado são estritamente controladas. O status de um requisito ($\sigma_{i,t}$) só pode mudar para VERIFICADO ou INVALIDADO com base em uma decisão respaldada pelo verificador. Isso garante que as atualizações de progresso sejam fundamentadas em evidências verificáveis, em vez de apenas no auto-relato do agente.

2. Fluxo de Trabalho Estruturado

O framework opera em um loop de execução fixo: Planejador $\rightarrow$ Ator $\rightarrow$ Verificador $\rightarrow$ Atualização de Estado.

• Planejador (Planner): Lê o estado atual para selecionar o próximo subobjetivo ($g_t$). Ele não precisa reconstruir o progresso a partir do histórico bruto.
• Ator (Actor): Tenta executar o subobjetivo no ambiente, produzindo um traço de ação ($\tau_t$).
• Verificador (Verifier): Verifica se o subobjetivo tentado produziu progresso válido usando sondagem estruturada e agêntica (ex: checando arquivos, saídas de shell, estados de aplicação). Ele gera uma decisão ($d_t$) para verificar, invalidar ou deixar o estado inalterado.
• Memória (Memory): Fornece suporte condicionado ao estado, sugerindo subobjetivos ou padrões de ação baseados em experiências reutilizáveis.

Principais Capacidades Habilitadas

• Checkpoint de Progresso: O histórico de estado serve como um snapshot autocontido e legível por humanos, permitindo que os agentes retomem a execução sem reproduzir todo o histórico de interação.
• Recuperação de Falhas Direcionada: Quando o progresso estagna, o sistema diagnostica o problema usando evidências verificadas (ex: falta de evidência, requisitos conflitantes) e seleciona intervenções específicas (replanejamento, tentativa de repetição ou intervenção humana) em vez de tentativas genéricas.
• Execução Suportada por Ferramentas: Padrões recorrentes são resumidos em procedimentos reutilizáveis. O ator pode invocar essas ferramentas, mas os resultados só são confirmados no estado se forem verificados.

Contribuições Principais

1. Estado Unificado: Introdução de uma representação de estado compacta, tipada e auditável que fornece planejamento, atuação e verificação com uma visão compartilhada do progresso da tarefa.
2. Fluxo de Trabalho Estruturado: Design de um loop de planejamento-atuação-verificação onde apenas decisões respaldadas pelo verificador podem confirmar, preservar ou invalidar o progresso.
3. Validação Empírica Abrangente: Demonstração de que o framework melhora diversos backbones de LLM e VLM em tarefas de uso de computador de longo horizonte e generaliza através de domínios (desktop, web e Minecraft).

Resultados Experimentais

OSWorld-Verified (Desktop)

O framework foi avaliado no OSWorld-Verified, um benchmark para uso de computador de longo horizonte. O StructAgent melhorou consistentemente o desempenho em vários backbones:

• Qwen3.5-9B: Melhorou a taxa de sucesso de 27,0% (modelo único) para 46,9%.
• Qwen3.5-27B: Melhorou a taxa de sucesso de 31,6% para 62,2%.
• MiniMax-M3: Alcançou um novo estado da arte de código aberto de 78,9%, superando a linha de base de modelo único de 75,2%.
• Desempenho por Domínio: Os ganhos foram mais pronunciados em tarefas de "Escritório" (planilhas, documentos), onde estados intermediários duráveis e verificações baseadas em arquivos estão disponíveis. Tarefas cross-application permaneceram desafiadoras, mas viram melhorias com backbones mais fortes.

Generalização

• Web (Mind2Web): O StructAgent generalizou para ambientes web, alcançando 47,3% (Qwen3.5-9B) e 52,3% (Qwen3.5-27B), superando as linhas de base reproduzidas. Os ganhos foram mais fortes em tarefas de busca de informação, onde o progresso pode ser rastreado via URLs e estados de página.
• Minecraft: O framework foi instanciado no Minecraft substituindo as fontes de evidência de desktop por verificação baseada em inventário. Alcançou uma taxa média de sucesso ponderada por tarefa de 76% (contra 59% do Optimus-1), demonstrando que a disciplina de atualização de estado é agnóstica ao domínio.

Análise

• Qualidade da Verificação: A verificação estruturada melhorou o recall de 0,67 para 0,81 em comparação com a verificação puramente visual, principalmente ao recuperar conclusões verdadeiras que eram invisíveis em screenshots finais (ex: existência de arquivos, saídas de comando).
• Modos de Falha: A análise das trajetórias falhas revelou que os erros estão distribuídos entre o Planejador (30%), o Verificador (30%) e o Ator (33%), indicando que a confiabilidade de longo horizonte requer melhorias em todo o sistema, e não apenas o escalonamento do ator.

Significância e Alegações

O artigo argumenta que o propósito da abstração é criar um nível semântico onde se possa ser "absolutamente preciso" (citando Edsger W. Dijkstra). O StructAgent alcança isso ao se afastar da geração contínua sobre históricos ruidosos em direção a uma estrutura causal explícita.

Os autores afirmam que:

1. Transparência e Controle: Ao impor transições de estado respaldadas pelo verificador, o progresso do agente torna-se transparente, auditável e controlável.
2. Robustez: O framework permite recuperação de falhas direcionada e conclusão de tarefas baseada em evidências, reduzendo a dependência de alegações frágeis de "CONCLUÍDO" auto-relatadas.
3. Generalidade: O paradigma centrado no estado não está preso a escalas de modelos específicas ou ambientes de desktop; ele se generaliza efetivamente para navegadores web e ambientes de jogos (Minecraft) ao adaptar a fonte de evidência enquanto mantém o mesmo fluxo de trabalho estrutural.

O trabalho posiciona-se como uma solução de nível de sistema para a confiabilidade de longo horizonte, sugerindo que estruturar o próprio progresso da tarefa é tão crítico quanto melhorar os modelos de linguagem subjacentes.