Engenharia de harness: como tirar as garantias dos agentes LLM dos prompts e levá-las para o código

Pesquisadores publicaram no arXiv, em 10 de julho de 2026, um preprint com um padrão de engenharia de harness para agentes LLM corporativos. As garantias determinísticas saem dos prompts e vão para o código e para artefatos de validação, o que permite construir sistemas auditáveis sem perder qualidade nas respostas.

O que há de errado com a abordagem baseada só em prompts

Aplicações corporativas de LLM costumam começar como protótipos em que o comportamento é definido inteiramente por prompts e pelo contexto de RAG. Na passagem para produção surgem novos requisitos: limites de fontes, roteamento de entidades, contratos de resposta e rastreamentos reproduzíveis. Os prompts lidam mal com isso.

Os autores fizeram um experimento de controle: com o modelo inalterado e apenas a camada de enforcement trocada, os prompts deixavam violações chegar ao usuário, já que linguagem de recomendação inadequada e vazamentos de traces internos não eram bloqueados. O harness eliminou os dois problemas por completo, sem reduzir a utilidade do sistema.

Como funciona o padrão harness

A ideia central é tirar o comportamento determinístico dos prompts e levá-lo para código, manifestos, esquemas e artefatos de validação em torno de uma "composition boundary" substituível. As afirmações das fontes continuam sendo a autoridade para as respostas em runtime, e o código, não as instruções do prompt, verifica todos os contratos. Essa arquitetura permite trocar o modelo sem reconstruir o sistema inteiro.

O padrão foi testado em um recorte público de dados de cinco grupos corporativos coreanos (25 empresas listadas). Principais resultados:

• 5 conglomerados coreanos, 25 empresas de capital aberto: o conjunto de dados de teste
• 3 modelos hosted usados no experimento de troca de modelo
• 270/270 requisições passaram na verificação de contratos na troca de modelo
• 120/120: utilidade das respostas com a abordagem harness
• 88/120: utilidade com um guardrail externo bolt-on, com a mesma segurança

Um controle de fault-injection confirmou que os validadores funcionam: em todos os cenários, eles identificaram corretamente os contratos quebrados de propósito.

Por que o harness é melhor que guardrails externos?

Um guardrail externo bolt-on previne violações tão bem quanto o harness, mas ao custo de recusas excessivas. Com apenas o guardrail externo, o sistema deu 88 respostas úteis de 120, enquanto o harness manteve 120/120.

"Somente o enforcement controlado pelo código garante segurança e

preserva a utilidade total", resumem os autores.

A diferença fundamental: o harness é incorporado à arquitetura e entende o contexto da requisição, por isso não rejeita respostas legítimas. O guardrail externo vê apenas a saída final e precisa pecar pelo excesso de cautela, o que resulta na perda de 27% das respostas úteis.

O que isso significa

A engenharia de harness oferece um padrão reutilizável para sair de um protótipo de LLM e chegar a um sistema de produção auditável. Prompts não garantem o cumprimento de contratos em ambiente corporativo: são necessários artefatos de controle versionados no código. Para equipes que constroem agentes LLM corporativos, é um guia prático: as garantias de comportamento devem viver no código, não nas instruções.

Perguntas frequentes

Em quais dados o harness foi testado?

Os autores usaram um recorte público de dados de cinco grandes grupos corporativos coreanos, com 25 empresas listadas. Os testes cobriram 270 requisições pela composition boundary em três modelos hosted diferentes.

Qual a diferença entre o harness e um guardrail bolt-on?

O guardrail bolt-on atinge o mesmo nível de segurança, mas gera recusas excessivas: 88 respostas úteis de 120, contra 120/120 do harness. O harness é incorporado à arquitetura e entende o contexto da requisição, por isso não sacrifica qualidade em nome da segurança.