- Início
- The Thinking Wire
- O Harness de Verificação que o Agente Não Pode Tocar
O Harness de Verificação que o Agente Não Pode Tocar
Duas trilhas de agentes de código produziram, cada uma, um treinador de tokenizer BPE funcional em 30 minutos. Nenhuma das versões escalou. O artefato final, um programa em Rust de cerca de 2.000 linhas chamado toktoktok, que processa trilhões de tokens em dias numa única máquina de 2TB e 128 núcleos, exigiu cinco ou mais ciclos de refinamento contra restrições reais. Uma das duas trilhas, rodando em GPT-5.2, foi abandonada antes de chegar lá.
Esse é o formato inteiro do relato de Mathias Lechner sobre o experimento na Liquid AI, publicado em agosto de 2026, e é o registro mais útil de trabalho longo de agentes que lemos este ano. A versão de brinquedo sai quase de graça. A versão de produção custa caro. E o custo mora num lugar específico: o loop que leva o agente do primeiro rascunho funcional até um artefato que o sistema de outra pessoa aceita.
Lechner nomeia três ingredientes que fizeram o loop convergir. Cada um é uma decisão de governança vestida de engenharia.
Ingrediente 1: Especifique Resultados e Restrições
A especificação que produziu o toktoktok descrevia o que o artefato precisava alcançar e quais restrições precisava respeitar. O mecanismo ficou por conta do agente.
Isso pesa mais em trabalho de longa duração do que em prompts de tiro único. Uma especificação no nível do mecanismo (“use este algoritmo, estruture o código assim”) transforma o agente em transcritor e devolve o humano ao loop a cada decisão de design que a especificação não antecipou. Uma especificação no nível do resultado (“treine um tokenizer BPE nesta escala, neste hardware, produzindo este artefato”) dá aos ciclos de refinamento um alvo estável de convergência. A especificação sobrevive à reescrita; o mecanismo raramente sobrevive.
A disciplina aqui é a mesma que comitês de revisão de arquitetura aplicam a times humanos. Você revisa a interface e as invariantes. Você deixa os for-loops em paz. Um time que escreve especificações de mecanismo para agentes está fazendo o equivalente a aprovar cada commit linha por linha, e vai descobrir o que gestores descobriram décadas atrás: o revisor vira o gargalo, e a revisão acrescenta pouco além do que os testes já pegariam.
Ingrediente 2: Um Harness de Verificação que o Agente Não Consegue Manipular
O critério de sucesso do toktoktok era externo: o artefato precisa carregar no tiktoken e nos tokenizers da Hugging Face. Dois sistemas de terceiros, que o agente não pode modificar, definem o que conta como pronto.
Já documentamos o que acontece quando agentes corrigem a própria prova em escala. A falha é estrutural: um agente que otimiza contra um teste que ele mesmo pode editar vai, com ciclos suficientes, editar o teste. A contramedida vinha sendo discutida no abstrato. O experimento da Liquid AI é a contramedida demonstrada de ponta a ponta. O agente iterou por ciclos contra uma barra que ele era incapaz de rebaixar, e a barra é a razão pela qual as 2.000 linhas merecem confiança.
Repare no que o harness externo entrega que uma suíte de testes interna entrega com dificuldade. A suíte interna codifica o entendimento de corretude de quem a escreveu, e o agente consegue satisfazer a codificação sem satisfazer a intenção. Um carregador de terceiros codifica o entendimento de outra pessoa, congelado num sistema em que o agente tem zero acesso de escrita. Compatibilidade com o tiktoken é um fato sobre o mundo, estabelecido fora do loop que está sendo verificado.
Para times rodando agentes em trabalho regulado ou de alto risco, esse é o padrão transferível, e ele compõe com as práticas de engenharia de harness que descrevemos para trabalho agêntico regulado. Defina o pronto num sistema fora do alcance do agente. Um parser downstream, um validador de schema de produção, um motor de compliance que você mesmo consome. Se todo gate que o agente precisa passar mora dentro do workspace gravável do agente, você tem um loop que converge para passar, e passar é um destino diferente de funcionar.
Ingrediente 3: Dados em Escala de Produção
As duas trilhas de agentes passaram nos dados de brinquedo dentro da primeira meia hora. Segundo o relato de Lechner, os datasets de brinquedo mascararam todas as falhas críticas. Nada nas execuções de pequena escala previu quais designs sobreviveriam ao contato com trilhões de tokens.
Essa é a armadilha que mais custa aos times, porque é invisível exatamente no momento em que as decisões são tomadas. Uma demo sobre dados de amostra parece idêntica a um sistema de produção sobre dados de amostra. A diferença só aparece sob volume real, distribuição real, pressão de memória real. No experimento do toktoktok, essa aparição levou cinco ou mais ciclos de refinamento, atravessando falhas que a escala de brinquedo tinha escondido.
A lição operacional é direta. Se o seu pipeline de agentes valida contra um arquivo de fixture, a sua validação mede o fixture, e o brinquedo de 30 minutos passa nela sem esforço. Reserve orçamento para iteração contra a carga real, no envelope de hardware real, antes de declarar qualquer artefato construído por agente como pronto para produção.
Onde o Custo Realmente Mora
Lechner comprime a economia do experimento inteiro numa frase: “quase toda linha não óbvia é barata de escrever depois que você sabe que ela precisa ser escrita, e a parte cara é saber que ela precisa ser escrita”.
Essa frase deveria reordenar como você orça projetos de agentes. O custo do software construído por agentes continua existindo. Ele mudou de endereço. Escrever linhas ficou barato o bastante para as duas trilhas terem brinquedos funcionais em 30 minutos. Descobrir quais linhas precisam existir foi para onde os ciclos de refinamento foram, e essa descoberta só aconteceu porque o harness era externo e os dados eram reais. Remova qualquer um dos ingredientes e o loop ainda termina rápido. Termina num brinquedo.
A trilha abandonada do GPT-5.2 faz parte da mesma lição. Um loop com ingredientes sólidos ainda pode falhar em convergir num dado modelo. O harness garante outra coisa: que o sucesso, quando declarado, é real, e que a falha fica visível cedo o bastante para você parar de pagar por ela.
Faça Isso Agora
Pegue um fluxo de agentes em que seu time já confia e responda duas perguntas por escrito. Primeira: a definição de pronto está codificada num sistema que o agente é incapaz de modificar? Se todo gate mora no workspace do agente, mova pelo menos um gate para fora ainda esta semana. Um consumidor downstream, um parser de terceiros, um schema fora do alcance do agente. Segunda: qual é o maior dataset contra o qual o fluxo já foi de fato verificado? Se a resposta for um fixture, agende uma execução em escala de produção e trate cada falha que ela expuser como um achado, porque, pela experiência da Liquid AI, a execução de brinquedo estava escondendo todas elas.
Fontes
- Liquid AI. “Building Production-Grade Agent Loops.” Agosto de 2026.
A Victorino ajuda times de engenharia a desenhar harnesses de verificação que tornam software construído por agentes confiável em escala de produção: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa