- O primeiro benchmark para avaliar quantitativamente a eficácia de skills de agentes (Agent Skills) baseados em grandes modelos de linguagem (LLMs), incluindo 84 tarefas em 11 domínios
- Cada tarefa é avaliada em três condições: sem skills, com skills curadas e com skills autogeradas, com um total de 7.308 trajetórias de execução coletadas
- As skills curadas mostraram uma melhora média de +16,2 p.p. no desempenho, mas com grande variação entre domínios, e algumas tarefas (16 de 84) tiveram queda de desempenho
- Skills autogeradas (Self-generated Skills) não foram eficazes em média, mostrando que o modelo não consegue gerar conhecimento procedural de forma estável por conta própria
- Módulos de skill pequenos e focados (2–3 componentes) são mais eficientes do que skills abrangentes em formato de documentação, e modelos menores usando skills alcançam desempenho semelhante ao de modelos grandes sem skills
Visão geral do SKILLSBENCH
- O SKILLSBENCH é um benchmark para avaliar o efeito do reforço por skills em agentes LLM, construído com base no framework Harbor
- Cada tarefa inclui ambiente em contêiner, verificador determinístico e resposta de referência (oracle)
- A mesma tarefa é executada repetidamente com e sem aplicação de skills para medir o efeito puro das skills
- Diferentemente dos benchmarks existentes, que avaliam apenas a capacidade básica do modelo, o SKILLSBENCH mede diretamente o impacto das skills no desempenho
Definição e composição de skills (Agent Skills)
- Uma skill é um pacote estruturado que contém conhecimento procedural (procedural knowledge) e expande o comportamento do agente no momento da inferência, sem modificar o modelo
- Componentes:
SKILL.md (procedimento de abordagem da tarefa), scripts executáveis, templates de código, exemplos etc.
- A skill deve atender aos quatro critérios a seguir
- Incluir conteúdo procedural
- Ser aplicável a uma classe de tarefas, e não a um único caso
- Incluir componentes estruturados
- Garantir portabilidade com base em sistema de arquivos
- Prompt de sistema, exemplos few-shot, recuperação RAG e documentação de ferramentas não são considerados skills
Composição das tarefas (Task) e construção do dataset
- Cada tarefa é composta por quatro elementos: instrução, ambiente, resposta e verificador
- O ambiente é isolado em contêiner Docker para garantir reprodutibilidade
- O verificador usa scripts de teste determinísticos para decidir automaticamente aprovação ou falha
- 105 colaboradores enviaram 322 tarefas candidatas, e 84 tarefas finais foram selecionadas após validação automática e revisão humana
- Os colaboradores precisavam atender aos seguintes requisitos
- Instruções escritas por humanos (proibida geração por LLM)
- A skill deve fornecer diretrizes procedurais, e não a resposta de uma tarefa específica
- Toda verificação deve ser feita de forma determinística (baseada em assertions)
- É preciso passar por validação estrutural automática, execução oracle, detecção de geração por IA e auditoria de vazamento
- Para evitar vazamento, skills que incluíssem nomes de arquivos específicos da tarefa, constantes ou referências a testes eram rejeitadas
Composição do benchmark e classificação de dificuldade
- O SKILLSBENCH é composto por 84 tarefas em 11 domínios (software, saúde, finanças, robótica etc.)
- A dificuldade é dividida em três níveis com base no tempo de execução humana
- Core (menos de 60 minutos): 17
- Extended (1–4 horas): 43
- Extreme (mais de 4 horas): 26
Configuração experimental
- Avaliação de três harnesses comerciais de agentes: Claude Code, Gemini CLI, Codex CLI
- Sete modelos utilizados: GPT-5.2, Claude Opus 4.5/4.6, Claude Sonnet 4.5, Claude Haiku 4.5, Gemini 3 Pro, Gemini 3 Flash
- Avaliação em três condições
- No Skills: sem aplicação de skills
- With Skills: com skills curadas
- Self-Generated Skills: o modelo gera e aplica suas próprias skills
- Foram coletadas 7.308 trajetórias válidas de execução (trajectories)
Métricas de avaliação
- A taxa de aprovação (pass rate) é usada como métrica principal
- O ganho normalizado (normalized gain) também é calculado para analisar juntos o ganho absoluto e o ganho proporcional
- Cada tarefa é repetida 5 vezes, e a pontuação média é então calculada
Principais resultados
- Skills curadas apresentaram uma melhora média de +16,2 p.p., com faixa de +13,6 a +23,3 p.p. conforme a configuração
- Há grande variação entre domínios: saúde teve a maior melhora (+51,9 p.p.), enquanto engenharia de software teve a menor (+4,5 p.p.)
- Em 16 das 84 tarefas, o desempenho caiu em vez de melhorar
- Skills autogeradas não tiveram efeito em média, ou tiveram impacto negativo
- Os modelos não conseguem gerar conhecimento procedural de forma estável por conta própria
- Skills focadas (2–3 módulos) mostraram maior eficiência do que skills abrangentes em formato documental
- A combinação de modelo menor + skills alcançou desempenho semelhante ao de um modelo maior sem skills
Conclusão
- O SKILLSBENCH oferece um sistema de avaliação centrado em skills e comprova quantitativamente o impacto das skills na capacidade real de execução de tarefas por agentes LLM
- Os resultados mostram que a qualidade do design das skills e a adequação ao domínio são decisivas para melhorar o desempenho
- Pode servir como base para pesquisas futuras que busquem esclarecer os princípios de design estrutural das skills e os limites da geração automática
1 comentários
Comentários do Hacker News
O conceito de “Self-Generated Skills” é interessante, mas vale apontar que ele é diferente do que as pessoas imaginam como “o processo de um LLM aprender habilidades por conta própria”
No estudo, trata-se apenas de instruir o modelo por prompt a gerar conhecimento procedimental relevante antes de resolver o problema, então isso está longe de uma verdadeira “habilidade aprendida pela experiência”
Espero que a imprensa faça essa distinção com clareza
Mesmo que o LLM gere habilidades por conta própria, a estrutura não permite exploração nem aprendizado, então no fim ele só repete o próprio contexto
Generalizar esses resultados é bastante enganoso
Se o conhecimento já está dentro do modelo, não há motivo para escrevê-lo como documento; isso só faz sentido quando se trata de informação realmente difícil de explicitar
Criar a skill antes da tentativa é uma abordagem distante da realidade
Foi eficaz deixar o agente fazer perguntas e passar pelo processo de resolução do problema, para depois condensar o resultado em uma skill compacta baseada em evidências
① capturar a falha → ② diagnosticar a causa → ③ escolher a ferramenta de melhoria → ④ registrar como artefato versionado → ⑤ promover a gate quando necessário
Incluímos esse loop como instrução padrão para todos os agentes
Eu uso separadamente um skill-creator para Claude
Para evitar que Claude reescreva como skill algo que ele já sabe, o documento deve incluir obrigatoriamente apenas
① informações fora dos dados de treino, ② contexto válido só para a sessão atual, ③ informações que alinhem o comportamento do Claude do futuro
O conteúdo completo está neste link do GitHub
Os dados de treinamento da internet têm qualidade muito irregular, então é difícil esperar que o modelo faça escolhas em nível de especialista
Pode ser um bom critério: um bom texto com insights não triviais equivale a uma boa skill
O ponto mais interessante do estudo é que skills autogeradas pioram o desempenho (-1.3pp), enquanto skills curadas melhoram bastante (+16.2pp)
Isso bate com a hipótese de que LLMs são excelentes consumidores de conhecimento procedimental, mas fracos como produtores
O efeito é muito maior em healthcare do que em software, possivelmente porque já existe abundância de dados de SWE
Por exemplo, Adobe React Spectrum UI fica péssimo sem skill, mas muda completamente com uma skill bem feita
Pedir simplesmente ao modelo “crie uma skill” não tem muito sentido
Se ele não expande seu conhecimento com novas informações ou materiais externos, isso no fim é apenas um ciclo de realimentar a própria saída
Eu uso um skill-creator que faz pesquisa automaticamente durante a criação da skill e refina o resultado com base em informações atualizadas e no workflow
Nessa condição, criar skills não tem sentido
Quanto mais se automatiza o LLM em várias camadas, mais a qualidade tende a cair em cada etapa
Se a pessoa define a ideia e o plano de implementação e o LLM só codifica, tudo bem; mas quando ele também assume o planejamento, ocorre uma queda brusca de qualidade
Ao repetir resumos e reproduções, o significado acaba colapsando
Em certos intervalos, é preciso ter entrada humana fresca
Em codebases grandes, eu primeiro faço o LLM escrever um relatório de exploração e, numa nova sessão, trabalho usando esse relatório como referência
Gasta mais tokens, mas evita perder detalhes importantes
No fim, o ponto central é se você consegue fornecer conhecimento de mundo suficiente ao modelo
Linguagem natural é inerentemente instável, então quanto mais ela é retransmitida, maior a distorção
O próprio fato de conseguirmos nos comunicar tão bem já é surpreendente
Em uma estrutura open loop, a precisão cai, mas se cada etapa puder se ajustar por conta própria, tudo fica muito mais estável
Estou construindo um data warehouse agentic-ready (GitHub.com/mathisdrn/orca)
No começo eu queria otimizar skills por benchmark, mas abordagens como DsPy e GEPA, que usam a própria linguagem do modelo como avaliador e construtor, parecem mais eficientes
Tenho curiosidade se o skill-creator da Anthropic ou da OpenAI também tem essa estrutura de auto-otimização
Não acho que este estudo seja surpreendente nem tenha grande relevância prática
Na prática, quase nunca o modelo gera skills apenas com seu próprio conhecimento latente
Como o estudo testou justamente essa condição restrita, o resultado era previsível
O mais interessante seria ver o modelo entrevistar humanos ou gerar skills após pesquisa profunda
Na verdade, o mais surpreendente é que esse paper tenha saído
Além disso, esse tipo de estudo ajuda a conter “gestores que mandam o modelo escrever documentos de best practices sem nenhum contexto”
Este estudo não considera esse contexto
Ultimamente parece que gente demais, muito inteligente, está desperdiçando energia nesses debates sobre IA
Antes, simplesmente faziam software útil; agora ficam obcecados com o novo tema de IA que surge toda semana
Isso tem um efeito de nerd-sniping ainda mais forte do que Web3 ou frameworks JS
Este artigo, na prática, só confirmou um resultado bastante previsível
Mas é bem possível que logo surja um novo modelo e torne essas discussões irrelevantes
Muitas equipes recebem ordem para migrar para uma “estratégia de skills”, mas nesse meio-tempo um modelo novo já faz melhor
No fim, todos estão tentando se orientar dentro de uma estrutura de sobrevivência instável
Eu também vejo com frequência a queda de qualidade de documentação autogerada
Quando o LLM extrai “best practices” do código, muitas vezes ele documenta padrões errados como se estivessem corretos
Por exemplo, já vi casos de uso inadequado de
ConfigureAwait(false)eTask.Runem código C#Para resolver isso, estamos construindo um sistema de conhecimento curado
Acredito que agentic coding baseado em Markdown será a próxima camada de abstração
Ainda não está claro como essa característica afeta o comportamento do sistema como um todo
O título enviado era “Self-generated agent skills are useless”, mas isso viola as diretrizes do HN
O correto é manter o título original e expressar a opinião nos comentários
Acho que um título claro pode gerar mais insight para a comunidade
A intenção não era caçar clique, e sim destacar a descoberta central