Gerar, Avaliar, Repetir: O Que Agentes de Longa Duração Exigem do Harness

Prithvi Rajasekaran, da Anthropic, publicou um artigo sobre design de harness para aplicações de longa duração. O título é sóbrio: “Harness Design for Long-Running Application Development.” O conteúdo é mais interessante do que parece à primeira vista. Não pelo que apresenta como inovação, mas pelos dados empíricos que escapam entre as linhas.

Três padrões merecem atenção: a separação entre geração e avaliação, os contratos de sprint aplicados a agentes, e o comportamento de degradação em janelas de contexto longas. Cada um revela algo sobre o estado atual da engenharia de agentes.

Gerar e Avaliar Como Papéis Separados

O artigo propõe uma arquitetura de três agentes: Planner (que cria especificações), Generator (que implementa) e Evaluator (que testa via Playwright MCP). Rajasekaran compara essa estrutura a GANs, as redes adversariais generativas.

A comparação é sedutora. Também é estruturalmente incorreta.

Em uma GAN, gerador e discriminador são treinados em conjunto. O gradiente do discriminador flui de volta para o gerador. Cada ciclo melhora ambos os componentes. O que Rajasekaran descreve é diferente: um agente gera código, outro agente avalia o resultado, e o primeiro tenta de novo se falhar. Não há fluxo de gradientes. Não há treinamento adversarial. Não há melhoria conjunta dos componentes.

O nome correto é mais simples e mais antigo: loop de geração-e-teste com separação de papéis. A separação é útil. O rótulo de GAN é marketing.

Dito isso, a utilidade prática da separação é real. Um agente que avalia seu próprio output tem viés sistêmico de superestimação. Dados independentes confirmam isso: agentes consistentemente classificam como correto aquilo que não é. Um avaliador externo, mesmo compartilhando os mesmos pontos cegos do modelo base, reduz a taxa de falsos positivos.

A Anthropic reconhece o problema e propõe calibração via exemplos few-shot. Na prática, isso significa injeção manual de julgamento humano. O avaliador automatizado funciona até o limite da calibração que um humano providenciou. Para aplicações curtas, basta. Para sessões de horas, a calibração pode ficar obsoleta antes do fim da execução.

Sprint Contracts: Critérios de Aceite Renomeados

O conceito de “sprint contracts” é apresentado como peça central da arquitetura. Antes de cada sprint de implementação, o Generator propõe escopo e critérios de sucesso. O Evaluator valida esses critérios antes da codificação começar. Depois da implementação, o Evaluator testa contra os critérios acordados.

Se isso soa familiar, deveria. A indústria pratica Acceptance Test-Driven Development (ATDD) há mais de vinte anos. Behavior-Driven Development (BDD) formaliza exatamente esse fluxo: definir critérios de aceite antes de implementar, depois validar contra eles. O livro de Dan North sobre BDD é de 2006.

A diferença é que aqui os “stakeholders” são agentes de IA em vez de pessoas. E essa diferença, embora real, não justifica um vocabulário novo. Renomear práticas estabelecidas obscurece a arte anterior e dificulta que engenheiros conectem o padrão a duas décadas de aprendizado acumulado.

Como discutimos em Harness Engineering Não É Novo, a tendência de reembalar disciplinas existentes sob rótulos novos é recorrente nesse campo. Cada publicação apresenta sua variação como descoberta. O que se acumula não é conhecimento novo, mas reconhecimento tardio de práticas antigas.

A Degradação do Contexto Longo

Aqui os dados ficam genuinamente interessantes.

Rajasekaran documenta um fenômeno que chama de “ansiedade de contexto”: modelos que operam em sessões longas começam a encerrar tarefas prematuramente. Não por incapacidade técnica. Por algo que se assemelha a impaciência. O modelo, conforme a janela de contexto se enche, passa a declarar tarefas completas antes de concluí-las.

A solução proposta é um “reset estruturado de contexto.” Em vez de comprimir o histórico (técnica comum que perde informação silenciosamente), o sistema reinicia o contexto com um resumo curado, preservando decisões e estado mas descartando o ruído acumulado.

Isso confirma o que outros pesquisadores já reportaram. Dados da morphllm.com atribuem 65% das falhas de agentes em ambiente corporativo a context drift. O padrão é consistente: janelas de contexto maiores adiam o problema. Não resolvem.

Para quem projeta sistemas de agentes em produção, o implicação é direta. Se seu harness depende de sessões longas sem reset de contexto, você está construindo sobre uma fundação que degrada com o tempo. Como exploramos em padrões de orquestração de agentes, a arquitetura do harness precisa tratar gerenciamento de contexto como preocupação de primeira classe.

Os Números Que Importam

O artigo apresenta custos de dois projetos:

Retro Game Maker. Primeira tentativa: $9 em 20 minutos. O jogo não funcionava. Segunda tentativa, com o harness completo de três agentes: $200 em 6 horas. O jogo funcionava. Aumento de 22 vezes no custo para saltar de “quebrado” para “funcional.”

DAW (Digital Audio Workstation). $124,70 em 3 horas e 50 minutos, usando um harness simplificado.

Dois pontos sobre esses dados.

Primeiro, são estudos de caso individuais. Sem repetição, sem análise de variância, sem controle experimental. Não sabemos se $200 é o custo típico ou o melhor caso selecionado. Quando a Anthropic reporta resultados de produtos Anthropic, a probabilidade de seleção favorável não é negligenciável.

Segundo, a razão de 22x entre “sem harness” e “com harness” é informativa mesmo sem rigor estatístico. Ela sugere que o custo do harness não é incremental. É um salto discreto. Você investe na infraestrutura de orquestração ou aceita output inutilizável. Não existe meio-termo produtivo.

Já documentamos esse padrão com dados mais amplos em A Diferença do Harness. Os benchmarks CORE-Bench e SWE-bench confirmam a mesma dinâmica: a diferença entre harness mínimo e harness bem projetado não é marginal. É categórica.

A Complexidade Não Diminui. Ela Se Move.

O insight mais interessante do artigo é quase uma nota de rodapé.

Rajasekaran observa que conforme os modelos melhoram, a complexidade necessária do harness diminui para tarefas que já eram resolvíveis. Mas essa mesma melhoria habilita tarefas novas, mais difíceis, que exigem harnesses mais sofisticados. “O espaço de combinações interessantes de harness não encolhe. Ele se move.”

Isso beira a tautologia, mas a observação prática é válida. Organizações que investem em harness engineering não estão resolvendo um problema temporário. Estão investindo em uma capacidade que evolui junto com a fronteira. O harness de hoje resolve tarefas que eram impossíveis ontem. O harness de amanhã resolverá tarefas que são impossíveis hoje.

A diferença entre tautologia e insight depende do que você faz com a observação. Para quem planeja orçamento, ela significa que a linha de investimento em harness não tem data de expiração. Diferente do custo por token (que cai a cada trimestre), o retorno da engenharia de harness persiste e se acumula.

Como discutimos em arquiteturas multiagentes, os padrões de supervisão entre agentes não são artefatos de uma geração específica de modelo. São padrões arquiteturais que transcendem o componente.

O Que Fica

Separadas do marketing, as contribuições reais do artigo são três.

Dados empíricos de custo para sessões longas de agente. Poucos publicam isso. Mesmo imprecisos, $200 por uma aplicação funcional é um dado de referência que não existia.

Confirmação independente de que viés de autoavaliação é um problema estrutural, não anedótico. A solução proposta (calibração few-shot) é parcial, mas o diagnóstico é sólido.

Documentação do fenômeno de degradação em contexto longo, com uma solução prática (reset estruturado) que funciona melhor que compressão. Não é um achado original, mas é uma validação útil de práticas que organizações já adotam.

O restante é reembalagem de práticas conhecidas, analogia imprecisa com GANs, e a previsível dinâmica de uma empresa escrevendo sobre a eficácia de seus próprios produtos.

Para quem constrói agentes de longa duração, a lição prática é simples: separe geração de avaliação, defina critérios antes de implementar, resete o contexto periodicamente, e espere pagar significativamente mais por sessões que funcionam do que por sessões que parecem funcionar.

---

Fontes

• Rajasekaran, Prithvi (Anthropic). “Harness Design for Long-Running Application Development.” Março 2026.
• Anthropic. “Building Effective Agents.” 2024.
• morphllm.com. Dados sobre falhas de agentes em ambientes corporativos e context drift. 2025.
• North, Dan. “Introducing BDD.” 2006.

Na Victorino, projetamos harnesses de agentes para aplicações de longa duração que funcionam em produção, não apenas em demos: contato@victorino.com.br | www.victorino.com.br