Engenharia de prompt, contexto, loop e grafo acabaram se revelando como peças da mesma máquina. O harness é onde elas finalmente convivem.
Cada fase do desenvolvimento com IA ganhou seu próprio cargo. A engenharia de prompt veio primeiro, quando a arte toda consistia em encontrar a frase certa.
A engenharia de contexto surgiu logo 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 está se espalhando agora é engenharia de harness, e é o primeiro que explica todos os outros.
Um harness é tudo o que envolve 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 agendamento que o desperta 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 sob seu controle.
1/ Sete Engenharias, Uma Máquina
Disciplina
A pergunta que ela responde
Onde vive no harness
Engenharia de prompt
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 loop
O que inicia uma execução e o que a encerra
O executor: gatilhos, condições de parada, orçamentos
Engenharia de grafo
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 dentro de um prompt.
Esse último ponto carrega a maior parte do peso.
O 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 você o escreveu, mas o próximo modelo lê o mesmo parágrafo de maneira diferente.
2/ Anatomia de um Harness
O hábito mais útil que adquiri é 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. Todo o resto é escrito para não se importar com o que essa linha diz. Essa é toda a história sobre portabilidade.
permissions: importa mais do que tools:, embora apareça mais abaixo no arquivo. Escrever o que o agente pode alterar e 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 na frente.
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 possíveis 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 o Kimi K3 É o Motor Que Eu Colocaria Nele
O que o harness precisa
O que o Kimi K3 oferece
Um executor capaz de distribuir tarefas
Agent Swarm: até 300 agentes trabalhando no mesmo problema simultaneamente, sem escrever um orquestrador
Código forte o suficiente para escrever suas próprias verificações
#1 no Frontend Code Arena com 1.679, à frente do Fable 5 (1.631) e do GPT-5.6 Sol (1.618), liderando 6 de 7 domínios
Um motor que melhora por baixo dos panos
De #18 para #1 em uma única atualização de julho
A primeira linha importa mais do que parece. Quase todo harness caseiro cresce e ganha um orquestrador feito à mão em algum momento, e esse costuma ser 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 painel que lê 40-runs. Um motor que lidera a arena de frontend acerta essas coisas na primeira tentativa com muito mais frequência.
A terceira linha é a defesa da engenharia de harness em um único dado. Quando um modelo sobe dezessete posições da noite para o dia, um harness coloca essa subida 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. É nos hooks que um harness deixa de ser apenas uma estrutura 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 de qualquer coisa sair da máquina
Mantém na fila até que você aprove
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 o 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
Somente o hook on_fail 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 de Trabalho
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. O post_run acrescenta o registro, e o loop para sozinho, bem dentro do orçamento de 45 minutos definido na configuração.
Às 07:30, você lê um arquivo e toma duas decisões. Esse é todo o custo matinal de executar a engenharia de loop e a engenharia de grafo dessa forma, e é exatamente o objetivo 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 de novo. O que quebrar era harness vivendo 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 ter 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 agendamento
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 atual
Um cliente cujas execuções já registram em 40-runs
Template de harness de nicho
A pasta e o yaml empacotados para um setor: pesquisa, recrutamento, compliance
O mesmo harness comprovado em dois mercados diferentes
Eu construiria o segundo canal primeiro. Cada grande lançamento embaralha o ranking; só o K3 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.
Resumo Rápido
Engenharia de prompt, contexto, ferramentas, loop, grafo e avaliação acabam 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 à frente das ferramentas e o verificador fora do agente. Então, o próximo salto no ranking será uma mudança de configuração, não uma reconstrução.
E se você achou isso útil:
- Marque este artigo. Os links mudam e novos repositórios surgem semanalmente; você vai 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 eu compartilho meus prompts brutos, skills personalizados e alfas que ainda são cedo demais para o X
