Como escrever prompts de sistema para agentes de IA que não falham em produção

Sumário

Atualizado julho de 2026.

TL;DR: Um prompt de sistema em produção tem cinco camadas: identidade (quem é o agente e o que ele não pode fazer), contexto (o que sabe sobre o ambiente), tarefa (como é o sucesso passo a passo), formato de saída (a camada mais subestimada) e casos extremos (o que fazer quando as entradas falham). A maioria dos prompts falha porque pula as camadas 4 e 5. Escreva o formato de saída antes de qualquer outra coisa — isso te obriga a ser preciso sobre o que você realmente quer.

[Perspectiva do operador] Eu gerencio mais de 30 agentes de IA em produção para minha marca de consultoria e a Pickleland, uma instalação de pickleball em Pflugerville, TX. Reescrevi mais prompts de sistema do que escrevi — geralmente porque a primeira versão parecia funcionar bem nos testes e depois se degradava silenciosamente em produção. Isso é o que aprendi sobre escrever prompts que duram.

O problema do prompt de sistema que ninguém admite

A maioria dos prompts de sistema para agentes é escrita em cerca de 20 minutos, testada em dois ou três exemplos e depois nunca mais tocada. O modelo é lançado. Por um tempo, funciona. Então algo muda — as entradas ficam mais bagunçadas, o modelo é atualizado, um novo caso extremo aparece — e o agente começa a produzir lixo. Silenciosamente. Em escala.

O problema não é que o prompt original era ruim. É que a maioria dos prompts é escrita para demonstrar o caminho feliz. Eles são projetados para a entrada que você tinha em mente quando construiu o agente, não para a distribuição completa de entradas que o agente realmente verá.

As cinco camadas de um prompt de sistema em produção

Penso em cada prompt de sistema que escrevo em cinco camadas. Elas não precisam aparecer nesta ordem — mas todas precisam estar presentes.

Camada 1: Identidade

A identidade diz ao modelo quem ele é e quais são suas restrições operacionais. Não um personagem de jogo de papéis — uma definição funcional do que este agente faz e não faz.

Uma camada de identidade sólida responde três perguntas:

• De que este agente é responsável?
• Do que ele NÃO é explicitamente responsável (e deve escalar ou recusar)?
• Que padrões ele mantém?

O escopo explícito do que NÃO está incluído é a parte que a maioria dos operadores pula. Sem ela, o modelo tentará ser útil fora de sua alçada — e é aí que as coisas dão errado.

Camada 2: Contexto

O contexto é o que o agente sabe sobre seu ambiente que não está na mensagem do usuário. Isso inclui a data e hora atuais (injetar dinamicamente — nunca confie no senso interno de tempo do modelo), estado relevante de sistemas externos e regras de negócios que não são óbvias a partir da descrição da tarefa.

A maioria dos agentes que reviso está com falta de contexto. Não assuma. Injete.

Camada 3: Tarefa

A camada de tarefa descreve o que o agente faz, passo a passo. Não “ajudar clientes” — o fluxo de decisão real. Escreva-a como um fluxograma, não como uma diretiva. Fluxogramas são mais robustos porque reduzem a necessidade do modelo de inferir o que você quer em casos ambíguos.

Camada 4: Formato de saída

Esta é a camada mais subestimada e a mais responsável por falhas silenciosas.

Se você não especificar o formato de saída com precisão, o modelo produzirá uma saída que parece correta para um leitor humano, mas é inconsistente o suficiente para quebrar a análise posterior. Escreva o formato de saída primeiro. Se você não consegue descrever exatamente como quer que a saída seja, você ainda não entende a tarefa bem o suficiente para automatizá-la.

Para saída estruturada, especifique o esquema exato. Para saída em prosa, especifique estrutura, comprimento e restrições de tom — incluindo antipadrões explícitos.

Para agentes de alto risco, uso a saída estruturada do Claude com um esquema JSON definido.

Camada 5: Casos extremos

A camada de casos extremos responde: o que o agente faz quando a entrada é ambígua, incompleta, no idioma errado, hostil ou claramente incorreta? Para cada caso extremo, dê ao modelo um caminho de resposta explícito.

Como eu mantenho prompts de sistema ao longo do tempo

Um prompt de sistema em produção é um documento vivo:

1. Verificação pontual semanal. Reviso de cinco a dez saídas aleatórias de cada agente de alto risco em relação à saída esperada.
2. Revisão após atualização do modelo. Cada vez que a versão do modelo subjacente muda, executo o agente contra o conjunto dourado completo do meu framework de avaliação.
3. Registro de casos extremos. Mantenho um registro das entradas que o agente tratou mal. Quando três ou mais entradas compartilham um padrão, adiciono uma regra explícita.
4. Versionamento do prompt. Cada mudança significativa recebe um comentário de versão.

Perguntas frequentes

Qual deve ser o comprimento de um prompt de sistema em produção?

Longo o suficiente para cobrir as cinco camadas. Curto o suficiente para que você possa lê-lo em dois minutos e detectar desvios. Para a maioria dos meus agentes, isso é de 200 a 600 palavras.

Quando devo dividir uma tarefa complexa em vários agentes em vez de um prompt longo?

Quando a tarefa tem dois ou mais modos distintos que exigem contexto diferente, formatos de saída diferentes ou tratamento de erros diferente. Veja agentes por eventos vs programados para o padrão.

Qual é a razão mais comum para um prompt que funcionou no teste falhar em produção?

As entradas de teste não eram representativas da distribuição de produção. Construa um conjunto de testes a partir do tráfego de produção real, não de entradas imaginadas.

Como sei quando atualizar o prompt vs atualizar o código?

Se o agente está produzindo o formato de saída errado, atualize o prompt. Se o agente está produzindo a saída correta, mas o sistema posterior não consegue usá-la, atualize o código. Se o agente está produzindo fatos incorretos com confiança, verifique primeiro a camada de contexto.