Um agente em vez de um otimizador isolado: uma estrutura unificada que evolui simultaneamente em várias tarefas
Os autores demonstram que um único modelo congelado, numa versão inalterada do harness, primeiro resolve tarefas e depois edita o próprio código, com base em registos completos de execução. A evolução multitarefa de um esqueleto de 49 linhas melhorou os resultados dentro da distribuição e em benchmarks de validação, permitindo superar o Codex em alguns deles.
O que é um harness e por que o otimizar
Harness é o código em torno de um agente baseado num modelo de linguagem. Organiza prompts, chamadas de ferramentas, gestão do contexto e execução. A forma como este código está estruturado determina como o agente resolve uma tarefa.
Na maioria dos métodos existentes, o harness é criado por uma pessoa. Um proposer separado altera o harness do solver. Evolui-se um harness distinto para cada benchmark. Esta abordagem restringe as melhorias a uma única tarefa.
Critério prático: uma estrutura única evolui em várias tarefas ao mesmo tempo, em vez de ser adaptada separadamente a cada benchmark.
Estrutura única: o agente como o seu próprio otimizador
O artigo de Qiankai Xu foi submetido a 29 de setembro de 2026. Intitula-se «Self-Evolving Harness on Multiple Tasks with the Agent as Its Own Optimizer». A abordagem baseia-se num único modelo congelado e numa única versão do harness.
O modelo começa por resolver tarefas como solver. Depois, é o próprio modelo que assume o papel de proposer. Lê registos completos das execuções e edita diretamente o harness que o executa. Não é necessário um proposer separado.
| Parâmetro | Método típico | Abordagem do artigo |
|---|---|---|
| Quem altera o harness | Proposer separado | O mesmo modelo congelado |
| Harness inicial | Criado por uma pessoa | Uma versão do harness |
| Âmbito | Um harness por benchmark | Tarefas de cinco benchmarks de diferentes áreas |
| Papéis | Proposer e solver separados | O modelo começa como solver e depois passa a proposer |
Critério prático: um agente que lê as suas próprias execuções e altera o seu próprio harness substitui um otimizador separado.
Cinco benchmarks e separação dos dados
Cada ciclo de evolução inclui tarefas de cinco benchmarks de diferentes áreas. As tarefas de treino e as tarefas reservadas para avaliação são estritamente separadas.
Além disso, são realizadas avaliações em cinco benchmarks fora da distribuição. Estes benchmarks não foram usados durante a evolução.
Critério prático: as avaliações fora da distribuição testam a transferência, não apenas a adaptação a tarefas conhecidas.
Duas etapas de evolução
O processo de evolução é apresentado como o treino de um modelo profundo em duas etapas:
- Pré-treino multitarefa.
- Treino contínuo.
A versão inicial do harness tinha 49 linhas. No final da primeira etapa, o resultado médio aumentou 4,48 pontos nos benchmarks dentro da distribuição. Nos benchmarks fora da distribuição, o aumento foi de 12,64 pontos. Nos primeiros, o resultado superou o Codex; nos segundos, igualou-o.
Na segunda etapa, a evolução adicional no Claw-Eval aumentou o resultado neste benchmark de 66,17 para 68,06. Nesta avaliação, a abordagem superou o Codex.
Critério prático: o pré-treino alarga a transferência, enquanto o treino contínuo aperfeiçoa o resultado num benchmark específico.
Mecanismos que surgiram durante a evolução
Os autores analisam três mecanismos:
- truncamento da saída;
- compressão do histórico;
- verificação independente.
O truncamento da saída limita o tamanho da resposta. A compressão do histórico reduz o contexto. A verificação independente acrescenta uma etapa de controlo do resultado. Estes mecanismos surgiram de alterações ao harness, em vez de terem sido definidos por uma pessoa.
Critério prático: os mecanismos que surgem durante a evolução servem de referência para avaliar a própria estrutura.
Perguntas mais frequentes
Materiais semelhantes
Todos os materiais
Avaliação de agentes de programação no desenvolvimento XR interativo: resultados do GenXR-Bench
Foi publicado o GenXR-Bench, um conjunto de 112 tarefas especializadas para avaliar de ponta a ponta agentes de programação no desenvolvimento interativo de XR: desde o aprimoramento de funcionalidades e a correção de defeitos até a criação de aplicações com verificação do comportamento em dispositivos de consumo. Entre os dez modelos testados, o melhor resultado foi de 50,9% no Pass@1; entre as falhas recorrentes estão o processamento de eventos assíncronos de sensores, a ancoragem de objetos no espaço real e a compreensão das interações em contextos físicos.
5 novembro 2026
Anotação híbrida de imagens: a automatização acelera o treino de modelos de visão por computador
O artigo descreve como a pré-anotação por algoritmos reduz o trabalho manual e melhora a qualidade dos conjuntos de dados de treino, bem como por que motivo a verificação por amostragem humana continua a ser necessária. São abordadas as limitações do método em condições difíceis de captura e em tipos de objetos raros.
5 novembro 2026
Da recompensa escalar à fronteira de Pareto: síntese de RTL com aprendizagem por reforço multiobjetivo
É proposto um método para treinar um modelo de linguagem a gerar não apenas um esquema, mas um conjunto de candidatos RTL com diferentes compromissos entre área, latência e consumo de energia; a recompensa é calculada com base na contribuição de cada variante para o hipervolume da fronteira de Pareto. No RTLLM v2, o hipervolume relativo aumentou 13,3 p.p. em relação à versão de base sem otimização de PPA e 14,4 p.p. em relação ao treinamento por reforço com um único objetivo.
5 novembro 2026