Harness x Loops x Grafos

A confusão é compreensível. As três ideias giram em torno do mesmo modelo, todas influenciam a confiabilidade e todas podem conter "loops". No entanto, não são sinônimos. Elas descrevem decisões de engenharia distintas, e essa distinção é importante no momento em que um agente deixa um notebook de demonstração e começa a lidar com arquivos, APIs, clientes ou código em produção.

A RESPOSTA EM 30 SEGUNDOS

• A engenharia de harness (estrutura de suporte) constrói o mecanismo em torno do modelo.
• A engenharia de loop projeta o ciclo repetitivo de execução e feedback.
• A engenharia de grafos torna explícita a topologia do fluxo de trabalho: nós, ramificações, junções, transições de estado e ciclos controlados.

O modelo é basicamente: ambiente → feedback → fluxo.

Por que esses termos ganharam relevância de repente

Um modelo de linguagem bruto não consegue criar texto, manter o estado de um projeto, executar uma bateria de testes, interagir com um navegador, aplicar uma regra de aprovação ou reiniciar uma tarefa que falhou. Essas capacidades provêm do ambiente em que o modelo está inserido. À medida que o software baseado em agentes amadurece, uma pilha tecnológica padrão de engenharia começa finalmente a se consolidar. Na base, encontra-se o agent harness (a estrutura de suporte ao agente) — o código que efetivamente executa os modelos. Em seguida, vêm os loops, responsáveis pela execução repetitiva e pelas verificações de qualidade. Por fim, os grafos mapeiam os caminhos estruturados que orientam todo o processo.

A terminologia ainda não está totalmente padronizada. No cenário atual, o termo "agent harness" começa a adquirir uma definição bastante específica. O termo "loop engineering" surgiu mais recentemente, em 2026, entre os profissionais da área. A engenharia de grafos deve ser compreendida de forma prática, e não como um campo acadêmico; trata-se simplesmente do processo de criação de fluxos de trabalho de agentes na forma de grafos direcionados explícitos ou máquinas de estado. Essa distinção prática é útil, pois evita que um termo da moda oculte a verdadeira questão de projeto.

Um grafo direcionado explícito (ou digrafo) é uma estrutura matemática e computacional em que o conjunto de vértices e as arestas direcionadas (arcos) são armazenados diretamente na memória, como em listas ou matrizes de adjacência, diferindo de grafos implícitos gerados por regras dinâmicas.

Engenharia Harness de Agentes

Segundo a LangChain, o agente é composto pelo modelo e pela estrutura de suporte (harness); esta estrutura engloba o código, a configuração e a lógica de execução externos ao modelo. Na prática, isso inclui o system prompt, definições de ferramentas, memória, sistemas de arquivos, sandboxes, roteamento de modelos, transferências de controle (handoffs), hooks de middleware, compactação, permissões, registro de logs e interfaces de verificação.

O SDK de Agentes da OpenAI descreve esse mesmo núcleo operacional sob a perspectiva de tempo de execução (runtime): o executor (runner) chama o modelo, executa chamadas de ferramentas, gerencia transferências de controle, mantém o estado e só interrompe a operação quando a execução atinge uma condição terminal real.

O termo harness (estrutura de suporte/ambiente de operação) é útil porque desvia a atenção da idolatria em torno do modelo. Duas equipes podem utilizar o mesmo modelo de base e obter resultados muito diferentes: uma fornece ao modelo ferramentas limpas, um ambiente de trabalho estável, permissões restritas e estado observável, enquanto a outra lhe dá um prompt vago e um wrapper de API pouco confiável. A inteligência pode ser semelhante, mas as condições de trabalho não. O que uma estrutura de suporte robusta geralmente inclui:

• Injeção de contexto: instruções, fatos recuperados, estado da conversa, habilidades e políticas específicas da tarefa
• Interfaces de ação: APIs, navegadores, shells, interpretadores de código, bancos de dados e ferramentas compatíveis com MCP
• Persistência: arquivos, checkpoints, sessões, registros de progresso, histórico do Git e memória de longo prazo
• Controle de execução: timeouts, tentativas de reexecução, limites de orçamento, roteamento de modelos, criação de subagentes e etapas de aprovação
• Segurança e governança: permissões, isolamento, listas de permissão (allow lists), gerenciamento de segredos e autorização humana
• Observabilidade: rastreamentos (traces), entradas e saídas de ferramentas, transições de estado, custos, latência e resultados de avaliação

O modelo está inserido em uma estrutura de suporte mais ampla que engloba contexto, controle, ação, persistência e verificação. Se você remover o modelo da sua arquitetura, tudo o que restar provavelmente fará parte dessa estrutura de suporte: ferramentas, acesso a dados, armazenamento de estado, sandbox, middleware, avaliadores, política de novas tentativas e interface do usuário (UI).

Onde a engenharia dessa estrutura de suporte se mostra valiosa

O desenvolvimento dessa estrutura de suporte é fundamental para tarefas de longa duração. Ao trabalhar com codificação em múltiplas sessões, a Anthropic descobriu que a simples compactação de contexto não bastava. Não se tratava apenas de um prompt melhor, mas sim de uma configuração robusta que incluía um inicializador, um arquivo de progresso, histórico do Git e uma disciplina de trabalho incremental, permitindo que cada novo contexto compreendesse o que já havia sido feito e o que ainda restava realizar. É um sistema de trabalho aprimorado do ponto de vista do agente. Aplique a engenharia dessa estrutura de suporte quando o agente carecer de uma funcionalidade, não conseguir retornar a um estado limpo, perder o estado, acessar dados em excesso, não puder ser auditado ou apresentar comportamentos diferentes dependendo do ambiente.

Engenharia de Loops

Cada agente que utiliza uma ferramenta possui um pequeno loop embutido:

• chamar o modelo
• analisar os resultados
• executar as ferramentas
• inserir observações no modelo
• repetir até obter uma resposta final

Quando os desenvolvedores criam ou empilham intencionalmente novos ciclos em torno desse comportamento, tem-se o início da "engenharia de loops", termo utilizado pela OpenAI. Um loop de verificação, por exemplo, permite que o agente crie um artefato, execute uma verificação determinística ou uma avaliação, receba feedback explícito e repita o processo apenas se houver erros comprovados. Um loop orientado a eventos ativa o agente quando um agendamento, um webhook ou um novo documento é recebido. Um loop de melhoria analisa rastros e falhas, modifica instruções ou ferramentas e testa se a nova versão apresenta melhor desempenho. A abordagem da LangChain para 2026 descreve isso como uma pilha de loops, e não como uma única instrução while mágica.

A anatomia de um ciclo bem projetado:

• Gatilho: o que inicia um novo ciclo; solicitação do usuário, agendamento, falha em teste, novos dados ou feedback de um avaliador
• Objetivo: um estado específico a ser alcançado, e não uma instrução vaga de "continuar melhorando"
• Estado e memória: informações necessárias para o próximo ciclo, sem a necessidade de reprocessar tudo
• Política de ação: o que o agente pode alterar, chamar, delegar ou gastar
• Evidências: testes, validação de esquema, citações, diferenças (diffs), métricas ou revisão humana
• Feedback: uma descrição concisa e acionável sobre o motivo da falha da evidência
• Critério de parada: sucesso, limite de orçamento, esgotamento de tempo (timeout), erro irrecuperável ou escalonamento para intervenção humana

Um ciclo de verificação envolve o ciclo do agente com um avaliador externo e uma condição explícita de aprovação. Não baseie o ciclo no nível de confiança; baseie-o em evidências. "O agente diz que terminou" não é uma condição de parada; "os testes passam, os links são resolvidos, o esquema é validado e o revisor aprova" — isso sim é uma condição de parada.

Por que a engenharia de ciclos não se resume à engenharia de prompts

Um prompt instrui o modelo sobre o que fazer durante uma chamada. Um ciclo especifica o que o sistema faz após a chamada:

A qualidade do prompt continua sendo importante, mas o ciclo transforma uma instrução de execução única (one-shot) em um processo gerenciado. O principal trade-off envolve custo e latência. Cada avaliador, revisor ou tentativa adicional implica uma nova chamada de modelo ou execução de ferramenta. A orientação geral da Anthropic é optar pela arquitetura mais simples que funcione e adicionar complexidade de agente apenas quando o ganho de desempenho justificar. O mesmo conselho se aplica aos ciclos: utilize-os onde o custo da falha for superior ao custo da verificação.

Engenharia de Grafos

A engenharia de grafos, no entanto, propõe uma questão diferente: não apenas o que o agente faz, mas qual componente tem permissão para ser executado em seguida. As etapas são representadas por nós, e as etapas permitidas são representadas por arestas. Essas arestas podem ser usadas para indicar sequenciamento, ramificação condicional, ramificação paralela (fan-out), junções, loops e interrupções humanas. O estado percorre o grafo, e a topologia permite verificar o fluxo de controle desejado. O LangGraph é uma infraestrutura de orquestração de baixo nível para agentes de longa duração e com estado (stateful), oferecendo execução durável, persistência de estado e controle com intervenção humana (human-in-the-loop), além de um foco explícito no controle dos agentes, em vez de apenas na abstração do fluxo de trabalho. A documentação do Microsoft AutoGen é extremamente direta: utilize um grafo quando precisar de controle preciso sobre a ordem dos agentes, diferentes próximos passos para resultados distintos, ramificação determinística ou processos complexos de múltiplas etapas com ciclos. O que os engenheiros de grafos realmente decidem:

• Limites dos nós: qual tarefa cabe a uma função determinística, a uma chamada de LLM, a um agente especializado ou a uma etapa de revisão humana
• Esquema de estado: o que cada nó pode ler ou atualizar, e como atualizações paralelas são consolidadas
• Condições de roteamento: quais critérios determinam o encaminhamento da tarefa (avançar, retroceder, mover lateralmente ou escalar)
• Concorrência: o que pode ser executado em paralelo, o que exige sincronização (junção) e quais recursos compartilhados requerem coordenação
• Ciclos e saídas: onde tentativas de reexecução são permitidas, qual o limite de tentativas e o que garante a segurança do ciclo
• Durabilidade: onde ocorrem pontos de verificação (checkpoints) e como a execução é retomada após uma interrupção.

O canvas apresentado acima permite inspecionar agentes, habilidades e relacionamentos como um sistema composto. Aqui, a engenharia de grafos refere-se à engenharia de uma execução baseada em grafos. Isso difere da engenharia de grafos de conhecimento, nos quais o grafo representa entidades e relacionamentos presentes nos dados; já um grafo de fluxo de trabalho representa o controle e as transições de estado.

Quando vale a pena utilizar grafos

Os grafos são valiosos quando o processo envolve ramificações significativas, trabalho em paralelo, aprovações, caminhos de recuperação ou múltiplos agentes especializados. Eles são menos úteis quando a tarefa consiste simplesmente em "fornecer três ferramentas a um agente e deixá-lo trabalhar". Embora um grafo possa facilitar a depuração, ele também pode cristalizar suposições precocemente. Se o modelo precisar criar o plano dinamicamente, forçar a inclusão de todos os caminhos possíveis em um diagrama pode tornar o sistema mais frágil, e não o contrário.

Como as três camadas funcionam em conjunto em um sistema real

Considere um agente de pesquisa e publicação responsável por produzir um relatório informativo com dados factuais sobre o setor.

Observe o aninhamento: o grafo é executado dentro da estrutura de suporte (harness); um ou mais loops residem dentro do grafo; e a estrutura fornece o estado, as ferramentas e os avaliadores de que esses loops necessitam. As categorias se sobrepõem porque as camadas de software se sobrepõem, mas cada uma delas oferece à equipe uma alavanca diferente para acionar quando o sistema falha.

Escolha a camada de engenharia diagnosticando a falha

Os erros custosos por trás de arquiteturas de agentes fracas

Construir um grafo antes de entender o trabalho

As equipes às vezes traduzem um processo de negócios em dezenas de nós antes de observarem como um agente competente realmente o executa. Comece com registros de um ambiente de teste mais simples e, em seguida, formalize os fluxos estáveis.

Permitir que o mesmo modelo escreva e avalie sem salvaguardas

A autorrevisão pode ajudar, mas está sujeita a pontos cegos compartilhados. Dê preferência a verificações determinísticas sempre que possível, separe o contexto do revisor e exija aprovação humana para ações de alto impacto.

Usar a estratégia de "continuar tentando" como especificação de loop

Um loop de repetição sem limites gera desperdício de recursos. Todo loop precisa de um objetivo mensurável, novas evidências, um limite de tentativas e um fluxo de escalonamento definido.

Tratar o ambiente de execução (harness) como um depósito de recursos

Mais ferramentas e memória não significam, automaticamente, melhor desempenho. Um conjunto de ferramentas excessivo aumenta erros de seleção, um contexto poluído gera confusão e permissões amplas elevam os riscos.

Culpar o modelo por falhas de orquestração

Um modelo não consegue compensar de forma confiável estados desatualizados, esquemas de ferramentas ambíguos, APIs com falhas ou condições de saída ausentes. Aprimore a camada responsável pela falha.

Uma checklist antes de ir para produção

• Infraestrutura de execução (Harness): As ferramentas são restritas, documentadas e observáveis? O estado é persistente? As permissões seguem o princípio do privilégio mínimo? Os operadores podem pausar, inspecionar e retomar uma execução?
• Ciclo (Loop): Quais evidências comprovam o sucesso? Que feedback é retornado em caso de falha? Quantas tentativas são permitidas? O que acontece quando o orçamento se esgota?
• Grafo: Quais caminhos devem ser determinísticos? Onde o trabalho pode ser executado em paralelo? Qual estado é compartilhado? Onde estão os pontos de intervenção humana e as rotas de recuperação?
• Avaliação: A equipe consegue reproduzir rastreamentos reais, comparar versões e atribuir melhorias a uma alteração específica, em vez de à intuição?
• Operações: Custo, latência, taxa de falha, taxa de intervenção e sucesso em nível de tarefa são monitorados em produção?

A maneira mais simples de lembrar a diferença

Projete algo para ser um modelo e fazê-lo funcionar. A metodologia de engenharia de loop é iterativa, verificável e retomável. Um caminho de execução complexo é tornado explícito e controlável através do uso da engenharia de grafos. Nenhum dos três é substituído por nenhum dos outros. Mesmo que o harness tenha perdido o seu estado, um gráfico bem desenhado não é suficiente. Porém, mesmo com o melhor harness, se não houver nenhuma evidência ou regra de parada, é um desperdício de dinheiro! Loops cuidadosamente elaborados ainda são difíceis de operar quando ramificações, paralelismo e aprovações estão incorporados no código ad-hoc. Se essas três camadas forem projetadas em conjunto, surgirão sistemas de agentes confiáveis, desde que a equipe esteja ciente do que cada camada deve resolver.

Fontes:

• A Anatomia de uma Estrutura de Agente (Agent Harness) – Saiba como essas estruturas transformam modelos de IA em motores de trabalho autônomos. Explore os componentes principais: sistemas de arquivos, sandboxes e memória.
• Agents SDK | OpenAI API – Entenda a composição do OpenAI Agents SDK e saiba quais documentos consultar em seguida.
• Frameworks de Agentes LangChain e LangGraph Atingem a Versão 1.0 – LangChain 1.0 e LangGraph 1.0 já estão disponíveis. Crie agentes de IA prontos para produção com mais rapidez usando ferramentas padronizadas, personalização de middleware e estado persistente.
• GraphFlow (Fluxos de Trabalho) – AutoGen – Nesta seção, você aprenderá a criar um fluxo de trabalho multiagente usando o GraphFlow (ou simplesmente "flow"). Ele utiliza execução estruturada e controla com precisão a interação entre agentes para realizar uma tarefa.
• A Arte da Engenharia de Loops – Agentes automatizam tarefas do mundo real, mas um desempenho confiável exige mais do que um bom modelo; requer uma estrutura (harness) cuidadosamente projetada para tarefas específicas. Este artigo explora o loop central do agente, como o empilhamento e a extensão de loops criam agentes mais eficazes, e como instrumentar cada nível com primitivas do LangChain.
• Apresentando o AutoGen Studio da Microsoft Research – O AutoGen Studio, construído sobre o framework de código aberto e flexível AutoGen da Microsoft para orquestração de agentes de IA, oferece uma interface intuitiva. Isso permite que desenvolvedores criem, testem, personalizem e compartilhem soluções de IA multiagente rapidamente, com pouco ou nenhum código.
• Como Criar uma Estrutura de Agente Harness – Agentes eficazes são construídos com estruturas (harnesses) intimamente ligadas à tarefa em questão. A maneira mais fácil de criar uma estrutura personalizada é usando a função create_agent do LangChain combinada com middleware. Este guia aborda o loop central do agente e como personalizá-lo para o caso de uso do seu agente.
• Um guia prático para a criação de agentes – Um guia abrangente sobre o design, a orquestração e a implementação de agentes de IA, cobrindo casos de uso, seleção de modelos, design de ferramentas, mecanismos de segurança (guardrails) e padrões multiagente.
• Criando Agentes de IA Eficazes – Conselhos e orientações práticas da Anthropic para a criação de sistemas de agente único e multiagente prontos para produção.