Resumo Técnico: EvoClawBench

Declaração do Problema

Benchmarks existentes para agentes de Grandes Modelos de Linguagem (LLMs) avaliam primariamente a conclusão de tarefas, o uso de ferramentas ou a utilidade de habilidades pré-curadas. No entanto, eles falham em isolar uma questão específica de aprendizado de ciclo fechado: Pode um agente, em tempo de execução, converter evidências de suas próprias execuções concluídas em habilidades reutilizáveis que melhorem execuções inéditas, após contabilizar todo o overhead de tokens, custo e tempo de autoria e sumarização?

As avaliações atuais não distinguem entre a capacidade de um agente de resolver uma tarefa diretamente e sua capacidade de destilar memória procedural de uma tentativa anterior de resolver uma tarefa semelhante posteriormente. Essa lacuna deixa o "ciclo de vida da habilidade" — autoria, destilação do próprio run, reuso e verificação de mutação — subespecificado.

Metodologia: EvoClawBench

Para abordar isso, os autores introduzem o EvoClawBench, um benchmark projetado para avaliar o ciclo de vida completo da memória procedural. O benchmark consiste em 100 tarefas compreendendo 502 subproblemas em diversos domínios (codificação, dados, escritório, segurança, operações e fluxos de trabalho de documentos de domínio). Cada tarefa contém subproblemas estruturalmente relacionados e repetidos para criar oportunidades de reconhecimento de padrões e codificação de procedimentos reutilizáveis.

Protocolo de Avaliação

O benchmark compara três estratégias de execução distintas para a mesma tarefa, modelo e tempo de execução:

1. BASELINE (LINHAGEM): O agente resolve a tarefa diretamente sem criar ou editar quaisquer habilidades. Isso mede a capacidade bruta de resolução de tarefas.
2. PRESKILL (PRÉ-HABILIDADE): O agente entra primeiro em uma fase de autoria de habilidade para criar habilidades específicas da tarefa com base no prompt. Ele então executa a tarefa em um workspace novo usando apenas as habilidades geradas. Isso testa se um agente consegue inferir um procedimento útil antes de resolver a tarefa.
3. POSTSKILL (PÓS-HABILIDADE): O agente primeiro resolve a tarefa sem habilidades. O sistema então fornece um contexto compacto contendo o prompt da primeira execução, resumo da graduação, prévias de saída e transcrição. O agente sumariza habilidades reutilizáveis a partir dessa evidência, que são então injetadas em uma segunda execução inédita. Isso testa diretamente a questão central: destilar memória procedural de uma execução concluída.

Restrições Técnicas e Métricas

• Isolamento: Cada execução ocorre em um workspace isolado para evitar vazamento de estado.
• Verificações de Mutação: O benchmark realiza o hash dos arquivos de habilidade antes e depois da execução. Se uma execução de reuso modificar, adicionar ou deletar uma habilidade, ela é sinalizada como uma skill_mutation_violation (violação de mutação de habilidade), garantindo que a condição experimental (reuso de uma habilidade fixa) seja mantida.
• Graduação: As tarefas utilizam graduadores automatizados ou híbridos (automatizado + LLM) que inspecionam artefatos concretos (JSON, scripts, relatórios) em vez de respostas em linguagem natural.
• Métricas: O benchmark reporta tanto pontuações de execução exclusiva (taxa de sucesso da tarefa) quanto métricas de ponta a ponta (uso de tokens, custo e tempo). O ganho de eficiência é calculado como a razão entre o uso de recursos da baseline e o uso do candidato.

Principais Contribuições

1. Construção de Benchmark: O EvoClawBench fornece uma suíte padronizada para avaliar se agentes podem aprender habilidades reutilizáveis a partir de fluxos de trabalho autorreferenciais controlados e evidências de seus próprios runs. Ele suporta múltiplos runtimes (atualmente OpenClaw e nanobot) e inclui fixtures, graduadores e scripts.
2. Protocolo de Três Modos: A formalização das condições BASELINE, PRESKILL e POSTSKILL separa o desempenho de execução exclusiva do overhead do fluxo de trabalho completo, permitindo a detecção de violações de mutação de habilidade.
3. Achados Empíricos: O artigo fornece resultados cross-runtime demonstrando que os benefícios de habilidades autor-elaboradas não são automáticos nem monotônicos.
4. Artefato Aberto: As tarefas do benchmark, fixtures, graduadores e exportações de resultados são liberados publicamente.

Resultados

Experimentos conduzidos com os runtimes OpenClaw e nanobot através de cinco modelos (GPT-5.4, Qwen3.6-Plus, DeepSeek-V4-Pro, MiniMax-M2.7, GPT-5.4 mini) produziram os seguintes achados:

• O Scaffolding do Runtime é Crítico: O desempenho é fortemente dependente do runtime do agente. Sob o OpenClaw, as pontuações de BASELINE permaneceram abaixo de 20% para todos os modelos. Sob o nanobot, as pontuações de BASELINE variaram de 56,45% a 96,13%. Isso indica que o wrapping de prompt específico do runtime e a invocação de ferramentas impactam significamente a capacidade baseline.
• Efeitos de Habilidade Não Monotônicos: Habilidades autor-elaboradas não garantem ganhos de desempenho.
  • nanobot GPT-5.4 permaneceu estável acima de 96% em todos os modos.
  • nanobot MiniMax-M2.7 melhorou de 90,97% (BASELINE) para 94,50% (POSTSKILL).
  • nanobot DeepSeek-V4-Pro sofreu regressão catastrófica, caindo de 77,77% (BASELINE) para 4,80% (PRESKILL) e 0,99% (POSTSKILL).
  • OpenClaw mostrou resultados similarmente mistos, com algumas execuções de habilidade próximas à baseline e outras colapsando.
• Sensibilidade ao Custo: Mesmo quando a qualidade da execução exclusiva é preservada, os fluxos de trabalho de habilidade incorrem em um overhead substancial. As razões de eficiência de tokens de ponta a ponta foram consistentemente abaixo de 1.0 (ex: 0,38 para PRESKILL e 0,30 para POSTSKILL no Qwen3.6-Plus), o que significa que os fluxos de trabalho completos usam significativamente mais tokens do que a execução direta.
• Contagem de Habilidades vs. Qualidade: O número de habilidades criadas não prediz ganhos. Altas contagens de habilidades correlacionaram-se tanto com melhorias quanto com regressões. O artigo sugere que a qualidade e o ajuste da habilidade gerada (especificamente, evitar o overfitting ao contexto da primeira execução) são mais críticos do que a quantidade.
• Riscos de Overfitting: A análise qualitativa (Figura 4) indica que os resumos de POSTSKILL podem codificar suposições excessivamente específicas da primeira execução (ex: nomes de arquivos específicos ou padrões de fixture) que interferem na segunda execução em um contexto novo.

Significância e Alegações

O artigo alega modestamente que aprender habilidades reutilizáveis a partir dos próprios runs de um agente é seletivo e sensível ao custo, em vez de um benefício automático.

• Não é uma Solução Universal: Adicionar autoria de habilidades a um loop de agente não melhora inerentemente o desempenho. Os resultados indicam que, para muitas combinações de modelo-runtime, o overhead de autoria e sumarização de habilidades supera os benefícios, ou as habilidades geradas degradam o desempenho por overfitting.
• Foco no Ciclo de Vida: O benchmark desloca o foco da avaliação de "o agente consegue resolver a tarefa?" para "o agente consegue gerenciar o ciclo de vida da memória procedural (autoria, destilação, reuso e validação) de forma eficaz?".
• Direções Futuras: Os autores sugerem que sistemas de habilidade futuros devem empregar políticas de criação seletiva e validação antes do reuso. Eles também enfatizam que os relatórios de benchmark devem incluir proveniência, verificações de mutação e custos de recursos de ponta a end-to-end para fornecer uma avaliação realista da utilidade da habilidade.

O artigo conclui que, embora a memória procedural seja uma direção prática para especializar agentes, os agentes atuais ainda não são confiáveis em todo este ciclo de vida, e o trade-off entre custo e qualidade deve ser explicitamente gerenciado.