Arbor — Otimização Autônoma por Refinamento de Árvore de Hipóteses

Visão Geral

Esta habilidade executa um loop de Otimização Autônoma (AO): começando com um artefato existente e um objetivo mensurável, melhore-o através de muitas rodadas de experimentação e avaliação — sem supervisão humana passo a passo, enquanto verifica o overfitting (sobreajuste) ao sinal de desenvolvimento. É a ferramenta certa quando o gargalo não é escrever uma boa mudança, mas sim organizar dezenas de tentativas para que as lições se acumulem em vez de evaporarem.

Implementa o Refinamento de Árvore de Hipóteses (HTR) do Arbor (Jin et al., 2026). A ideia principal: manter o estado da pesquisa em uma árvore de hipóteses persistente em vez de no histórico de conversas. Cada nó vincula uma hipótese, o insight destilado que ela produziu e um ponteiro para a versão do artefato que a realiza. Você atua como o coordenador de longa duração que possui essa árvore e decide onde pesquisar; subagentes executores de curta duração testam uma hipótese cada um em worktrees (árvores de trabalho) isoladas do Git e reportam de volta. Um portão de mesclagem retido admite uma mudança apenas quando ela melhora em um avaliador de teste contra o qual os executores não otimizam. Isso é o que transforma tentativa e erro em pesquisa cumulativa e auditável.

Use o gerenciador de estado scripts/tree.py para toda a contabilidade (criação de nós, escrita de evidências, propagação de insights, poda, portão de mesclagem, projeção Observe). Ele registra pontuações e decisões; ele não executa avaliadores, cria worktrees, verifica referências do Git ou mescla branches do Git. Apenas o coordenador escreve o estado compartilhado, serialmente; os executores retornam evidências. O auxiliar não possui bloqueio de múltiplos escritores. Seu esquema JSON é separado dos checkpoints do Arbor de upstream.

Quando usar esta habilidade

Recorra ao Arbor quando a tarefa for melhoria iterativa de um artefato concreto sob um avaliador:

• Treinamento de modelos: mudanças de otimizador/arquitetura/receita para diminuir a perda ou atingir uma meta em menos etapas.
• Engenharia de harness/agente: aumentar a taxa de aprovação ou a precisão de um loop de agente, harness de busca ou scaffold de uso de ferramentas.
• Síntese de dados: melhorar um pipeline de geração/filtragem julgado pelo comportamento do modelo downstream.
• Otimização de benchmark: tarefas no estilo MLE-bench / Kaggle de "melhorar a submissão".
• Otimização de prompt/sistema onde você pode pontuar saídas automaticamente.

Os sinais distintivos: há um artefato que você pode modificar, um objetivo, uma maneira de pontuar candidatos e você espera executar muitos experimentos. Se o usuário quiser apenas uma única correção ou uma resposta de um tiro, isso é exagero — faça o trabalho diretamente. Se eles quiserem ideação aberta sem um avaliador, use hypothesis-generation ou scientific-brainstorming em vez disso.

A configuração AO — defina isso primeiro

Antes de qualquer experimento, estabeleça a tupla da tarefa (M_0, O, E_dev, E_test). Registre a configuração resolvida, usando as instruções existentes do usuário; esclareça apenas as decisões ausentes:

• M_0 — material inicial: o artefato a ser melhorado (um repositório, um script, uma configuração, um prompt). Certifique-se de que esteja sob controle do Git e que funcione atualmente.
• O — objetivo: o objetivo em linguagem natural e a direção da métrica (maximizar precisão? minimizar perda/etapas?).
• E_dev — avaliador de desenvolvimento: um comando que você pode executar livremente durante a busca para pontuar um candidato. Rápido, repetível.
• E_test — avaliador de teste retido: um protocolo de avaliação separado (exemplos retidos ou sementes independentes pré-declaradas) usado apenas no portão de mesclagem. Ele não deve ser usado como um oráculo de busca — esse é o ponto principal.

Congele o avaliador, a divisão do conjunto de dados e a métrica antes da busca, e registre suas versões com cada pontuação. Decisões repetidas de mesclagem no mesmo conjunto retido ainda podem adaptar a busca a esse conjunto; uma worktree nova evita contaminação de arquivos, não vazamento estatístico. Mantenha um conjunto de avaliação final intocado para a afirmação final, ou divulgue que o resultado relatado foi selecionado usando feedback repetido do portão.

Se o usuário não lhe deu uma divisão limpa de desenvolvimento/teste, construa uma e diga isso. A separação desenvolvimento/teste é o mecanismo que detecta o overfitting: um candidato que vence no desenvolvimento, mas não no teste, não é um sucesso, é um aviso de que você está explorando o sinal de feedback. Uma execução maior nos mesmos exemplos não é um holdout independente. Se não houver um holdout defensável, rotule os resultados como apenas para desenvolvimento.

…