Resumo Técnico: Módulos de Habilidades e Memória Online Sempre Valem Seus Tokens?

Declaração do Problema

Agentes web online frequentemente aumentam um modelo "ator" base com módulos para memória, indução de fluxo de trabalho ou síntese de habilidades (ex: Memória de Fluxo de Trabalho de Agente, Indução de Habilidade de Agente, ReasoningBank). Embora esses módulos visem melhorar o sucesso da tarefa através do reuso de conhecimento de trajetórias anteriores, eles incorrem em um custo significativo de tokens durante o tempo de teste. Esse custo raramente é relatado junto ao custo de inferência do ator, criando um "problema de alocação simples": tokens gastos para induzir, recuperar ou injetar conhecimento reutilizável são tokens indisponíveis para a execução direta da tarefa (observar, raciocinar, agir).

A questão central abordada é se, sob um orçamento total de inferência fixo, é mais eficaz alocar tokens para módulos de aumento online ou para um ator vanilla que utiliza o mesmo orçamento para passos de interação adicionais. Isso é particularmente relevante à medida que os modelos de fronteira (ex: Gemini 3, GPT-5.4) melhoraram no raciocínio de múltiplos passos, potencialmente reduzindo a necessidade de andaimes (scaffolding) externos.

Metodologia

O estudo conduz uma avaliação com orçamento restrito em três domínios WebArena (Shopping, Reddit, Admin) e um domínio WorkArena-L1 (trabalho de conhecimento empresarial).

Sistemas Comparados

Os autores comparam três métodos de aumento online contra um baseline vanilla com orçamento correspondente:

1. AWM (Agent Workflow Memory): Induz fluxos de trabalho em linguagem natural a partir de trajetórias bem-sucedidas.
2. ASI (Agent Skill Induction): Sintetiza e reutiliza funções de habilidade Python executáveis.
3. ReasoningBank: Destila estratégias de raciocínio de sucessos e falhas em um banco de memória.
4. Vanilla-IB (Vanilla-Increased-Budget): Um ator vanilla sem módulos auxiliares. Para garantir uma comparação de orçamento justa, seu horizonte de interação é estendido de 10 passos padrão para 15 passos. Ele também emprega um mecanismo de poda da árvore de acessibilidade baseado em regras para reduzir o comprimento do contexto sem chamadas de LLM.

Configuração Experimental

• Modelos: Gemini 3 Flash, GPT-5.4-mini e Qwen 3.6-27B.
• Contabilidade de Orçamento: O uso total de tokens é agregado através de todos os componentes do sistema (ator + módulos auxiliares).
• Rigor de Avaliação: Ao contrário de trabalhos anteriores que frequentemente relatam métricas de execução única, este estudo relata resultados de três execuções independentes para capturar a variância de execução para execução. As métricas incluem taxa de sucesso agregada (SR), total de tokens por tarefa e limites de estabilidade por tarefa (Any-of-3 e All-of-3).
• Domínios: WebArena (Shopping, Reddit, Admin) e WorkArena-L1 (tarefas de ServiceNow).

Resultados Principais

1. Superioridade do Baseline Vanilla no Desempenho Agregado

Em todos os três domínios WebArena e em todos os três modelos, o baseline Vanilla-IB consistentemente igualou ou superou a taxa de sucesso agregada dos métodos aumentados (AWM, ASI, ReasoningBank).

• Eficiência de Tokens: O Vanilla-IB frequentemente alcançou esses resultados usando menos tokens totais do que os métodos aumentados.
• Dependência do Modelo: A lacuna de desempenho foi mais pronunciada com o GPT-5.4-mini, sugerindo que modelos mais fracos podem gerar fluxos de trabalho ou habilidades ruidosas que degradam o desempenho. Mesmo com modelos mais fortes, os métodos aumentados não conseguiram superar o ator vanilla com orçamento correspondente.
• WorkArena-L1: A tendência se manteve em ambientes empresariais, onde o Vanilla-IB permaneceu competitivo com os melhores métodos aumentados enquanto usava menos tokens.

2. A Ilusão do "Assimetria de Orçamento"

O estudo revela que ganhos aparentes de aumento frequentemente derivam de assimetria de orçamento. Por exemplo, no domínio Reddit com Gemini 3 Flash, AWM e Vanilla-IB tiveram taxas de sucesso idênticas em 10 passos. No entanto, o AWM consumiu significativamente mais tokens. Quando o horizonte do Vanilla-IB foi estendido (até 25 passos), ele superou o AWM em taxa de sucesso, mantendo o uso de menos tokens do que a configuração de 10 passos do AWM. Isso indica que o "benefício" do módulo foi amplamente um artefato do método aumentado possuir um orçamento de tokens maior, não uma vantagem arquitetônica superior.

3. Fontes de Overhead de Tokens

A análise de decomposição de tokens (Tabela 3) identifica duas fontes de overhead para métodos aumentados:

1. Custos Explícitos do Módulo: Tokens consumidos por chamadas de indução, recuperação e verificação.
2. Inflação de Contexto Implícita: Fluxos de trabalho, memórias ou habilidades recuperados são injetados no prompt do ator a cada passo, aumentando o tamanho do prompt e, consequentemente, o custo de cada chamada subsequente do ator.

4. Variância de Execução para Execução e Estabilidade

Descobriu-se que as taxas de sucesso de execução única são instáveis. O estudo relata métricas Any-of-3 (sucesso em pelo menos uma execução) e All-of-3 (sucesso em todas as três execuções). As lacunas entre esses limites foram significativas, indicando que avaliações de execução única escondem ruído substancial ao nível da tarefa. Essa variância é exacerbada por fatores ambientais (timeouts, carregamento de páginas) e pela natureza estocástica da amostragem de LLM.

5. Fragilidade Estrutural do Aumento

• Habilidades Programáticas (ASI): Habilidades sintetizadas dependem de IDs de árvore de acessibilidade dinâmicos (BIDs). Se o estado da página mudar (ex: recarregamento), esses IDs tornam-se inválidos, causando falhas silenciosas ou erros. Agentes vanilla, que consultam o LLM a cada passo, adaptam-se naturalmente às mudanças de estado.
• Confundimento de Verificação: No ASI, funções são frequentemente armazenadas mesmo se falharem inicialmente, mas o agente se recupera via ações primitivas, levando a uma biblioteca de habilidades "quebradas".
• Contaminação: AWM e ReasoningBank frequentemente induzem conhecimento de trajetórias falhas porque o "juiz" (avaliador) vê apenas o resultado final, não os passos intermediários. Isso leva à injeção de estratégias incorretas no contexto do agente.

Significância e Alegações

O artigo defende uma mudança na higiene de avaliação para agentes web online:

1. Relato de Custo Total: Comparações devem relatar o uso total de tokens em todos os módulos, não apenas o ator.
2. Baselines com Orçamento Correspondente: Métodos aumentados devem ser comparados contra atores vanilla que utilizam o mesmo orçamento total de inferência (ex: via horizontes estendidos) em vez de contagens de passos fixas.
3. Relato de Múltiplas Execuções: Avaliações devem relatar a variância de múltiplas execuções (ex: Any-of-3/All-of-3) como um critério central, pois métricas de execução única são insuficientes para capturar a confiabilidade de agentes online.

Os autores concluem que, embora as habilidades e a memória de fluxo de trabalho possam oferecer ganhos em domínios altamente repetitivos, seus benefícios aparentes muitas vezes desaparecem quando o overhead é contabilizado contra um ator com orçamento correspondente. A rápida melhoria dos modelos base sugere que o andaime externo pode não ser mais necessário para muitas tarefas, e que "mais passos de interação" é frequentemente um uso mais eficiente de tokens do que "andaimes mais complexos".

Limitações

Os autores reconhecem que suas conclusões são restritas aos domínios específicos (Shopping, Reddit, Admin) e modelos testados. Eles observam que ambientes com distribuições de tarefas altamente homogêneas ou APIs de alto nível estáveis (onde a descoberta de habilidades offline é amortizada) podem apresentar diferentes trade-offs favorecendo o aumento. Além disso, o ajuste de orçamento é uma aproximação baseada em contagens de passos, já que o ajuste exato de tokens é difícil em ambientes web dinâmicos.