AI Engineering · 75 min

Instrumente e Faça o Deploy de um Agente

Adicione logging JSON estruturado a um agente minimalista, containerize com um Dockerfile não-root e healthcheck, rode via Docker Compose vinculado ao localhost, e prove que ele sobrevive a um crash reiniciando sozinho.

Premium

Problema

Fazer um agente responder corretamente num notebook é os 80% fáceis. Os 20% restantes — a parte que determina se ele sobrevive ao contato com tráfego real — é operacional: você consegue dizer o que ele fez e quanto tempo levou depois do fato, ele roda como um container que você consegue entregar a um time de operações sem uma revisão de segurança apontar "roda como root", e ele volta sozinho se o processo morrer às 3 da manhã? Neste lab você vai pegar um agente pequeno e autocontido (um serviço HTTP minimalista simulando uma chamada de modelo e uma tool call — sem exigir nenhuma chave de API externa) e levá-lo de "roda na minha máquina" a "roda como um container monitorado com política de restart". Concretamente: adicione logging JSON estruturado de cada chamada de modelo e tool call (latência, uma contagem de tokens estimada, sucesso ou falha), escreva um `Dockerfile` que roda como um usuário não-root com `HEALTHCHECK`, escreva um `docker-compose.yml` mínimo vinculando o serviço só a `127.0.0.1`, suba e confirme que o healthcheck de fato reporta `healthy` (não só "o container está rodando"), e por fim mate o processo dentro do container de propósito e confirme que o Docker o reinicia sem você fazer nada. Nenhum desses passos é exótico — este é o mesmo checklist que um engenheiro com mentalidade de produção percorre para qualquer serviço, agente ou não. O ponto deste lab é garantir que você já fez isso uma vez, de ponta a ponta, em vez de só ter lido sobre cada peça isoladamente.

Objetivos

Ao final deste lab você será capaz de:

Pré-requisitos

Para completar este lab você vai precisar de:

O que "instrumentado e deployado" realmente significa aqui

agent.py (logs estruturados)
    │
    ▼
Dockerfile (usuário não-root, HEALTHCHECK)
    │
    ▼
docker-compose.yml (bind 127.0.0.1, política de restart)
    │
    ▼
docker inspect → "healthy"
    │
    ▼
mata o processo → container reinicia sozinho

Cada camada nessa pilha é uma afirmação real e separadamente
verificável. "Está instrumentado" significa que você consegue apontar
para uma linha de log JSON e ler latência e status nela. "Está
saudável" significa que o docker inspect diz isso, não que você deu
uma olhada no docker ps e não estava vermelho. "Ele se recupera"
significa que você mesmo o matou e viu ele voltar, não que a linha
restart: está presente no YAML.

Por que uma chamada de modelo falsa, não uma API real

O agente deste lab simula a "chamada de modelo" e a "tool call" com
lógica local determinística em vez de chamar um provedor de LLM real.
Isso é deliberado: a habilidade ensinada aqui é instrumentação e
deploy, não engenharia de prompt, e manter o agente livre de chaves de
API externas significa que todo checkpoint deste lab funciona da mesma
forma para todo mundo, sem nada para falhar por causa de uma
credencial faltando ou uma indisponibilidade de provedor.

Como trabalhar neste lab

Acerte o logging localmente primeiro (Passo 1) antes de containerizar
qualquer coisa — debugar Python dentro de um container que você também
está debugando pela primeira vez é estritamente mais difícil que
debugá-lo isoladamente. Os Passos 2–5 então o movem para o Docker uma
preocupação de cada vez.

Passos

Conteúdo exclusivo para assinantes. Ver planos