Harness para agentes: invista no feedback que muda o resultado

Naresh Jain comparou agentes construindo um serviço Java com e sem um harness comportamental, composto de especificações, exemplos e verificações executáveis.[11] Cada condição teve dez execuções por modelo, e a aceitação foi feita por uma suíte externa de 178 testes.[11] O resultado publicado no site de Martin Fowler é menos confortável que uma receita universal: o mesmo apoio teve valor diferente conforme o modelo.[11]

O que muda para quem desenvolve

Com GPT-6 Sol, houve aprovação em dez de dez execuções nas duas condições.[11] Sem harness, a média foi aproximadamente 6min51s e US$ 0,406; com ele, 19min53s e US$ 2,679.[11] Não houve melhoria observável na aceitação dessa tarefa.[11]

Com GPT-6 Luna, a aprovação passou de três em dez para dez em dez com harness, enquanto o custo estimado subiu de US$ 0,086 para US$ 0,273 por tentativa.[11] Luna com harness custou aproximadamente 33% menos por tentativa que Sol sem harness, com a mesma aprovação observada.[11] São estimativas equivalentes de API baseadas em tokens, não faturas.[11]

Minha análise é que há dois investimentos diferentes: feedback para orientar a construção e avaliação para decidir se a entrega está correta. O experimento não elimina o segundo. Todos os resultados passaram pela suíte externa, inclusive quando o agente trabalhou sem harness.[11]

As falhas de Luna sem apoio apareceram em fronteiras como timeouts, acompanhamento assíncrono, serialização Kafka e códigos HTTP.[11] Isso sugere uma hipótese prática: tornar os casos de erro executáveis pode ser mais valioso que acrescentar instruções genéricas sobre qualidade.

Como aplicar

Escolha uma tarefa representativa e preserve uma suíte de aceite independente. Separe exemplos disponibilizados durante a construção de casos reservados para a decisão final. O agente não deve poder enfraquecer as expectativas para obter aprovação.

Compare três arranjos: apoio executável frequente, apoio somente nos contratos críticos e verificação ao final. Mantenha escopo, modelo e ambiente documentados. Conte tentativas rejeitadas e retrabalho, não apenas a melhor execução.

Em uma API com processamento adiado, inclua exemplos que distingam sucesso imediato, timeout, resposta de acompanhamento e conclusão posterior. Observe status, cabeçalhos e efeito externo. Uma resposta aparentemente correta não basta se o evento foi publicado de forma errada.

Inclua o tempo humano de criar e manter contratos na conta. Antes de aumentar o aparato, identifique quais falhas ele detecta e se esse feedback realmente altera a taxa de entregas aceitas.

Cuidados e limites

O estudo usou um único projeto novo, requisitos excepcionalmente detalhados e dez tentativas por condição.[11] Não estima confiabilidade de longo prazo nem demonstra o mesmo efeito em legado, requisitos vagos ou modelos locais.[11]

Orientações e testes foram adicionados juntos, portanto seus efeitos não foram separados.[11] Um gate final para modelos fortes é uma hipótese do artigo, não um arranjo medido nesse estudo.[11] O ponto não é ter menos testes. É colocar o feedback onde ele reduz erro sem comprar um custo recorrente que não muda o resultado.

Fonte

[11] Fonte: Martin Fowler, artigo de Naresh Jain