Curso open source mostra que o "harness" supera a escolha do modelo em agentes de codificação
A discussão sobre qual modelo de linguagem utilizar costuma dominar as decisões em projetos de agentes de inteligência artificial. No entanto, experimentos recentes na área de engenharia de "harness" — a estrutura que orquestra o loop de execução do agente — indicam que o componente responsável pela forma como o sistema é executado tem impacto igual ou superior ao do modelo em si. Em um experimento da LangChain com o benchmark Terminal-Bench, a troca apenas do harness, mantendo o mesmo modelo, fez um agente de codificação subir da trigésima posição para o top cinco.
O resultado reposiciona a pergunta central: se a qualidade final depende do harness, então a forma como o loop é executado deixa de ser um detalhe de implantação e passa a ser uma decisão de arquitetura. Essa é a tese explorada no curso open source "Building a Coding Agent From Scratch", de Paul Iusztin, publicado pela Decoding AI. O curso constrói um agente em Python chamado Decode e separa três modos de execução, cada um com perfil próprio de latência e, portanto, com indicação diferente de provedor de inferência.
No centro do sistema está um harness headless, ou seja, sem interface própria. Dentro dele roda o loop de agente que todo harness compartilha: o modelo de linguagem escolhe uma ação, uma ferramenta é executada e a observação volta como entrada para o próximo ciclo. Tudo lê e escreve na janela de contexto. O agente em si é enxuto. No Decode, ele é definido em cerca de vinte linhas usando Pydantic AI, compondo modelo, ferramentas e tipo de saída. Já no código-fonte do Claude Code que vazou recentemente, o loop central tem aproximadamente 150 linhas. Todo o restante, incluindo memória, habilidades, sandbox, permissões, feedback de LSP e compactação, faz parte do harness.
A partir desse núcleo headless, três modos de execução se conectam. O primeiro é o modo interativo online, em que uma interface de terminal é conectada a uma sessão ao vivo, em memória e no mesmo processo. Os eventos são transmitidos por geradores assíncronos à medida que os tokens chegam. O ponto crítico desse modo é o controle de direção da conversa. Se o usuário digitar enquanto uma chamada de ferramenta está em andamento, injetar a mensagem imediatamente pode corromper o turno. A solução do Decode é uma fila de comandos com portão de prioridade. A entrada é armazenada ao chegar e injetada apenas em um ponto seguro do loop. Dois desses pontos são expostos: o MODEL_REQUEST, antes da próxima chamada ao modelo, e o WOULD_STOP, quando o turno iria terminar. Três modos de entrada se relacionam a eles. O Enter simples direciona dentro do turno. Alt mais Enter enfileira um comando até o fim do turno. Esc aciona um cancelamento cooperativo, limpando ambas as filas sem corromper o histórico. Como há uma pessoa lendo cada token, esse modo é limitado pela latência, o que o torna adequado a APIs hospedadas de baixa latência.
O segundo modo é o remoto offline, em que o harness permanece headless e roda em um servidor por meio de um agent runtime. O Decode utiliza o Kitaru, agent runtime da ZenML, implantado no Google Cloud Platform, com os agentes executando no Modal. Não há ninguém acompanhando. Uma fila de tarefas é distribuída entre N harnesses em paralelo, cada um produzindo seu próprio pull request. Como o runtime registra o progresso passo a passo, um sandbox que falhe no meio da tarefa é retomado a partir do último passo registrado, em vez de reiniciar. Ferramentas são executadas dentro dos Modal Sandboxes remotamente e em Docker localmente. A métrica relevante nesse cenário é vazão por dólar, não tempo até o primeiro token.
O terceiro modo é o assíncrono online, que fica entre os dois anteriores. Uma sessão ao vivo envia trabalho para uma fila e retorna imediatamente. Workflows em segundo plano distribuem chamadas ao modelo e publicam os resultados posteriormente. O usuário está online, mas não acompanha cada etapa. Como a fila possui o trabalho, a execução sobrevive ao cliente que a iniciou. É o padrão por trás de agentes acionados por Slack e revisão de pull requests em background, e a cobrança se assemelha a processamento em lote, não a chat.
A diferença de custo entre os modelos é expressiva. Em um cenário com mil documentos de trinta mil tokens de entrada e cerca de quinhentos tokens de saída cada, as taxas de fronteira de três dólares por milhão de tokens de entrada e quinze dólares por milhão de tokens de saída colocam o custo próximo a noventa e sete dólares. O cache de prompts não reduz esse valor porque cada documento tem prefixo diferente. Processado em lote em uma GPU serverless a aproximadamente três mil tokens por segundo, o mesmo trabalho leva menos de três horas de GPU e custa cerca de treze dólares. No caso oposto, o modelo padrão de teste do Decode, o Qwen3.6 35B, roda em uma única H200. A tabela de preços do Modal lista a H200 SXM em cerca de quatro dólares e cinquenta e quatro centavos por hora. Deixar um agente interativo ocioso durante dez horas esperando uma confirmação pode acrescentar cerca de quarenta e cinco dólares à conta.
A lógica que une essas comparações é direta. Trabalho interativo paga por token porque há uma pessoa esperando. Trabalho offline e assíncrono paga por hora de GPU porque o objetivo é vazão e tempo ocioso é desperdício. Há ainda um segundo eixo, entre capacidade reservada e serverless. As reservas cobram a tarifa de pico durante todo o contrato, enquanto o serverless acompanha a curva de demanda. Quando a razão entre pico e média supera o desconto da reserva, o serverless é mais barato. Dados do Modal indicam descontos típicos de duas a cinco vezes diante de razões pico-média de cinco a dez vezes em inferência, treinamento e desenvolvimento agentico. Pesquisas do setor citadas colocam a utilização de reservas abaixo de trinta por cento, frequentemente abaixo de dez por cento.
