Pular para o conteúdo
· 6 min de leitura

Harness engineering: por que o ambiente do agente importa mais que o modelo

Modelo é o motor. O harness é o carro inteiro. Trocar de modelo sem mexer no harness é como tunar a injeção sem checar os pneus.

Victor Dantas Comitê de IA · Bamse

Toda conversa sobre agentes começa na mesma pergunta: qual modelo usar. É a pergunta errada, ou pelo menos a menos importante. O modelo é o motor. O harness - o sistema inteiro que envolve o modelo - é o carro. E eu já vi muito motor de Fórmula 1 patinar dentro de um carro mal montado.

Harness engineering é a disciplina de construir tudo que fica EM VOLTA do modelo: o system prompt e as instruções, o conjunto e a qualidade das ferramentas, as skills, os hooks que rodam antes e depois de cada chamada de ferramenta, as permissões, a gestão de contexto e memória, e os loops de feedback - testes, verificação, retentativa. É onde a confiabilidade em produção é ganha ou perdida.

O motor é a parte fácil

Modelo de fronteira você troca numa linha de config. O que não troca numa linha é o harness: as ferramentas que você desenhou, os guardrails que você escreveu, o contexto que você decidiu mostrar. Um harness bom faz um modelo mediano virar confiável. Um harness ruim desperdiça o melhor modelo do mercado - ele tem o poder, mas não tem onde apoiar o pé.

"Trocar de modelo é tunar a injeção. Se os pneus estão carecas, o carro continua saindo da pista na mesma curva."

Onde o harness decide o jogo

Três decisões de harness que mudaram o comportamento dos nossos agentes em produção, na ordem em que mais doeram.

Primeiro, desenho de ferramenta. Tínhamos uma ferramenta genérica de "rodar query" que o agente acertava em metade das vezes. Quebramos ela em ferramentas estreitas, com nomes que dizem exatamente o que fazem e argumentos que não deixam o agente inventar. A taxa de acerto subiu sem trocar uma vírgula do modelo. Ferramenta é a interface do agente com o mundo: nome ruim e argumento ambíguo são bug de produto, não de IA.

Segundo, um hook que roda DEPOIS de cada edição de arquivo e formata o código automaticamente. O agente não precisa lembrar de rodar o formatter, não gasta um turno nisso, e o diff sai limpo toda vez. É determinístico - não depende do modelo estar de bom humor. Neste site mesmo a formatação roda assim, num hook pós-edição, não na cabeça do agente.

Terceiro, um hook que roda ANTES de cada comando de shell e bloqueia padrões perigosos. Ele sai com código de saída 2, que nega a chamada de verdade e devolve o motivo pro agente ler - diferente de um aviso que só reclama e deixa passar. É a diferença entre "por favor não faça isso" e "o sistema não vai deixar você fazer isso".

* Regra de Bolso

Antes de pedir um modelo melhor, pergunte se o agente tem as ferramentas certas, os guardrails certos e o contexto certo. Quase sempre o problema está no harness, não no motor.

O melhor do harness é que ele é seu. O modelo é um produto de outra empresa, atualizado e depreciado fora do seu controle. As ferramentas, os hooks, as instruções e os loops de feedback são código que você escreve, versiona e testa (o meu fica reunido no Harness Engineering Playbook). É aí que mora a vantagem durável - e é por isso que eu gasto muito mais tempo no carro do que escolhendo o motor.

Gostou desse escrito?

Posso passar essas e outras notas para o seu time num formato de workshop ou de mentoria recorrente pelo programa de Mentoria de IA da Bamse.

Conversar sobre mentoria
Próximo Escrito

Skills do Claude Code: quando criar uma - e quando NÃO criar