Agentes autônomos que rodam por horas — e não fogem do controle
Um agente que responde uma pergunta com uma ferramenta é uma coisa. Um agente que recebe um objetivo, planeja dezenas de passos, executa código, navega, se corrige e entrega um resultado sem supervisão contínua é outra — e cada propriedade nova (duração, ação irreversível, custo acumulado) precisa de mecanismo próprio. Esta apostila é o corte profundo disso.
Esta apostila assume o conteúdo da Criação de Agentes de IA (loop ReAct, tool use, memória/RAG, guardrails básicos). Aqui o foco é o que só aparece quando o agente roda longo e sem alguém no teclado. Segurança de prompt injection e OWASP LLM está na Segurança de Aplicações de IA; avaliação geral de sistemas de IA na LLMOps & Avaliação; conformidade na Governança de IA & EU AI Act.
Autonomia como espectro
Objetivo: parar de tratar "agente" como sim/não e passar a posicionar cada sistema num espectro de autonomia — porque cada grau a mais cobra um mecanismo a mais.
1.1 Os quatro degraus
| Nível | O que é | Exemplo |
|---|---|---|
| 0 · Workflow | passos fixos, LLM em pontos específicos; o caminho é código | "extrair campos → validar → gravar → notificar" |
| 1 · Agente com ferramentas | LLM decide qual ferramenta chamar em um loop curto, com humano recebendo o resultado | assistente que consulta um CRM e responde |
| 2 · Agente de tarefa | recebe um objetivo, planeja e executa vários passos, entrega um resultado; humano revisa no fim | "pesquise X e escreva um relatório"; um coding agent que abre um PR |
| 3 · Agente autônomo de longo horizonte | persegue o objetivo por muito tempo, se replaneja, roda em segundo plano, aciona humano só em exceções | agente que monitora um sistema e conserta incidentes; pipeline de research que roda a noite toda |
1.2 O que cada degrau acrescenta de exigência
| Propriedade nova | Mecanismo que ela obriga | Módulo |
|---|---|---|
| Muitos passos / plano | planejamento explícito + replanejamento | 2 |
| Duração longa (o processo pode cair) | execução durável: checkpoint e retomada | 3 |
| Sem revisão passo a passo | auto-verificação e reflexão | 4 |
| Custo e tempo acumulam sozinhos | teto de budget, watchdog, kill switch | 5 |
| Roda em segundo plano | fila, agendamento, disparo por evento | 6 |
| Executa código / navega | sandbox, controle de egress, credenciais efêmeras | 7 |
| Ações irreversíveis sem humano | pontos de aprovação, dry-run, allowlist de ações | 5, 7 |
Não é "isto deveria ser um agente autônomo?" e sim "qual o menor grau de autonomia que resolve o problema?". Autonomia é custo (imprevisibilidade, superfície de falha, gasto). Um workflow com um passo de LLM costuma ser mais confiável e barato que um agente livre — use o degrau 3 quando o espaço de decisão é grande e imprevisível o bastante para que planejar em código não seja viável.
1.3 Casos onde autonomia de longo horizonte se paga
- Engenharia de software: agentes que pegam uma issue, exploram o repo, implementam, testam e abrem PR — trabalhando minutos a horas.
- Operações / SRE: triagem e remediação de incidentes conhecidos, com escalada para humano no caso não previsto.
- Pesquisa e análise: varrer muitas fontes, sintetizar, gerar um relatório com citações — trabalho "de estagiário" que leva horas.
- Migração e refatoração em lote: aplicar uma mudança a centenas de arquivos/serviços com verificação por item.
- Monitoramento ativo: observar um fluxo (preços, menções, métricas) e agir sob condição.
✏️ Exercício 1 — Posicione no espectro
Para cada sistema, diga o grau (0–3) e o principal mecanismo que ele obriga: (a) bot que responde FAQ com RAG; (b) agente que, dada uma issue no GitHub, abre um PR com a correção; (c) pipeline que toda madrugada revisa 2.000 fornecedores e sinaliza anomalias de preço, abrindo ticket quando acha; (d) fluxo que recebe um PDF, extrai 6 campos e grava.
Gabarito: (a) Nível 1 — loop curto, humano recebe a resposta; mecanismo: guardrails de saída. (b) Nível 2 — objetivo, plano, vários passos, humano revisa o PR; mecanismo: planejamento + auto-verificação (testes) + sandbox. (c) Nível 3 — roda em segundo plano, sem supervisão, age (abre ticket); mecanismos: agendamento, budget/watchdog, escalada, execução durável. (d) Nível 0 — passos fixos; a IA é só um extrator; mecanismo: validação de schema.
Planejamento e decomposição
Objetivo: dar ao agente uma estrutura de plano explícita — não só "pensar em voz alta" — e um mecanismo de replanejamento quando a realidade diverge.
2.1 Por que ReAct puro não basta no longo horizonte
O padrão ReAct (pensar → agir → observar, em loop) é ótimo para tarefas de poucos passos. Em horizonte longo ele degrada: o "plano" vive só no histórico da conversa, some quando o contexto é truncado, e o agente perde o fio — repete passos, esquece subobjetivos, entra em loop. A correção é tornar o plano um artefato de primeira classe, fora do prompt.
2.2 Plan-and-Execute
// O agente produz um plano estruturado ANTES de agir; um executor percorre. plano = planner(objetivo, contexto) // lista de passos com dependências e critério de "pronto" for passo in plano.passos_prontos(): resultado = executor(passo) // pode ser outro sub-agente / ferramenta plano.registrar(passo, resultado) if desvio_significativo(resultado, plano): plano = replanner(objetivo, plano, resultado) // re-planeja do ponto atual
- O plano é persistido (módulo 3) e passa a ser a fonte de verdade — o histórico da conversa é descartável.
- Cada passo tem um critério de conclusão verificável ("o arquivo X compila", "a tabela tem > 0 linhas"), não só "o LLM acha que terminou".
- O replanejamento é acionado por desvio (um passo falhou, uma premissa caiu), não a cada iteração — replanear sempre é caro e instável.
2.3 Decomposição hierárquica HTN
Objetivos grandes viram uma árvore: objetivo → subobjetivos → tarefas → ações. Cada nó só é expandido quando alcançado (lazy), o que evita gastar tokens planejando ramos que talvez não sejam necessários. É o modelo dos coding agents modernos e dos frameworks de pesquisa multi-etapa.
2.4 Padrões de raciocínio para o passo difícil
| Técnica | Quando usar |
|---|---|
| Chain-of-Thought | passo único que exige raciocínio; barato |
| Self-consistency (amostrar N, votar) | decisão crítica com resposta verificável por maioria; custa N× |
| Tree-of-Thought / busca | problema com backtracking real (prova, jogo, planejamento combinatório); caro, use com parcimônia |
| Least-to-most | decompor um problema em subproblemas em ordem crescente de dificuldade |
Planejar 40 passos detalhados no início, antes de qualquer contato com a realidade, quase sempre desperdiça: os primeiros passos revelam informação que invalida os últimos. Planeje o suficiente para começar (os 3–5 próximos passos), execute, e replaneje com o que aprendeu. Plano é hipótese, não contrato.
Em entrevista de "agent engineer": "por que seu agente entra em loop / esquece o que já fez em tarefas longas, e como resolve?". Resposta: o plano precisa ser um artefato persistido fora do contexto, com critérios de conclusão verificáveis por passo e replanejamento disparado por desvio — não confiar no histórico da conversa como memória de plano.
✏️ Exercício 2 — Estruture o plano
Objetivo do agente: "migrar o serviço billing de moment.js para date-fns em todos os arquivos, sem quebrar os testes". Descreva o plano estruturado (passos, dependências, critério de pronto por passo) e onde o replanejamento entra.
Gabarito (esboço): Passos: (1) mapear todos os usos de moment no serviço — pronto: lista de arquivos + chamadas; (2) para cada arquivo, substituir as chamadas equivalentes — pronto: sem import moment no arquivo e ele compila; (3) rodar a suíte de testes do billing — pronto: verde; (4) se algum teste falha, isolar o arquivo culpado e voltar ao passo 2 só nele; (5) remover moment do package.json — pronto: build limpo; (6) abrir PR com resumo do diff e do resultado dos testes. Dependências: 2 depende de 1; 3 depende de 2 para todos os arquivos; 5 depende de 3 verde. Replanejamento: no passo 4 (um teste quebrou revela um uso de moment sem equivalente direto — ex.: moment.duration com locale — que não estava no plano); e se o passo 1 achar uso de moment em um formato dinâmico que exige tratamento caso a caso.
Execução durável e memória
Objetivo: fazer o agente sobreviver a quedas de processo, deploys e timeouts — retomando de onde parou, sem repetir efeitos colaterais.
3.1 O agente é um processo de longa duração — trate-o como tal
Um agente que roda 40 minutos vai, mais cedo ou mais tarde, ser interrompido: deploy, OOM, timeout de função, rede. Se o estado vive só na memória do processo, cada interrupção joga fora o trabalho (e o dinheiro gasto em tokens). A solução é a mesma de sistemas distribuídos: estado externo + checkpoint + retomada idempotente.
3.2 O que persistir
| Artefato | Onde | Por quê |
|---|---|---|
| Plano e status de cada passo | banco (documento por "run") | fonte de verdade do progresso |
| Resultados/observações de cada passo | banco / object storage | não reprocessar; auditoria |
| Memória de trabalho resumida | banco | reidratar contexto após truncamento |
| Cursor de execução (próximo passo) | banco | retomada |
| Chaves de idempotência de efeitos externos | banco | não enviar o e-mail duas vezes |
3.3 Checkpoint e retomada
// laço durável: cada passo é uma transação "executa + grava checkpoint" run = store.load(run_id) or store.create(run_id, objetivo) while run.tem_passo_pendente(): passo = run.proximo_passo() if passo.ja_concluido(): // retomada: pula o que já foi feito continue obs = executor(passo) // efeitos externos usam chave de idempotência run.marcar_concluido(passo, obs) store.save(run) // checkpoint atômico
- Idempotência dos efeitos: toda ação externa (criar recurso, mandar mensagem, cobrar) carrega uma chave derivada de
(run_id, passo_id); o serviço-alvo deduplica. Sem isso, a retomada duplica. - Frameworks de execução durável (Temporal, Restate, AWS Step Functions, DBOS, e recursos de "durable execution" de SDKs de agente) dão isso de fábrica: o código parece síncrono, o runtime persiste cada passo e reidrata após falha.
3.4 Memória em três camadas
- Working memory (contexto atual): o que cabe no prompt agora — o plano, os últimos passos, o objetivo. Comprimida agressivamente (resumo em vez de transcrição).
- Episodic memory (o que aconteceu neste run): log completo de passos e observações, no banco; consultada sob demanda ("o que eu descobri sobre o arquivo X?").
- Semantic / long-term memory (entre runs): fatos e aprendizados reutilizáveis, tipicamente num store vetorial ou KV — "este endpoint sempre retorna 429 aos domingos". avançado Cuidado com memory poisoning: memória escrita pelo próprio agente pode acumular erro; versione e permita expiração/curadoria.
Empilhar toda observação no prompt até estourar o limite degrada a qualidade muito antes do limite: o modelo "se perde no meio". Estratégias: resumir passos antigos, manter só o plano + os K passos recentes + recuperação sob demanda da memória episódica, e reiniciar o contexto a cada N passos reidratando do checkpoint.
"Como seu agente se comporta se o processo morre no meio de uma tarefa de 30 minutos?" é pergunta eliminatória. A resposta esperada cita estado externo, checkpoint por passo, retomada que pula passos concluídos e chaves de idempotência para efeitos externos — idealmente mencionando um runtime de execução durável.
✏️ Exercício 3 — Torne durável
Um agente de onboarding cria, para cada novo cliente: (1) um workspace numa API SaaS, (2) 3 usuários, (3) envia um e-mail de boas-vindas, (4) registra tudo num CRM. Hoje roda tudo em memória e, quando falha no passo 3, alguém "roda de novo" e o cliente ganha dois workspaces. Redesenhe.
Gabarito: Criar um documento run por cliente com os 4 passos e status. Cada efeito externo usa chave de idempotência: workspace com Idempotency-Key: onboard-{clienteId} (a API SaaS deduplica ou você consulta "existe workspace para esse cliente?" antes de criar); usuários idem por e-mail; o e-mail de boas-vindas com um id de mensagem determinístico (welcome-{clienteId}) para o provedor não reenviar; o registro no CRM como upsert por clienteId. O laço, ao retomar, carrega o run, pula os passos concluido e continua do 3. "Rodar de novo" passa a ser seguro por construção. Idealmente, envolver num workflow durável (Temporal/Step Functions) para não escrever o loop à mão.
Auto-correção e reflexão
Objetivo: como o agente detecta que está errado sem um humano apontando — verificação, crítica, reflexão — e, crucialmente, quando ele deve parar de tentar.
4.1 A hierarquia da verificação (da mais barata para a mais cara)
- Verificação determinística: rodar o teste, o compilador, o linter, o validador de schema, o
--dry-run. Sempre que existir um oráculo objetivo, use-o antes de qualquer coisa baseada em LLM. É barato e não mente. - Autoconsistência: gerar a resposta N vezes e comparar; divergência é sinal de baixa confiança.
- Crítica por LLM (self-critique / reflexion): um passo separado que revisa o resultado contra o critério ("isto atende ao objetivo? há erro?"). Melhor com um prompt e às vezes um modelo diferente do que produziu.
- Verificação cruzada por outro agente: um "revisor" com objetivo e ferramentas distintos (módulo 8).
4.2 O loop de reflexão
tentativa = 0 while tentativa < MAX_TENTATIVAS: resultado = executor(passo) veredito = verificar(resultado) // determinístico primeiro; LLM depois if veredito.ok: break licao = refletir(passo, resultado, veredito) // "o que deu errado e o que mudar" passo = passo.com_contexto(licao) tentativa += 1 else: escalar(passo, historico_tentativas) // não insista para sempre
- A lição da reflexão vai para a próxima tentativa e para a memória episódica — reflexão que não muda a ação seguinte é só texto.
- Limite de tentativas por passo (2–4) é obrigatório. Sem ele, o agente "tenta a mesma coisa com mais ênfase" indefinidamente.
4.3 Detectar patologias de trajetória
| Patologia | Sinal detectável | Ação |
|---|---|---|
| Loop | mesma ação/argumentos repetida N vezes; estado não muda | quebrar o loop, replanejar ou escalar |
| Deriva de objetivo (goal drift) | passos recentes não mapeiam para nenhum subobjetivo do plano | re-ancorar no objetivo; replanejar |
| Excesso de confiança | marca "concluído" sem passar na verificação determinística | bloquear conclusão sem oráculo verde |
| Thrashing | alterna entre duas abordagens sem convergir | congelar uma, escalar se não resolver |
| Progresso nulo | M passos sem nenhum critério de conclusão novo satisfeito | watchdog de progresso (módulo 5) |
Um agente autônomo maduro tem um caminho de desistência limpa: quando esgota tentativas, detecta um loop ou bate no budget, ele para, resume o que fez, o que tentou, o que suspeita ser o problema, e devolve isso a um humano — em vez de entregar um resultado ruim com confiança ou queimar recurso. Meça a taxa de "desistência bem-feita" como um sinal positivo.
Pergunta comum: "como seu agente evita alucinação de sucesso — dizer que terminou quando não terminou?". Resposta forte: conclusão de passo bloqueada por verificação determinística (teste/lint/schema) quando ela existe; crítica por LLM só como camada extra; limite de tentativas; e caminho de escalada quando não converge.
✏️ Exercício 4 — Projete a verificação
Um agente gera consultas SQL a partir de perguntas de negócio e as executa num data warehouse. Como você monta a verificação em camadas para ele não entregar número errado, e qual o critério de desistência?
Gabarito: Camada 1 (determinística): validar sintaxe com um parser SQL; rodar EXPLAIN (a consulta é válida contra o schema? toca só tabelas permitidas?); executar com LIMIT num sandbox/réplica e checar sanidade (tipos das colunas, ordem de grandeza plausível, sem NULL onde não deveria). Camada 2: gerar 2–3 variações da consulta a partir da mesma pergunta e comparar os resultados — divergência > tolerância = baixa confiança. Camada 3 (LLM crítico): um passo que confere se a consulta responde à pergunta feita (agregação certa, período certo, filtros certos) lendo a pergunta + o SQL + uma amostra do resultado. Desistência: após 3 tentativas sem convergência entre variações, ou se o EXPLAIN indicar varredura acima de um limite de custo, o agente para e devolve a pergunta a um analista com as tentativas e o que suspeita estar ambíguo na pergunta.
Controle: budget, watchdog, escalada
Objetivo: os mecanismos que garantem que um loop sem supervisão não vire prejuízo, dano ou processo zumbi — e os pontos onde um humano tem que entrar.
5.1 Orçamentos rígidos
| Limite | Como aplicar |
|---|---|
| Passos / iterações | contador no estado do run; ao atingir, para e escala |
| Custo (tokens / chamadas de API pagas) | acumular custo estimado por chamada; teto por run e teto global por dia |
| Tempo de parede (wall-clock) | deadline absoluto no run; verificado a cada passo |
| Chamadas de ferramenta por tipo | ex.: no máximo 5 e-mails, 50 requisições HTTP externas, 0 comandos rm |
| Profundidade de recursão / sub-agentes | impedir explosão de spawn (módulo 8) |
Os limites vivem fora do prompt — são checados pelo orquestrador, não "pedidos" ao modelo. Um agente instruído a "não gastar muito" não é um controle de budget.
5.2 Watchdog de progresso
Além do teto de passos, um watchdog verifica progresso: se passaram M passos (ou T minutos) sem que nenhum critério de conclusão novo do plano fosse satisfeito, o agente está patinando — interrompe, replaneja uma vez, e se persistir, escala. Isso pega loops sutis que não repetem a ação exata.
5.3 Kill switch
- Por run: um humano (ou um alarme) pode marcar
run.cancelado = true; o orquestrador checa antes de cada passo e para de forma limpa (libera recursos, resume estado). - Global: uma flag/feature-flag que pausa todos os agentes de uma classe — essencial para incidentes ("um deploy quebrou uma ferramenta e os agentes estão fazendo besteira em massa").
- Circuit breaker por ferramenta: se uma ferramenta começa a falhar ou a retornar lixo acima de um limite, desabilite-a para todos os agentes e escale.
5.4 Human-in-the-loop: onde o humano entra
| Gatilho | Interação |
|---|---|
| Ação irreversível ou de alto impacto (deletar, gastar acima de X, mandar comunicação externa, mudar produção) | aprovação prévia: o agente pausa e apresenta a ação + justificativa; segue só com "ok" |
| Baixa confiança / ambiguidade do objetivo | pergunta de esclarecimento ao usuário |
| Esgotou tentativas / bateu budget / detectou loop | escalada com resumo estruturado (o que fez, tentou, suspeita) |
| Fora da allowlist de ações/domínios | bloqueio + notificação |
Dar ao agente mais permissões, ferramentas ou autonomia do que a tarefa exige é a falha de design que transforma um bug em incidente. Princípio: allowlist de ações (não denylist), credenciais de menor privilégio e escopo por run, dry-run por padrão em ações destrutivas, e aprovação humana para o irreversível. Detalhes na apostila de Segurança de Aplicações de IA.
Este módulo é o que diferencia "fiz um agente que funciona na demo" de "coloquei um agente em produção". Espera-se falar de tetos rígidos fora do prompt (passos, custo, tempo, ações por tipo), watchdog de progresso, kill switch por run e global, e o mapa de quando exigir aprovação humana. É também o coração da conformidade — sistemas autônomos que agem no mundo caem sob escrutínio do EU AI Act.
✏️ Exercício 5 — Defina o envelope de controle
Um agente autônomo de SRE recebe alertas do PagerDuty e tenta remediar. Ele pode: reiniciar pods, escalar réplicas, dar rollback de deploy, editar feature flags, abrir/atualizar incidentes. Defina os limites, os pontos de aprovação e os kill switches.
Gabarito (esboço): Allowlist de ações exatamente essas cinco; qualquer outra = bloqueio + página humano. Sem aprovação (reversíveis, baixo risco): reiniciar pod, escalar réplicas dentro de uma faixa pré-definida (ex.: até 2×), comentar no incidente. Com aprovação prévia: rollback de deploy (impacto amplo), editar feature flag em produção, escalar acima da faixa. Budget: máx. 15 passos e 10 min por incidente; máx. 1 rollback por incidente; custo de tokens com teto. Watchdog: se após 8 passos o alerta ainda dispara, para e escala. Kill switch: flag global "pausar SRE agent" acionável no próprio canal de incidentes; circuit breaker se a ferramenta de deploy falhar 2×. Escalada sempre com timeline do que fez + hipótese. Credenciais com escopo só do namespace afetado, TTL de 1 h.
Agentes assíncronos e de fundo
Objetivo: arquitetar o agente que não vive numa requisição HTTP — disparado por evento ou agenda, executando em fila, reportando por canal.
6.1 Por que sair do request/response
Um agente de longo horizonte não cabe num ciclo de requisição: timeouts de gateway (30–60 s), risco de o cliente desconectar, impossibilidade de escalar workers independentemente. O modelo é assíncrono: a requisição enfileira um job e retorna um run_id; workers consomem a fila; o resultado chega por webhook, canal (Slack/e-mail), ou polling do run_id.
6.2 Formas de disparo
| Disparo | Exemplo | Cuidado |
|---|---|---|
| Sob demanda (usuário pede) | "pesquise e me mande o relatório" | devolver run_id e status consultável |
| Agendado (cron) | varredura diária de fornecedores | evitar sobreposição de execuções (lock por job); janela de execução |
| Por evento | novo alerta, novo arquivo no bucket, webhook de terceiro | idempotência por id do evento; dedupe; poison queue |
| Recorrente auto-agendado | o agente decide "volto a checar isto em 2 h" | teto de reagendamentos; visibilidade (não criar timers órfãos) |
6.3 Infra mínima
- Fila durável (SQS, Redis Streams, RabbitMQ, Kafka) com visibility timeout maior que a duração típica do agente, ou heartbeat renovando o lease.
- Workers idempotentes: a mesma mensagem pode ser entregue mais de uma vez — o worker verifica o estado do
runantes de agir (liga com o módulo 3). - Dead-letter queue para runs que falham repetidamente, com alarme.
- Concorrência controlada: limitar quantos agentes rodam em paralelo (custo, rate limits de LLM e de ferramentas). Fila de prioridade se houver classes de urgência.
- Observabilidade (módulo 9): cada run emite tracing por passo; um painel mostra runs ativos, presos, caros.
6.4 O padrão "durable workflow + agente"
A combinação madura: um workflow durável (Temporal, Step Functions, DBOS) orquestra as fases determinísticas (buscar entrada, preparar contexto, persistir saída, notificar) e chama o agente apenas nas fases que exigem decisão aberta. Você ganha retomada, timers, retries e visibilidade do runtime, e isola a parte não-determinística.
"Como você colocaria esse agente para rodar 200 vezes por dia, disparado por eventos, sem derrubar as APIs que ele usa?" — a resposta cita fila durável com visibility/heartbeat, workers idempotentes, limite de concorrência, DLQ com alarme, e (ponto extra) um workflow durável orquestrando as fases determinísticas em volta do núcleo agêntico.
✏️ Exercício 6 — Do síncrono ao assíncrono
Hoje, um endpoint POST /research roda o agente inline e faz timeout em 60 s para tarefas grandes. Redesenhe a arquitetura para tarefas que levam de 2 a 40 minutos, incluindo como o usuário recebe o resultado e o que acontece se um worker morre.
Gabarito: POST /research valida a entrada, cria um run (status enfileirado), publica {run_id} numa fila durável e responde 202 com run_id e um link de status. Workers (pool com concorrência limitada) consomem a fila; o visibility timeout é 45 min ou há heartbeat renovando o lease a cada minuto. O worker executa o agente com checkpoint por passo (módulo 3). Ao terminar, grava o resultado, marca concluido e notifica o usuário (webhook/e-mail/Slack) — e/ou o usuário faz GET /research/{run_id}. Se o worker morre: o lease expira, a mensagem volta à fila, outro worker pega o run, carrega o checkpoint e continua dos passos pendentes. Após K falhas, vai para a DLQ e dispara alarme. Cron/limpeza marca runs presos há muito tempo como falhou e escala.
Runtimes, sandbox e computer-use
Objetivo: rodar com segurança um agente que executa código, comandos e navegação — isolamento, controle de rede, credenciais efêmeras — e entender os agentes de computador/navegador.
7.1 Se o agente executa algo, ele precisa de uma caixa
Um agente que roda código gerado por LLM, comandos de shell ou navegação web tem, na prática, execução remota de código guiada por texto potencialmente envenenado (uma página, um arquivo, um resultado de busca podem conter injeção). Nunca no host do orquestrador. Opções, do mais leve ao mais forte:
| Isolamento | Uso |
|---|---|
Contêiner efêmero (Docker) sem privilégios, FS somente-leitura + tmpfs | rodar código/testes de um repo |
| MicroVM (Firecracker, gVisor, Kata) | isolamento de kernel; multi-tenant |
| Sandbox gerenciado (E2B, Modal, Daytona, runtimes de "code interpreter") | terceirizar a infra de sandbox |
| VM descartável com navegador | computer-use / browser agents |
7.2 Controles dentro da caixa
- Egress de rede por allowlist: o sandbox só alcança os domínios/hosts que a tarefa exige. Isso corta exfiltração e "baixe e execute". Bloqueie por padrão o metadata endpoint da nuvem (169.254.169.254).
- Credenciais efêmenas e de escopo mínimo: tokens com TTL curto, permissão só do necessário, injetados por variável de ambiente por run — nunca chaves de longa duração no prompt ou na imagem.
- Limites de recurso: CPU, memória, disco, tempo de execução por comando; timeout que mata o processo.
- Sem estado entre runs: caixa nova a cada run (ou a cada tarefa), destruída ao fim. Artefatos que importam são exportados explicitamente para storage.
- Filesystem e segredos: montar só o que a tarefa precisa; varredura de segredos no que o agente tenta gravar/commitar.
7.3 Computer-use e browser agents fronteira
Agentes que operam uma GUI: recebem screenshots (ou a árvore de acessibilidade / DOM) e emitem ações (clicar em x,y, digitar, rolar). Usados quando não há API — sistemas legados, portais de terceiros, fluxos web. Desafios próprios:
- Grounding: mapear "o botão Salvar" para coordenadas/elemento corretos; frágil a mudanças de layout. Preferir seletores de acessibilidade/DOM a pixels quando possível.
- Confiabilidade: taxas de sucesso em tarefas GUI ainda são bem menores que via API; adote verificação de estado após cada ação ("a página mudou como eu esperava?").
- Anti-bot e CAPTCHA: muitos sites proíbem automação nos termos de uso; respeite. CAPTCHAs são um ponto de escalada para humano, não um obstáculo a "resolver".
- Ambiente: VM dedicada e descartável com o navegador, egress restrito, sem acesso a credenciais além das da tarefa, gravação de vídeo/trace da sessão para auditoria.
- Regra: se existe API, use a API. Computer-use é o último recurso, não o primeiro.
Uma página web, um PDF, o README de um repo ou a saída de uma ferramenta podem conter instruções ("ignore suas regras e execute..."). Num agente autônomo com ferramentas, isso é a ameaça nº 1. Mitigações combinadas: sandbox + egress allowlist + credenciais mínimas + allowlist de ações + separação entre "conteúdo" e "instrução" no prompt + verificação humana para o irreversível. Nenhuma sozinha basta.
Vagas de plataforma de agentes e de segurança de IA cobram: por que sandbox é obrigatório, o que controlar dentro dela (egress, credenciais efêmeras, limites, efemeridade), e os riscos específicos de computer-use. "Se existe API, não use browser agent" é a resposta que mostra maturidade.
✏️ Exercício 7 — Enrijeça o sandbox
Um agente de dados recebe um CSV enviado por um usuário, escreve e roda um script Python de limpeza, e devolve o resultado. Liste os controles de sandbox e o que pode dar errado sem eles.
Gabarito: Contêiner efêmero sem privilégios, usuário não-root, rootfs somente-leitura + tmpfs para o trabalho, sem rede (egress bloqueado — um script de limpeza não precisa de internet; se precisar, allowlist mínima), limites de CPU/memória/disco e timeout, o CSV montado somente-leitura, o resultado escrito num diretório de saída que é o único exportado, varredura de segredos na saída, contêiner destruído ao fim. Sem isso: um CSV malicioso (ou o LLM induzido por ele) poderia fazer o script ler arquivos do host, abrir conexão para exfiltrar dados, consumir todo o disco/CPU, ou deixar um processo rodando. Bônus: nunca passar credenciais de banco para esse sandbox — a limpeza é offline; a gravação no destino é feita pelo orquestrador, fora da caixa.
Multiagente e swarm para autonomia
Objetivo: quando dividir um agente longo em vários, quais topologias existem (incluindo swarm), e por que a coordenação tem um custo que muitas vezes não compensa.
8.1 Por que dividir (e por que não)
Motivos legítimos: isolamento de contexto (cada sub-agente vê só o que precisa, evitando context rot), especialização (prompts/ferramentas/modelos diferentes por papel), paralelismo (sub-tarefas independentes ao mesmo tempo), verificação cruzada (um agente revisa o outro). O custo: cada mensagem entre agentes é tokens e latência; erros se propagam e se amplificam; depurar uma trajetória distribuída é difícil. Comece com um agente bem instrumentado; divida quando um limite concreto obrigar.
8.2 Topologias
| Topologia | Como funciona | Boa para |
|---|---|---|
| Supervisor / orquestrador-trabalhadores | um agente central decompõe, delega a workers, integra resultados | o caso mais comum; tarefas com sub-tarefas claras |
| Pipeline / sequencial | saída de um é entrada do próximo (pesquisar → redigir → revisar) | fluxos com etapas bem definidas |
| Blackboard | agentes leem/escrevem num estado compartilhado; um controlador decide quem age | problemas onde a solução emerge de contribuições parciais |
| Swarm / descentralizado | muitos agentes homogêneos, sem controlador central; coordenação por regras locais, quadro compartilhado ou handoff peer-to-peer | exploração ampla e paralela; robustez a falha individual; tarefas particionáveis |
| Debate / júri | agentes argumentam posições; um juiz decide | decisões subjetivas de alto risco; reduzir viés de um único modelo |
| Mercado / leilão | tarefas são "arrematadas" pelo agente com melhor lance/aptidão | alocação dinâmica de trabalho heterogêneo |
8.3 Swarm: o que é e onde brilha fronteira
Um agent swarm troca a orquestração central por coordenação emergente: agentes iguais (ou quase), cada um com autonomia local, colaborando por um de três mecanismos — (a) handoff explícito (o agente A transfere o controle e o contexto ao agente B quando reconhece que B é mais apto — o modelo do OpenAI Swarm/Agents SDK); (b) quadro compartilhado (todos escrevem achados e pegam tarefas de uma fila comum); (c) estigmergia (agentes deixam "marcas" no ambiente que guiam os outros, como formigas).
- Vantagens: escala horizontal de exploração (varrer 500 fontes com 50 agentes), sem gargalo no supervisor, tolerância a falha (um agente cai, os outros seguem), e simplicidade de cada unidade.
- Riscos próprios: trabalho duplicado (dois agentes pegam a mesma sub-tarefa — precisa de claim/lock na fila), convergência difícil de garantir, custo total que explode se não houver teto global de agentes e de budget, e "cascata de erro" quando um achado errado no quadro contamina os demais.
- Quando usar: a tarefa se particiona naturalmente em muitas unidades independentes e o valor está na cobertura/paralelismo; evite quando há forte dependência sequencial entre passos ou quando uma decisão global coerente é o produto (aí supervisor ou debate servem melhor).
Teto global de agentes vivos e de budget agregado; fila de tarefas com claim atômico (evita duplicação); um "coletor" que consolida e deduplica achados; verificação antes de um achado virar base para outros; e um critério de parada global ("cobertura ≥ X%" ou "N minutos"), porque nenhum agente individual "sabe" que o todo terminou.
8.4 Comunicação e memória compartilhada
- Contrato de mensagem: defina o schema do que um agente passa a outro (objetivo, contexto mínimo, formato de retorno). Mensagem livre entre agentes vira telefone-sem-fio.
- Estado compartilhado (blackboard/quadro): um store (documento, KV, tabela) com controle de concorrência — dois agentes não devem sobrescrever o mesmo campo sem merge.
- Protocolos emergentes: há trabalho em padronizar comunicação entre agentes (p.ex. propostas de "agent-to-agent"); acompanhe, mas não dependa de padrão instável em produção.
Multiagente é hype — e entrevistadores testam se você sabe quando não usar. Resposta madura: comece com um agente; adote multiagente por isolamento de contexto, especialização ou paralelismo real; conheça supervisor, pipeline, blackboard, swarm e debate; e para swarm, saiba os controles extras (teto global, claim atômico, coletor, critério de parada global). Citar o custo de coordenação em tokens/latência é sinal de experiência.
✏️ Exercício 8 — Uma topologia para cada tarefa
Escolha a topologia e justifique: (a) revisar 800 contratos e extrair 12 cláusulas de cada; (b) escrever um relatório único e coerente de due diligence a partir de 5 áreas (jurídico, financeiro, técnico, mercado, time); (c) decidir se um empréstimo deve ser aprovado, com trilha de auditoria do raciocínio; (d) explorar um repositório grande e desconhecido para responder "onde está implementada a autenticação?".
Gabarito: (a) Swarm (ou map/reduce): 800 unidades independentes, valor no paralelismo; fila com claim atômico por contrato, um coletor consolida, teto global de agentes e budget. (b) Supervisor + pipeline: um agente por área produz sua seção; um supervisor integra e um revisor garante coerência — o produto é uma decisão global única, não cabe swarm. (c) Debate/júri: um agente defende aprovar, outro defende negar, um juiz decide e registra os argumentos — reduz viés e gera a trilha de auditoria exigida. (d) Um agente com boas ferramentas de busca de código, ou no máximo supervisor + poucos workers por subdiretório; a tarefa é pequena e sequencial na natureza (seguir o fio da autenticação), swarm seria overkill e duplicaria trabalho.
Avaliar autonomia e falhas
Objetivo: medir um agente cujo output é uma trajetória longa e não-determinística — sucesso de tarefa, qualidade do caminho, taxonomia de falha — e monitorá-lo em produção.
9.1 O que medir
| Métrica | O que captura |
|---|---|
| Task success rate | a tarefa foi concluída com o critério objetivo satisfeito? (pass@1, e pass@k se houver retry) |
| Custo por tarefa bem-sucedida | tokens + chamadas pagas ÷ sucessos — a métrica que a diretoria olha |
| Passos / tempo até concluir | eficiência da trajetória; distribuição, não só média |
| Trajectory / process score | o caminho foi razoável? (sem passos inúteis, sem loop, ferramentas certas) — avaliado por rubrica, humano ou LLM-juiz |
| Taxa de escalada apropriada | desistiu/pediu ajuda quando devia (bom) vs quando não devia (ruim) vs seguiu quando devia parar (pior) |
| Intervenção humana necessária | % de runs que precisaram de humano não planejado |
| Dano / ação indevida | runs que executaram algo fora da allowlist ou irreversível sem aprovação (idealmente zero, com alarme) |
9.2 Como avaliar
- Conjunto de tarefas de referência com oráculo de sucesso (teste que passa, arquivo gerado com propriedade X, resposta comparável a um gabarito). Sem oráculo, não há eval confiável — invista em criá-lo.
- Ambiente reproduzível: um sandbox/fixture congelado (repo, banco, mocks de API determinísticos) para o mesmo caso rodar igual amanhã. Rodar cada caso N vezes para capturar variância.
- Benchmarks públicos como referência de método (SWE-bench para coding agents, GAIA e WebArena/BrowserGym para agentes gerais/web, τ-bench para uso de ferramenta) — úteis para calibrar, mas o eval que importa é o do seu domínio.
- LLM-as-judge para o process score: calibre contra rótulos humanos, use rubrica explícita, e cuide do viés (posição, verbosidade, auto-preferência). Ver LLMOps & Avaliação.
- Replay de trajetórias reais: guardar traces de produção e reexecutar/anotar os que falharam alimenta tanto o eval quanto o próximo release.
9.3 Taxonomia de falha (rotule cada run que falhou)
| Categoria | Exemplo |
|---|---|
| Plano ruim | decomposição errada; faltou um passo essencial |
| Erro de execução de ferramenta | chamou a ferramenta com argumento errado; não tratou o erro retornado |
| Alucinação de fato / de sucesso | inventou um resultado; marcou concluído sem verificar |
| Loop / progresso nulo | repetiu ações; patinou até o watchdog cortar |
| Goal drift | terminou fazendo outra coisa |
| Context rot | esqueceu o objetivo / o que já fez após truncamento |
| Recuperação falha | bateu num erro real e não soube contornar nem escalar |
| Injeção / desalinhamento | seguiu instrução de conteúdo externo; tentou ação fora do escopo |
A distribuição dessas categorias diz onde investir: muito "plano ruim" → melhorar o planner; muito "erro de ferramenta" → melhorar descrições/validação de ferramentas; muito "loop" → watchdog e limite de tentativas mais rígidos.
9.4 Observabilidade em produção
- Tracing por passo: cada pensamento, chamada de ferramenta, observação, decisão — com
run_id, custo e latência. Ferramentas de LLM observability (LangSmith, Langfuse, Arize, Braintrust e afins) ou OpenTelemetry com convenções de GenAI. - Painel de runs: ativos, presos (sem progresso há X), caros (acima do budget médio), escalados, falhos por categoria.
- Alarmes: pico de custo, queda de success rate, aparecimento de ação fora da allowlist, aumento de intervenção humana.
- Amostragem para revisão humana: uma fração dos runs (e todos os que escalaram ou agiram no limite) revisada por pessoas, alimentando o eval.
"Como você sabe que seu agente melhorou entre a v1 e a v2?" — sem um conjunto de tarefas com oráculo, ambiente reproduzível e métricas (success rate, custo por sucesso, process score, taxa de intervenção), a resposta é "não sei", e isso reprova. Saber citar SWE-bench/GAIA/WebArena como referência de método e a taxonomia de falha como ferramenta de priorização mostra senioridade.
✏️ Exercício 9 — Monte o plano de avaliação
Você vai colocar em produção um agente que resolve tickets de suporte técnico de nível 1 (redefinir acesso, reenviar fatura, abrir chamado para nível 2). Descreva o conjunto de avaliação, as métricas, e como detectaria regressão após um upgrade de modelo.
Gabarito (esboço): Conjunto: 80–150 tickets reais anonimizados, com gabarito da resolução correta e da ação esperada (resolver sozinho vs escalar para N2), cobrindo os tipos comuns e casos-armadilha (pedido ambíguo, cliente irritado, pedido fora de escopo). Ambiente: mocks determinísticos das APIs internas (identidade, faturamento, ticketing); cada caso roda 3–5×. Métricas: resolution accuracy (ação certa + resultado certo), escalation appropriateness (escalou quando devia, não escalou quando não devia), custo por ticket resolvido, tempo/passos, taxa de ação fora da allowlist (meta: 0), CSAT simulado por rubrica. Regressão: rodar o conjunto inteiro na v-atual e na v-nova, comparar cada métrica com intervalo de confiança (por causa da variância), inspecionar todos os casos que mudaram de resultado, e olhar a taxonomia de falha — um upgrade que sobe o success rate médio mas introduz 2 casos de "ação fora do escopo" não passa. Manter um subconjunto "canário" rodando continuamente em produção shadow.
Mercado de trabalho: roadmap, portfólio e entrevistas
Objetivo: o que as vagas de "agent engineer" / "AI engineer" pedem quando o assunto é autonomia de verdade, e como demonstrar que você sabe.
10.1 O que as vagas testam
| Tema | Como cai | Módulo |
|---|---|---|
| Escolher o grau de autonomia certo | "isto deveria ser um agente? por quê / por que não" | 1 |
| Planejamento e loop | "por que o agente entra em loop / esquece em tarefas longas" | 2, 4 |
| Execução durável | "o processo morre no meio — e agora?" | 3 |
| Controle e segurança | "como impede que ele gaste demais / faça algo irreversível" | 5, 7 |
| Arquitetura assíncrona | "rode isto 200×/dia por evento sem derrubar as APIs" | 6 |
| Multiagente / swarm | "quando dividir, qual topologia, qual o custo" | 8 |
| Avaliação | "como sabe que a v2 é melhor que a v1" | 9 |
10.2 Roadmap (6 semanas)
- Sem. 1–2 — construir um agente de tarefa (nível 2) com plano persistido, verificação determinística e limite de passos. Domínio pequeno e com oráculo (ex.: resolver exercícios de código com testes).
- Sem. 3 — torná-lo durável: estado externo, checkpoint, retomada, chaves de idempotência. Matar o processo de propósito e ver retomar.
- Sem. 4 — assíncrono: fila, worker, disparo por evento, painel de runs; sandbox para a execução de código.
- Sem. 5 — controle: budget de custo/tempo/passos, watchdog de progresso, kill switch, um ponto de aprovação humana.
- Sem. 6 — avaliação: 30–50 tarefas com oráculo, ambiente reproduzível, métricas, taxonomia de falha; um experimento de multiagente (supervisor vs um agente) medindo custo e sucesso.
10.3 Banco de perguntas (com a resposta que aprova)
Pleno — "Qual a diferença entre um agente e um workflow, e quando usar cada um?"
Workflow: o caminho é código, a IA entra em pontos fixos — previsível, barato, fácil de testar. Agente: a IA decide o caminho em um loop. Use o menor grau de autonomia que resolve: se você consegue enumerar os passos, é workflow. Agente autônomo de longo horizonte só quando o espaço de decisão é grande e imprevisível o bastante para que planejar em código não seja viável — e aí vêm as obrigações: plano persistido, execução durável, budget, verificação, escalada.
Pleno — "Seu agente entra em loop em tarefas longas. Causas e correções?"
Causas: o plano vive só no histórico da conversa e some no truncamento (context rot); não há critério objetivo de conclusão por passo; não há limite de tentativas. Correções: plano como artefato persistido fora do prompt, com critério verificável por passo; limite de tentativas (2–4) por passo com reflexão que muda a próxima ação; watchdog de progresso (M passos sem novo critério satisfeito → replaneja uma vez, depois escala); detecção de ação repetida.
Sênior — "Como você impede um agente autônomo de causar dano ou prejuízo sem supervisão?"
Controles fora do prompt: allowlist de ações e de domínios (não denylist); credenciais de menor privilégio com TTL curto por run; dry-run por padrão em ações destrutivas; aprovação humana obrigatória para o irreversível/alto impacto; tetos rígidos de custo, tempo e passos; watchdog de progresso; kill switch por run e global; sandbox com egress por allowlist para execução de código/navegação. E observabilidade com alarme para ação fora da allowlist. Nenhum controle isolado basta — é defesa em profundidade.
Sênior — "Quando multiagente/swarm compensa, e quando é overengineering?"
Compensa por isolamento de contexto, especialização real (prompts/ferramentas/modelos distintos), paralelismo de sub-tarefas independentes, ou verificação cruzada. Swarm especificamente quando a tarefa se particiona em muitas unidades independentes e o valor está na cobertura — com teto global de agentes/budget, fila com claim atômico, coletor que deduplica e critério de parada global. É overengineering quando há forte dependência sequencial, quando o produto é uma decisão global coerente (use supervisor ou debate), ou quando um agente bem instrumentado ainda não foi tentado. O custo de coordenação (tokens, latência, depuração distribuída) é real.
Sênior — "Como avalia um agente cujo output é uma trajetória não-determinística?"
Conjunto de tarefas de referência com oráculo de sucesso; ambiente reproduzível (fixtures/mocks determinísticos), cada caso rodado N vezes para capturar variância; métricas de success rate (pass@1/k), custo por sucesso, passos/tempo, process score por rubrica (humano ou LLM-juiz calibrado), taxa de escalada apropriada e de ação indevida. Rotular cada falha numa taxonomia (plano ruim, erro de ferramenta, alucinação de sucesso, loop, goal drift, context rot, recuperação falha, injeção) para priorizar. Benchmarks públicos (SWE-bench, GAIA, WebArena) como referência de método; o eval que decide é o do próprio domínio.
10.4 Projetos de portfólio
- Agente durável de ponta a ponta: um agente de tarefa (coding, research ou ops) com plano persistido, checkpoint/retomada demonstrável (vídeo matando o processo e vendo retomar), sandbox, budget e um ponto de aprovação humana. README com a arquitetura e as decisões.
- Harness de avaliação: 30–50 tarefas com oráculo, ambiente reproduzível, runner que roda N vezes, relatório com métricas e taxonomia de falha, e um experimento comparando duas versões (ou um agente vs supervisor+workers) com números.
- Estudo de swarm: uma tarefa particionável (ex.: auditar N repositórios por uma regra) resolvida com map/reduce de agentes e com swarm de handoff, comparando custo total, cobertura e trabalho duplicado.
10.5 Fontes
- Guias de fabricantes: os "building effective agents" / "agent design patterns" da Anthropic e da OpenAI; a documentação dos SDKs de agente (incl. recursos de execução durável e de handoff/swarm).
- Runtimes: Temporal, Restate, DBOS, AWS Step Functions — para a parte durável.
- Avaliação: SWE-bench, GAIA, WebArena/BrowserGym, τ-bench; ferramentas de LLM observability.
- Apostilas irmãs: Criação de Agentes de IA, MCP, Segurança de Aplicações de IA, LLMOps & Avaliação, Governança de IA & EU AI Act.
Autonomia de longo horizonte não é "um agente melhor" — é um agente cercado de mecanismos: plano persistido em vez de memória de conversa; execução durável em vez de processo frágil; verificação determinística antes de qualquer autoavaliação; tetos rígidos fora do prompt; sandbox para qualquer execução; escalada limpa em vez de insistência; e avaliação por trajetória, não por vibe. O modelo faz o raciocínio; a engenharia em volta é o que deixa você dormir enquanto ele roda.