LongWoF-Bench: Avaliando a evolução da orientação procedimental para tarefas verificáveis ​​de longo fluxo de trabalho

Capítulo 1: Introdução

À medida que grandes modelos melhoram a modelagem de contexto longo, o uso de ferramentas e a execução de código, seus aplicativos estão se expandindo de respostas isoladas a perguntas para cenários complexos que exigem uma sequência de operações. Em uma tarefa Markdown-to-Repository, por exemplo, um modelo deve ler um documento de requisitos e uma base de código existente, produzir um plano de implementação e uma lista de tarefas, modificar o código e executar testes para validar o resultado. Em uma tarefa orientada por regras, o modelo deve manter o estado intermediário, realizar o raciocínio em várias etapas e, por fim, retornar um resultado válido que satisfaça todas as restrições.

Chamamos essas tarefas de tarefas de longo fluxo de trabalho de ponta a ponta. Formalmente, dada uma entrada inicial $(x)$, um ambiente acionável $(E_0)$, um conjunto de restrições $(C)$ e um verificador $(V)$, o modelo deve gerar uma sequência de ações interdependentes $a_1,a_2,\ldots,a_T$. Essas ações impulsionam transições de estado $E_t=f(E_{t-1},a_t)$ e, em última análise, produzem um resultado $(y)$. Uma tarefa é um longo fluxo de trabalho de ponta a ponta quando as ações posteriores dependem do estado ou de artefatos intermediários criados por ações anteriores e o sucesso é determinado uniformemente pela condição terminal verificável $V(x,E_T,y,C)=1$. Aqui, “fluxo de trabalho longo” refere-se à dependência entre estágios e ao estado em constante evolução, não apenas ao comprimento da entrada, ao comprimento da saída ou ao tempo de execução.

Sob restrições de saída explícitas, o modelo deve transformar múltiplos julgamentos ou operações dependentes num produto final que um programa ou regra possa verificar com precisão. Um “fluxo de trabalho” nem sempre significa chamadas de ferramentas externas. Em tarefas de código e agente, pode incluir a leitura de arquivos de entrada, a obediência a um contrato CLI, a produção de artefatos JSON/TXT especificados e a aprovação em testes ocultos. Em tarefas matemáticas e de regras, pode envolver a seleção de uma fórmula, o tratamento de limites, a aplicação de prioridade de regra e a normalização do formato da resposta. Em todos os casos, o sucesso depende tanto da compreensão da tarefa como da implementação correta de uma série de restrições num resultado verificável.

Para estudar essa capacidade, usamos tarefas de programação do SkillsBench (Li et al., 2026) e o enquadramento de recuperação de regras do GuideBench (Diao et al., 2025). A partir deles, identificamos tipos comuns de fluxos de trabalho longos e dificuldades criadas pela combinação de restrições, e apresentamos o LongWoF-Bench. Suas 778 tarefas verificadas cobrem geração de código (code_generation), raciocínio matemático (math_reasoning), cumprimento de regras (rule_following) e orquestração de agentes (agent_env_synth). Código exige geração de programas e testes ocultos; matemática, respostas curtas exatas e normalização; regras, prioridades e decisões discretas; e ambientes de agentes, interfaces de pacotes, vários arquivos de saída e verificação no estilo pytest. Um manifesto comum, avaliadores ocultos e um protocolo rigoroso permitem comparar todas as tarefas na mesma estrutura de conclusão de fluxos de trabalho.

O benchmark aborda três questões de pesquisa:

• RQ1: Quão confiáveis ​​são os modelos atuais em tarefas de longo fluxo de trabalho verificáveis ​​por máquina e cruzadas?
• RQ2: Como os prompts auxiliares, como Skill e Gene, afetam a taxa de aprovação de tarefas e o consumo de tokens?
• RQ3: Quais tipos de tarefas, tipos de modelos e fonte de construção de Gene se beneficiam mais da orientação procedimental?

Estas questões examinam a capacidade de um modelo para completar tarefas de forma independente, utilizar conhecimentos processuais e equilibrar a aplicabilidade e o custo de diferentes métodos de assistência.

Para respondê-las, avaliamos vários modelos nas mesmas tarefas, ambientes de execução e avaliadores ocultos sob três condições: nenhum contexto auxiliar (no_context), um manual de tarefas predefinido (Skill) e um prompt de procedimento derivado da experiência, Gene (Wang et al., 2026). A Skill descreve o fluxo de trabalho, o uso da interface, o procedimento de execução de regras e as armadilhas comuns. Gene usa campos estruturados para representar o padrão de tarefa, sinais de aplicabilidade, estratégia de execução, verificações de comprovação e restrições críticas. Os Genes são construídos a partir de trajetórias de modelos que passaram na verificação ou, quando não existe uma trajetória bem-sucedida, a partir de sinais de professores fornecidos por uma solução de referência. Todos os ativos auxiliares passam por auditoria de vazamento para que respostas e outras informações críticas não sejam expostas no prompt. Comparamos taxas de aprovação estritas e uso de token sob as três condições e, em seguida, agrupamos os resultados por tipo de tarefa, tipo de modelo e fonte de Gene.

O experimento produz três descobertas principais. Primeiro, mesmo o modelo mais forte, o Opus 4.8, atinge apenas uma taxa de aprovação rigorosa de 20,2% sem contexto auxiliar, mostrando que os modelos atuais ainda não conseguem completar estas tarefas de longo fluxo de trabalho de forma confiável. Em segundo lugar, a assistência processual melhora o desempenho, mas os seus benefícios e custos diferem consoante a forma. No geral, Gene fornece orientação de tarefas mais eficaz com menos tokens do que Skill. Terceiro, o benefício não é uniforme: ele muda substancialmente com o tipo de tarefa, a capacidade do modelo e a fonte de construção do Gene. O valor do conhecimento processual depende, portanto, de quão bem ele se adapta ao modelo e à tarefa.

O relatório faz três contribuições correspondentes a essas questões.

• Primeiro, construímos um benchmark unificado para tarefas de longo fluxo de trabalho de ponta a ponta. LongWoF-Bench cobre quatro tipos de tarefas com 778 tarefas verificáveis ​​e usa avaliadores ocultos, além de regras de saída estritas para medir a conclusão de cada tarefa.
• Em segundo lugar, apresentamos e implementamos Gene como um prompt auxiliar estruturado. Comparado com um manual de Skills mais completo, Gene representa experiência processual em campos mais curtos e auditáveis. Sob um processo de evolução definido, ele extrai as informações de maior valor do fluxo de execução de um modelo forte e empacota essas informações como um prompt auxiliar. Isso transforma a assistência de um prompt longo e comum em uma condição experimental que pode ser comparada e analisada.
• Terceiro, comparamos sistematicamente três condições entre modelos e trilhas de tarefas: sem contexto auxiliar, Skill e Gene. Sem assistência imediata, mesmo o Opus 4.8 atinge apenas uma taxa de aprovação estrita de 20,2%, confirmando que o benchmark continua desafiador. Os Genes evoluídos são mais valiosos do que as Skills para resolver tarefas de fluxo de trabalho longo e consomem menos tokens.

Capítulo 2: Construindo LongWoF-Bench

2.1 Design de tarefa de referência

2.1.1 Construindo tarefas de longo fluxo de trabalho de ponta a ponta

A unidade de tarefa principal do LongWoF-Bench consiste em uma especificação de tarefa pública, um espaço de entrega e um verificador oculto:

A especificação pública $(S)$ fornece a entrada inicial $(x)$, ambiente acionável $(E_0)$ e conjunto de restrições $(C)$. O espaço de entrega $\mathcal{Y}$ descreve o que o modelo deve enviar e $(V)$ é um verificador oculto do modelo. O modelo executa uma sequência de ações interdependentes $a_1,\ldots,a_T$, conduzindo o ambiente de $(E_0)$ para $(E_T)$ e produzindo uma entrega final $y\in\mathcal{Y}$. A tarefa é aprovada quando $V(x,E_T,y,C)=1$.

Considere a tarefa LongWoF-Bench que solicita a um modelo que construa código de orquestração para um sistema de controle de cruzeiro adaptativo. Sua especificação $(S)$ inclui arquivos de parâmetros do veículo, 150 segundos de dados do sensor e requisitos de interface e desempenho para modos de cruzeiro, seguimento e frenagem de emergência. Seu espaço de entrega $\mathcal{Y}$ inclui arquivos de código para o controlador PID, sistema de controle de cruzeiro e simulador, juntamente com resultados de ajuste, dados de simulação e um relatório de análise. O modelo deve implementar o controlador e a lógica de comutação de modo, ajustar os parâmetros PID, executar a simulação completa e manter todos os resultados consistentes.

O verificador oculto $(V)$ verifica a existência do arquivo e várias propriedades adicionais. Ele importa e invoca as classes enviadas, executa novamente a simulação, verifica modos de controle, interfaces e formatos de saída e verifica medidas de desempenho, incluindo tempo de subida, overshoot, erro de estado estacionário, distância segura de seguimento e limites de aceleração. Ele também altera os parâmetros PID e verifica se o comportamento do sistema muda de acordo. Isso distingue um sistema de controle funcional da saída de simulação codificada.

Um programa estruturalmente completo ou superficialmente plausível é, portanto, insuficiente. O código final e cada entrega derivada devem satisfazer conjuntamente $V(x,E_T,y,C)=1$.

Esta definição também estabelece os critérios de admissão para tarefas de referência. Primeiro, uma tarefa deve ter uma especificação pública descritível a partir da qual o modelo possa obter as informações necessárias para resolvê-la, por meio de entradas acessíveis e imediatas, interfaces que podem ser chamadas ou instruções de saída. Em segundo lugar, a tarefa deve suportar a execução da máquina ou a correspondência exata, para que o resultado não dependa de uma classificação subjetiva. Terceiro, o avaliador deve separar as informações visíveis e ocultas do modelo. O modelo pode ver o prompt, os arquivos de entrada, as interfaces de pacote acessíveis, o protocolo de saída e a Skill ou Gene injetado sob a condição relevante. Ele não deve ver dados de teste ocultos, respostas de ouro, lógica de verificador interno, soluções de referência ou constantes privadas disponíveis apenas para o avaliador. Este limite é necessário para que a comparação posterior seja justa.

2.1.2 Trilhas de fluxo de trabalho LongWoF-Bench

A versão atual do LongWoF-Bench mantém 778 tarefas verificadas. As quatro faixas de avaliação diferem da seguinte forma:

As trilhas produzem diferentes tipos de resultados, mas todas exigem que o modelo transforme as restrições da especificação pública em um resultado verificável. Falhas de código e agente aparecem através da execução de programas e verificações de arquivos. As falhas matemáticas e de regras aparecem por meio da normalização das respostas e da correspondência exata. A estrutura partilhada evita que essas diferenças desapareçam numa pontuação agregada e permite que análises posteriores revelem quais as tarefas que mais dependem de orientação procedimental externa.

2.1.3 Síntese de tarefas LongWoF-Bench

As tarefas seguem um design de “prompt público mais avaliação oculta”. A partir de uma semente predefinida, cada tarefa recebe um task.md visível no modelo que explica o objetivo, os formatos de entrada e saída e os dados disponíveis. O diretório de tarefas também contém dados de teste, uma solução de referência, saída de ouro oculta e um avaliador automático. Durante a avaliação formal, o modelo recebe apenas o prompt público e qualquer contexto auxiliar para a condição atribuída. Depois de produzir uma resposta ou programa, o avaliador oculto o executa, compara os resultados, registra se foi aprovado e mede o uso do token. O benchmark mede, portanto, se um modelo pode realmente completar uma tarefa sob regras complexas, processamento de dados, execução de código e restrições de formatação, e não se ele se lembra de uma resposta de múltipla escolha.

Ao contrário de um benchmark convencional de formato único, o LongWoF-Bench pergunta consistentemente se o produto final funciona. Os programas de código e agente devem ser executados. As respostas matemáticas e de regras devem ser analisadas e combinadas sob um formato estrito. Experimentos posteriores podem comparar de forma justa nenhum contexto auxiliar, Skill e Gene porque todas as três condições enfrentam as mesmas tarefas e verificadores; apenas as informações auxiliares fornecidas ao modelo mudam.

2.2 Construindo prompts auxiliares: Skill e Gene

Muitas falhas em fluxos de trabalho complexos ocorrem não porque falta ao modelo todo o conhecimento relevante, mas porque ele não consegue invocar o processo de execução correto de forma consistente. Ele pode saber ler os dados, mas ignorar o protocolo de saída; entende uma regra, mas não consegue verificar primeiro uma substituição de prioridade mais alta; ou escolha um algoritmo comum sem perceber que uma condição de contorno anula sua estratégia padrão. A etapa exata da falha não é conhecida antecipadamente, portanto, a execução da tarefa deve produzir experiência processual genuinamente útil que pode ser fornecida como assistência.

Introduzimos um novo prompt auxiliar: um Gene baseado no protocolo GEP (EvoMap, 2026a). Ao contrário de uma Skill convencional, Skill se assemelha a um manual de tarefas predefinido, enquanto Gene se assemelha a uma experiência processual destilada de uma execução bem-sucedida (EvoMap, 2026b). Skill é um documento auxiliar de autoria humana definido antes da execução da tarefa e não pode se adaptar ao processo de execução do modelo. Gene resume a experiência processual que o próprio modelo destila sob as regras do Gene durante a execução da tarefa.

Gene tem um objetivo diferente. Não tenta cobrir todas as informações básicas. Em vez disso, ele comprime um caminho de sucesso verificado em um prompt de procedimento estruturado: o padrão do problema, os sinais que mostram quando a estratégia se aplica, as etapas críticas de execução, os limites que precisam de verificações prévias e as verificações necessárias antes do envio. Os Genes neste experimento vêm de duas fontes. Uma é uma trajetória de modelo bem-sucedida que passou na verificação da tarefa. A outra, usada quando não existe uma trajetória bem-sucedida, é destilada a partir de um sinal do professor fornecido pela solução de referência. O primeiro representa mais diretamente a experiência destilada do sucesso real: mantém a parte que mudou o caminho de execução em vez de escrever outro manual mais longo.

Os dois prompts também são sintetizados de forma diferente:

• Skill é um manual de tarefas bastante completo que cobre o tipo de tarefa, processo recomendado, regras de interface, armadilhas comuns e requisitos de saída. Nesta versão de benchmark, as Skills são principalmente reescritas de materiais de construção de tarefas e soluções de referência, seguidas de auditoria. São, portanto, condições instrucionais fortes, em vez de Skills de estilo de mercado geradas apenas a partir da solicitação do público.
• Gene é mais curto e pode ser entendido como um prompt de execução compactado a partir de uma experiência bem-sucedida. Quando um modelo encontra uma solução aprovada usando o prompt público e o feedback do verificador, o Gene é destilado dessa trajetória. Se a primeira tentativa falhar, a próxima implementação sofre mutação: o modelo recebe uma tarefa pública truncada, sua tentativa anterior e feedback de execução limpo e, em seguida, produz uma solução corrigida. O processo se repete até que o verificador seja aprovado ou o orçamento de implementação se esgote. Se a exploração nunca for bem-sucedida, o pipeline atual voltará à destilação da solução de referência.

Considere um exemplo simples. Uma tarefa pede ao modelo que selecione uma ação de limpeza para o equipamento após produzir uma “pasta de girassol e gergelim”, usando regras de risco de resíduos para uma linha de processamento de alimentos. A dificuldade está na ordenação das regras, não no formato de saída. Ambos os ingredientes são sementes e são coprocessados ​​em uma pasta homogênea. O modelo deve aplicar precedência de isenção antes de calcular a pontuação máxima de risco e mapeá-la para um limite.

O caso mostra a distinção. Skill fornece um processo completo e alerta o modelo para não omitir isenções, mas ainda deixa a decisão de prioridade crítica para o modelo. Gene compacta a correção aprendida após duas falhas de modelo forte em uma ordem de execução mais difícil: primeiro aplique a isenção de coprocessamento para que a sobretaxa de alérgeno de gergelim não seja adicionada diretamente ao risco mais alto; em seguida, pegue a pontuação máxima pós-isenção e mapeie-a para a camada intermediária. Gene não é apenas um manual mais curto. Ele transforma a etapa mais propensa a erros e sua ordenação correta em orientações processuais disponíveis em uma única execução.

Assim, Skill fornece instrução estática, enquanto Gene fornece uma estratégia de execução compactada; A Skill é uma sinalização, enquanto o Gene é um caminho já percorrido. As três condições experimentais agora podem ser definidas com precisão:

• no_context mede a conclusão ponta a ponta usando apenas o prompt público;
• with_skill mede se o modelo pode usar uma descrição de tarefa relativamente completa, mas estática;
• with_gene mede se o modelo pode usar um guia processual mais curto e estruturado derivado de uma experiência bem-sucedida ou de um sinal do professor.

Capítulo 3: Resultados experimentais

3.1 Configuração experimental e definições estatísticas

Avaliamos sete modelos nas tarefas do 778 LongWoF-Bench. O conjunto contém 127 tarefas agent_env_synth, 341 code_generation, 151 math_reasoning e 159 rule_following. Cada modelo é executado sob três condições:

• no_context: o modelo recebe apenas o prompt público;
• with_skill: o prompt público é complementado por uma Skill completa para a tarefa atual;
• with_gene: o prompt público é complementado por um Gene processual.

A métrica principal é a taxa estrita de aprovação de tarefas. Uma tarefa conta como aprovada somente quando todos os pontos de verificação são aprovados e o verificador retorna passed=true. O custo de tokens é a soma de entrada, saída e tokens de pensamento registráveis.

Distinguimos quatro conjuntos de avaliação por fonte de Gene:

O modelo usado para construir Genes neste experimento é Claude Opus 4.8. A estratégia de evolução aumenta o esforço de pensamento de fraco para forte nas tentativas de implementação, em vez de fixar um nível de pensamento e alterar um coeficiente de temperatura convencional. O modelo forte resolve primeiro a tarefa pública. Após uma falha, ele revisa a solução usando feedback limpo do verificador, em no máximo três implementações. Assim que uma implementação realmente passa no verificador, um Gene é destilado dessa trajetória bem-sucedida.

3.2 Resultados experimentais gerais (RQ1: Quão confiáveis ​​são os modelos atuais em tarefas de longo fluxo de trabalho verificáveis ​​por máquina e cruzadas?)

A tabela a seguir relata os resultados completos no subconjunto evoluído pelo Opus. Sob no_context, o modelo mais forte, Claude Opus 4.8, passa apenas 54,8% das tarefas; os demais modelos variam de 31,7% a 47,6%. Mesmo o melhor modelo falha em quase metade das tarefas durante uma execução sem assistência. Os modelos atuais não lidam com esses fluxos de trabalho cruzados e verificáveis ​​por máquina de forma confiável por conta própria e ainda se beneficiam de prompts auxiliares.

Cada resultado with_opus_gene aqui usa um Gene destilado de uma trajetória de execução real verificada produzida por Claude Opus 4.8, em vez de uma reescrita da resposta de referência. O Opus Gene supera claramente o Skill em todos os modelos testados. Quando um Gene comprime o processo aprendido através da exploração bem-sucedida do modelo, os modelos posteriores podem usá-lo de forma mais confiável do que uma Skill descritiva completa.

Executamos uma análise contrastante para separar o efeito da estrutura genética do efeito da evolução bem-sucedida. Nas tarefas restantes de destilação de referência, a conclusão se inverte: Gene geralmente tem desempenho inferior ao Skill. Este resultado reforça a interpretação de que a vantagem não advém da mera compressão de informações relacionadas às respostas. Ela vem da estratégia evoluída que destila um processo de execução bem-sucedido em uma orientação procedimental reutilizável. A estrutura evoluída do processo, em vez de apenas a compactação imediata, produz o ganho.

3.3 Análise de custo de token (RQ2: Como Skill e Gene afetam a taxa de aprovação e o uso de token?)

O experimento compara duas maneiras do Opus 4.8 resolver as mesmas tarefas:

• Exploração convencional de modelo forte: um modelo capaz tenta a tarefa, lê o feedback limpo do verificador após a falha e tenta novamente até o limite permitido até que uma tentativa seja aprovada. Esta é a linha de base.
• Execução assistida por Gene EvoMap: um Gene destilado da experiência de modelo forte torna-se um contexto processual que qualquer modelo pode usar para uma tentativa with_gene. A taxa de aprovação é muito maior do que sem Gene, enquanto o consumo de tokens é substancialmente menor do que a exploração em várias rodadas. Este é o nosso modo.

Esta seção conta input_tokens + output_tokens + thoughts_tokens. Para Claude Opus 4.8, os tokens de saída do provedor já incluem pensamento, então “Saída incluindo pensamento” denota o total recuperável do lado da conclusão. A linha de base de múltiplas rodadas conta apenas os tokens usados ​​em implementações de resolução/mutação que descobrem uma trajetória de passagem; não inclui o custo posterior da destilação genética.

Conventional multi-round exploration:
252 tasks
  -> Round 1 solve, thinking off
     -> pass: distill Gene
     -> fail: sanitized verifier feedback
  -> Round 2 mutate, thinking low
     -> pass: distill Gene
     -> fail: sanitized verifier feedback
  -> Round 3 mutate, thinking high
     -> pass: distill Gene

Total: 404 model calls, 252 verified successful trajectories

Single-round Gene reuse:
252 tasks + Opus Genes
  -> one with_gene_opus attempt per task
  -> 252 model calls, 200 passed tasks

Este conjunto de avaliação contém todas as tarefas que produziram uma trajetória verificada durante a exploração de múltiplas rodadas. A primeira linha abaixo simula o processo convencional de múltiplas rodadas e não é uma taxa de aprovação de uma chamada. As linhas restantes relatam a resolução única das mesmas tarefas com a condição auxiliar correspondente.

A tabela suporta quatro conclusões diretas:

1. no_context parece usar o menor número de tokens, mas passa apenas 138 das 252 tarefas. Ele economiza contexto e ao mesmo tempo descarta uma grande quantidade de informações processuais.
2. A Skill aumenta a contagem de passes de 138 para 161, mas o total de tokens chega a 803.099. Um manual de tarefas estático ajuda, mas não é necessariamente econômico.
3. Opus Gene passa 200 tarefas em uma rodada, 39 a mais que Skill, enquanto usa 79.619 tokens a menos, uma redução de 9,9%.
4. Em comparação com a exploração multi-rodada do Opus, a reutilização de Genes em uma rodada reduz as chamadas de 404 para 252, eliminando 152 chamadas exploratórias, e reduz o total de tokens de 1.333.968 para 723.480, uma redução de 45,8%.

A eficiência do token de Gene não vem apenas de um prompt mais curto. Ele transforma o feedback de falha, as etapas de correção e o eventual fluxo de trabalho bem-sucedido da exploração de múltiplas rodadas em memória processual injetável. Um modelo posterior recebe a estratégia de execução resultante em vez de começar a tentativa e erro do zero. Gene não coloca a resposta no prompt; ele disponibiliza um caminho de execução que originalmente exigia múltiplas tentativas como contexto processual reutilizável.

3.4 Opus Gene versus Skill por tipo de tarefa (RQ3: Quais tipos de tarefas, tipos de modelos e fontes de Genes se beneficiam da orientação procedimental?)

Dividir as 252 tarefas desenvolvidas pelo Opus por tipo produz uma visão mais detalhada. Os quatro grupos contêm 64, 62, 30 e 96 tarefas, totalizando 252. Estas tabelas, portanto, descrevem apenas Genes evoluídos e excluem Genes destilados por referência. O Opus Gene oferece ganhos mais consistentes em ambientes de agentes e cumprimento de regras, enquanto o código e a matemática dependem mais fortemente do modelo alvo.

agent_env_synth (64 tarefas)

código_geração (62 tarefas)

math_reasoning (30 tarefas)

rule_following (96 tarefas)

Em agent_env_synth, Opus Gene supera Skill em todos os sete modelos, com ganhos de +15,6 a +29,7 pontos percentuais. As tarefas de ambiente ainda exigem comportamento de pacote, vários arquivos e restrições de teste, mas a interface e a ordem de execução extraídas de trajetórias bem-sucedidas reduzem consistentemente as omissões.

O cumprimento de regras também melhora para todos os sete modelos, em +2,1 a +22,9 pontos percentuais. Muitas falhas de tarefas de regras decorrem do tratamento inconsistente de prioridades, substituições, limites de igualdade ou restrições de opções discretas, em vez de uma incapacidade de ler o prompt. Gene explicita essas verificações processuais e ajuda o modelo a tomar a decisão correta.

A geração de código é mista. Sonnet, Gemini Flash e Qwen Coder se beneficiam de Gene; Opus, Gemini Pro e Qwen 3.5 diminuem ligeiramente; MiniMax permanece inalterado. A orientação procedimental compactada pode reduzir omissões na interface e no fluxo de trabalho, mas nem sempre substitui uma Skill mais completa. O efeito depende de como o modelo alvo utiliza as duas formas de contexto.

O raciocínio matemático requer mais cautela. Opus 4.8 sobe de 43,3% para 83,3%; Gemini Pro e os dois modelos em 0% permanecem inalterados; Soneto, MiniMax e Qwen 3.5 diminuem. A matemática de respostas curtas depende muito da execução simbólica exata, do cálculo de limites e da normalização das respostas. A orientação procedimental pode sugerir um método, mas não pode substituir a computação e pode distrair alguns modelos.

Esses resultados no nível da trilha explicam por que o LongWoF-Bench abrange várias trilhas. Uma pontuação agregada pode mostrar que a assistência ajuda, mas apenas a análise ao nível da via revela quais as formas de tarefas que beneficiam e onde os problemas permanecem.

3.5 Sobreposição evoluída comum: Gene Gemini versus Gene Opus

Os conjuntos de tarefas evoluídos para Gemini Gene e Opus Gene não são idênticos, portanto, comparar cada um em seu próprio conjunto completo seria inválido. Em vez disso, usamos as 180 tarefas desenvolvidas por ambos. O Opus Gene permanece consistentemente mais forte que o Gemini Gene nesta sobreposição, mostrando que a capacidade do modelo de autoria de Genes afeta a usabilidade do Gene resultante.

3.6 Estudos de caso

Caso 1: code_generation / T0161, composição de ensaio de furo de sondagem

Tarefa. Um pipeline de geociências indica collars.csv e assays.csv. As linhas de ensaio podem conter intervalos de profundidade sobrepostos e marcadores abaixo da detecção, como '<0.01'. O programa deve: (1) converter <x em x/2; (2) resolver intervalos de profundidade sobrepostos em segmentos mutuamente exclusivos; (3) recompor esses segmentos em caixas fixas de dois metros da profundidade 0 a max_depth; (4) calcular um alteration_index para cada caixa; e (5) calcular cada buraco mineralization_score como a soma dos valores compostos de Au/Cu acima da mediana de todo o cliente potencial, onde a mediana é calculada em cada composto de dois metros no conjunto de dados.

Processo convencional e como a Opus evoluiu o Gene:

• Rollout 1 (resolver) → FAIL (pass_rate=0.875). Opus resolveu sobreposições com uma regra de “intervalo posterior vence”: a última linha substituiu a anterior onde quer que elas se sobrepusessem.
• Rollout 2 (mutate) → FAIL (pass_rate=0.875). Opus manteve a mesma convenção e apenas fortaleceu o tratamento de NaN. O teste de sobreposição ainda falhou.
• Rollout 3 (mutate) → PASS (pass_rate=1.0). Opus alterou a semântica de sobreposição. Em vez de deixar o intervalo posterior vencer, ele fez a média dos valores de cada intervalo que cobre o segmento e, em seguida, ponderou o comprimento desses segmentos nas caixas de dois metros. Isso correspondeu à semântica de composição esperada e foi aprovado.

A inovação foi semântica: os intervalos de ensaio sobrepostos devem ser calculados em média, em vez de sobrescritos. É isso que o Gene captura.

Gene evoluído (T0161.json, carga útil):

{
  "type": "Gene",
  "summary": "Build a geoscience/interval pipeline that cleans below-detection markers, resolves overlapping depth intervals, composites into fixed-length bins, and emits per-row and per-entity aggregate CSVs.",
  "category": "innovate",
  "signals_match": [
    "drillhole assay compositing",
    "below-detection limit markers like '<0.01'",
    "overlapping depth intervals to mutually exclusive segments",
    "fixed-length 2-meter downhole composites",
    "alteration index / mineralization score formulas",
    "prospect-wide median threshold aggregation",
    "--input/--output directory CLI with named CSV outputs",
    "length-weighted interval averaging"
  ],
  "strategy": [
    "Parse CLI --input/--output dirs; read collars and assays CSVs by exact column names; create output dir with makedirs(exist_ok=True).",
    "Clean value columns: convert '<x' strings to x/2 (half detection limit), '>x' to x, blanks/'na' to NaN, else float; coerce depth columns to numeric.",
    "Per hole, resolve overlaps: collect breakpoints from all from/to bounds, for each adjacent segment use midpoint to find covering intervals and average their values into one exclusive segment.",
    "Composite into exact fixed-length bins from 0 to max_depth (ceil(max_depth/len) bins); for each bin length-weight each value by overlap length with segments, divide by total weight, NaN if none.",
    "Compute per-bin derived index per given formula guarding zero/NaN denominators; write one CSV with hole_id, bin from/to, and index using the required header order.",
    "Compute dataset-wide medians across ALL bins for threshold columns; per hole sum bin values exceeding their respective medians for the score and take per-hole max values; write the summary CSV with exact headers.",
    "Verify both output files exist, column names/order match the contract, and every hole appears even with empty or missing assays."
  ],
  "preconditions": [
    "Medians for scoring must be computed across the full composited dataset, not per hole.",
    "Bins must span exactly 0..max_depth and exist for holes with no assay coverage (values NaN).",
    "Overlap resolution must produce mutually exclusive segments before any compositing aggregation.",
    "String/NaN/empty assay cells must be sanitized before numeric ops to avoid type errors."
  ],
  "constraints": { "max_files": 1, "forbidden_paths": [".env", "secrets", "credentials"] },
  "validation": []
}

Gemini Pro sem Gene: falhou. O resolve_overlaps do Gemini classificou os intervalos e truncou o intervalo anterior no início do próximo intervalo, um método “cortar, não combinar” que descartou valores sobrepostos:

prev = resolved[-1]
if row['depth_from'] < prev['depth_to']:
    if row['depth_from'] > prev['depth_from']:
        prev['depth_to'] = row['depth_from']   # trim only; discard overlap contribution
    else:
        resolved.pop()
resolved.append(row)

O resultado foi FAIL:L2_prospect_summary_adv_overlap - Mismatch in mineralization_score for key ('H003',): got 0.0, expected 202.0. O tratamento de sobreposição removeu a contribuição que impulsionou a pontuação.

Gemini Pro com Gene: aprovado. Guiado pela estratégia de “coletar pontos de interrupção, intervalos de cobertura médios e, em seguida, pesar o comprimento em compartimentos”, o Gemini construiu segmentos de pontos de interrupção, fez a média de cada intervalo de cobertura e, em seguida, ponderou o comprimento dos segmentos em compartimentos de dois metros:

boundaries = sorted(set(hole_assays['depth_from']).union(hole_assays['depth_to']))
for seg_from, seg_to in adjacent_pairs(boundaries):
    covering = hole_assays[(hole_assays.depth_from <= seg_from) & (hole_assays.depth_to >= seg_to)]
    seg_data[col] = np.average(vals[valid], weights=w[valid])   # average, not overwrite

Sem Gene, o modelo adotou como padrão a heurística comum de mesclagem de intervalo “vitórias posteriores / corte do intervalo anterior”. Parece razoável, mas é errado para a composição do ensaio e reduziu a pontuação de mineralização do H003 a zero. A Opus aprendeu em duas implementações fracassadas que a convenção correta é a média ponderada pelo comprimento. Gene deu ao Gemini essa convenção precisa, permitindo que ele fosse composto corretamente na primeira tentativa.

Caso 2: Rule_following / T0659, código de despacho de emergência

Tarefa. Dado um cenário 911 envolvendo um distúrbio doméstico interno, um sujeito segurando uma faca de cozinha (arma branca), sem ferimentos visíveis e uma geolocalização exatamente 5 ZDU de distância, escolha o código de despacho correto entre dispatch_omega, dispatch_sigma, dispatch_theta e dispatch_zeta. A decisão depende de duas regras de interação: a comparação distância-limiar (exatamente 5 excede estritamente o limite?) e a precedência de arma/lesão (arma presente sem lesão é mapeada para o nível armado sem lesão).

Processo convencional e como a Opus evoluiu o Gene:

• Rollout 1 (solve) → FAIL (pass_rate=0.667). Opus se recusou a confirmar, argumentou que a tabela de regras estava faltando, emitiu o espaço reservado dispatch_omega e disse que a escolha não pôde ser verificada.
• Rollout 2 (mutate) → FAIL (pass_rate=0.667). Opus selecionou dispatch_theta, raciocinando que uma arma aumentava a resposta independentemente do limite de distância. Isso agravou demais o caso: ignorou o rebaixamento de ausência de feridos e tratou a distância limite como um gatilho de escalada.
• Rollout 3 (mutate) → PASS (pass_rate=1.0). Opus aplicou a precedência corretamente. Exatamente 5 ZDU não excedem estritamente o limite, portanto o escalonamento de distância não é acionado. Uma arma sem ferimentos é mapeada para o nível armado sem ferimentos: dispatch_sigma.

Gene evoluído (T0659.json, carga útil):

{
  "type": "Gene",
  "summary": "Select a dispatch/response code by applying weapon and injury precedence rules combined with a strict ZDU/distance threshold comparison, emitting an exact two-line ANSWER/ANALYSIS contract.",
  "category": "other",
  "signals_match": [
    "dispatch code selection",
    "threshold comparison on distance units (ZDU)",
    "rule precedence for weapon-involved incidents",
    "ANSWER and ANALYSIS exact two-line output",
    "weapon present but no visible injuries",
    "911 / emergency dispatch scenario",
    "choose one of several action tokens",
    "case-insensitive exact-match grading"
  ],
  "strategy": [
    "Extract every decision factor from the prompt: weapon present?, injuries present?, distance value, and the exact stated threshold.",
    "Apply the threshold as written: treat 'exactly equal' as NOT exceeding unless rule says >= (strict vs non-strict matters most for boundary values).",
    "Resolve precedence order: injury-tier > armed-no-injury > distance-only codes; pick the highest-priority rule whose conditions are fully satisfied.",
    "When a weapon exists but injuries are explicitly denied, choose the armed-but-no-injury tier, not the injury escalation or plain distance code.",
    "Map the satisfied rule to its corresponding code token and verify it is one of the allowed options.",
    "Emit exactly two lines: 'ANSWER: <token>' then 'ANALYSIS: <one paragraph ≤80 words citing the rule>', with no extra output or whitespace lines."
  ],
  "preconditions": [
    "Confirm whether the boundary value triggers escalation (strict > vs >=) before deciding distance effect.",
    "Verify the chosen token is spelled exactly as an allowed option for case-insensitive exact match.",
    "Ensure precedence (weapon/injury rules) overrides distance-only codes when both apply."
  ],
  "constraints": { "max_files": 1, "forbidden_paths": [".env", "secrets", "credentials"] },
  "validation": []
}

Gemini Pro sem Gene: falhou. Gemini escalou demais a arma e manipulou mal o limite, selecionando dispatch_theta:

ANSWER: dispatch_theta
ANALYSIS: ... because the subject is exactly 5 ZDU away ..., the threshold comparison for a weapon-related incident indicates dispatch_theta ...

Este é o mesmo erro que a Opus cometeu na implementação 2: tratar a distância do limite mais a arma como exigindo o nível mais alto, ignorando o rebaixamento sem ferimentos.

Gemini Pro com Gene: aprovado.

ANSWER: dispatch_sigma
ANALYSIS: ... a bladed weapon with no visible injuries at exactly 5 ZDU ... under the rule precedence, the combination of weapon and close distance ... no active injury indicates the dispatch_sigma code.

A tarefa tem duas armadilhas bem conhecidas: um limite estrito versus não estrito (exatamente 5 “excede” o limite?) e uma ordem de precedência (lesão > armado sem lesão > apenas distância). O modelo sem contexto falhou em ambos, como aconteceu com a Opus antes da convergência. Gene declara ambas as regras explicitamente: tratar a igualdade como não excedendo, a menos que a regra diga >=, e mapear a arma presente com lesão negada para o nível armado sem lesão, em vez de escalação de lesão. Gemini, portanto, aplica a precedência corretamente e seleciona dispatch_sigma.

O que os dois casos compartilham

Os dois casos mostram o mesmo padrão: uma heurística padrão plausível viola um contrato específico da tarefa.

• T0161: tratar o intervalo posterior como substituto do anterior descarta contribuições sobrepostas.
• T0659: presumir que uma arma sempre aumenta a resposta ignora o rebaixamento por ausência de ferimentos e o limite estrito de distância.

A Opus precisou de dois ou três rollouts para isolar a regra corretiva de cada caso. O Gene evoluído resume essa regra em poucas linhas de strategy e preconditions, permitindo que o Gemini a aplique na primeira tentativa.

O caso de código mostra como Gene evita depuração repetida e grandes reescritas. O caso de regras mostra como evita erros de prioridade e de limite. Juntos, eles explicam por que a orientação processual pode reduzir o custo de exploração, sem afirmar que produz o mesmo ganho em todos os tipos de tarefa.

Referências

• Diao, L., Xu, X., Sun, W., Yang, C., & Zhang, Z. (2025). GuideBench: Benchmarking Domain-Oriented Guideline Following for LLM Agents. ACL 2025, 11361-11399.
• EvoMap. (2026a). GEP Protocol Deep Dive: Genetic Engineering for AI Agent Self-Evolution.
• EvoMap. (2026b). Agent Skill vs GEP Gene: The Fundamental Divide Between Tools and Evolution.
• Li, X., et al. (2026). SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks. arXiv:2602.12670.
• Wang, J., Ren, Y., & Zhang, H. (2026). From Procedural Skills to Strategy Genes: Towards Experience-Driven Test-Time Evolution. arXiv:2604.15097.