Em vez de treinar um agente multimodal tarefa por tarefa, o artigo "The Trinity: Capability-Driven Recursive Self-Improvement for Multimodal Agents" propõe reorganizar o aprendizado em torno de capacidades compartilhadas. São autores Weidong Tang, Ruiheng Wang, Jingxuan Zhang e mais dezoito coautores.
A partir de trajetórias verificadas, o framework induz uma árvore de capacidades. Gera mundos simulados para cada nó dessa árvore.
Evolui módulos de Harness que depois são roteados conforme a tarefa.
Os autores relatam ganho médio de 34 pontos em 28 benchmarks de treino e de 26 pontos em 18 benchmarks não vistos. O conjunto inclui duas tarefas incorporadas do mundo real.
O trabalho está no arXiv e tem página de projeto em trinity-rsi.GitHub.io.
O que os autores propõem
A tese central é uma mudança de eixo: sair de um autoaperfeiçoamento orientado por tarefa para um autoaperfeiçoamento orientado por capacidade. Os autores argumentam que tarefas com modalidades e formas superficiais diferentes podem compartilhar os mesmos requisitos cognitivos subjacentes.
O exemplo que usam é direto. ARC-AGI-3 e Micromouse têm estruturas completamente distintas, mas ambos exigem percepção acurada e rastreamento de estado.
No primeiro caso, reconhecer estados de grade e suas mudanças. No segundo, atualizar continuamente informações do ambiente durante a exploração de um labirinto.
Se essa premissa vale, agrupar tarefas por requisito compartilhado transforma o mecanismo subjacente em objetivo comum de aprendizagem, o que favoreceria generalização. A partir daí, os autores propõem que múltiplos Harnesses especializados sejam evoluídos em paralelo e selecionados por um roteador ciente de capacidade.
Não um Harness global nem uma miríade de Harnesses específicos por tarefa.
O artigo é explícito ao dizer que está fazendo uma defesa de posição, não apenas apresentando um sistema. A posição é que a otimização específica por tarefa limita a generalização de capacidades.
Contexto: qual problema está sendo atacado
O enquadramento parte de uma visão de inteligência multimodal como laço coevolutivo entre mundos e agentes, com humanos guiando a aprendizagem e o ambiente fornecendo tarefas verificáveis. Escalar esse laço esbarra em dois gargalos, segundo os autores.
O primeiro é o custo de construir ambientes heterogêneos e verificáveis em escala. O segundo é que o desempenho do agente passa a ser limitado pelo Harness, a camada que coordena um modelo congelado.
A iteração manual desse Harness não acompanha o crescimento da diversidade e da complexidade das tarefas.
Trabalhos anteriores de autoaperfeiçoamento recursivo de Harness, argumentam os autores, concentram-se em tarefas de modalidade textual, como código e matemática, e adotam evolução específica por tarefa. Isso funciona quando as tarefas compartilham requisitos parecidos, mas tende a produzir overfitting de Harness e baixa generalização entre tarefas heterogêneas.
O extremo oposto também não resolve. Um Harness único e global não acomoda demandas conflitantes, incluindo trade-offs de desempenho e eficiência em tarefas incorporadas.
O artigo se posiciona exatamente no meio desse espectro.
Como funciona
O framework organiza o ciclo em três papéis. O Evolver extrai requisitos das especificações públicas e das trajetórias verificadas e reconstrói a árvore original de tarefas como uma árvore hierárquica de capacidades.
O Creator materializa essas capacidades em mundos simulados. O Explorer percorre a árvore evoluindo módulos reutilizáveis de Harness.
O pipeline tem três estágios. No primeiro, o Evolver normaliza benchmarks públicos multimodais em especificações de objetivos, observações, ações, feedback, critérios de conclusão e orçamentos, com checagem independente contra as fontes.
Os benchmarks são agrupados em cinco domínios de requisito: descoberta de regras, resolução de problemas com restrições, percepção e controle, interação multiagente e ambientes de horizonte longo. O Explorer coleta trajetórias apenas nas instâncias de treino.
As divisões de treino e de tarefas não vistas são fixadas antes da indução de capacidades.
No segundo estágio, agentes independentes propõem categorias de capacidade, um juiz consolida, e revisores checam definições, evidências, atribuições e cobertura. A árvore é construída só com tarefas de treino, com uma ordem determinística de capacidades definida previamente.
Cada nó agrupa tarefas que compartilham requisitos.
Aí entra o componente mais interessante: o Capability-Driven Real2Sim2Real. Para tarefas heterogêneas no mesmo nó, o Creator abstrai os requisitos comuns em mundos simulados simplificados e verificáveis.
Exclui layouts das tarefas-alvo, provas privadas e traços de solução, mas preserva o processo decisório central.
Um pool de verificadores checa vinculação ao nó, execução, transições de estado, renderização e conclusão. Mundos só são admitidos se o desempenho de um Harness de triagem cair numa faixa intermediária predefinida.
Caso contrário, o Creator ajusta a dificuldade em dimensões predefinidas. A avaliação nas tarefas originais mede a transferência.
No terceiro estágio, o Explorer constrói uma árvore de Harness alinhada à árvore de capacidades, com herança seletiva dos módulos ancestrais e refinamento local. Os módulos operam sobre seis protocolos de fluxo de controle descritos pelos autores: Percepção, Memória, Inferência, Planejamento, Orquestração e Loop.
O host valida evidência, propriedade, interfaces, linhagem e asserções tipadas antes de admitir qualquer atualização. Módulos ancestrais são preservados.
Ao fim de cada iteração, o Creator deduplica e mescla módulos complementares para formar um novo Base Harness. Fechando o ciclo, o Capability-Aware Harness Router usa informação pública da tarefa e experiência verificada para escolher o ramo compatível da árvore.
Resultados reportados
Os números centrais que os autores reportam são ganhos médios de 34 pontos em 28 benchmarks de treino e de 26 pontos em 18 benchmarks não vistos. O artigo também afirma que os Harnesses evoluídos transferem para duas tarefas incorporadas do mundo real.
É o teste mais duro do argumento, porque é justamente onde a simulação simplificada poderia quebrar.
Há ainda duas contribuições que os autores destacam além dos números. A primeira é a conexão entre requisitos de capacidade no nível da tarefa e configurações reutilizáveis de módulos, examinada com associações empíricas e intervenções controladas para identificar quais tipos de suporte de módulo importam em cada tarefa.
A segunda é a alegação de eficiência: mirar lógica de decisão compartilhada produziria melhora efetiva de Harness a baixo custo de evolução.
Limitações e o que não foi provado
O material disponível não traz uma seção formal de limitações, e algumas questões ficam em aberto. A árvore de capacidades é construída exclusivamente com tarefas de treino.
Os requisitos das tarefas não vistas são identificados depois, com as categorias já fixadas, apenas para avaliação retroativa do roteador.
Isso é metodologicamente correto, mas significa que a granularidade e a cobertura das categorias são decididas antes de qualquer contato com o que não foi visto. É um viés difícil de quantificar.
O resultado final também depende de verificadores executados pelo host e de um conjunto de benchmarks normalizados por uma interface comum de observação-ação. Os autores afirmam checagem independente contra as fontes, mas o grau de sensibilidade dos ganhos a essa camada de verificação não é detalhado no extrato.
O backbone permanece congelado: o que evolui é o Harness, não o modelo. O artigo não isola quanto do ganho de 26 pontos em tarefas não vistas vem de generalização real de capacidade e quanto vem de adaptação do roteador.
34 e 26 pontos são médias agregadas. Sem a distribuição por benchmark, é difícil saber se o ganho é amplo ou concentrado em poucos domínios.
Os cinco domínios de requisito têm naturezas muito distintas, de descoberta de regras a interação multiagente.
Por que isso importa para quem constrói com IA
Para quem trabalha com agentes em produção, a mensagem prática é que a camada de coordenação virou objeto de engenharia sistemática, não de ajuste artesanal. A estrutura de seis protocolos, Percepção, Memória, Inferência, Planejamento, Orquestração e Loop, é uma taxonomia útil mesmo fora do framework.
Separa responsabilidades que costumam se misturar em prompts monolíticos.
A segunda lição é sobre organização de avaliação. Agrupar tarefas por requisito compartilhado, em vez de por modalidade ou domínio de aplicação, é uma decisão de design que afeta diretamente o que o sistema aprende a generalizar.
Times que mantêm suítes de avaliação heterogêneas podem se beneficiar dessa releitura: em vez de perguntar "meu agente vai bem em imagem, texto e áudio", perguntar quais mecanismos decisórios cada tarefa realmente exige.
A terceira é o custo. A proposta de mundos simulados simplificados e verificáveis, com faixa de dificuldade controlada, ataca o gargalo mais caro de qualquer pipeline de agentes: gerar ambiente de treino suficiente.
Se a transferência para as duas tarefas incorporadas reais se sustentar em replicações independentes, é um caminho concreto para reduzir dependência de coleta manual de trajetórias.
Referências
TANG, Weidong; WANG, Ruiheng; ZHANG, Jingxuan; et al. The Trinity: Capability-Driven Recursive Self-Improvement for Multimodal Agents. arXiv:2610.36077 [cs.AI], 2026.
Disponível em: https://arxiv.org/abs/2610.36077. Página do projeto: https://trinity-rsi.github.io/.
