LongHorizon-Harness: a arquitectura que ensina agentes de IA a não perderem o fio
LongHorizon-Harness: a arquitectura que ensina agentes de IA a não perderem o fio
Os agentes de inteligência artificial já conseguem (faz algum tempo) escrever código, operar aplicações, consultar páginas web e executar comandos no terminal. O problema surge quando uma tarefa exige dezenas ou centenas de passos interdependentes. Nesses cenários, uma falha inicial pode contaminar todas as decisões seguintes, enquanto o histórico da sessão cresce até se tornar difícil distinguir o que foi realmente concluído do que foi apenas afirmado.
O LongHorizon-Harness propõe uma resposta arquitectural a esse problema. Em vez de manter toda a tarefa numa única sessão contínua, o sistema coloca o estado do trabalho num registo separado da execução. Esse registo só deve receber factos confirmados através de uma inspeção independente do ambiente, criando uma distinção clara entre uma ação tentada, uma conclusão alegada e uma conclusão comprovada.
A arquitectura organiza cada ciclo em três papéis: Manager, Executor e Auditor. O Manager preserva o objetivo original, analisa o estado verificado e define a próxima subtarefa. O Executor trabalha num contexto novo e concentra-se apenas nessa subtarefa. Depois, o Auditor inspecciona os ficheiros, aplicações, processos ou resultados produzidos, sem ter acesso ao raciocínio interno nem ao histórico completo do Executor.
Esta separação pretende atacar três fragilidades recorrentes dos agentes de longo prazo: erros que se acumulam, degradação do contexto e perda do estado da tarefa. Uma sessão longa pode continuar a produzir actividade mesmo depois de se afastar do objetivo. Ao conservar apenas relatórios compactos de auditoria entre rondas, o LongHorizon-Harness tenta reduzir esse desvio sem apagar o progresso que já foi confirmado.
O princípio central é simples: o Executor pode dizer o que tentou fazer, mas não pode transformar essa afirmação em progresso permanente. Uma exigência só passa ao estado concluído quando o Auditor encontra evidência no ambiente. Se uma operação falhar, o erro fica limitado à ronda correspondente e a próxima decisão é tomada a partir do último estado considerado fiável.
O design deste processi também introduz contratos de subtarefa. Cada contrato define um objetivo imediato, critérios de aceitação, dependências e limites de atuação. O Manager pode decidir continuar, terminar, declarar a tarefa bloqueada ou pedir intervenção humana. Desta forma, a decomposição não é fixa desde o início: é actualizada com base no que foi realmente verificado em cada etapa.
Segundo o preprint publicado no arXiv, o sistema foi avaliado em três referências para tarefas de longa duração: WeaveBench, OSWorld 2.0 e Terminal-Bench 2.1. Estes testes cobrem, respectivamente, tarefas que combinam interfaces gráficas e linha de comandos, fluxos de trabalho em aplicações de desktop e problemas técnicos executados através do terminal.
Na comparação apresentada pelos autores, o Qwen 3.7-Plus com Claude Code passou de 51,8% para 80,7% no PassRate do WeaveBench quando foi acrescentada a arquitectura LongHorizon-Harness. No Terminal-Bench 2.1, a taxa indicada subiu de 69,7% para 77,2%. No OSWorld 2.0, a conclusão binária passou de 2,8% para 8,3%, o que corresponde a uma multiplicação de três vezes, embora partindo de uma base muito baixa.
Os números devem, contudo, ser interpretados com cuidado. O WeaveBench é um teste exigente, com 114 tarefas em oito áreas, e utiliza uma avaliação sensível ao percurso seguido pelo agente, não apenas ao ficheiro final. A comparação apresentada pelo projecto mantém o modelo e o backend de execução, alterando sobretudo a camada de coordenação. Ainda assim, os resultados são experiências dos autores e não equivalem a uma replicação independente ou a uma validação universal em todos os ambientes.
Há também uma diferença importante entre melhorar a coordenação e aumentar a capacidade fundamental de um modelo. O LongHorizon-Harness não treina um novo modelo nem concede competências que o modelo subjacente não possua. A sua contribuição está em preservar melhor as capacidades existentes, recuperar de falhas, manter evidência entre rondas e impedir que uma conclusão não verificada seja tratada como facto.
Esta abordagem é particularmente relevante em tarefas que atravessam várias ferramentas. Um agente pode começar num navegador, continuar no terminal, editar um documento numa aplicação gráfica e regressar à linha de comandos para validar o resultado. Cada interface revela uma parte diferente do estado do trabalho, pelo que uma simples memória textual pode não ser suficiente para reconstruir o que aconteceu.
O projecto disponibiliza o código no GitHub e apresenta uma instalação através do pacote lh-harness. A integração é feita por uma camada AgentAdapter, permitindo associar diferentes modelos e backends aos papéis de Manager, Executor e Auditor. O repositório indica suporte para ambientes com Claude Code, Codex CLI e outros adaptadores compatíveis, embora a disponibilidade concreta dependa da configuração e das ferramentas instaladas.
A ideia mais importante não é que os agentes precisem simplesmente de janelas de contexto maiores. É que precisam de uma forma mais rigorosa de saber o que aconteceu. Para tarefas curtas, uma sessão única pode ser suficiente. Para trabalhos prolongados, a fiabilidade depende cada vez mais de separar acção, memória de estado e verificação. O LongHorizon-Harness transforma essa separação numa regra estrutural: executar, auditar e só depois preservar o progresso.
O código e a documentação do projecto estão disponíveis em GitHub. O artigo técnico pode ser consultado no arXiv, enquanto a página oficial apresenta a arquitectura, os exemplos e os resultados detalhados: LongHorizon-Harness.
