Agentes de longa duração e multiagentes

Aula 28

Por que agentes falham em projetos longos

O artigo Effective harnesses for long-running agents, da Anthropic, parte de uma analogia: imagine um projeto tocado por engenheiros em turnos, em que cada um chega sem nenhuma lembrança do turno anterior. É exatamente o que acontece quando uma tarefa ultrapassa a janela de contexto: cada nova sessão começa do zero.

O artigo identifica dois modos de falha principais. No primeiro, o agente tenta fazer tudo de uma vez, fica sem contexto no meio de uma funcionalidade e deixa o trabalho pela metade, sem registro do que faltava. No segundo, uma sessão posterior olha o projeto, vê que muita coisa já existe e declara a tarefa concluída antes da hora. O texto lista quatro falhas recorrentes e suas correções:

O artigo registra também que a compactação de contexto, sozinha, não resolve esses problemas. O resumo automático preserva parte do estado, mas não substitui um registro estruturado e verificável do que já foi feito.

Fontes desta aula: Anthropic: Effective harnesses for long-running agents

Aula 29

O padrão inicializador e agente de código

A solução proposta pela Anthropic usa dois papéis. Na primeira sessão, um agente inicializador monta o ambiente: cria o init.sh para subir o projeto, o arquivo claude-progress.txt, a lista de funcionalidades e o primeiro commit. Nas sessões seguintes, um agente de código avança de forma incremental, uma funcionalidade por vez, e sempre deixa o projeto num estado limpo. Uma nota do artigo esclarece que os "agentes diferentes" só diferem no prompt inicial: o harness, as ferramentas e o prompt de sistema são os mesmos.

Cada sessão do agente de código segue uma rotina fixa de início:

1. Rodar pwd para saber onde está.
2. Ler o git log e o arquivo de progresso.
3. Ler a lista de funcionalidades e escolher a de maior prioridade ainda não concluída.
4. Subir o servidor de desenvolvimento com o init.sh.
5. Rodar um teste básico de ponta a ponta antes de começar algo novo, para garantir que a sessão anterior não deixou nada quebrado.

O teste de ponta a ponta foi decisivo. O artigo relata que o agente marcava funcionalidades como prontas depois de testes unitários ou chamadas à API, sem verificar a aplicação de verdade. A automação de navegador via Puppeteer MCP resolveu boa parte disso, com uma limitação registrada: o agente não enxerga alertas nativos do navegador por essa ferramenta.

Um segundo artigo, de março de 2026, evoluiu o padrão para três agentes: um planejador que transforma um pedido curto numa especificação, um gerador que implementa e um avaliador que usa Playwright para clicar pela aplicação e dá nota com limites mínimos por critério. A inspiração declarada são as redes adversariais generativas: separar quem produz de quem avalia cria uma alavanca de feedback forte, porque é mais fácil calibrar um avaliador para ser cético do que pedir ao próprio gerador que critique o seu trabalho.

Fontes desta aula: Anthropic: Effective harnesses for long-running agents · Anthropic: Harness design for long-running apps

Aula 30

Subagentes como firewall de contexto e o padrão orquestrador-trabalhadores

Um subagente é um agente que o agente principal chama para uma tarefa delimitada, com janela de contexto própria. A HumanLayer define seu papel principal como firewall de contexto: o subagente pode ler dezenas de arquivos e gastar dezenas de milhares de tokens investigando, mas devolve ao agente principal só um resumo condensado. A Anthropic quantifica: um subagente explora com dezenas de milhares de tokens e devolve de 1.000 a 2.000.

O sistema de pesquisa multiagente da Anthropic é o caso mais documentado do padrão orquestrador-trabalhadores. Um agente líder planeja, cria subagentes que buscam em paralelo e sintetiza os resultados. Os números do artigo mostram o ganho e o custo:

• Um líder Claude Opus 4 com subagentes Claude Sonnet 4 superou um único Opus 4 em 90,2% na avaliação interna de pesquisa, principalmente em perguntas amplas.
• O volume de tokens sozinho explica 80% da variação de desempenho no benchmark BrowseComp. Tokens, número de chamadas de ferramenta e escolha de modelo juntos explicam 95%.
• Agentes usam cerca de 4 vezes mais tokens que uma conversa comum. Sistemas multiagentes usam cerca de 15 vezes mais.
• O paralelismo (3 a 5 subagentes ao mesmo tempo, cada um usando 3 ou mais ferramentas em paralelo) reduziu o tempo de pesquisas complexas em até 90%.

A lição é que multiagente compensa quando o valor da tarefa paga o custo e quando o trabalho é paralelizável. O artigo também conta falhas iniciais instrutivas, como criar 50 subagentes para perguntas simples. A correção foi colocar regras de escala no prompt: uma pergunta factual usa um agente com 3 a 10 chamadas, uma comparação usa de 2 a 4 subagentes, e só pesquisas complexas usam mais de 10. Cada delegação precisa de objetivo, formato de saída, orientação sobre ferramentas e fontes, e limites claros da tarefa.

Fontes desta aula: Anthropic: How we built our multi-agent research system · HumanLayer: Skill Issue · Anthropic: Effective context engineering for AI agents

Aula 31

Estudo de caso: um compilador C escrito por Claudes em paralelo

Em fevereiro de 2026, Nicholas Carlini, da Anthropic, publicou o experimento mais ambicioso de harness até então: 16 agentes Claude trabalhando em paralelo construíram, ao longo de duas semanas e quase 2.000 sessões do Claude Code, um compilador de C com 100 mil linhas em Rust, sem dependências e sem acesso à internet. O compilador consegue compilar o kernel Linux 6.9 para x86, ARM e RISC-V, passa em cerca de 99% da maioria das suítes de teste de compiladores, incluindo os testes de tortura do GCC, e compila projetos como QEMU, FFmpeg, SQLite, PostgreSQL e Redis. O custo foi de cerca de 20 mil dólares em API.

O harness era deliberadamente simples:

• Um laço em bash que inicia uma nova sessão do Claude Code assim que a anterior termina, sempre a partir do mesmo arquivo de prompt, rodando dentro de contêineres, sem nunca rodar na máquina do autor.
• Coordenação sem orquestrador: cada agente reivindica uma tarefa gravando um arquivo de trava numa pasta current_tasks/, e o git resolve os conflitos.
• Papéis especializados para alguns agentes: remover duplicação, melhorar desempenho, qualidade do código gerado, crítica de qualidade do Rust e documentação.
• Testes de altíssima qualidade e o GCC usado como oráculo: para achar bugs na compilação do kernel, partes eram compiladas com o GCC e partes com o novo compilador, isolando o par que falhava.

O artigo é honesto sobre os limites: o compilador ainda chama o GCC para gerar código x86 de 16 bits, não tem assembler nem linker próprios, gera código mais lento que o GCC sem otimizações e não substitui um compilador de produção. A lição para harness engineering é que, com sensores fortes (testes, oráculo, CI) e coordenação mínima, muitos agentes conseguem avançar sozinhos num problema enorme. O investimento estava nos sensores, não na orquestração.

Fontes desta aula: Anthropic: Building a C compiler with parallel Claudes

Aula 32

Agentes de manutenção: a coleta de lixo da dívida técnica

Código escrito por agentes acumula dívida técnica rapidamente: pequenas duplicações, padrões inconsistentes, documentação que deixa de bater com o código. No relato da OpenAI sobre harness engineering, a resposta foi tratar a manutenção como trabalho contínuo de agentes: agentes de "coleta de lixo" rodam em segundo plano, procuram desvios em relação às regras e à documentação do repositório e abrem pull requests pequenos de refatoração.

A vantagem do formato é o tamanho das mudanças. Um PR que corrige um único padrão em poucos arquivos é rápido de revisar e fácil de reverter. Uma grande refatoração trimestral é arriscada e costuma ser adiada. O compilador C usou a mesma ideia com papéis fixos: agentes dedicados a remover duplicação e a criticar a qualidade do código produzido pelos outros.

Para quem usa Claude Code ou Codex, o padrão pode ser aplicado com tarefas agendadas: um agente que roda toda noite, verifica se os documentos em docs/ ainda descrevem o código, procura violações das regras do AGENTS.md que os linters não pegam e abre no máximo um ou dois PRs pequenos. O limite de quantidade é importante para não transformar a revisão humana em gargalo.

Fontes desta aula: OpenAI: Harness engineering (Ryan Lopopolo) · Anthropic: Building a C compiler with parallel Claudes

Erros comuns

• Confiar na compactação para tarefas de vários dias. Use arquivo de progresso, lista de funcionalidades e commits.
• Deixar o agente marcar como pronto sem teste de ponta a ponta. Testes unitários passando não garantem que a aplicação funciona.
• Multiagente para tudo. O custo em tokens é cerca de 15 vezes o de uma conversa. Use quando a tarefa for valiosa e paralelizável.
• Delegação vaga para subagentes. Sem objetivo, formato e limites, o subagente duplica trabalho ou volta com o resumo errado.
• Rodar agentes autônomos fora de contêiner. O próprio experimento do compilador roda em contêineres isolados.

Aplicação prática

1. Para uma tarefa grande, crie um progress.md e uma lista de funcionalidades em JSON com o campo passes, e instrua o agente a ler os dois no início de cada sessão.
2. Escreva uma rotina de início de sessão (pwd, git log, progresso, servidor, teste básico) e coloque no AGENTS.md ou numa skill.
3. Use um subagente para investigar uma parte desconhecida do código e compare o contexto consumido com fazer a investigação na sessão principal.
4. Configure uma tarefa noturna de manutenção que abra no máximo um PR pequeno por noite.

Siglas usadas neste módulo

JSON:

JavaScript Object Notation, formato de dados em texto.

API:

Application Programming Interface, interface de programação de aplicações.

CI:

Continuous Integration, integração contínua.

GCC:

GNU Compiler Collection, coleção de compiladores do projeto GNU.

MCP:

Model Context Protocol, protocolo aberto para conectar agentes a ferramentas.

PR:

Pull Request, pedido de integração de mudanças.