A engenharia de prompts, contexto, loops e grafos acabou sendo apenas uma peça da mesma máquina. O harness é onde elas finalmente vivem juntas.
Cada fase da construção com IA ganhou seu próprio cargo. A engenharia de prompts veio primeiro, quando o ofício inteiro consistia em encontrar a frase certa.
A engenharia de contexto surgiu depois, quando ficou óbvio que a frase importava menos do que tudo o que era carregado ao redor dela. Neste verão foi a vez dos loops e, poucas semanas depois, dos grafos.
O nome que se espalha agora é engenharia de harness, e é o primeiro que explica todos os outros.
Um harness é tudo o que cerca o modelo: as ferramentas que ele pode chamar, os arquivos que lê antes de qualquer coisa, os diretórios onde pode escrever, as verificações que sua saída deve passar, o cronograma que o acorda e a regra que encerra a execução.
Cada disciplina anterior acaba sendo um único componente desse quadro, construído separadamente e batizado com seu próprio nome.
Comecei a prestar atenção por uma razão prática. O modelo subjacente continua mudando, às vezes subindo dezessete posições no ranking em uma única atualização, e o harness é a única parte do sistema que permanece sua.
1/ Sete Engenharias, Uma Máquina
Disciplina
A pergunta que ela responde
Onde vive no harness
Engenharia de Prompts
O que exatamente estou pedindo
SKILL.md, a especificação da tarefa carregada primeiro
Engenharia de Contexto
O que o modelo vê em cada etapa
O montador de contexto: restrições, esquemas, páginas recuperadas
Engenharia de Ferramentas
Com o que ele pode interagir e em qual formato
Definições de ferramentas com entradas e saídas tipadas
Engenharia de Loops
O que inicia uma execução e o que a termina
O executor: gatilhos, condições de parada, orçamentos
Engenharia de Grafos
O que ele lembra e como as coisas se conectam
A camada de memória: nós, arestas tipadas, aliases
Engenharia de Avaliação (Eval)
Como um resultado é rejeitado
O verificador, fora do controle do agente
Engenharia de Harness
O que mantém tudo isso unido
O quadro, as permissões e os hooks
Leia a tabela de cima para baixo e você tem uma história. Leia de baixo para cima e você tem uma arquitetura: a engenharia de harness é o trabalho de decidir onde cada uma das outras seis vive, para que nenhuma delas acabe escondida em um prompt.
Esse último ponto carrega a maior parte do peso.
Um prompt é o lugar mais fácil para colocar qualquer coisa, então tudo acaba migrando para lá: o formato de saída, a regra de parada, as correções da semana passada, a lista de coisas que o agente nunca deve tocar. Funciona perfeitamente no modelo para o qual foi escrito, mas o próximo modelo lê o mesmo parágrafo de forma diferente.
2/ Anatomia de um Harness
O hábito mais útil que desenvolvi é escrever todo o harness em um único arquivo de configuração, para que nada importante fique implícito:
1# harness.yaml2model: kimi-k3 # uma linha. tudo abaixo sobrevive a uma troca3tools: [browser, fs, shell, search]4permissions:5 write: [./10-returns, ./20-graph, ./40-runs]6 ask_first: [send, publish, pay, delete]7context:8 always: [SKILL.md, CONSTRAINTS.md, SCHEMA.md]9 per_agent: return_schema10runner:11 trigger: cron "0 2 * * *" # noturno, enquanto você dorme12 stop: 40 verified nodes OR 3 passes with nothing new13 budget: { agents: 300, minutes: 45, retries: 2 }14memory:15 graph: ./20-graph16 aliases: ./aliases.csv17verify:18 - script: checks/schema.py19 - agent: reviewer, fresh context20hooks:21 pre_tool: hooks/pre_tool.sh22 post_run: append 40-runs/
Três linhas nesse arquivo fazem a maior parte do trabalho.
model: é uma linha propositalmente. Tudo o mais é escrito para não se importar com o que essa linha diz. Essa é toda a história da portabilidade.
permissions: importa mais do que tools:, embora esteja mais abaixo no arquivo. Escrever o que o agente pode alterar e sobre o que ele precisa perguntar antes é o que separa um sistema que você deixa rodando durante a noite de um que você fica observando sentado.
verify: tem duas entradas por um motivo. O script não custa nada e pega qualquer erro mecânico. O revisor é um segundo agente que nunca viu o primeiro trabalhar, porque um agente avaliando sua própria saída encontra todas as razões para aprová-la.
No disco, o harness é uma pasta, e cada engenharia da tabela ganha seu próprio endereço dentro dela.
3/ Por Que Kimi K3 É o Motor Que Eu Colocaria Nele
O que o harness precisa
O que Kimi K3 oferece
Um executor capaz de distribuir tarefas
Agent Swarm: até 300 agentes em um problema ao mesmo tempo, sem escrever um orquestrador
Código forte o suficiente para escrever suas próprias verificações
#1 na Frontend Code Arena com 1.679, à frente do Fable 5 (1.631) e GPT-5.6 Sol (1.618), liderando 6 de 7 domínios
Um motor que melhora sob seus pés
De #18 para #1 em uma única atualização de julho
A primeira linha importa mais do que parece. Quase todo harness caseiro cresce com um orquestrador feito à mão em algum momento, e geralmente é o arquivo mais frágil da pasta. Com o swarm, a distribuição vira uma linha de orçamento, agents: 300, e o harness só precisa lidar com o que volta.
A segunda linha importa porque um harness é principalmente código que o modelo escreve para você: scripts de hook, verificações de esquema, o pequeno dashboard que lê 40-runs. Um motor que lidera a arena frontend acerta essas coisas na primeira tentativa com muito mais frequência.
A terceira linha é o argumento para a engenharia de harness em um único dado. Quando um modelo sobe dezessete posições da noite para o dia, um harness coloca esse salto para funcionar no mesmo dia, porque a única linha que precisa mudar é model.
4/ Hooks: Os Reflexos
Um hook é um script curto que o harness executa em um momento fixo, independentemente do que o modelo decidir fazer. É onde um harness deixa de ser um layout de pastas e começa a se comportar como um sistema de segurança.
Hook
Quando dispara
O que faz
pre_tool
Antes de qualquer chamada de ferramenta
Bloqueia escritas fora da lista de permissões
post_tool
Depois de cada retorno
Executa a verificação de esquema e rejeita saídas malformadas na hora
pre_send
Antes que qualquer coisa saia da máquina
Mantém em fila até você aprovar
on_fail
Após um resultado rejeitado
Anexa o motivo da falha à nova tentativa
post_run
Quando a condição de parada é atingida
Acrescenta o registro da execução a 40-runs e compara diferenças no grafo
O hook pre_tool da primeira linha cabe em cinco linhas:
1# hooks/pre_tool.sh2case "$TARGET" in3 ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;4 *) echo "blocked: $TARGET is outside the write list"; exit 1 ;;5esac
O hook on_fail sozinho muda a economia de um loop. Uma nova tentativa que leva consigo o motivo pelo qual a última falhou é uma correção. Sem esse motivo, o loop paga pelo mesmo erro uma segunda vez.
5/ Como É Uma Noite
Junte todas as peças e o harness se comporta como um turno da noite que segue regras. Às 02:00 o gatilho dispara e a consulta de lançamento seleciona todos os nós que precisam de trabalho. O swarm se distribui, um agente por nó.
Retornos que não passam no esquema são rejeitados pelo post_tool antes de chegarem ao grafo, e cada nó rejeitado tenta novamente uma vez com o motivo da falha anexado. Quando um agente tenta escrever fora de sua pasta, o pre_tool o impede sem acordar ninguém.
Nós mesclados e arestas tipadas chegam a 20-graph. Um e-mail rascunhado chega a pre_send e espera. post_run acrescenta o registro, e o loop para por conta própria, bem dentro do orçamento de 45 minutos da configuração.
Às 07:30 você lê um arquivo e toma duas decisões. Esse é todo o custo matinal de executar a engenharia de loops e a engenharia de grafos dessa maneira, e é todo o ponto do harness: tudo o que podia rodar sem você rodou, e as poucas coisas que precisavam de você estão esperando em um só lugar.
6/ O Teste de Troca
A auditoria mais rápida de qualquer configuração de agente: mude a linha do modelo e rode novamente. O que quebrar estava com o harness no lugar errado.
O que quebra após a troca
Onde estava escondido
Onde deveria estar
O formato de saída desvia
"always answer as JSON" no prompt
Um esquema de retorno mais um script que rejeita qualquer outra coisa
As execuções param de terminar sozinhas
"keep going until it's thorough"
Uma condição de parada baseada em contagens
As correções da semana passada sumiram
O histórico do chat
CONSTRAINTS.md, carregado a cada execução
A mesma empresa aparece três vezes
O julgamento do modelo
aliases.csv, verificado antes da mesclagem
Ele escreve em algum lugar que não deveria
Uma frase educada no prompt
Uma lista de permissões e um hook pre_tool
Uma configuração que passa no teste de troca é portátil, e ser portátil é o que faz valer dinheiro.
Quanto Custa e Quanto Paga
Empresas investem trimestres inteiros em plataformas internas de agentes. Um harness funcional é uma pasta, um arquivo de configuração e cinco scripts curtos, rodando em uma assinatura do Kimi. Essa lacuna é a oportunidade.
Canal
O que paga
O que você precisa primeiro
Configuração de harness para uma pequena equipe
Uma taxa única de quatro dígitos pela configuração, hooks e verificador em torno do fluxo de trabalho deles
Um harness seu, rodando em um cronograma
Retainer de dia de lançamento
Uma taxa mensal para rodar o teste de troca em cada grande lançamento de modelo e mover a equipe para o líder
Um cliente cujas execuções já registram logs em 40-runs
Template de harness de nicho
A pasta e o yaml empacotados para uma indústria: pesquisa, recrutamento, compliance
O mesmo harness comprovado em dois mercados diferentes
O segundo canal é aquele que eu construiria primeiro. Cada grande lançamento embaralha o ranking, o K3 sozinho subiu dezessete posições em uma atualização, e toda equipe com um harness precisa de alguém cujo trabalho seja rodar o teste de troca no dia do lançamento.
A Versão Curta
A engenharia de prompts, contexto, ferramentas, loops, grafos e avaliação acaba sendo componentes de uma única máquina, e a engenharia de harness é decidir onde cada um deles vive.
Coloque o modelo atrás de uma linha, as permissões na frente das ferramentas e o verificador fora do agente. Então, o próximo salto no ranking será uma mudança de configuração em vez de uma reconstrução.
E se você achou isso útil:
- Marque este artigo nos favoritos. Os links mudam e novos repositórios surgem semanalmente, você precisará disso como referência
- Para análises semanais profundas sobre arquitetura de IA, trading quantitativo e a economia de agentes, siga-me: @polydao
- Junte-se ao Canal TG: Buzzoni Notes - aqui compartilho meus prompts brutos, skills personalizados e alfas que são cedo demais para o X
