RiseHarness ensina agentes de terminal a corrigir a própria camada de orquestração sem retreinamento

Um agente de terminal pode resolver uma tarefa na primeira tentativa e falhar na segunda, mesmo com o mesmo modelo, o mesmo prompt e a mesma configuração. É essa instabilidade que o RiseHarness ataca: o framework, descrito em um artigo que apareceu no Hugging Face Daily Papers, reescreve de forma iterativa o harness do agente com os pesos do modelo totalmente congelados. No resumo, os autores não apresentam resultados numéricos, então só dá para avaliar a abordagem em si. Ainda assim, ela é bastante concreta.

A distância entre "sabe fazer" e "faz de forma confiável"

A premissa é simples. Em tarefas longas no terminal, cada ação do agente altera o contexto, e o contexto influencia a ação seguinte. Um erro aleatório em uma etapa inicial se espalha por toda a trajetória. O resultado é que a mesma tarefa, na mesma configuração, termina em sucesso em uma execução e em falha em outra. Os autores chamam isso de lacuna entre capacidade e execução confiável.

Por isso, o RiseHarness não persegue tarefas que o modelo nunca resolve. O foco são as tarefas "viradoras" (flipping tasks), em que há execuções bem-sucedidas e malsucedidas. A execução bem-sucedida vira referência para comparação com a que falhou. Assim, fica mais fácil separar um problema sistêmico do harness de simples azar.

Como funciona o ciclo

A análise usa dois tipos de dados: as trajetórias do agente e os traces internos do monitor de runtime. Os traces mostram como as ações do modelo interagem com a execução de comandos, o feedback, o gerenciamento de contexto e a decisão de encerrar a tarefa. Esses são os pontos que mais costumam quebrar em tarefas de longa duração.

Para conectar as observações ao código real, o framework usa o Harness Handbook. Ele relaciona as evidências das execuções ao comportamento do harness e ao seu código-fonte. Isso ajuda a encontrar problemas recorrentes em mecanismos comuns a muitas tarefas, em vez de remendar casos isolados.

A parte seguinte é a mais interessante. O RiseHarness procura implementações relevantes em outros frameworks de agentes e as adapta como referências de design para o modelo específico e para o protocolo de execução. As alterações candidatas passam por verificações comportamentais e por uma nova avaliação nas tarefas. As versões com ganho mensurável servem de base para a iteração seguinte. Com isso, um único harness reúne mecanismos adequados vindos de projetos diferentes, e os dados mais recentes das execuções orientam as próximas mudanças.

O que se sabe sobre o método

• Os pesos do modelo não mudam; só o harness é otimizado.
• A unidade de adaptação é um modelo concreto, e não um "agente em geral" abstrato.
• Tarefas com resultados mistos na mesma configuração têm prioridade.
• As fontes de sinal são as trajetórias do agente e os traces do monitor de runtime.
• As alterações só são aceitas após verificações comportamentais e novas execuções.
• A avaliação considera sucesso e confiabilidade em diferentes modelos, ablações sobre os traces de execução e a pesquisa externa, além da transferência para benchmarks desconhecidos com o mesmo modelo.

O último ponto é importante. Melhorias no harness podem facilmente sofrer overfitting ao conjunto de tarefas usado para ajustá-las. A verificação em benchmarks desconhecidos com o mesmo modelo mostra se o método encontrou mecanismos gerais de interação ou apenas ajustou o comportamento. O resumo não traz números concretos desses testes, então é preciso consultar o texto completo do artigo.

O que dá para aproveitar na prática

Três coisas são úteis para equipes que desenvolvem agentes de código e de terminal. Primeiro, medir a estabilidade, e não apenas o pass@1: rode cada tarefa várias vezes e acompanhe separadamente aquelas que dão resultados mistos. Segundo, registrar em log os eventos internos do harness no mesmo nível das ações do modelo. Sem traces de execução, de feedback e de decisões de encerramento, analisar uma falha vira adivinhação. Terceiro, rever o harness ao trocar de modelo: pela lógica dos autores, mecanismos que funcionaram bem com um modelo não precisam necessariamente servir para outro.

As limitações também são visíveis. O método exige muitas execuções repetidas, ou seja, orçamento de computação, e depende da qualidade do monitor. Até que ponto os mecanismos "emprestados" e adaptados convivem bem entre si é algo que as ablações do texto completo vão mostrar. Mas a ideia em si parece prática: parte da falta de confiabilidade dos agentes está no harness, e dá para corrigi-la com engenharia, sem mexer nos pesos.