Automatizando tarefas de sysadmin com agentes, skills e assistentes de IA

Tabela de Conteúdo

“Assistente”, “agente” e “skill” viram sinônimo em conversa de corredor, mas são três coisas técnicas diferentes. Confundir isso na hora de desenhar uma automação de infra é o motivo mais comum de dar errado: ou porque a automação nunca sai do “sugere e espera” quando o objetivo era autonomia, ou porque vira autonomia demais numa tarefa que devia ter aprovação humana no meio.

Assistente: espera comando, não decide sozinho

Assistente é reativo. Você pergunta, ele responde ou sugere; a ação de executar continua sendo sua. Perguntar “que comando lista pods em crashloop no namespace X” pra um chat de IA (Claude, ChatGPT, Copilot, tanto faz) é isso: ele te dá o kubectl, você roda.

Não tem estado entre uma pergunta e outra, não tem objetivo próprio, não decide o que fazer depois. O “depois” é sempre você que traz de novo.

Agente: recebe objetivo, decide as ferramentas, age sozinho

Agente é um loop: recebe um objetivo, escolhe qual ferramenta chamar, executa, olha o resultado, decide o próximo passo, repete até resolver (ou desistir). A diferença que importa pra automação não é “IA mais esperta”, é quem decide a próxima ação: no assistente é você, no agente é o loop.

Esse padrão de loop de raciocínio + chamada de ferramenta + observação do resultado é o mesmo em qualquer stack: Claude Agent SDK, Assistants API da OpenAI com function calling, Google ADK, ou um loop caseiro em cima de qualquer LLM com suporte a tool use. Muda a API, não muda o conceito.

Exemplo prático: um agente que monitora uma fila de alertas, abre um diagnóstico, roda os comandos que decidir que fazem sentido (kubectl describe, journalctl, checar métricas) e só then decide se reinicia o serviço ou escala pra alguém.

Skill: não age, é o manual que o agente carrega

Skill não executa nada sozinha. É um pacote de instrução (texto, exemplos, scripts, formato de saída esperado) que o agente carrega quando a tarefa bate com aquele contexto. Sem skill, o agente reinventa o processo de diagnóstico a cada chamada, com resultado inconsistente. Com skill, ele segue um runbook fixo.

A Anthropic formalizou isso em outubro/2025 como “Agent Skills”: pasta com SKILL.md + scripts opcionais, carregada sob demanda (progressive disclosure: só o nome fica visível até o agente decidir que a skill é relevante). Virou padrão aberto adotado também por OpenAI, Google, GitHub e Cursor. Mas o conceito em si não é exclusividade de ninguém, é o mesmo que já existia como “function spec”, “plugin” ou “tool definition” em outras stacks, só que reusável e versionável como qualquer arquivo do repositório.

Um SKILL.md mínimo genérico, ferramenta-agnóstico:

---
name: diagnostico-crashloop
description: Runbook pra diagnosticar pod em CrashLoopBackOff antes de qualquer ação corretiva
---

1. `kubectl describe pod <pod> -n <namespace>` — checar eventos e último exit code
2. `kubectl logs <pod> -n <namespace> --previous` — ler log da execução anterior ao crash
3. Se exit code 137: suspeita de OOM, checar `requests`/`limits`
4. Se exit code != 137 e != 0: erro de aplicação, não é infra — escalar pro time dono
5. Nunca reiniciar (`kubectl rollout restart`) antes de completar os passos 1-4

Onde cada um encaixa numa pipeline de automação, e onde não encaixa

O trade-off real é autonomia contra controle, não “qual é mais avançado”. Assistente tem risco de ação indesejada zero, porque não age. Agente tem blast radius real: se ele decidir errado, quem executa o comando é ele, não você revisando antes.

Isso não é motivo pra evitar agente em infra, é motivo pra não dar autonomia total de cara. Alguns limites que fazem diferença na prática:

  • Allowlist de comandos: o agente só pode chamar as ferramentas explicitamente liberadas pra aquele runbook, nada de shell genérico com acesso total.
  • Dry-run antes de ação destrutiva: reiniciar, escalar, deletar, sempre com uma etapa de simulação ou confirmação antes da execução real, principalmente em produção.
  • Escopo por namespace/ambiente: credencial do agente vale só pro que ele precisa tocar, nunca cluster inteiro.
  • Log de auditoria da decisão, não só da ação: guardar por que o agente escolheu aquele comando ajuda a debugar quando ele erra. E ele vai errar.

Quando a skill fica desatualizada e o agente continua “certo”

O gotcha que mais pega gente que já usa isso há um tempo: o agente segue o runbook certinho, mas o runbook (a skill) ficou desatualizado — por exemplo, um passo que checava /var/log/auth.log num host que migrou pra journald faz meses. O agente não erra a lógica, erra porque a fonte de verdade que ele carregou tá errada. Sintoma comum: agente reporta “nenhuma tentativa de login encontrada” quando na verdade tá lendo o arquivo errado — mesmo tipo de problema de backend que dá pra ver testando regex de log manualmente antes de confiar numa automação em cima dele.

Tratamento é o mesmo de qualquer runbook: skill é código, revisa em PR, testa contra ambiente real de vez em quando, não trata como documentação estática que escreve uma vez e esquece.

Simples assim :)