Engenharia de Prompt vs Engenharia de Contexto vs Engenharia de Harness

Equipes de agentes de envio em produção continuam redescobrindo a mesma lição: prompts inteligentes não são suficientes. O trabalho duradouro se divide em três partes—como você pergunta, o que o modelo vê e o software que envolve o ciclo.

Três camadas, um sistema

Em 2023, "engenharia de prompt" foi frequentemente tratada como o trabalho completo: encontrar a mensagem mágica do sistema, adicionar alguns exemplos, enviar. À medida que os agentes ganharam ferramentas, memória e efeitos colaterais, as falhas se deslocaram. Modelos alucinaram porque o catálogo de serviços estava ausente, não porque um adjetivo estava errado. Eles queimaram orçamentos porque cada turno enviava um megabyte de instruções. Eles tomaram ações destrutivas porque nada na execução dizia não.

Três termos agora descrevem trabalhos complementares—cada um resolve uma classe diferente de falha:

• Engenharia de prompt — moldar o comportamento por meio de instruções e exemplos na mensagem que você envia agora.
• Engenharia de contexto — decidir quais fatos, histórico e saída de ferramentas entram na janela de contexto finita antes que o modelo raciocine.
• Engenharia de harness — construir a execução em torno do modelo: loops de ferramentas, tentativas, políticas, observabilidade e portões humanos para que a saída probabilística se torne um software confiável.

Confundi-los leva a erros caros: polir a prosa enquanto o agente ainda não consegue ver os dados de propriedade, ou enfiar mais tokens na janela enquanto nada verifica os resultados da ferramenta antes que uma mudança em produção ocorra.

Harness do lado de fora, prompt mais próximo do modelo—cada camada tem um teto se a camada abaixo estiver ausente.

Engenharia de prompt: a pergunta

A engenharia de prompt é a arte de instruir o modelo de forma clara: papel, restrições, formato de saída, tom e quando recusar. Exemplos de poucos disparos, empurrões de cadeia de pensamento e saídas estruturadas (esquema JSON, dicas de escolha de ferramentas) vivem aqui. Isso importa. Pedidos ambíguos produzem ações ambíguas.

Também tem um teto. Prompts não podem inventar fatos que nunca foram recuperados. Eles não podem desfazer uma ferramenta que retorna JSON desatualizado. Eles não podem substituir um fluxo de aprovação quando o raio de explosão é um banco de dados de clientes. A engenharia de prompt otimiza como o modelo interpreta o que já possui —não se aquele material é verdadeiro, completo ou seguro para agir.

Invista aqui quando: as saídas são inconsistentes para as mesmas entradas, a formatação quebra analisadores a jusante, ou o modelo precisa de limites explícitos ("nunca delete", "sempre cite o campo de origem").

Pare aqui quando: falhas se rastreiam a dados ausentes, ferramentas erradas ou efeitos colaterais não governados—nenhuma quantidade de reformulação corrige um catálogo em branco.

Engenharia de contexto: a janela

A engenharia de contexto trata a janela de contexto como um recurso escasso e caro que você monta deliberadamente. Em vez de um prompt de sistema estático, você escolhe—por turno—o que o modelo deve ver: documentos relevantes, metadados de serviço, notas de incidentes recentes, resultados de ferramentas anteriores, histórico de conversas compactado e espaço negativo (o que omitir para que o sinal permaneça alto).

Técnicas típicas incluem recuperação sobre uma base de conhecimento, buscas cientes de grafo (proprietários, dependências, ambientes), sumarização e compactação de longas conversas, divulgação progressiva (metadados primeiro, instruções completas apenas quando uma habilidade é ativada) e higiene na saída da ferramenta (truncar logs, remover segredos, anexar proveniência). O objetivo é raciocínio fundamentado: o modelo deve argumentar com base em evidências que sua plataforma controla, não apenas a partir de pesos.

A engenharia de contexto é onde muitas equipes descobrem a economia de tokens. Enviar dez mil tokens de runbooks em cada "qual é o status?" é um problema de contexto, não um problema de prompt. Também é falhar em uma consulta de chamada porque o agente nunca puxou a equipe proprietária do catálogo.

Invista aqui quando: as respostas são genéricas, as taxas de alucinação caem quando você cola documentos manualmente, ou sessões de múltiplos turnos explodem em custo porque nada é podado ou direcionado.

Pare aqui quando: o modelo vê os fatos certos, mas o ciclo ainda comete erros duplos, ignora a verificação ou contorna a política—essas são falhas de harness.

Engenharia de harness: o ciclo

Um harness é tudo que transforma uma conclusão de chat em um agente: o ciclo de orquestração (planejar → chamar ferramenta → observar → repetir), timeouts e tentativas, sandboxing, logging estruturado, hooks de avaliação, cancelamento e os portões entre sugestão e execução. A engenharia de harness é engenharia de software aplicada a componentes não confiáveis—muito parecido com o que você faria ao envolver uma API externa em que não confia totalmente.

Preocupações concretas de harness incluem: quais ferramentas existem e quem pode invocá-las; modos de idempotência e execução a seco; aprovações humanas para ações de alto risco; comparação de resultados de ferramentas com políticas; disjuntores quando os custos ou taxas de erro aumentam; e rastreamento para que você possa reconstruir por que um agente reiniciou um serviço às 2 da manhã.

Agentes de codificação tornaram o termo visível: o modelo propõe edições, mas o harness aplica correções, executa testes, impõe limites de diretório e interrompe o ciclo em caso de falha. O mesmo padrão se aplica a agentes operacionais: o modelo propõe um passo de runbook; o harness verifica RBAC, abre um ticket de mudança e registra campos de auditoria antes que qualquer coisa toque a produção.

Invista aqui quando: o agente pode agir no mundo, os custos escalam com os usuários, você precisa de trilhas de auditoria amigáveis ao SOC, ou "funcionou na demonstração" não sobrevive a usuários paralelos e interrupções parciais.

Como eles se empilham

Pense em um único turno fluindo para baixo: o harness decide se um turno pode ser executado e quais ferramentas estão disponíveis. A engenharia de contexto preenche a janela com a fatia certa do seu patrimônio. A engenharia de prompt diz ao modelo como usar essa fatia (formato, cautela, prioridades). Depois que o modelo responde, o harness novamente—valida, executa, registra ou bloqueia.

Um turno, de cima para baixo: cada estágio tem um teto—prompt não pode corrigir um ciclo ruim; harness não pode inventar fatos ausentes.

Ignorar uma camada aparece de forma previsível. Agentes apenas com prompt soam confiantes e não sabem nada. Agentes ricos em contexto, mas sem harness, sabem muito e ainda quebram a produção. Harness sem contexto se torna automação rígida com um batom de modelo de linguagem—caro e frágil.

Matc