Em IA, o que é exatamente um "harness"?

Recentemente, vi o OpenClaw ser chamado de "harness". Eu pensei: “isso é interessante. O OpenClaw não é um harness. É um runtime de agente — ele direciona o loop do agente.” Então, o que a palavra "harness" realmente significa?

A conversa até agora

A base estrutural do conceito vem do artigo de Birgitta Böckeler de abril de 2026, que define um agente de forma elegante como modelo + harness = agente. Ela dividiu o stack em um harness do builder (o runtime interno incluído na ferramenta) e um harness do usuário (o contexto personalizado do desenvolvedor). Essa definição se baseou em uma onda de discussões em fevereiro de 2026. Elas incluíram a abordagem pragmática de Mitchell Hashimoto para contextos de engenharia do AGENTS.md, a visão geral da OpenAI sobre engenharia de harness interno para implantação automatizada e o memorando de resumo original de Böckeler.

5 camadas, de fora para dentro

Acho que um agente é mais do que apenas modelo + harness. Para mim, isso começa com a observação de que simplesmente não podemos confiar no runtime do agente. Para obter segurança na segurança da cadeia de suprimentos de software do código produzido por uma fábrica de agentes, precisamos de uma camada de sandbox distinta para capturar informações de procedência e limitar o impacto de um agente fora de controle.

Penso nessa arquitetura de runtime de agente seguro como uma boneca russa (matryoshka), de fora para dentro:

Infraestrutura → sandbox → harness do agente → runtime → modelo

Cada camada possui um proprietário, um modo de falha e um princípio de design diferentes. Vamos analisá-las.

Camada 1: Infraestrutura

A infraestrutura é onde os agentes são executados fisicamente. Podem ser runners do GitHub Actions, pods do Kubernetes ou máquinas virtuais (VMs). Essa camada envolve computação, rede e gerenciamento de recursos, e é mais importante do que se imagina.

Considere o que acontece quando você passa de um agente para dezenas de agentes executados em paralelo. Roy Belio colocou o sistema de autoresearch de Andrej Karpathy para executar 198 experimentos autônomos no OpenShift AI, incluindo agendamento de GPU e orquestração de tarefas sem intervenção humana. Isso não é um problema de harness. Não é um problema de sandbox. É um problema de infraestrutura. Sua plataforma consegue gerenciar solicitações de recursos concorrentes, impedir que agentes simultâneos esgotem os recursos uns dos outros e agendar cargas de trabalho de GPU?

O agendamento de GPU está se tornando uma disciplina de infraestrutura de primeira classe. O Red Hat OpenShift 4.21 incluiu a alocação dinâmica de recursos: uma API do Kubernetes que permite que cargas de trabalho solicitem GPUs por atributos (modelo, memória, capacidade de computação), em vez de contagens brutas. Ela também permite o compartilhamento de GPUs entre containers, para que sidecars de inferência leves não desperdicem um dispositivo inteiro. Isso é pura infraestrutura: sem política de sandbox, sem entrada no AGENTS.md e sem escolha de modelo. Apenas a plataforma cumprindo seu papel.

Camada 2: Sandbox

O sandbox restringe o que o agente pode fazer e limita o impacto potencial se algo der errado. Trata-se de isolamento. Minha colega, Marta Anon Ruiz, descreveu essa camada como “moldar a intencionalidade do agente”. Projetos como o OpenShell da NVIDIA operam nessa camada. Do ponto de vista da segurança da cadeia de suprimentos de software, este é o seu principal limite de confiança. É a diferença entre um agente que pode executar rm -rf / e um que não pode, ou entre um agente que pode usar gh issue delete em todos os seus GitHub issues e um que não pode (ou um que consegue escrever e executar o próprio script para fazer o mesmo).

Se a infraestrutura pergunta "onde o agente é executado?", o sandbox pergunta "o que o agente tem permissão para acessar?" São perguntas diferentes com respostas distintas.

A Red Hat publicou um guia detalhado sobre a criação de proteções resilientes para agentes de IA no Kubernetes, incluindo restrições de contexto de segurança (SCC) v2 restrito, NetworkPolicies de saída com bloqueio por padrão e controle de acesso baseado em função (RBAC) por agente. Cada um desses é um controle subtrativo, em que você começa com tudo o que o agente pode fazer e remove recursos até restarem apenas os necessários.

A camada de sandbox é mais profunda que as políticas de rede. O Red Hat OpenShift sandboxed containers, baseado em Kata Containers e peer-pods, é uma tecnologia essencial nessa camada, pois isola o processo do agente de seu host. Confira também o artigo sobre habilidades de agentes e ameaças à segurança, que explora soluções como a assinatura criptográfica de habilidades de agentes para verificar a procedência antes da execução. Uma habilidade não assinada injetada na cadeia de ferramentas de um agente caracteriza um ataque à cadeia de suprimentos de software. A camada de sandbox ajuda a mitigar esse risco.

Projetos como o OpenShell da NVIDIA são relevantes aqui, assim como os princípios de segurança incorporados aos runtimes de containers gerais. Nenhum deles é um "harness" na forma como Hashimoto descreve; você não ensina o agente a trabalhar melhor, você o impede de realizar tarefas perigosas ou inesperadas.

Camada 3: Harness do agente

Esta é a camada sobre a qual Hashimoto escreveu e é a que Birgitta Böckeler chama de harness do usuário. Esta é a camada de habilitação, que inclui arquivos AGENTS.md, habilidades, ferramentas personalizadas, linters, prompts do sistema e uma boa suíte de testes. Estes são os elementos que você projeta iterativamente para aumentar as chances de o agente acertar.

O artigo de Marco Rizzi sobre engenharia de harness com fluxos de trabalho estruturados cristaliza o princípio: "estrutura na entrada, estrutura na saída". O artigo descreve a varredura da estrutura do projeto com LSP e MCP para gerar prompts contextuais — não apenas dizendo ao agente o que fazer, mas fornecendo a informação estrutural necessária para que ele o faça bem. Na terminologia de Birgitta, isso é o controle "feedforward".

O uso de ferramentas é uma parte crítica do harness que viabiliza o que Birgitta Böckeler chama de guias computacionais. O uso de ferramentas e o padrão MCP tornaram possíveis agentes significativos, dando ao runtime do agente uma chance melhor de atingir seus objetivos. O artigo Como criar agentes de IA eficazes com o MCP detalha como habilitar agentes dando ao seu harness uma forma de acessar recursos corporativos dinamicamente.

Como você sabe se o seu harness funciona? Você o avalia. Michael Dawson escreve sobre o desenvolvimento orientado por avaliação, apresentando um framework de oito etapas usando padrões DeepEval e LLM-as-judge. As avaliações são o loop de feedback que informa se as alterações no harness melhoraram ou pioraram o agente. Sem elas, a engenharia de harness é baseada em suposições. Ferramentas como o evaluation hub ajudam a gerenciar isso em escala.

Artefatos de harness possuem um desafio de gerenciamento. À medida que o AGENTS.md cresce, as ferramentas se multiplicam e os prompts evoluem, como controlar suas versões? Como compartilhá-los entre projetos? O artigo sobre o Lola, um gerenciador de pacotes de contexto de IA, trata o contexto de IA como pacotes com versões controladas. Essa abordagem faz sentido. Se os artefatos do seu harness são artefatos de engenharia, gerencie-os como tal.

Camada 4: Runtime do agente

O runtime do agente é o mecanismo que aciona o loop do agente. Claude Code, OpenCode, Goose ou algo personalizado. Ele lida com o envio de ferramentas, janelas de contexto e gerenciamento de conversas.

Foi isso que a Anthropic chamou de "harness" naquele e-mail. Acredito que isso esteja incorreto — ou, pelo menos, impreciso. O runtime não é algo que você projeta e melhora, a menos que crie o seu próprio. Ele executa o loop: envia o prompt, recebe a resposta, despacha chamadas de ferramentas e processa os resultados. Não posso minimizar a importância desta camada. Os runtimes estão cada vez melhores e todos nos beneficiamos.

Mas algumas organizações criarão os seus próprios. Se você tiver requisitos de soberania, precisar de recursos que nenhum runtime comercial oferece ou se seu caso de uso exigir alto controle do comportamento do runtime, será necessário criar o seu próprio sistema usando APIs abertas. É aqui que projetos como o Llama Stack são importantes, expondo APIs abertas para respostas, manipulação de arquivos, pesquisa e, futuramente, memória. Um runtime soberano baseado em APIs abertas é uma proposta diferente de um serviço bloqueado em uma solução proprietária. As plataformas da Red Hat oferecem suporte a ambos os caminhos: equipes que adotam um runtime existente e projetam o harness do usuário em torno dele, e equipes que criam seu próprio runtime com APIs abertas por exigência do contexto.

Camada 5: Modelo e endpoint de inferência

No lado da veiculação, o guia da Red Hat para integrar o Claude Code com o Red Hat AI Inference Server no OpenShift utiliza vLLM no Red Hat AI para inferência on-premise. Seu modelo, seu cluster, seus dados. Executar a inferência em hardware próprio impacta significativamente o modelo de confiança de todo o seu stack de agentes.

Na parte de procedência, o trabalho da Red Hat em segurança da cadeia de suprimentos de software moderno, especificamente o Red Hat Trusted Artifact Signer e a assinatura criptográfica de modelos, é fundamental. Se você não puder verificar e gerenciar a procedência do modelo em execução, todo o seu stack acima dele será construído sobre uma base não verificada. A assinatura de modelos é para a camada de modelo o que a assinatura de habilidades é para a camada de harness: uma garantia criptográfica de execução do que foi planejado.

Subtrativo versus aditivo

O sandbox e o harness possuem filosofias de design opostas. O sandbox é subtrativo: você remove recursos para reduzir riscos. O harness é aditivo: você adiciona camadas de conhecimento e ferramentas para aumentar a competência. Se os confundirmos, prejudicaremos os princípios de design que devem guiar cada um.

Eles também possuem modos de falha diferentes. Uma falha no sandbox significa que o agente fez algo que não deveria ter permissão para fazer. Uma falha no harness significa que o agente executou mal algo que deveria ter feito bem. São problemas diferentes que exigem respostas diferentes.

O sandbox pode atuar como um registrador — um observador neutro das atividades do agente — que atesta as ações de forma mais confiável do que a autoatestação do runtime do agente.

O sandbox restringe e observa. O harness habilita e você pode melhorá-lo. O runtime executa e você não deve criar o seu próprio, a menos que seja estritamente necessário. Os agentes são tão seguros e confiáveis quanto o stack subjacente, e a Red Hat está criando esse stackPágina disponível no idioma inglês (Portuguese, Brazil não disponível): open source, em todas as camadas, do agendamento de GPU à assinatura criptográfica de modelos. Se você estiver implantando agentes em produção e quiser uma base verificável, e não apenas baseada em esperança, é para lá que estamos indo.