A openJiuwen publicou um novo artigo de investigação que trata o harness de um agente de programação como uma camada de sistema de primeira classe, e não como um simples wrapper à volta do modelo. O tema é relevante porque o desempenho em tarefas longas depende cada vez mais da forma como o harness gere contexto, ferramentas, continuação da tarefa, diagnósticos, delegação e critérios de paragem, e não apenas do modelo subjacente. O artigo descreve um substrato de execução comum para agentes individuais, subagentes delegados e fluxos multiagente, enquanto o repositório JiuwenSwarm disponibiliza uma implementação inspecionável.
Os autores reportam 82,6% no SWE-bench Verified e 87,19% no Terminal-Bench 2.1. Os números são relevantes, mas a questão de engenharia mais útil é perceber o que demonstram de facto. O próprio artigo alerta que os sistemas de leaderboard diferem em modelos, prompts, ferramentas e implementações. Assim, a conclusão mais sólida não é que um harness venceu definitivamente outro, mas que a orquestração se tornou uma componente mensurável do sistema de agentes e precisa de avaliação controlada própria.
O harness passa a ser um control plane
A openJiuwen separa a execução numa Inner Loop para interação entre modelo e ferramentas e numa Outer Loop para continuação e controlo ao nível da tarefa. Capacidades transversais são ligadas através de um mecanismo chamado Rail, usando lifecycle hooks e ordenação explícita, em vez de inserir cada capacidade num caminho de execução separado. As mesmas semânticas são reutilizadas em agentes individuais, subagentes delegados e Swarm Flow.
A arquitetura ataca um problema real. Agentes de programação acumulam planeamento, memória, gestão de contexto, controlos de segurança, intervenção humana, retries e delegação. Se cada nova capacidade alterar o núcleo do execution loop, o harness torna-se difícil de compreender e testar. Um substrato partilhado pode simplificar a composição, mas também transforma a configuração do harness numa superfície de controlo que precisa de versionamento, observabilidade e testes de regressão.
O repositório mostra que não se trata apenas de uma proposta conceptual. JiuwenSwarm disponibiliza colaboração multiagente, workflows determinísticos com Swarmflow, permissões de ferramentas, execução distribuída e um mecanismo Auto Harness destinado a otimizar o harness sem alterar os pesos do modelo. O projeto usa licença Apache-2.0 e pode ser instalado, o que melhora a possibilidade de inspeção e reprodução.
A adaptação em runtime altera o framework, não os pesos do modelo
A segunda ideia é runtime adaptivity. Em vez de voltar a treinar o modelo, a openJiuwen modifica o estado controlado pelo framework durante a execução. Context Management comprime, reduz ou desloca informação antiga; Goal Mode controla aceitação e paragem; feedback baseado em LSP injeta diagnósticos semânticos; Self-Reflection guarda experiência de trajetórias concluídas.
Esta distinção é importante para equipas que trabalham com modelos de terceiros. Parte das melhorias em tarefas longas pode vir do control plane em torno de um modelo fixo, o que tende a ser mais rápido de iterar do que fine-tuning. Mas esta camada cria também uma nova superfície de falha. Um gestor de contexto pode esconder evidência importante, uma regra de paragem pode terminar cedo demais e um ciclo de diagnóstico pode dar demasiado peso a sinais estáticos que não provam qualidade arquitetural ou correção de negócio.
Em produção, o harness não deve ser tratado como infraestrutura invisível. Os testes precisam de cobrir retenção de contexto, condições de paragem, permissões de ferramentas, comportamento de retry e injeção de diagnósticos, além do próprio modelo.
O headline de benchmark precisa de uma auditoria da alegação
O artigo reporta que openJiuwen com GPT-5.6 Sol atinge 87,19% no Terminal-Bench 2.1, contra 83,8% num resultado selecionado do Claude Code. Visto isoladamente, o diferencial de 3,39 pontos percentuais parece uma vantagem direta do harness. Não é uma estimativa controlada desse efeito, porque os sistemas usam modelos diferentes e também podem divergir em prompts, ferramentas e implementação.
O artigo inclui uma comparação mais informativa com Fable 5. Com o mesmo modelo, openJiuwen reporta 84,04% e Claude Code 83,8%, uma diferença de apenas 0,24 pontos percentuais. Os autores dizem explicitamente que o model matching reduz um fator de confusão, mas não elimina diferenças de prompts, ferramentas ou implementação dos agentes.
No SWE-bench Verified, a comparação é um pouco mais limpa porque openJiuwen e o melhor resultado selecionado usam ambos Claude 4.5 Opus, com 82,6% contra 79,2%. Mesmo assim, continua a ser uma comparação entre sistemas completos e não uma ablation controlada do harness. O artigo reconhece que são necessários estudos mais amplos e ablations mais detalhadas para isolar a contribuição dos diferentes mecanismos.
Por isso, a evidência atual suporta a afirmação de que openJiuwen é competitivo como sistema de agentes completo. Ainda não demonstra que Rail, Goal Mode, adaptação de contexto ou qualquer mecanismo individual seja a causa do ganho reportado.
O que as equipas de engenharia devem realmente medir
Uma avaliação útil deve manter tão constantes quanto possível o modelo, esforço de raciocínio, conjunto de ferramentas, orçamento de tokens e ambiente, variando depois os componentes do harness um de cada vez. Isso permitiria medir se gestão adaptativa de contexto, feedback LSP, lógica de paragem, reflexão ou coordenação multiagente contribuem realmente para taxa de conclusão, latência, custo ou fiabilidade.
Também é importante medir modos de falha e não apenas pass rate. Um agente long-horizon pode entrar em loop, esquecer restrições, esgotar orçamento, usar ferramentas em excesso, parar antes de cumprir critérios de aceitação ou transportar contexto desatualizado. Estes modos de falha ligam-se diretamente aos mecanismos de controlo que a openJiuwen tenta formalizar.
A implicação prática vai além deste projeto. A avaliação de agentes está a tornar-se uma disciplina full-stack. Um model score isolado não é suficiente quando o harness decide o que o modelo vê, que ferramentas pode usar, quando tenta novamente e quando termina. Comparações com o mesmo modelo e ablations do harness devem fazer parte da avaliação de alegações sobre ganhos de orchestration.
Porque vale a pena acompanhar este trabalho
openJiuwen continua a ser um preprint e a avaliação atual limita-se a SWE-bench Verified e Terminal-Bench 2.1. Os próprios autores pedem estudos controlados mais amplos com outros benchmarks, modelos e configurações. Não existe ainda base para tratar o sistema como universalmente superior ou pronto para produção.
O valor editorial resulta da combinação entre uma implementação open source inspecionável, uma arquitetura explícita de harness e resultados de benchmark que podem ser auditados em vez de simplesmente repetidos. A contribuição mais importante é enquadrar o controlo em runtime como uma camada de engenharia que pode mudar independentemente dos pesos do modelo.
Para developers e architects, a pergunta torna-se mais precisa: não «qual é o melhor coding model?», mas «qual combinação de modelo e harness produz resultados fiáveis com orçamento e control boundary fixos?» É um benchmark mais difícil, mas está muito mais próximo do comportamento real dos sistemas de agentes em produção.