Discuti com o meu harness e perdi
O dcode barrou três vezes uma instalação que eu tinha autorizado por escrito, e é disso que harness engineering trata.
Eu discuti com um software que eu mesmo escrevi e perdi, o que já seria constrangedor se não fosse, no fim das contas, a melhor notícia que eu recebi sobre o projeto em meses.
O dcode é o harness que eu escrevo. Cada linha saiu daqui, o que me colocava numa posição que eu confundi com autoridade. Pedi que instalasse uma ferramenta e autorizei por escrito, com todas as letras, do jeito solene com que a gente autoriza estagiário a mexer em produção, e ele barrou. Achei que fosse detalhe do caminho, tentei pelo gerenciador de pacotes, barrou de novo. Mandei copiar os arquivos direto, na marra, que é o equivalente adulto de chutar a porta, e aí barrou pela terceira vez. Passei então uma quantidade de tempo que eu prefiro não quantificar tentando convencer uma coisa que, por desenho, não deveria ser convencível justamente por mim.
Onde a autorização morava e onde a permissão faltava
A resposta estava ali desde o começo, embora tenha levado uns bons minutos de orgulho ferido para chegar: a autorização que eu dei morava numa conversa, e a permissão que faltava morava no harness, que são duas camadas com propósitos distintos, sendo que a de baixo só vale alguma coisa precisamente porque não obedece a de cima. Se bastasse me convencer para liberar a execução, aquilo não seria uma camada de segurança, seria um enfeite com sotaque de segurança.
O que separa um harness bom de um harness insuportável, aliás, não é o bloqueio em si, e sim o que vem depois dele. O agente não ficou tentando ângulos até algum passar, como quem testa maçanetas num corredor. Ele parou, explicou o que precisava e me devolveu o comando para eu rodar na mão. Um harness que barra mas vai te ensinando a contornar seria pior do que não ter harness nenhum, porque treinaria todo mundo, inclusive eu, a enxergar a fronteira como obstáculo de trânsito.
Depois disso, uma skill de terceiro tentou mandar no agente
Instalei uma skill escrita por outra pessoa, e na primeira execução o script dela imprimiu texto dirigido ao agente: instruções mandando desconsiderar parte das regras que ele tinha recebido, mais a afirmação de que instalar a ferramenta já constituía autorização para ela disparar subagentes por conta própria.
Não era ataque. Era um autor tentando garantir que a ferramenta dele funcionasse como projetada, o que é uma motivação absolutamente banal e até simpática. Mas o mecanismo é idêntico ao de um ataque, e é justamente aí que mora a lição, porque o que separa injeção maliciosa de conveniência de fornecedor é a intenção de quem escreveu, e intenção, até segunda ordem, não compila.
Se o harness tratar saída de ferramenta como instrução, toda dependência vira vetor: todo README, todo log, todo JSON de resposta de API, todo arquivo que entrar no repositório. A regra tem que ser estrutural em vez de caso a caso — instrução chega pelo canal do humano, e todo o resto é dado sobre o mundo, por mais que esteja escrito no imperativo e com pontuação convincente.
O que é o harness, agora que dá para dizer sem abstração
O harness é tudo que existe entre o modelo e o mundo: quais ferramentas ele enxerga, o que ele executa sem perguntar, o que sobrevive de uma sessão para a outra, o que dispara sozinho depois de cada edição e quanto do histórico volta a cada rodada.
Nada disso é prompt, e tudo isso muda o resultado mais do que o prompt muda. Um modelo excelente num harness ruim escreve código correto no diretório errado, apaga o arquivo que não devia com a mesma serenidade com que apagaria o certo, repete dez vezes uma chamada que já foi bloqueada nove, e encerra a sessão sem que nada do que descobriu no caminho sobreviva para a próxima.
Hooks são a parte que ninguém precisa lembrar de pedir
Um hook roda porque um evento aconteceu, e não porque alguém lembrou na hora certa: formatar depois de escrever, rodar o detector depois de mexer em interface, salvar estado quando a sessão termina.
Parece configuração e é, na prática, a diferença entre uma regra que você escreveu num arquivo de memória e uma regra que o sistema executa — a primeira depende de o agente lembrar dela, e a segunda não depende de nada. Quase toda instrução que você repete três vezes é um hook que você ainda não escreveu.
O que eu meço, já que acertar não é a métrica
A pergunta útil não é se o modelo acertou, porque modelo bom erra e modelo ruim acerta por sorte com frequência incômoda. A pergunta é se o harness deixou o erro barato: dá para desfazer, o dano ficou contido no que estava em escopo, o agente percebeu sozinho ou precisou de mim para perceber, e sobrou registro de por que a decisão foi tomada.
Um harness que responde sim para os quatro tolera um modelo pior, e um que responde não para os quatro não é salvo pelo melhor modelo do mundo.
A alavanca que sobra
Harness engineering é tratar o entorno como o artefato principal, projetando fronteira, permissão, memória e disparo automático com o mesmo cuidado com que se projeta um esquema de banco de dados.
E tem uma vantagem prática sobre a alternativa, que é a única razão pela qual eu passei a gastar mais tempo nisso do que escolhendo modelo: o modelo você não controla, e ele muda sozinho a cada dois meses sem te avisar. O harness é seu.