Skills: empacotando capacidades reaproveitáveis
Como skills empacotam instruções + ferramentas + conhecimento numa capacidade que o agente invoca.
5 min de leitura
Escolha como aprender
combine como quiserDica: o vídeo é um resumo visual rápido; o áudio e o texto trazem a aula completa. Terminar o áudio ou o vídeo, ou passar no quiz, já conta a aula como concluída.
Você já viu como ferramentas dão ações ao agente e como o MCP padroniza o acesso a essas ferramentas. Mas quando um agente precisa executar uma capacidade completa, como 'analisar um contrato' ou 'responder dúvidas de suporte', carregar tudo no prompt principal vira um caos. É aí que entra a skill: um pacote coeso de instruções, ferramentas e conhecimento que o agente carrega só quando precisa.
O que é uma skill, de verdade
Pense numa skill como um módulo de software, mas para comportamento de agente. Ela empacota três coisas juntas:
- Instruções / procedimento: o que fazer, em que ordem, como raciocinar sobre o problema.
- Ferramentas: quais tools (ou servidores MCP) essa capacidade precisa para agir no mundo.
- Conhecimento: contexto específico do domínio, documentos, exemplos, regras de negócio, que só faz sentido nessa capacidade.
Quando o agente decide que precisa da skill analise-contrato, ele a carrega: as instruções entram no contexto, as ferramentas ficam disponíveis, o conhecimento relevante é injetado. Quando termina, tudo isso sai. O prompt principal não carrega o peso de capacidades que não são necessárias naquele momento.
Isso tem um paralelo direto com código: você não importa todas as bibliotecas do projeto em cada função. Você importa o que a função precisa. Skills aplicam o mesmo princípio ao comportamento do agente, separação de responsabilidades, mas para raciocínio e ação.
Anatomia de uma skill
Uma skill é invocada pelo orquestrador do agente e compõe instruções, ferramentas e conhecimento num único pacote coeso.
- Orquestrador · loop ReAct
- Instruções · procedimento + raciocínio
- Ferramentas · extract-clauses, flag-risk
- Conhecimento · regras jurídicas, exemplos
- Servidor MCP · contract-tools
- Vector Store · embeddings jurídicos
Skills vs Tools vs MCP: onde cada um vive
Essa distinção confunde muita gente, então vou ser direto:
Tool é uma ação atômica: buscar-documento, enviar-email, executar-query. Ela faz uma coisa só e não sabe nada sobre o problema maior.
MCP é um protocolo de transporte e descoberta: padroniza como o agente encontra e chama tools, independente de onde elas estão hospedadas. É a camada de integração.
Skill é o nível acima dos dois. Ela orquestra: define o procedimento (primeiro extraia as cláusulas, depois classifique os riscos, depois gere o resumo), declara quais tools são necessárias (podendo usar MCP por baixo para acessá-las) e injeta o conhecimento de domínio relevante. Uma skill pode chamar várias tools. Uma tool não sabe que existe uma skill.
A analogia que uso: tool é uma função, MCP é o protocolo HTTP entre serviços, skill é o caso de uso, o serviço de domínio que orquestra chamadas e carrega o contexto certo para resolver um problema específico. Você pode ter uma skill sem MCP (tools locais), mas uma skill bem desenhada usa MCP para manter as tools desacopladas e reutilizáveis.
Tool vs MCP vs Skill, fronteiras claras
| Dimensão | Tool | MCP | Skill |
|---|---|---|---|
| Nível de abstração | Ação atômica | Protocolo / transporte | Capacidade de domínio |
| Contém instruções? | Não | Não | Sim |
| Contém conhecimento? | Não | Não | Sim |
| Quem chama? | Skill ou agente diretamente | Tool ou skill (transporte) | Orquestrador do agente |
| Reutilizável entre agentes? | Sim, mas granular | Sim (protocolo) | Sim, em nível de capacidade |
Na prática, crio uma skill quando percebo que um conjunto de instruções + tools começa a se repetir em mais de um agente ou fluxo. Se dois agentes diferentes precisam 'analisar sentimento de feedback de cliente', isso é uma skill, não duplico as instruções em cada prompt. O sinal mais claro para criar uma skill é quando você está copiando e colando instruções entre agentes. Outro sinal: quando um sub-problema tem um domínio de conhecimento próprio (jurídico, financeiro, técnico) que não deve vazar para o contexto geral do agente.
Skills no dia a dia e nas plataformas modernas
Exemplos concretos de skills que fazem sentido em sistemas reais:
suporte-tecnico: instruções de triagem, tools de busca na base de conhecimento e abertura de ticket, documentação de produtos injetada como contexto.analise-financeira: procedimento de leitura de balanço, tools de acesso a dados históricos via MCP, regras contábeis como conhecimento.geracao-codigo: instruções de boas práticas, tool de execução de código em sandbox, exemplos do padrão interno da empresa.
Nas plataformas modernas, o conceito aparece com nomes diferentes mas a mesma estrutura. O Amazon Bedrock AgentCore (que veremos na lição 17) trata skills como unidades de capacidade que o agente pode ativar dinamicamente. O Microsoft Copilot Studio chama de skills explicitamente. O Semantic Kernel da Microsoft tem o conceito de plugins que empacotam funções + descrições semânticas, é a mesma ideia. O AutoGen usa AssistantAgent com system prompts e tools específicos por agente, skills implícitas.
O padrão está convergindo: a indústria reconhece que agentes escaláveis precisam de capacidades modulares, não de prompts monolíticos. Quanto maior o agente, mais importante é essa separação. Um agente com 15 skills carregadas ao mesmo tempo é um agente com 15 problemas de contexto e foco.
O que fixar sobre skills
Dúvidas frequentes sobre skills
Uma skill pode chamar outra skill?
Sim, e isso é um padrão legítimo em agentes mais complexos, uma skill de 'análise completa de cliente' pode orquestrar skills menores de 'análise financeira' e 'análise de risco'. Mas cuidado com profundidade excessiva: dois níveis de composição já exigem atenção ao rastreamento e ao custo de contexto.
Skill é a mesma coisa que sub-agente?
Não exatamente. Um sub-agente tem seu próprio loop de raciocínio e pode tomar decisões independentes. Uma skill é mais determinística: segue um procedimento definido. Na prática, a fronteira é tênue, algumas plataformas implementam skills como sub-agentes leves. O que importa é a intenção: skill é capacidade empacotada, sub-agente é autonomia delegada.
Preciso de um framework específico para usar skills?
Não. Você pode implementar o conceito manualmente: um dicionário de skills com instruções, lista de tools e documentos de contexto, carregados dinamicamente no prompt conforme a intenção detectada. Frameworks como Semantic Kernel, LangGraph e Bedrock AgentCore só formalizam e automatizam esse padrão.
Checkpoint: Módulo 3
Fechando o Módulo 3
Chegamos ao fim do módulo de agentes. Você agora tem o mapa completo: o loop ReAct que dá autonomia ao agente, memória de curto e longo prazo para ele não esquecer, padrões de orquestração para problemas complexos, MCP para integrar ferramentas de forma padronizada, e skills para empacotar capacidades sem inflar o contexto. Esses não são conceitos isolados, eles se compõem. Um agente real usa todos ao mesmo tempo. No próximo módulo, vamos para a AWS: como o Amazon Bedrock e o Bedrock AgentCore transformam esses conceitos em infraestrutura gerenciada, pronta para produção. Antes de avançar, faça o checkpoint abaixo, ele cobre todo o Módulo 3.