Um agente de LLM é, na prática, um sistema. Um modelo congelado cercado por um harness: prompts, fluxo de controle, interfaces de ferramentas, memória e gestão de contexto.
No artigo RRSI: Regularized Recursive Self-Improvement of Agent Harnesses, Peng Xia, Rujun Han, Zifeng Wang e colegas argumentam que esse harness pode ser evoluído automaticamente em ciclos de auto-melhoria recursiva (RSI).
Essa evolução tende a sobreajustar ao conjunto de tarefas usado no processo. A proposta insere princípios de regularização na forma como candidatos são propostos e selecionados.
Os autores relatam ganhos de até 14,1 pontos no split de evolução, até 4,7 pontos em benchmarks fora de distribuição e um harness que consome 30% menos tokens de política que a evolução sem regularização.
O que os autores propõem
O RRSI mantém o harness inteiramente editável. Prompts, fluxo de controle, configuração, gestão de contexto, ferramentas, skills, memória e subagentes podem ser modificados, adicionados ou removidos.
A intervenção não está em restringir o espaço de hipóteses, e sim em regularizar a trajetória de busca dentro dele.
Peng Xia e coautores separam isso em dois lados. No lado do propositor, limitam quanto de capacidade adaptativa pode ser exercida por rodada e onde ela é gasta.
No lado do seletor, definem quais melhorias empíricas são fortes, baratas e livres de vazamento o suficiente para virarem estado permanente do harness.
Os autores enquadram essas restrições em três analogias explícitas com regularização clássica. O orçamento de edição se aproxima de uma restrição de cardinalidade no estilo L0.
A poda estrutural se aproxima da esparsificação Lasso/L1. A aceitação sensível a complexidade se aproxima do encolhimento Ridge/L2.
Eles são cuidadosos ao afirmar que a analogia vale para a esparsidade da atualização, não para um vetor de parâmetros fixo, e que não otimizam um objetivo com penalidade explícita. Página do projeto: regularized-rsi.com.
Contexto: qual problema está sendo atacado
O texto parte de uma premissa forte: boa parte do progresso recente em produtos de agentes veio de engenharia de harness, não de novos pesos de modelo.
O problema é que esse trabalho ainda é manual. Humanos leem trajetórias que falharam e ajustam o scaffold à mão, o que limita o avanço à quantidade de trajetórias que um engenheiro consegue inspecionar.
Métodos recentes automatizam esse laço usando LLMs para propor e selecionar edições componente a componente do harness com base no feedback das tarefas.
Isso configura, segundo os autores, uma forma prática de RSI no nível do sistema-agente: o feedback do sistema atual melhora o harness que molda seu comportamento seguinte.
O risco é o sobreajuste adaptativo. Como o conjunto de evolução é finito e reutilizado, os candidatos propostos em cada rodada dependem de medições feitas nas mesmas tarefas em rodadas anteriores.
Ganhos no conjunto de evolução podem não se traduzir em tarefas inéditas.
O artigo identifica três comportamentos acoplados que abrem essa lacuna entre evoluir e transferir: ajuste a padrões específicos do benchmark, perseguição de ruído de avaliação e acumulação de complexidade que melhora a pontuação sem melhorar o mecanismo do agente.
Os autores citam estudos recentes que observaram diferenças substanciais entre desempenho na evolução e em conjuntos reservados. Notam que trabalhos anteriores passaram a separar explicitamente tarefas de evolução e de avaliação para medir generalização.
Como funciona
No lado da proposta, três mecanismos operam juntos.
O primeiro é um orçamento de edições com annealing temporal. No início do processo, um candidato pode agrupar várias mudanças coordenadas para descobrir mecanismos novos.
Nas rodadas finais, o orçamento encolhe e as atualizações ficam mais esparsas e atribuíveis.
Sem esse teto, um propositor pode empacotar muitas modificações não relacionadas. Isso aumenta a capacidade efetiva do candidato de se ajustar a idiossincrasias do feedback e dificulta atribuir o ganho a um mecanismo específico.
O segundo é a atribuição de crédito sensível a evidências. Para cada candidato avaliado, o sistema registra o componente modificado, a hipótese testada, o diff de origem, as variações de pontuação e custo, e se o candidato foi aceito.
O propositor condiciona-se a esse histórico: mecanismos rejeitados permanecem como evidência negativa e mecanismos bem-sucedidos retêm crédito explícito.
Como cada avaliação é mais uma olhada adaptativa sobre o mesmo conjunto finito, repetir hipóteses já falsificadas desperdiça capacidade de busca.
O terceiro é a exploração estruturada. O histórico revela quando o propositor colapsou em uma família estreita de edições, por exemplo reescrever prompts repetidamente sem tocar em mecanismos estruturais.
O sistema trata a busca como estagnada quando o progresso das últimas rodadas fica dentro da faixa de ruído empírico. Reserva uma pequena fração do orçamento para componentes ainda não exercitados, papel análogo ao de regularização por diversidade ou entropia.
No lado da seleção, os critérios são não compensatórios. Um candidato precisa satisfazer vários deles antes que sua pontuação justifique substituir o incumbente.
Um crítico lê cada diff antes da avaliação completa e rejeita edições que codifiquem nomes de tarefas, nomes de entidades, valores específicos, respostas ou outra lógica particular ao benchmark de evolução, além de maquinário inerte.
O filtro ocorre antes da avaliação justamente para que um candidato vazado nunca receba a pontuação inflada que o tornaria atraente nas rodadas seguintes.
Há ainda uma aceitação sensível à estabilidade. Antes da evolução, os autores avaliam repetidamente o harness base inalterado para estimar uma faixa de ruído.
Exigem que o candidato supere um piso ajustado por esse ruído em relação à melhor pontuação observada até então.
A aceitação sensível a complexidade exige que ganhos acima da faixa de ruído justifiquem o aumento de custo em relação ao harness corrente.
Resultados reportados
Os autores avaliam o RRSI em oito benchmarks de três domínios: tarefas de coding, de workspace agêntico e de design de engenharia. Eles diferem em tipo de tarefa, ferramentas e verificador (suítes de testes unitários em coding; LLM-como-juiz em workspace agêntico).
Em cada domínio, o harness é evoluído sobre uma única suíte e depois executado sem alterações em benchmarks reservados.
Os números relatados: ganho de até 14,1 pontos no split contra o qual a evolução ocorre; até 4,7 pontos nos cinco benchmarks fora de distribuição (a introdução também afirma melhora em todos os seis splits reservados); desempenho médio até 22,9% acima da média das baselines anteriores; e um harness que roda com 30% menos tokens de política que a evolução sem regularização. O código está em GitHub.com/Google-research/rrsi.
Limitações e o que não foi provado
O material disponível não inclui a seção de limitações do paper. O extrato corta a descrição do método no meio do critério de aceitação sensível a complexidade, de modo que os limiares exatos de custo tolerado não são verificáveis aqui.
Também não estão nomeados, no material, os oito benchmarks, as baselines comparadas nem o modelo de backbone congelado usado. Todos os números acima são afirmações dos autores, não medições independentes.
Alguns pontos merecem ressalva metodológica. A transferência demonstrada é dentro do mesmo domínio: o harness evolui em uma suíte e é avaliado em benchmarks reservados daquele domínio.
Não está provado que ele generalize entre domínios distintos.
O verificador por LLM-como-juiz é, por natureza, ruidoso, e o próprio método depende de estimar uma faixa de ruído empiricamente. Se essa estimativa for mal calibrada, o piso de aceitação pode ser frouxo ou conservador demais.
O crítico que faz a triagem de vazamento é ele mesmo um LLM lendo diffs, e o extrato não quantifica sua taxa de erro.
Não há, no material, comparação do custo computacional total do processo de evolução regularizado versus o não regularizado. A economia relatada é de tokens de política em inferência, não do orçamento gasto para chegar ao harness.
Por que isso importa para quem constrói com IA
Para equipes que operam agentes em produção, a mensagem prática é que o harness é um alvo de otimização de primeira classe, e um alvo perigoso.
Qualquer laço automatizado que proponha mudanças em prompts, ferramentas ou fluxo de controle a partir de um conjunto fixo de tarefas de avaliação está sujeito ao mesmo tipo de sobreajuste adaptativo descrito no artigo, mesmo sem usar o método.
Três padrões do RRSI são diretamente reaproveitáveis: limitar quantas coisas mudam por iteração para preservar atribuibilidade; guardar histórico de hipóteses rejeitadas em vez de retestá-las; e exigir que ganhos de pontuação superem uma faixa de ruído medida, com custo em tokens como parte do critério de aceitação, e não como métrica secundária.
O resultado sobre consumo de tokens também é relevante em termos econômicos. Se a evolução regularizada gera harnesses que gastam 30% menos tokens de política mantendo ou ampliando desempenho, o argumento de que regular a busca produz mecanismos mais reutilizáveis, e não mais complexos, deixa de ser apenas estético.
A ressalva é que esses ganhos são medidos nos benchmarks dos autores, em cenários onde evolução e avaliação foram cuidadosamente separadas. É uma condição que a maioria dos times não implementa por padrão.
Referências
- Xia, P.; Han, R.; Wang, Z.; Chen, Y.; Zhang, Y.; Lee, Y.; Huang, C.; Yu, H.; CuiZhu, Z.; Ming, Y.; Yao, H.; Gokturk, B.; Pfister, T.; Lee, C.-Y. RRSI: Regularized Recursive Self-Improvement of Agent Harnesses. arXiv:2609.24972, cs.LG. https://arxiv.org/abs/2609.24972
- Página do projeto: https://regularized-rsi.com/
- Código: https://github.com/google-research/rrsi
- Trabalhos citados pelos autores como base das analogias de regularização, conforme a bibliografia mencionada no extrato: Hastie et al. (2009); Goodfellow et al. (2016); Louizos et al. (2018); Dwork et al. (2015); Haarnoja et al. (2018).
