EvoSkills Provou que Habilidades Autodidatas Funcionam. E Agora?

Existe uma sensação particular quando duas equipes de pesquisa separadas, trabalhando de forma independente, chegam à mesma conclusão desconfortável.

Eu sou Lena. Eu parei quando li both EvoSkills e EvoSkill consecutivamente. Não porque os resultados fossem exatamente surpreendentes — mas porque nenhum dos artigos se esquivou de dizer o que os dados realmente mostravam: as habilidades que humanos escrevem para agentes de IA têm um teto, e os agentes podem evoluir além dele por conta própria.

Isso não é uma afirmação pequena. E a pergunta seguinte — então o que fazemos com isso? — é uma que não consigo parar de pensar.

O Que EvoSkills e EvoSkill Realmente Mostraram

Dois artigos de pesquisa independentes, mesma conclusão: habilidades criadas manualmente têm um teto, agentes podem evoluir além dele de forma autônoma.

O Problema do Desalinhamento Cognitivo Humano-Máquina

Aqui está a parte que me surpreendeu.

EvoSkills não mostrou apenas que habilidades evoluídas têm desempenho melhor. Ela quantificou por que habilidades criadas por humanos apresentam desempenho inferior — e a resposta é mais estrutural do que a maioria das pessoas supõe. Designers humanos tendem a escrever fluxos de trabalho que correspondem à forma como nós pensamos sobre um problema: passos lineares, abstrações limpas, árvores de decisão organizadas. Mas o raciocínio de LLM não funciona assim.

No SkillsBench, o benchmark construído especificamente para testar isso, a diferença não era marginal. Habilidades curadas por humanos mostraram um desalinhamento cognitivo mensurável com a forma como modelos de linguagem grandes realmente navegam em tarefas de múltiplas etapas. As habilidades não estavam erradas — elas simplesmente não estavam moldadas para o motor de raciocínio que as executa.

Eu continuei voltando a isso. Não é que humanos sejam ruins em escrever instruções. É que otimizamos para legibilidade humana, não para os padrões de execução de LLM. Esses são alvos diferentes.

O Que a Auto-Evolução Realmente Produziu

Os números merecem ser analisados por um momento:

Começando de 32%, o agente atingiu 75% de taxa de aprovação em cinco rodadas de evolução. Na terceira rodada, já havia ultrapassado o teto curado por humanos. Essa é a parte que acho realmente difícil de racionalizar: o agente não estava apenas fechando uma lacuna — estava abrindo uma para o outro lado.

O EvoSkill, operando em um domínio de tarefa diferente (QA de documentos de escritório e pesquisa baseada na web), apresentou o mesmo resultado direcional. Ganhos absolutos menores, mas consistentes. +7,3% no OfficeQA, +12,1% no SealQA. Ambos superaram as linhas de base criadas por humanos.

Transferência entre modelos e tarefas cruzadas

Esse é o detalhe que quase ignorei, e não deveria ter ignorado.

As habilidades que evoluíram para um LLM passaram entre +35pp e +44pp entre seis modelos diferentes. Isso não é uma pequena vantagem de portabilidade — é a habilidade codificando algo sobre a estrutura de tarefas, não apenas as peculiaridades específicas do modelo.

Ainda mais interessante: as habilidades do SealQA transferiram zero-shot para o BrowseComp com um ganho de +5,3%. A habilidade nunca foi projetada para o BrowseComp. Simplesmente funcionou lá. Isso sugere que o que está sendo desenvolvido é algo mais próximo de uma estratégia de execução generalizável do que de um ajuste estreito no prompt.

Ainda não tenho certeza do que pensar disso. Mas já notei.

O limite que ambos os jornais atingiram

Foi aqui que eu desacelerei bastante.

Ambos os artigos demonstraram ganhos reais e reproduzíveis. E ambos os artigos, lidos com atenção, batem na mesma parede em aproximadamente o mesmo ponto. A parede não é exatamente técnica — é arquitetônica.

Escopo de Agente Único

Cada habilidade evoluída em ambos os estudos vive dentro do contexto de execução de um agente. Na prática: uma pasta no sistema de arquivos local do agente, um artefato versionado com escopo para a sessão desse agente.

Quando o agente é substituído, atualizado ou redesdobrado, a evolução não é mantida, a menos que alguém a migre explicitamente. Não existe um mecanismo de herança incorporado na configuração de pesquisa. A evolução é real. A persistência é frágil.

Sem Propagação em Rede

Cada novo agente, em ambos os artigos, inicia seu próprio ciclo de evolução do zero.

Pense no que isso significa em qualquer escala de implantação razoável. Dez agentes executando ciclos ao estilo EvoSkill produzem dez históricos de evolução separados. Esses históricos não se fundem. Eles não resolvem conflitos. O ganho acumulativo que torna os resultados dentro do agente tão impressionantes — aquela trajetória de 32% → 75% — é zerado para cada novo agente que entra em execução.

A melhoria é local. O ponto de partida é sempre o mesmo.

O Que os Artigos Deixaram Explícito como Aberto

EvoSkill sinaliza isso diretamente como trabalho futuro, não como um descuido: bibliotecas de habilidades compartilhadas onde habilidades descobertas em uma tarefa podem ser navegáveis, componíveis e reutilizáveis por outros agentes e usuários.

Essa frase é importante. Os pesquisadores não ignoraram esse problema — eles o nomearam. É uma questão de pesquisa em aberto, não um detalhe de implementação esperando para ser lançado. O problema da geração (os agentes podem evoluir habilidades melhores?) já tem uma forte resposta empírica. O problema da propagação (como habilidades evoluídas e validadas se movem entre agentes em escala?) não tem.

O Que os Artigos Deixam em Aberto na Camada de Sistemas

Quero ser cuidadoso aqui, porque esta seção é fácil de ser interpretada como um pitch de produto. Não é. É uma questão de engenharia, e eu acho que vale a pena levar a sério em seus próprios termos.

A Lacuna Entre Evolução Local e Herança Compartilhada

Habilidades autoevolutivas resolvem um problema de forma limpa: para um único agente executando tarefas repetidas, a evolução automatizada produz artefatos de execução melhores do que a autoria humana. Isso agora está bem comprovado.

O que elas não resolvem: o problema da propagação. Como uma habilidade validada e evoluída se move entre agentes? Como uma rede avalia se uma determinada habilidade é confiável antes de permitir que ela se espalhe? Como sinais de aptidão — evidências de que uma habilidade realmente funciona em tarefas e modelos diversos — se acumulam em uma escala maior que o histórico de uma sessão de agente?

Estas não são perguntas retóricas. Elas representam a lacuna entre um resultado de pesquisa e um primitivo de infraestrutura implantável.

O Que um Protocolo em Nível de Rede Precisaria Lidar

Se você estivesse projetando infraestrutura para fechar essa lacuna — e quero dizer realmente projetando, não promovendo — você precisaria, no mínimo:

• Uma camada de validação: habilidades evoluídas são avaliadas quanto à qualidade antes da propagação, não depois
• Um modelo de ciclo de vida: rastreamento de promoção, rejeição e revogação ao longo da história da habilidade
• Um mecanismo de busca: agentes recuperando capacidades comprovadas sem reconstruí-las do zero
• Uma abordagem de resolução de conflitos: quando duas habilidades evoluídas independentemente para a mesma tarefa divergem, como o sistema arbitra?

Nenhum desses problemas é resolvido pela arquitetura EvoSkills ou EvoSkill. Ambos os artigos são explícitos sobre isso. O Protocolo de Contexto do Modelo aborda a conectividade de ferramentas na camada de interface do agente, mas não define um ciclo de vida de evolução ou herança de habilidades. Esses são problemas genuinamente separados, em camadas diferentes do stack.

Para contexto sobre como o compartilhamento de capacidades de agentes está sendo abordado de forma mais ampla, vale a pena ler a especificação do protocolo Agent-to-Agent (A2A) do Google — ele define padrões de comunicação entre agentes, embora a semântica de propagação de habilidades permaneça fora do seu escopo.

Por que essa lacuna é importante para equipes de desenvolvimento

Uma equipe que implanta dez agentes executando ciclos de evolução no estilo EvoSkill terá dez repositórios de habilidades separados. Não existe um jeito definido na pesquisa atual de:

• Mesclar esses repositórios
• Identificar quais habilidades evoluídas são mais confiáveis
• Evitar que habilidades evoluídas de menor qualidade se espalhem para outros agentes
• Rastrear qual versão de uma habilidade ainda é válida à medida que o modelo subjacente ou o contexto da tarefa muda

Isso é um problema de infraestrutura não resolvido. Não é um problema pequeno.

O que isso significa para como você constrói fluxos de trabalho de agentes agora

Não acredito que a resposta certa para tudo isso seja paralisia. A pesquisa é clara o suficiente sobre algumas coisas para agir agora.

Pare de escrever habilidades manualmente para tarefas complexas

Este eu me sinto relativamente confiante.

Para tarefas profissionais de múltiplas etapas — análise de documentos, pesquisa na web, cadeias de raciocínio estruturadas — os resultados do EvoSkills e EvoSkill sugerem que evolução automatizada produz artefatos de execução melhores do que autoria humana. Não marginalmente melhores. Substancialmente melhores, em vários modelos e de formas que se transferem para novas tarefas.

A documentação do LangChain sobre memória de agentes e scaffolding de habilidades fornece uma base razoável para pensar sobre onde ciclos de evolução podem ser introduzidos em arquiteturas de agentes existentes. A versão resumida: se você ainda está ajustando manualmente instruções de habilidades para tarefas complexas e se perguntando por que o desempenho atinge um platô, esse platô pode ser estrutural, não solucionável por iteração.

Pense Sobre Onde as Habilidades Evoluídas Vivem

Uma habilidade evoluída localmente que permanece local é um ativo privado. Útil, mas limitado.

A comunidade de pesquisa está trabalhando ativamente no que vem a seguir: capacidade validada, compartilhável e herdável em escala de rede. O framework AutoGen da Microsoft Research é um dos projetos de código aberto mais maduros explorando padrões de coordenação multiagentes, e seu desenvolvimento contínuo vale a pena ser observado, especificamente sobre como ele lida com a transferência de capacidade evoluída entre agentes.

Por enquanto, a implicação prática é: projete seus ciclos de evolução com portabilidade em mente, mesmo que a infraestrutura de portabilidade ainda não exista completamente. Isso significa registrar as versões das habilidades evoluídas, acompanhar quais benchmarks de avaliação elas passaram e manter os artefatos de evolução separados do runtime do agente.

Perguntas Que Vale a Pena Fazer Antes de Construir

Antes de se comprometer com uma arquitetura de agente específica para um novo projeto, acho que vale a pena considerar:

• Onde as habilidades evoluídas viverão após a sessão terminar? Se a resposta for "no sistema de arquivos local do agente sem caminho de exportação", você está construindo um ativo privado sem caminho para valor acumulado.
• Quem as valida antes que outros agentes as usem? Benchmarks de validação automatizados são uma resposta; revisões humanas são outra. Nenhuma das duas é gratuita.
• Como você rastreia qual versão de uma habilidade ainda é confiável? À medida que o modelo subjacente atualiza, e o contexto da tarefa muda, uma habilidade que funcionava em fevereiro pode não funcionar em agosto. Rastrear versões e reavaliar não é opcional se você estiver construindo algo destinado a rodar por meses.

A pesquisa da OpenAI sobre uso de ferramentas e padrões de chamadas de funções é relevante aqui para entender como a invocação de habilidades é registrada e rastreada no nível de API — o que é um pré-requisito para qualquer rastreamento significativo da confiabilidade de habilidades.

FAQ

Qual é a diferença entre uma ferramenta e uma habilidade em sistemas de agentes?

Uma ferramenta é tipicamente uma capacidade discreta com uma interface de entrada/saída definida — uma chamada de função, um endpoint de API, um executor de código. Uma habilidade é um artefato de ordem mais elevada: um fluxo de trabalho estruturado, uma estratégia de raciocínio ou um padrão de execução em múltiplas etapas que orquestra o uso de ferramentas. Ferramentas são atômicas. Habilidades são composicionais. Os artigos EvoSkills e EvoSkill focam especificamente na camada de habilidades — a parte que determina como um agente aborda uma tarefa, não apenas quais capacidades ele pode invocar.

Como o EvoSkills difere do EvoSkill?

EvoSkills focou na evolução de habilidades independentes de tarefas, avaliada no SkillsBench, um benchmark multi-domínio cobrindo diversas tarefas profissionais. Mostrou uma melhoria na taxa de aprovação de 32% → 75% em cinco rodadas e demonstrou que habilidades evoluídas superam as curadas por humanos na terceira rodada. EvoSkill focou mais especificamente em tarefas de QA intensivas em conhecimento (OfficeQA, SealQA) e enfatizou a transferência zero-shot entre tarefas — a constatação de que habilidades evoluídas para SealQA foram transferidas para BrowseComp sem re-treinamento. Ambos os artigos demonstram que a evolução automatizada supera a autoria humana; eles diferem no escopo e nas propriedades específicas de transferência que caracterizam.

As habilidades evoluídas do EvoSkills ou EvoSkill podem ser usadas com qualquer agente?

Os resultados de transferência cruzada de modelos (+35pp a +44pp em seis LLMs) sugerem que habilidades evoluídas codificam informações estruturais de tarefas que se generalizam entre diferentes arquiteturas de modelo. Na prática, "qualquer agente" é uma afirmação muito forte — ambos os artigos operaram dentro de frameworks e benchmarks específicos. A afirmação mais precisa é: habilidades evoluídas sob um modelo foram transferidas de forma significativa para outros modelos em avaliações controladas. A portabilidade no mundo real entre diferentes runtimes de agentes continua sendo uma questão de implementação em aberto.

O que é o SkillsBench e quão confiáveis são seus resultados?

SkillsBench é um benchmark introduzido no artigo do EvoSkills, projetado para avaliar a qualidade de habilidades de agentes em tarefas profissionais de múltiplas etapas. Ele é estruturado para medir tanto a conclusão da tarefa quanto a qualidade do artefato de habilidade em si — não apenas se o agente obteve a resposta correta, mas se a habilidade que usou generalizaria. Como em qualquer benchmark de pesquisa, os resultados devem ser interpretados no contexto: o SkillsBench foi projetado pela mesma equipe que criou o EvoSkills, o que vale ser observado ao avaliar a independência da avaliação. A validação cruzada de benchmarks (a transferência SealQA → BrowseComp) fornece algum sinal externo, mas a área se beneficiaria de frameworks de avaliação mais diversos e construídos independentemente.

O que uma biblioteca compartilhada de habilidades realmente precisaria para funcionar em escala de rede?

No mínimo: um mecanismo de validação que teste habilidades evoluídas antes que sejam propagadas, um sistema de versionamento e ciclo de vida que acompanhe promoção e revogação, uma camada de indexação semântica para que agentes possam identificar habilidades relevantes sem uma busca exaustiva, e uma abordagem de resolução de conflitos para quando habilidades evoluídas de forma independente para a mesma tarefa divergirem. Os problemas mais difíceis são governança (quem decide quando uma habilidade está "boa o suficiente" para ser compartilhada?) e degradação de qualidade (como detectar quando uma habilidade anteriormente confiável se deteriora à medida que o contexto muda?). Nenhum dos artigos aborda essas questões — são explicitamente marcadas como trabalho futuro.

O que significa transferência de habilidade zero-shot no contexto do EvoSkill?

Transferência zero-shot significa que uma habilidade evoluída para uma tarefa foi aplicada a uma tarefa diferente sem qualquer treinamento adicional, ajuste fino ou adaptação. No caso do EvoSkill: habilidades evoluídas no SealQA foram aplicadas diretamente ao BrowseComp — uma tarefa de pesquisa baseada na web com estrutura e domínio diferentes — e produziram um ganho de +5,3% sem qualquer re-treinamento específico da tarefa. "Zero-shot" aqui refere-se ao artefato da habilidade, não ao modelo subjacente. O modelo não está sendo ajustado; o prompt/fluxo de trabalho da habilidade está sendo reutilizado como está. O fato de a reutilização ter produzido ganhos positivos sugere que a habilidade codificou algo sobre a estrutura da tarefa de pesquisa que se generalizou, em vez de algo estritamente específico ao formato do SealQA.

Postagens Anteriores:

• Recurso Claude Code Skills Explicado
• Claude Code Skills: Guia de Construção, Compartilhamento e Extensão
• Claude Skills: skill.md vs Capacidade do Agente
• Agent Hooks: Cadeias de Execução de IA
• Como Funcionam os Servidores MCP