Uma equipe da Universidade de Ciência e Tecnologia da China e da Universidade Batista de Hong Kong publicou EvolveNet em 5 de agosto de 2026—um framework que melhora agentes LLM evoluindo o harness executável que envolve um modelo fixo em cinco domínios de benchmark, sem retreinar pesos.
O harness é o programa executável que constrói contexto, invoca ferramentas, verifica resultados e recupera-se de falhas. EvolveNet argumenta que esta camada—não o modelo base—é o alvo principal de otimização. Testes em text-to-SQL, codificação em ciência de dados, programação competitiva, engenharia de software e fluxos de trabalho com agentes mostraram melhoria em todos os cinco, com os maiores ganhos em cargas de trabalho heterogêneas.
Sistemas anteriores de evolução de harness—Darwin Gödel Machine, Meta-Harness, GEPA—assumem que toda experiência de execução flui para um único otimizador que evolui um harness sequencialmente. Isso funciona em laboratórios. Quebra quando a experiência vem de usuários, organizações e ambientes distintos que não podem agrupar dados de carga de trabalho. A maioria das implantações corporativas se enquadra nessa restrição. EvolveNet distribui o harness compartilhado para implantações de agentes local-de-dados, permite que cada um evolua contra sua própria carga de trabalho, e coleta apenas as adaptações de programa resultantes para agregação. Cargas de trabalho brutas permanecem locais.
Mesclar programas modificados independentemente não é média de parâmetros—adaptações entram em conflito no nível de escopo. EvolveNet introduz agregação de programa tipada por escopo e guiada por evidência para resolver conflitos. Resultados de ablação mostram que ganhos vêm de compor adaptações entre agentes, não de selecionar entre elas. Para plataformas multi-tenant, federação de diffs de programa—não seleção da melhor variante—impulsiona melhoria coletiva.
Um artigo paralelo (arXiv:2605.30621) revela onde EvolveNet compensa: capacidade de atualização de harness é plana entre tiers de modelo. Atualizações Qwen3.5-9B geram ganhos comparáveis a Claude Opus 4.6. Mas benefício de harness é não-monótônico. Modelos de tier médio se beneficiam mais; modelos de tier fraco falham em ativar ou seguir artefatos atualizados; modelos de tier forte se beneficiam menos que tier médio. Para decisões de stack: o evoluidor não precisa ser seu modelo mais forte, mas o agente resolvendo a tarefa precisa ser.
Outro artigo relacionado (arXiv:2605.27276) enquadra a restrição nitidamente. Sistemas somente harness melhoram "higiene de engenharia de software—parsing, retentativas, dispatch"—e raramente entregam raciocínio específico de domínio que o modelo base não pode produzir. Agentes de produção perdem desempenho significativo para recuperação de erro frágil e invocações de ferramentas mal estruturadas muito antes de atingir o teto do que o modelo base pode raciocinar. Corrigir o harness primeiro está correto.
Evolução de harness é entregue como diffs de programa, não passos de gradiente. Nenhum cluster GPU, nenhum retreinamento, nenhuma troca de serviço. Para equipes executando agentes em modelos API de terceiros—onde atualizações de peso são impossíveis—evolução de harness estilo EvolveNet é toda a superfície de otimização.
Instrumente implantações para capturar adaptações de programa por domínio de carga de trabalho. Construa a camada de agregação que as compõe. Trate esse pipeline como a alavanca principal para melhoria de produção antes de agendar um fine-tune.