Resumo Técnico: Agentes Web Devem Adotar o Paradigma Planejar-Depois-Executar

Declaração do Problema

O artigo argumenta que a arquitetura padrão atual para agentes web de Modelos de Linguagem de Grande Escala (LLM), ReAct (Raciocínio-e-Ação), é fundamentalmente insegura e ineficiente para ambientes web.

A Vulnerabilidade Central:
Em um loop ReAct, o agente observa o ambiente (a página web), consulta o LLM para a próxima ação e a executa. O conteúdo web é inerentemente uma mistura de elementos de interface confiáveis e dados não confiáveis de terceiros (por exemplo, avaliações de usuários, anúncios, postagens em fóruns, conteúdo patrocinado). Como o loop ReAct intercala observação e seleção de ação, o conteúdo não confiável é apresentado ao modelo exatamente quando ele decide a próxima etapa do fluxo de controle. Isso cria um caminho direto para ataques de injeção de prompt indireta, onde um atacante pode manipular o fluxo de controle do agente (por exemplo, sequestrar o agente para realizar ações não autorizadas como exfiltração de dados ou transferências financeiras) em vez de meramente influenciar valores de dados.

Questões Secundárias:

• Ineficiência: Agentes ReAct são "de visão curta", replanejando a cada etapa com base no estado atual. Isso leva a alto uso de tokens, latência e custo, pois o agente redescobre repetidamente fluxos de trabalho que frequentemente são estáticos e repetíveis.
• Reprodutibilidade: A natureza dinâmica do ReAct torna difícil depurar e verificar o comportamento do agente, pois o fluxo de controle é determinado por observações em tempo de execução em vez de um plano fixo.

Metodologia: Planejar-Depois-Executar (PTE)

Os autores propõem Planejar-Depois-Executar (PTE) como uma arquitetura alternativa segura. No PTE, o agente compromete-se com um programa específico da tarefa antes de observar o conteúdo web em tempo de execução.

Componentes Arquiteturais Chave:

1. Interface de API Confiável: Em vez de interagir com elementos DOM brutos ou capturas de tela, o agente interage com uma API confiável (fornecida pelo site ou construída como um SDK do lado do cliente). Esta API expõe funções tipadas (por exemplo, pesquisar(consulta), adicionar_ao_carrinho(sku)) com esquemas de entrada/saída conhecidos.
2. Fase de Planejamento: O planejador LLM gera um programa determinístico (o plano) com base no objetivo do usuário e nas definições da API confiável. Crucialmente, o planejador não recebe conteúdo web em tempo de execução. O grafo de fluxo de controle é fixo nesta etapa.
3. Fase de Execução: Um executor executa o programa pré-comprometido. O conteúdo web em tempo de execução é usado apenas para preencher parâmetros, determinar resultados de ramificação ou influenciar valores de dados dentro do grafo de execução predefinido.
4. Sub-rotinas LLM: Para manter a utilidade, o framework permite o uso de sub-rotinas LLM para processamento local de dados (por exemplo, extração, classificação, sumarização) dentro do plano fixo. No entanto, essas sub-rotinas são estritamente restritas: elas não podem gerar novo código, selecionar novas ferramentas ou alterar o fluxo de controle. Suas saídas são tipadas e tratadas como dados, não como instruções.

Garantia de Segurança:
O PTE impõe uma separação estrita entre fluxo de controle (determinado durante o planejamento) e fluxo de dados (determinado durante a execução). Conteúdo web não confiável pode influenciar valores (por exemplo, qual produto é selecionado com base em uma avaliação), mas não pode redefinir a tarefa ou fazer com que o modelo sintetize novas ações em tempo de execução. Isso previne o sequestro do fluxo de controle.

Contribuições Chave

1. Crítica Arquitetural do ReAct: O artigo identifica que a intercalação de observação e seleção de ação no ReAct é uma falha arquitetônica para agentes web, tornando-os inerentemente vulneráveis à injeção de prompt.
2. Proposta de PTE para Agentes Web: Os autores introduzem uma mudança de paradigma onde agentes escrevem programas sobre APIs de sites tipadas antes da execução, isolando o planejamento de conteúdo não confiável.
3. Taxonomia de Tarefas e Análise Empírica:
   • Os autores categorizam tarefas web em três tipos: Seguras (código estático), Seguras com Influência (requer sub-rotinas LLM para processamento de dados) e Replanejamento-Necessário (requer planejamento dinâmico orientado a dados).
   • Eles analisam o benchmark WebArena (860 tarefas em 6 sites simulados).
   • Resultado: 100% das tarefas do WebArena são compatíveis com PTE. Especificamente, 81,28% podem ser concluídas com planos puramente programáticos (sem sub-rotinas LLM em tempo de execução), e os 18,72% restantes requerem sub-rotinas LLM para processamento de dados, mas permanecem seguros contra sequestro de fluxo de controle. Nenhuma das tarefas exigiu replanejamento dinâmico.
4. Identificação de Lacunas de Infraestrutura: O artigo destaca que a principal barreira à adoção do PTE não é a capacidade de modelagem, mas a infraestrutura. As interfaces web atuais (cliques, rolagens) não são semanticamente tipadas. Os autores argumentam pelo desenvolvimento de:
   • APIs de sites tipadas, completas e auditáveis (ou SDKs do lado do cliente).
   • Mecanismos de descoberta de API para ajudar planejadores a encontrar endpoints relevantes.
   • Estratégias robustas de tratamento de erros para planos estáticos (por exemplo, lógica de retry explícita).

Resultados e Descobertas

• Segurança: O PTE elimina a terceira categoria de ameaça em seu modelo (sequestro de fluxo de controle) por design. Embora tarefas "Seguras com Influência" permaneçam vulneráveis à manipulação de resultados (por exemplo, uma avaliação adversária alterando uma seleção de produto), o dano é limitado; o atacante não pode redirecionar o agente para realizar ações não relacionadas e destrutivas.
• Aplicabilidade: A análise do WebArena demonstra que a vasta maioria das tarefas web comuns (compras, postagens em fóruns, rastreamento de problemas) possui fluxos de controle estáticos que podem ser determinados apenas a partir do prompt do usuário, tornando-as candidatas ideais para PTE.
• Eficiência: Ao planejar uma vez e executar um programa fixo, o PTE reduz o consumo de tokens e a latência em comparação com o loop iterativo ReAct. Também permite o armazenamento em cache de planos para consultas comuns.

Significado e Alegações

O artigo afirma que tarefas web não precisam de reatividade por padrão; elas precisam de APIs de sites tipadas, completas e auditáveis.

• Mudança de Responsabilidade: Os autores argumentam que o problema de segurança não é um "problema de modelagem" (ou seja, treinar modelos para serem mais robustos), mas um "problema de infraestrutura". A web atual carece das interfaces necessárias para execução segura de agentes.
• Agenda de Pesquisa: O artigo delineia uma agenda de pesquisa focada em construir a infraestrutura necessária:
  1. Interfaces: Padronizar APIs web amigáveis a agentes e automatizar a geração de SDKs do lado do cliente.
  2. Design de Planejador: Criar agentes que geram programas expressivos e específicos da tarefa usando essas APIs confiáveis.
  3. Verificação: Verificar estaticamente programas gerados contra políticas de segurança e restringir sub-rotinas LLM via verificação de tipos.
  4. Avaliação: Desenvolver benchmarks que meçam conjuntamente segurança, utilidade e eficiência.

Os autores concluem que, embora o ReAct possa ainda ser superior para sites altamente dinâmicos, tarefas com exploração intensiva ou fluxos de trabalho que abrangem sites não pré-processados, o Planejar-Depois-Executar deve ser a arquitetura padrão para agentes web para garantir segurança e eficiência.