Artigos
Pára de atirar SOPs diretamente para os AI Agents: usa o RFC 2119 (MUST/SHOULD/MAY) para controlar o comportamento do Agent com precisão
Ao enfiar SOPs humanos diretamente num LLM, o Agent costuma acertar à primeira e falhar nas três seguintes. Este artigo demonstra como reescrever System Prompts e Agent Skills com o MUST, SHOULD e MAY do RFC 2119, delimitando restrições rígidas, recomendações fortes e discricionariedade autónoma, com três princípios práticos de implementação.
· 4 min de leitura
Ao implementar Agents no terreno, a armadilha mais comum de muitas equipas é pegar num documento de Word/Notion inteiro com um «SOP humano» e enfiá-lo diretamente no LLM, à espera de que ele resolva tudo sozinho. O resultado parece uma lotaria: corre bem à primeira e descarrila nas três vezes seguintes.
O problema não está na capacidade insuficiente do modelo, mas no facto de os SOPs humanos conterem uma enorme quantidade de «conhecimento tácito (Tacit Knowledge)». O cérebro humano deduz de forma automática que «valores abaixo de 500 euros não precisam de aprovação» ou que «se dermos com um erro neste passo, podemos ignorá-lo para já»; contudo, para um LLM, o texto não estruturado não tem fronteiras de rigor, pelo que ele se limita a improvisar.
Para tornar o comportamento do Agent determinístico, o primeiro passo não é mudar para um modelo maior, mas sim adotar uma norma clássica das especificações de protocolos de rede: a gradação semântica do RFC 2119.
Indo direto à conclusão: marca apenas conformidade, segurança e o Schema nuclear como MUST; deixa as restantes fronteiras para o SHOULD e o MAY; e entrega os nós de alto risco a validação humana.
Porquê o RFC 2119?#
Ao escrever um System Prompt, um Agent Skill ou uma Workflow Rule, expressões vagas como «tem em atenção», «seria bom que» ou «tenta ao máximo» não impõem qualquer limite ao modelo. A utilização de níveis verbais explícitos força uma demarcação clara dos limites de decisão.
MUST / REQUIRED: Restrições rígidas, tolerância zero#
- Semântica: Estritamente proibido ignorar, sem quaisquer exceções.
- Cenários de aplicação: Validação de dados, verificações de segurança, especificações de output do Schema, interceção de alto risco.
- Exemplo: «Antes de invocar a API de faturas,
MUST validar primeiro se o número de colaborador existe; se o retorno for vazio, MUST interromper a execução de imediato.»
SHOULD / RECOMMENDED: Forte recomendação, mas permite desvios justificados#
- Semântica: Deve ser respeitado, exceto se houver motivos contextuais de peso; em caso de desvio, o Agent tem de justificar o seu Reasoning.
- Cenários de aplicação: Escolha de estratégias algorítmicas, preferências de classificação, lógica de retentativas.
- Exemplo: «Para Tickets de apoio ao cliente,
SHOULD encaminhar prioritariamente para a equipa de suporte de primeira linha; caso envolva litígios financeiros, é permitido reencaminhar para a equipa de auditoria financeira.»
MAY / OPTIONAL: Opcional e autónomo, discricionariedade total#
- Semântica: O modelo decide autonomamente se executa ou não, consoante o Context disponível ou o orçamento de tokens.
- Cenários de aplicação: Informação complementar, sugestões de aprofundamento, formatos opcionais de logs.
- Exemplo: «Ao gerar o resumo do processamento,
MAY anexar 1～2 IDs de Tickets históricos de casos semelhantes para referência.»
Três princípios para a implementação prática#
1. Evita encher tudo de MUST, preserva espaço para o Reasoning#
Definir todas as regras como MUST equivale a tratar o LLM como um Deterministic Compiler, facilitando conflitos de regras ou deadlocks lógicos resultantes da expansão de Context. Reserva o MUST apenas para «conformidade, segurança e o Schema nuclear», delegando as restantes fronteiras ao SHOULD.
Decompõe o Prompt nos quatro blocos seguintes para tornar o Scope de cada nível semântico evidente à primeira vista:
## Parameters
## Constraints (RFC 2119)
## Execution Steps
## Error Handling
3. Nós de alto risco associados a Human-in-the-loop#
Quando uma condição atinge uma fronteira crítica de MUST (como transações individuais > $5,000 ou alterações a privilégios de Admin), o único comportamento MUST do Agent é «suspender o pipeline e aguardar pela aprovação humana», e nunca tomar a decisão em nome do operador.
Conclusão: de brinquedo de Demo para Production-Ready#
Pensa no Agent como uma linha de produção industrial, e não como um faz-tudo omnipotente. Ao estabelecer um contrato de comportamento através do RFC 2119, o teu Agent conseguirá finalmente passar de um brinquedo de Demo para uma solução verdadeiramente Production-Ready.