Harness² — Arnesamento de Tarefas Recorrentes
Adaptado de Harness²: Recursive Agent Harnessing for an Open World, reduzido ao caso em que uma execução já foi aceita e o objetivo é repeti-la.
Visão Geral
Suceder uma vez não é o mesmo que ser repetível. O run aceito é seu único ponto de referência confiável: ele tem uma entrega real, uma trajetória real e os lugares que o usuário editou pessoalmente.
O objeto de otimização é o processo do próximo run, não a entrega deste run. Portanto, a saída não é um relatório melhor — é um arnês (harness), um POP (SOP) e uma lista de verificação de regressão.
Quando Usar
- O usuário diz "faremos isso toda semana de agora em diante" ou "vamos travar esse processo"
- O mesmo tipo de tarefa foi feito pelo menos uma vez, e esse resultado foi aceito
- O processo vive na cabeça de alguém: quem executa qual script primeiro, qual etapa precisa de verificação humana, onde estão as armadilhas
- A mesma classe de tarefa continua falhando da mesma forma: atribuições de fonte ausentes, definições inconsistentes, retrabalho constante
Quando NÃO Usar
- Tarefa única → apenas execute-a
- Existe um avaliador real, teste unitário ou critério de aceitação computável → use-o; ele supera o contraste comportamental por uma ampla margem
- O usuário quer apenas uma mudança de formato ou definição, e já disse qual → edite o arnês diretamente, pule o loop de contraste
- O processo já está estável, e o custo ou a latência é restrito
O que é um arnês (harness)
Tudo ao redor do modelo que pode ser editado. Quatro são suficientes para rodar; oito é o conjunto completo:
| Componente | Papel | Mínimo |
|---|---|---|
| prompt de sistema | função, contrato de saída | ✅ |
| orientação de ferramentas | quando usar cada fonte de dados, como preencher argumentos | ✅ |
| skills | julgamento e procedimentos reutilizáveis | ✅ |
| guardrails | restrições rígidas (nunca inventar números, sempre citar fontes) | ✅ |
| memória | notas de domínio carregadas entre instâncias | |
| scripts | trabalho determinístico (conversão, dedup, agregação) | |
| subagentes | verificação ou recuperação paralela separada | |
| plugins | middleware (forçar uma auto-verificação a cada N passos) |
Um arnês deve existir como arquivos para ser comparado (diffed) e reutilizado. "Geralmente fazemos assim", deixado dentro de um chat, não pode ser solidificado.
O loop: Propor → Sondar → Compor
0. Congele a linha de base
Arquive o último run na íntegra: snapshot do arnês, trajetória completa (sequência de chamadas de ferramenta + artefatos intermediários), entrega final, o diff de edição do usuário, critérios de aceitação, snapshot de dados ou janela de tempo.
Os lugares que o usuário editou pessoalmente são locais de defeito de alta confiança — mais confiáveis do que qualquer suposição.
1. Propor
Leia a linha de base, então proponha dois candidatos, cada um com uma frase nomeando o defeito que visa:
- invariante: defeitos de processo — sem verificação cruzada, resultados intermediários nunca persistidos, falhas não repetidas, fontes não rotuladas, contexto estourado
- domínio: restrições profissionais desta classe de tarefa — definições consistentes, conversão de moeda ou unidade, janelas de tempo alinhadas
Você precisa de ambos para separar "doença geral" de "doença específica desta classe de tarefa." Com um único candidato você não pode atribuir o resultado.
2. Sondar
Repita com a mesma entrada, controlando variáveis: mesmo modelo, mesmo conjunto de ferramentas, mesmo snapshot de dados. Apenas o arnês muda.
Compare duas coisas:
- Delta comportamental em relação à linha de base: conjunto e ordem de ferramentas, contagem de passos, chamadas repetidas, erros e retentativas, se pontos de correção humana desapareceram, se intermediários foram persistidos, se as fontes estão totalmente atribuídas
- Consistência da repetição: execute novamente — a estrutura é a mesma? A métrica central da solidificação é a estabilidade, não o melhor-run-único
O contraste mostra "o comportamento mudou." Não mostra "o resultado está certo." Nunca confunda os dois.
3. Compor
Mantenha apenas mudanças que (a) ainda atendam aos critérios de aceitação após a repetição e (b) reduzam retrabalho ou correção humana. Manter o original é permitido — uma mudança sem evidência é ruído.
Registre cada decisão em uma linha: mudança | defeito visado | evidência observada | adotada / revisada / descartada.
4. Solidificar
Três artefatos; faltar qualquer um significa que não está solidificado:
harness/— os arquivos editáveisSOP.md— passos, pontos de verificação, quando um humano deve ser consultado, armadilhas conhecidas (mais de dez itens e ninguém lê)REGRESSION.md— a lista de verificação de aceitação a ser percorrida após o próximo run
Se uma mudança for adotada em várias rodadas, promova-a a um script ou skill independente.
Hierarquia de evidências
diff de edição do usuário > comparação com a entrega aceita > consistência da repetição > delta da trajetória > intuição
Não é evidência: um relatório mais longo ou mais detalhado, "o usuário não reclamou desta vez", o modelo afirmando que foi melhor.
Orçamento
Padrão k=1 mais uma repetição. A solidificação compensa ao longo do tempo, então amortize-a entre as rodadas: sonde um candidato durante cada run recorrente, em vez de gastar 3× de uma vez para executar todos os ramos paralelos.
Bandeiras vermelhas — pare quando vir uma
- Herdar o arnês anterior por inteiro sem ler o diff de edição do usuário
- Repetir com uma entrada, modelo ou snapshot de dados diferente e ainda afirmar "está melhor"
- Concluir a partir de uma única repetição sem descartar a aleatoriedade
- Mudar cinco componentes de uma vez, tornando a atribuição impossível
- Um POP de 20 itens que ninguém seguirá na próxima vez
- Escrever um truque de sorte único como entrada invariante
Erros comuns
| Erro | Consequência | Correção |
|---|---|---|
| Otimizar antes de arquivar | linha de base perdida, mudanças não atribuíveis | congele a linha de base primeiro |
| "Lê-se melhor" como evidência | você solidifica uma preferência, não um processo | vincule a uma observação concreta |
| Mudanças apenas no prompt, sem pontos de verificação | humanos ainda corrigem manualmente na próxima vez | pareie cada defeito com um ponto de verificação |
| POP escrito como um diário de viagem | ninguém lê, então nada é solidificado | escreva apenas pontos de decisão e armadilhas |