- Início
- The Thinking Wire
- O Critério do Harness: Manter Toda Chamada Dentro da Distribuição
O Critério do Harness: Manter Toda Chamada Dentro da Distribuição
Treine um modelo apenas em tarefas curtas, envolva-o no programa certo e ele se sustenta em tarefas retidas de 8 a 32 vezes mais longas, “com aproximadamente 10x de ganho na avaliação para o mesmo ganho de treino em relação a treinar diretamente o Transformer subjacente”. O resultado é de Alex L. Zhang e Omar Khattab, do MIT CSAIL, publicado como pesquisa no blog de Zhang em julho de 2026. Todos os experimentos rodam sobre um único modelo aberto, o Qwen3-30B-A3B-Instruct-2507.
O número é interessante. O critério que o produziu é mais útil, porque dá para revisar um harness existente contra ele em uma tarde.
Localmente Dentro da Distribuição
Os autores dão o nome de LID: toda chamada individual ao modelo precisa ver um prompt que esteja dentro da distribuição dos dados de treino, mesmo quando a trajetória inteira está fora dela.
São duas afirmações separadas sobre dois objetos separados. A trajetória é o arco completo de uma execução de agente, uma migração de quatro horas atravessando duzentos arquivos, e nenhum corpus de treino contém algo com esse formato. A chamada é um forward pass com um prompt. O LID diz que a trajetória pode ser estranha e que cada prompt individual não pode.
Essa decomposição transforma um argumento filosófico sobre limites de modelo em uma pergunta de revisão com resposta sim ou não. Escolha qualquer chamada de uma execução longa. Despeje o prompt exato que foi pela rede. Pergunte se aquele prompt se parece com algo em que o modelo foi treinado. Se for um acúmulo de 180 mil tokens somando system prompt, doze schemas de ferramenta, quarenta saídas de ferramenta, três despejos de arquivo e um plano que o próprio modelo escreveu noventa minutos atrás, a resposta é não, e o modelo está extrapolando em cada passo dali em diante.
Zhang e Khattab ligam isso a escala de forma direta: “melhores retornos em escala exigem generalização composicional, e a capacidade de generalização composicional parece precisar viver, em grande medida, naquilo que hoje chamamos de harness”. Para quem acompanhou nosso texto sobre o que é um agent harness, esta é a forma forte daquele argumento. O harness carrega o viés indutivo. Nas palavras deles, “o trabalho primário do harness deveria ser carregar um viés indutivo de nível mais alto, capaz de reduzir problemas complexos e desconhecidos a composições de problemas mais simples”.
O Diagnóstico Nomeado
A parte que vai circular em canais de engenharia é a avaliação que os autores fazem das ferramentas que as pessoas de fato usam. Eles escrevem que “designs de harness existentes, como Claude Code e Codex, falham em facilitar observações localmente dentro da distribuição (LID) para a rede neural subjacente… eles dependem fundamentalmente de inundar a janela de contexto do Transformer com informação específica da tarefa intercalada, saídas de chamadas de ferramenta…”.
Os autores chegaram a isso lendo a arquitetura. Eles não rodaram o Claude Code contra uma suíte para publicar uma nota. Observaram que um único contexto crescente, intercalando texto da tarefa com saída de ferramenta, garante que chamadas tardias de uma execução longa vejam prompts diferentes de tudo que existia no treino.
O diagnóstico explica um modo de falha que a maioria dos times já sentiu e rotulou errado. Já medimos o quanto o harness move resultados sobre modelos idênticos; aqui está um mecanismo para parte daquela variação. Execuções longas de agente degradam de um jeito característico: a primeira hora é afiada, a terceira hora produz trabalho confiante que contradiz silenciosamente decisões tomadas na primeira. Times costumam atribuir isso a limites de contexto ou a um modelo “cansado”, que não existe. O LID dá uma explicação mecânica. Cada chamada sucessiva está mais distante da distribuição de treino que a anterior, e a curva de degradação acompanha o acúmulo, não o relógio.
Dois Mecanismos que Valem Copiar
A arquitetura que os autores treinam é um Recursive Language Model, e dois de seus mecanismos são transferíveis para harnesses que você já opera.
O primeiro é context offloading. O contexto específico da entrada é passado como variável simbólica, de modo que a chamada raiz nunca vê o conteúdo bruto diretamente. O modelo raiz raciocina sobre uma referência. As subchamadas resolvem a referência quando precisam dos bytes. O prompt que o modelo raiz enxerga continua pequeno e continua com o formato dos prompts em que ele foi treinado, por maior que fique o conjunto de documentos por baixo.
O segundo é chamada programática de subagentes com armazenamento baseado em REPL. As subchamadas partem de código executável, e suas saídas caem em um armazenamento em vez de voltar para a janela de contexto de quem chamou. O pai decide o que ler de volta.
Argumentamos em engenharia de harness é subtração que o melhor trabalho de harness apaga andaimes em vez de acrescentá-los. Context offloading é aquele argumento com um mecanismo acoplado. A remoção tem destino: uma referência, que foi como todas as outras camadas da computação resolveram o mesmo problema décadas atrás.
O que a Evidência Cobre
Precisão sobre o setup importa aqui, porque a afirmação é forte e a base de evidência é um post de blog de dois pesquisadores.
Generalização de comprimento: 150 passos de treino com batch 64 e 4 rollouts por amostra usando prime-rl, avaliando cada checkpoint de 10 passos em splits de 8 a 32 vezes o comprimento das tarefas de treino. Generalização de estratégia: 500 passos, avaliados a cada 20 passos em um domínio de ambiente diferente. Em MRCRv2, GraphWalks, OOLONG e OOLONG-Pairs, o RLM treinado “se aproxima ou supera um RLM com um modelo de fronteira, GPT-5.5, na avaliação longa, enquanto supera com folga o Transformer base”.
Os próprios autores declaram o custo: “o tempo de execução do treino do RLM é de 1,5 a 3x maior que o dos equivalentes com Transformer base, por conta de múltiplos passos por amostra e da espera por subchamadas”. É um imposto real e vale citar para quem lê a manchete e presume que a abordagem sai de graça.
Três ressalvas acompanham os números. É pesquisa publicada no blog dos próprios autores, sem revisão por pares, portanto sem crivo externo. Todos os resultados são autorreportados. Tudo roda sobre um único modelo aberto de 30B, então a generalização da própria afirmação de generalização segue não testada.
Nada disso enfraquece o critério. O LID é um princípio de design que dá para aplicar e verificar localmente, e ele se sustenta ou cai no seu harness, e não nas curvas de treino deles.
Rode a Revisão de LID
Quatro passos, uma tarde, sobre a execução de agente que mais importa na sua organização.
Capture um prompt real. Instrumente o harness para logar o prompt completo de toda chamada ao modelo em uma execução longa. Não um resumo. Os bytes exatos.
Ordene por tamanho e olhe a cauda. Pegue o maior prompt da execução e leia como se você fosse o modelo. Conte quantas fontes distintas de texto estão intercaladas ali. Se forem mais de três, você está fora do formato dos dados de treino comuns.
Encontre a primeira carga descarregável. Procure o maior bloco de conteúdo específico da tarefa sobre o qual o modelo que chama nunca raciocina de fato, e roteie esse bloco por referência. Conteúdo de arquivo e despejo de saída de ferramenta costumam ser os dois primeiros candidatos.
Meça a mesma execução de novo. Compare a distribuição de tamanho de prompt e a taxa de sucesso ponta a ponta antes e depois. A falha que você quer mover é a contradição da terceira hora, então meça na terceira hora.
A consequência estratégica para quem compra IA merece ser dita com clareza. Confiabilidade em trabalho longo e desconhecido é propriedade da arquitetura que você possui e pode alterar, de modo que um upgrade de fornecedor não entrega isso e uma troca de modelo também não. A generalização composicional mora no harness, e o harness é seu.
Fontes
- Alex L. Zhang e Omar Khattab, MIT CSAIL. “Language model harnesses are compositional generalizers.” Julho de 2026.
A Victorino revisa harnesses de agentes contra critérios como o LID e reconstrói os que inundam a própria janela de contexto: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa