Engenharia de aproveitamento: A camada de execução de que os agentes de IA realmente precisam

Mitchell Hashimoto construiu a HashiCorp e co-criou a Terraform. Em fevereiro de 2026, publicou uma publicação no seu blogue em que descrevia um hábito que tinha desenvolvido enquanto trabalhava com agentes de IA: sempre que um agente cometia um erro, criava uma correção permanente no ambiente do agente. Chamou-lhe "engenharia do arnês". Em poucas semanas, a OpenAI e a Anthropic publicaram artigos de engenharia que expandiam a ideia. O termo " engenharia do arnês " tinha chegado.

A expressão teve eco porque dá nome a um problema que todos os engenheiros que constroem agentes de IA já enfrentaram. A engenharia imediata permite obter melhores resultados numa única volta. A engenharia de contexto gere o que o modelo vê. Mas nenhuma delas aborda o que acontece quando um agente funciona de forma autónoma durante horas, tomando centenas de decisões sem supervisão. É essa a lacuna que a engenharia de aproveitamento preenche - e quase sempre depende da pesquisa híbrida (pesquisa híbrida de texto integral e semântica) para funcionar.

O que é a engenharia de arreios?

A engenharia de equipamentos é a disciplina que consiste em conceber o ambiente de execução em torno de um agente de IA autónomo. Define as ferramentas que o agente pode chamar, onde obtém informações, como valida as suas próprias decisões e quando deve parar.

Para compreender a sua importância, considere três camadas de desenvolvimento de agentes de IA:

Camada	O que optimiza	Âmbito	Exemplo
Engenharia de pedidos	O que se diz ao modelo	Troca única	Poucos exemplos, instruções de cadeia de pensamento
Engenharia de contexto	O que o modelo pode ver	Janela de contexto	Recuperação de documentos, compressão de histórico
Engenharia de utilização	O mundo em que o agente actua	Execução autónoma de várias horas	Ferramentas, lógica de validação, restrições arquitecturais

A Prompt Engineering optimiza a qualidade de uma única troca - fraseologia, estrutura, exemplos. Uma conversa, um resultado.

A Engenharia de Contexto gere a quantidade de informação que o modelo pode ver de uma só vez - que documentos recuperar, como comprimir o historial, o que cabe na janela de contexto e o que é descartado.

A Engenharia de Aproveitamento constrói o mundo em que o agente opera. Ferramentas, fontes de conhecimento, lógica de validação, restrições de arquitetura - tudo o que determina se um agente pode funcionar de forma fiável em centenas de decisões sem supervisão humana.

Três camadas de desenvolvimento de agentes de IA: A engenharia de prontidão optimiza o que o utilizador diz, a engenharia de contexto gere o que o modelo vê e a engenharia de aproveitamento concebe o ambiente de execução

As duas primeiras camadas determinam a qualidade de uma única jogada. A terceira determina se um agente pode funcionar durante horas sem que o utilizador o observe.

Estas não são abordagens concorrentes. São uma progressão. À medida que a capacidade do agente aumenta, a mesma equipa passa por todas as três - muitas vezes dentro de um único projeto.

Como a OpenAI usou o Harness Engineering para construir uma base de código de milhões de linhas e as lições que aprendeu

A OpenAI realizou uma experiência interna que coloca a Harness Engineering em termos concretos. Eles o descreveram em seu blog de engenharia, "Harness Engineering: Leveraging Codex in an Agent-First World". Uma equipa de três pessoas começou com um repositório vazio no final de agosto de 2025. Durante cinco meses, não escreveram qualquer código - cada linha foi gerada pelo Codex, o agente de codificação alimentado por IA da OpenAI. O resultado: um milhão de linhas de código de produção e 1500 pedidos pull fundidos.

A parte interessante não é o resultado. São os quatro problemas que eles enfrentaram e as soluções de camada de arnês que eles construíram.

Problema 1: Nenhum entendimento compartilhado da base de código

Que camada de abstração o agente deve usar? Quais são as convenções de nomenclatura? Onde foi parar a discussão de arquitetura da semana passada? Sem respostas, o agente adivinhava - e adivinhava mal - repetidamente.

O primeiro instinto foi um único ficheiro AGENTS.md contendo todas as convenções, regras e decisões históricas. Falhou por quatro razões. O contexto é escasso, e um ficheiro de instruções inchado afastava a tarefa real. Quando tudo é marcado como importante, nada o é. A documentação apodrece - as regras da segunda semana tornam-se erradas na oitava semana. E um documento plano não pode ser verificado mecanicamente.

A solução: reduzir AGENTS.md para 100 linhas. Não são regras - é um mapa. Ele aponta para um diretório estruturado docs/ contendo decisões de projeto, planos de execução, especificações do produto e documentos de referência. Linters e CI verificam se as ligações cruzadas permanecem intactas. O agente navega exatamente para o que precisa.

O princípio subjacente: se algo não está no contexto em tempo de execução, não existe para o agente.

Problema 2: O controlo de qualidade humano não conseguia acompanhar o ritmo da produção do agente

A equipa ligou o protocolo Chrome DevTools ao Codex. O agente podia fazer capturas de ecrã de caminhos da IU, observar eventos de tempo de execução e consultar registos com LogQL e métricas com PromQL. Definiram um limite concreto: um serviço tinha de ser iniciado em menos de 800 milissegundos para que uma tarefa fosse considerada concluída. As tarefas do Codex eram executadas por mais de seis horas seguidas, geralmente enquanto os engenheiros dormiam.

Problema 3: Deriva arquitetónica sem restrições

Sem barreiras, o agente reproduzia os padrões que encontrava no repositório - incluindo os maus.

A solução: arquitetura estrita em camadas com uma única direção de dependência imposta - Types → Config → Repo → Service → Runtime → UI. Os linters personalizados aplicavam estas regras mecanicamente, com mensagens de erro que incluíam a instrução de correção em linha.

Arquitetura rigorosa em camadas com validação de dependência unidirecional: Tipos na base, IU no topo, linters personalizados aplicam regras com sugestões de correção em linha

Numa equipa humana, este constrangimento surge normalmente quando uma empresa aumenta a escala para centenas de engenheiros. Para um agente de codificação, é um pré-requisito desde o primeiro dia. Quanto mais rápido um agente se move sem restrições, pior é o desvio da arquitetura.

Problema 4: Dívida técnica silenciosa

A solução: codificar os princípios fundamentais do projeto no repositório e, em seguida, executar tarefas do Codex em segundo plano, de acordo com um calendário, para procurar desvios e submeter PRs de refacção. A maioria foi fundida automaticamente num minuto - pequenos pagamentos contínuos em vez de cálculos periódicos.

Porque é que os agentes de IA não conseguem avaliar o seu próprio trabalho

A experiência da OpenAI provou que a Harness Engineering funciona. Mas uma investigação separada expôs um modo de falha no seu interior: os agentes são sistematicamente maus a avaliar os seus próprios resultados.

O problema aparece de duas formas.

Ansiedade de contexto. À medida que a janela de contexto se enche, os agentes começam a terminar as tarefas prematuramente - não porque o trabalho esteja feito, mas porque sentem que o limite da janela está a aproximar-se. A Cognition, a equipa por detrás do agente de codificação de IA Devin, documentou este comportamento enquanto reconstruía o Devin para o Claude Sonnet 4.5: o modelo apercebeu-se da sua própria janela de contexto e começou a tomar atalhos muito antes de ficar realmente sem espaço.

A correção deles foi pura engenharia de hardware. Eles habilitaram o contexto beta de 1 milhão de tokens, mas limitaram o uso real a 200 mil tokens - enganando o modelo para que ele acreditasse que tinha uma ampla margem de manobra. A ansiedade desapareceu. Não foi necessário alterar o modelo; apenas um ambiente mais inteligente.

A atenuação geral mais comum é a compactação: resumir o histórico e permitir que o mesmo agente continue com o contexto compactado. Isso preserva a continuidade, mas não elimina o comportamento subjacente. Uma alternativa é a redefinição do contexto: limpar a janela, iniciar uma nova instância e transferir o estado através de um artefacto estruturado. Isto elimina completamente o gatilho da ansiedade, mas exige um documento de transferência completo - lacunas no artefacto significam lacunas na compreensão do novo agente.

Viés de autoavaliação. Quando os agentes avaliam os seus próprios resultados, atribuem-lhes uma pontuação elevada. Mesmo em tarefas com critérios objectivos de aprovação/reprovação, o agente detecta um problema, convence-se a si próprio de que não é grave e aprova trabalho que deveria falhar.

A correção baseia-se nas GANs (Generative Adversarial Networks): separar completamente o gerador do avaliador. Numa GAN, duas redes neurais competem - uma gera, outra avalia - e essa tensão adversária força a qualidade a subir. A mesma dinâmica aplica-se aos sistemas multi-agentes.

A Anthropic testou isto com um conjunto de três agentes - Planificador, Gerador, Avaliador - contra um agente individual com a tarefa de construir um motor de jogo retro 2D. Descrevem a experiência completa em "Harness Design for Long-Running Application Development" (Anthropic, 2026). O Planificador expande um pequeno pedido para uma especificação completa do produto, deixando deliberadamente por especificar os pormenores de implementação - o excesso de especificação precoce leva a erros a jusante. O Gerador implementa funcionalidades em sprints, mas antes de escrever código, assina um contrato de sprint com o Avaliador: uma definição partilhada de "feito". O Avaliador usa o Playwright (a estrutura de automação de navegador de código aberto da Microsoft) para clicar na aplicação como um utilizador real, testando a IU, a API e o comportamento da base de dados. Se alguma coisa falhar, o sprint falha.

O agente solo produziu um jogo que tecnicamente foi lançado, mas as conexões entidade-para-tempo de execução foram quebradas no nível do código - descobertas apenas pela leitura do código-fonte. O arnês de três agentes produziu um jogo jogável com geração de níveis assistida por IA, animação de sprite e efeitos sonoros.

Comparação entre o agente solo e o arnês de três agentes: o agente solo funcionou durante 20 minutos a nove dólares com uma funcionalidade central quebrada, enquanto o arnês completo funcionou durante 6 horas a duzentos dólares, produzindo um jogo totalmente funcional com funcionalidades assistidas por IA

A arquitetura de três agentes custou cerca de 20 vezes mais. O resultado passou de inutilizável para utilizável. Esta é a principal troca que a Harness Engineering faz: despesas estruturais em troca de fiabilidade.

O problema de recuperação dentro de cada chicote de agentes

Ambos os padrões - o sistema estruturado docs/ e o ciclo de sprint Gerador/Avaliador - partilham uma dependência silenciosa: o agente tem de encontrar a informação certa a partir de uma base de conhecimento viva e em evolução quando precisa dela.

Isto é mais difícil do que parece. Vejamos um exemplo concreto: o Gerador está a executar o Sprint 3, implementando a autenticação do utilizador. Antes de escrever o código, ele precisa de dois tipos de informação.

Primeiro, uma consulta de pesquisa semântica: quais são os princípios de conceção deste produto em relação às sessões de utilizador? O documento relevante pode utilizar "gestão de sessões" ou "controlo de acesso" - não "autenticação de utilizador". Sem uma compreensão semântica, a recuperação não o faz.

Em segundo lugar, uma consulta de correspondência exacta: que documentos fazem referência à função validateToken? Um nome de função é uma cadeia arbitrária sem significado semântico. A recuperação baseada na incorporação não a consegue encontrar de forma fiável. Apenas a correspondência de palavras-chave funciona.

Estas duas consultas ocorrem em simultâneo. Não podem ser separadas em passos sequenciais.

A pesquisa vetorial pura falha na correspondência exacta. A BM25 tradicional falha nas consultas semânticas e não consegue prever o vocabulário que um documento irá utilizar. Antes do Milvus 2.5, a única opção eram dois sistemas de recuperação paralelos - um índice vetorial e um índice de texto integral - a funcionar em simultâneo no momento da consulta com uma lógica de fusão de resultados personalizada. Para um repositório docs/ com actualizações contínuas, ambos os índices tinham de se manter sincronizados: cada alteração de documento desencadeava a reindexação em dois locais, com o risco constante de inconsistência.

Como o Milvus 2.6 resolve a recuperação de agentes com um único pipeline híbrido

O Milvus é um banco de dados vetorial de código aberto projetado para cargas de trabalho de IA. O Sparse-BM25 do Milvus 2.6 colapsa o problema de recuperação de pipeline duplo em um único sistema.

Na ingestão, o Milvus gera duas representações simultaneamente: uma incorporação densa para recuperação semântica e um vetor esparso codificado por TF para pontuação BM25. As estatísticas globais do IDF são actualizadas automaticamente à medida que os documentos são adicionados ou removidos - não há necessidade de reindexação manual. No momento da consulta, uma entrada em linguagem natural gera internamente ambos os tipos de vectores de consulta. O Reciprocal Rank Fusion (RRF) funde os resultados classificados e o autor da chamada recebe um único conjunto de resultados unificado.

Antes e depois: dois sistemas separados com sincronização manual, resultados fragmentados e lógica de fusão personalizada versus pipeline único do Milvus 2.6 com dense embedding, Sparse BM25, fusão RRF e manutenção automática de IDF produzindo resultados unificados

Uma interface. Um índice para manter.

No benchmark BEIR - um conjunto de avaliação padrão que abrange 18 conjuntos de dados de recuperação heterogéneos - o Milvus alcança uma taxa de transferência 3-4x superior à do Elasticsearch com uma recuperação equivalente, com uma melhoria de até 7x QPS em cargas de trabalho específicas. Para o cenário de sprint, uma única consulta encontra o princípio de conceção da sessão (caminho semântico) e todos os documentos que mencionam validateToken (caminho exato). O repositório docs/ é atualizado continuamente; a manutenção do IDF BM25 significa que um documento recentemente escrito participa na pontuação da consulta seguinte sem qualquer reconstrução em lote.

Esta é a camada de recuperação construída exatamente para esta classe de problemas. Quando um agente precisa de pesquisar uma base de conhecimento viva - documentação de código, decisões de design, histórico de sprint - a pesquisa híbrida de pipeline único não é uma coisa boa de se ter. Ela é o que faz o resto do chicote funcionar.

Os melhores componentes do arnês são projectados para serem eliminados

Cada componente de um arnês codifica uma suposição sobre as limitações do modelo. A decomposição do sprint era necessária quando os modelos perdiam a coerência em tarefas longas. A reposição do contexto era necessária quando os modelos sentiam ansiedade perto do limite da janela. Os agentes de avaliação tornaram-se necessários quando a tendência para a autoavaliação era incontrolável.

Estes pressupostos expiram. O truque da janela de contexto da cognição pode tornar-se desnecessário à medida que os modelos desenvolvem uma verdadeira resistência a longos contextos. À medida que os modelos continuarem a melhorar, outros componentes tornar-se-ão uma sobrecarga desnecessária que torna os agentes mais lentos sem acrescentar fiabilidade.

A Harness Engineering não é uma arquitetura fixa. É um sistema recalibrado a cada novo lançamento de modelo. A primeira pergunta após qualquer grande atualização não é "o que posso acrescentar?". É "o que é que posso remover?"

A mesma lógica aplica-se à recuperação. À medida que os modelos lidam com contextos mais longos de forma mais fiável, as estratégias de fragmentação e o tempo de recuperação mudarão. A informação que hoje necessita de uma fragmentação cuidadosa pode ser ingerida como páginas completas amanhã. A infraestrutura de recuperação adapta-se juntamente com o modelo.

Todos os componentes de um sistema bem construído estão à espera de serem tornados redundantes por um modelo mais inteligente. Isso não é um problema. É o objetivo.

Comece a usar o Milvus

Se está a construir uma infraestrutura de agentes que necessita de uma recuperação híbrida - pesquisa semântica e por palavra-chave num único pipeline - eis por onde começar:

• Leia as notas de lançamento do Milvus 2.6 para obter todos os detalhes sobre o Sparse-BM25, a manutenção automática do IDF e os benchmarks de desempenho.
• Junte-se à comunidade Milvus para fazer perguntas e partilhar o que está a construir.
• Reserve uma sessão gratuita do Milvus Office Hours para analisar o seu caso de utilização com um especialista em bases de dados vectoriais.
• Se preferir ignorar a configuração da infraestrutura, o Zilliz Cloud (Milvus totalmente gerido) oferece um nível gratuito para começar com créditos gratuitos de $100 após o registo com o e-mail de trabalho.
• Inscreva-nos no GitHub: milvus-io/milvus - 43k+ estrelas e a crescer.

Perguntas frequentes

O que é a harness engineering e qual é a sua diferença em relação à prompt engineering?

A engenharia de prontidão optimiza o que diz a um modelo numa única troca - fraseado, estrutura, exemplos. A Harness Engineering constrói o ambiente de execução em torno de um agente de IA autónomo: as ferramentas que pode chamar, o conhecimento a que pode aceder, a lógica de validação que verifica o seu trabalho e as restrições que impedem a deriva arquitetónica. A engenharia de prontidão molda um turno de conversação. A engenharia de aproveitamento determina se um agente pode funcionar de forma fiável durante horas em centenas de decisões sem supervisão humana.

Porque é que os agentes de IA precisam de pesquisa vetorial e de BM25 ao mesmo tempo?

Os agentes têm de responder simultaneamente a duas consultas de recuperação fundamentalmente diferentes. Consultas semânticas - quais são os nossos princípios de conceção das sessões de utilizador? - requerem densas incorporações vectoriais para corresponder a conteúdos concetualmente relacionados, independentemente do vocabulário. Consultas de correspondência exacta - que documentos referem a função validateToken? - requerem uma pontuação de palavras-chave BM25, porque os nomes das funções são cadeias arbitrárias sem significado semântico. Um sistema de recuperação que lida apenas com um modo perderá sistematicamente as consultas do outro tipo.

Como é que o Milvus Sparse-BM25 funciona para a recuperação de conhecimento de agentes?

Aquando da ingestão, o Milvus gera simultaneamente uma incorporação densa e um vetor esparso codificado por TF para cada documento. As estatísticas globais do IDF são actualizadas em tempo real à medida que a base de conhecimentos muda - não é necessária uma reindexação manual. No momento da consulta, ambos os tipos de vectores são gerados internamente, o Reciprocal Rank Fusion funde os resultados classificados e o agente recebe um único conjunto de resultados unificado. Todo o pipeline é executado através de uma interface e de um índice - essencial para bases de conhecimento continuamente actualizadas, como um repositório de documentação de código.

Quando devo adicionar um agente avaliador ao meu conjunto de agentes?

Adicione um Avaliador separado quando a qualidade de saída do seu Gerador não puder ser verificada apenas por testes automatizados ou quando a tendência de autoavaliação tiver causado defeitos perdidos. O princípio fundamental: o Avaliador deve estar arquitetonicamente separado do Gerador - o contexto partilhado reintroduz a mesma tendência que está a tentar eliminar. O Avaliador deve ter acesso a ferramentas de tempo de execução (automação do navegador, chamadas de API, consultas a banco de dados) para testar o comportamento, não apenas revisar o código. A pesquisa da Anthropic descobriu que essa separação inspirada no GAN mudou a qualidade do resultado de "tecnicamente lançado, mas quebrado" para "totalmente funcional com recursos que o agente solo nunca tentou".