Nos últimos meses, a palavra "harness" tomou conta das conversas sobre agentes de IA. Toda ferramenta nova parece anunciar o próprio harness, e cada uma promete algo diferente. O termo virou moda rápido, mas o conceito por trás dele não é modismo. É a peça que decide se um agente sobrevive fora de uma demonstração bonita e passa a resolver problema real dentro de um sistema em produção.
Um exemplo ajuda a entender o tamanho dessa virada. Em agosto de 2026, a DeepSeek publicou no GitHub um projeto chamado deepseek-harness e, em dois dias, ele já somava mais de 95 mil estrelas. Nove meses antes, um engenheiro austríaco lançou sozinho um agente de código chamado Pi, com apenas quatro ferramentas embutidas e quase nada além disso. O Pi levou cerca de um ano de crescimento orgânico para chegar perto de 92 mil estrelas, sem nenhum pico de lançamento. Duas filosofias de arquitetura completamente diferentes, mas o mesmo termo por trás de ambas: harness.
Neste artigo, vou explicar o que é um agent harness, mostrar um exemplo prático de como ele aparece no dia a dia de uma entrega de software e discutir por que a qualidade desse harness importa mais do que o modelo de linguagem escolhido.
Um modelo de linguagem faz uma coisa só: dado um pedaço de texto e uma lista de ferramentas disponíveis, ele prevê a próxima resposta ou qual ferramenta chamar. Todo o resto é trabalho do harness.
Isso inclui o loop que chama o modelo repetidas vezes, o código que executa as ferramentas de fato, a memória que decide o que sobrevive de um turno para o outro, o planejamento que organiza os passos antes da execução começar, e o sandbox que limita o que o agente pode tocar no sistema. Quando qualquer uma dessas peças falha, o sintoma é sempre parecido de fora para dentro: o agente trava, esquece o que estava fazendo ou consome o contexto inteiro numa tarefa que deveria ser simples.
Esse ciclo (montar o prompt, o modelo responder com uma chamada de ferramenta, o harness executar essa chamada, devolver o resultado ao modelo e repetir) é o mesmo em praticamente qualquer ferramenta de agente do mercado, de Claude Code a Cursor. Ele é conhecido como loop ReAct, um nome que vem de um artigo acadêmico de 2022 que descreveu raciocínio e ação como um processo intercalado.
O que muda de um harness para outro, e o que de fato determina se ele é bom no que faz, é tudo o que envolve esse ciclo: quão bem o planejamento organiza a tarefa antes de qualquer execução, como a memória decide o que manter e o que descartar, quão isolado é o sandbox e se o harness consegue delegar um pedaço do trabalho para um subagente sem poluir a conversa principal.
A explicação acima descreve a arquitetura de um jeito mais abstrato. Luiz Schons, engenheiro sênior no PicPay, chega numa definição parecida a partir de um ângulo mais prático, na série "Arquitetura AI Friendly" que ele publica no próprio blog.
Para ele, um agente não é formado só pelo modelo. Existe uma camada ao redor que define quais informações o agente recebe, quais ferramentas pode usar, como o estado da tarefa é mantido, quais ações exigem aprovação humana e como o resultado é verificado. Essa camada é o harness. Ele reúne o contexto, as skills, as tools, as conexões MCP, as permissões, o estado da tarefa, a observabilidade e os mecanismos de verificação.
Uma forma simples de separar as responsabilidades, que ele usa no mesmo artigo: o agente coordena o objetivo, a skill orienta como pensar sobre um problema específico, a tool executa uma ação concreta, e o harness é quem disponibiliza essas ferramentas e aplica as permissões sobre elas. Uma skill pode recomendar que uma ferramenta seja usada, mas não é ela quem decide se essa ferramenta está disponível ou se a chamada pode de fato ser executada. Essa decisão pertence ao harness.
Essa distinção resolve uma confusão comum. Quando um agente erra, a primeira reação costuma ser trocar de modelo ou reescrever o prompt. Na maioria das vezes, o problema está em outro lugar: falta uma ferramenta, falta uma fonte de contexto, falta uma permissão bem definida ou falta um mecanismo de feedback que avise o agente que algo deu errado.
A parte mais interessante da série de Luiz Schons é justamente onde ele coloca esse conceito para funcionar num cenário concreto. O exemplo usado é um pedido simples na aparência: um cliente quer solicitar reembolso parcial de um pedido, devolvendo só alguns itens da compra.
Um agente que recebe apenas esse texto e já parte para escrever código tende a produzir uma solução plausível e, ainda assim, errada. O fluxo proposto mostra onde o harness entra em cada etapa da entrega:
Questionar o épico antes de codar. O primeiro trabalho do agente não é criar arquivos, é transformar o pedido em perguntas: quem pode solicitar o reembolso, existe prazo, o que acontece se o provedor de pagamento aceitar o reembolso mas a atualização interna falhar. Uma skill de planejamento orienta essas perguntas, e uma tool busca épicos e decisões anteriores no histórico do time.
Fazer a investigação técnica (spike). Aqui o agente usa diferentes fontes de contexto (o fluxo de cancelamento existente, a integração com o provedor de pagamento, testes já escritos, eventos publicados após mudanças de pagamento) para reconstruir como o sistema realmente funciona hoje, em vez de apenas localizar arquivos com nomes parecidos.
Registrar a decisão. O resultado da investigação não fica apenas na conversa com o agente. Vira um documento com contexto, alternativas consideradas, decisão tomada e riscos identificados, algo perto de um ADR. Esse registro alimenta o contexto de futuras demandas.
Definir o que significa sucesso antes de criar tarefas. Sucesso, nesse caso, não é medido pela quantidade de arquivos alterados. É medido por critérios como: o valor reembolsado nunca ultrapassa o valor pago, a mesma solicitação não é processada duas vezes, a taxa de erro não aumenta depois do deploy.
Definir a observabilidade antes de escrever o código. Antes da implementação, o time decide quais métricas serão coletadas, quais logs serão emitidos, e qual sinal deve disparar um rollback. Sem isso, a equipe publica a mudança e fica sem evidência de que ela funcionou.
Implementar, revisar e documentar. Só depois de tudo isso é que a implementação acontece. O agente pode preparar o pull request e o plano de deploy, mas a aprovação de mudanças de contrato, os trade-offs de negócio e a decisão final continuam sendo responsabilidade da equipe.
O ponto central desse exemplo é simples: a implementação do código é só uma etapa, e muitas vezes nem é a mais complexa. Entender o problema, tomar decisões, definir o que é sucesso e planejar a observabilidade exigem mais raciocínio do que escrever a solução em si. Um agente só participa bem desse processo quando o harness ao redor dele oferece contexto, skills e ferramentas suficientes para cada uma dessas etapas. Sem isso, o agente tende a preencher as lacunas com suposições.
Um harness bem construído muda a forma como um time avalia e depura ferramentas de IA no dia a dia.
Primeiro, ele muda onde o time procura quando algo dá errado. Um agente que trava no meio de uma tarefa longa raramente está com problema no modelo. Geralmente falta planejamento antes da execução, memória que perdeu contexto relevante, ou um sandbox mal configurado que bloqueou uma ação necessária. Saber separar essas camadas evita que o time gaste uma semana depurando o harness por um bug que na verdade está no sandbox, ou vice versa.
Segundo, ele muda o critério de escolha de ferramentas. Estrelas no GitHub e picos de lançamento medem atenção, não confiabilidade. O contraste entre o crescimento repentino do DeepSeek Harness e a curva lenta e constante do Pi mostra dois caminhos diferentes chegando a números parecidos, mas só um deles reflete gente usando a ferramenta seis meses depois, sem alarde. Antes de adotar um harness para o time, vale perguntar qual problema real ele resolve: falta de portabilidade entre modelos, sessões longas que perdem contexto, ou tarefas repetitivas que poderiam virar conhecimento reutilizável.
Terceiro, ele muda a proporção do trabalho de engenharia. Se o harness cuida bem de planejamento, memória, observabilidade e permissões, o time passa menos tempo corrigindo comportamento errático do agente e mais tempo revisando decisões de negócio, que é onde a responsabilidade humana continua sendo insubstituível.
Antes de adotar uma ferramenta de agente para o time, algumas perguntas ajudam a enxergar além do hype:
Nenhuma resposta errada aqui invalida uma ferramenta por completo. Elas apontam qual problema aquele harness resolve bem e qual ele deixa para o time resolver por conta própria.
Um agent harness não é uma categoria misteriosa de software. É a camada que transforma a previsão de texto de um modelo em um agente capaz de planejar, agir, verificar o próprio trabalho e seguir até a tarefa terminar. O modelo raciocina. O harness dá lugar para esse raciocínio virar ação, memória e verificação.
A escolha de ferramenta importa menos do que entender essa arquitetura. Um harness com poucas peças, bem construídas, tende a superar um harness cheio de recursos mal integrados. E, principalmente para times de engenharia, entender onde o harness termina e onde começa a responsabilidade humana é o que decide se um agente vira uma ferramenta confiável ou uma fonte constante de surpresas em produção.
Nenhum comentário ainda. Seja o primeiro.
Ao desenvolver aplicações modernas com PHP, uma das tarefas mais comuns é manipular arrays — filtrando, transformando ou agrupando dados. Embora o PHP nativamente ofereça funções poderosas para isso, como array_map,…
Laravel, php, Tutorial
Enviar mensagens de email é uma parte essencial de muitas aplicações web, e o Laravel, um popular framework PHP, torna esse processo bastante fácil. No entanto, durante o desenvolvimento, é crucial testar o envio de…
Artigo, Laravel, php