No desenvolvimento de agentes de software autônomos, o desafio inicial parece simples: dar uma instrução e esperar que a máquina a execute. No entanto, a jornada para tornar essa execução confiável e previsível é tudo menos trivial. Na Lerian Studio, essa jornada culminou na criação do Ring: um sistema de workflow e biblioteca de skills que transforma a maneira como assistentes de IA abordam o desenvolvimento de software. O Ring força a aplicação de boas práticas de engenharia, como TDD, planejamento e revisões sistemáticas, que agentes de IA frequentemente ignoram.
Este artigo compartilha as lições fundamentais que aprendemos ao longo do desenvolvimento do Ring, mergulhando na ciência por trás do que realmente funciona ao instruir um Large Language Model (LLM) em um contexto de agência.
Lição 1: A Estrutura é a Nova Engenharia de Prompt
Nossa primeira grande descoberta foi que a forma como estruturamos uma instrução é muito mais impactante do que as palavras exatas que usamos. LLMs são treinados em vastos corpora de dados estruturados, como código-fonte, HTML e XML. Eles desenvolvem uma compreensão inata de hierarquia e encapsulamento.
Em vez de depender de comandos imperativos soltos, passamos a usar delimitadores claros, como tags XML, para separar diferentes partes do prompt. Essa abordagem, que chamamos de "Engenharia Estrutural", provou ser um divisor de águas.
Por que Tags XML Funcionam?
As tags XML funcionam por três razões principais:
Delimitação Clara: Tags como <contexto>, <regras> e <tarefa> criam fronteiras cognitivas para o modelo. Isso evita que a instrução "vaze" para o contexto ou que o modelo confunda um exemplo com uma ordem direta.
Referenciabilidade: Torna-se trivial apontar para seções específicas. Uma instrução como "Siga as regras na seção <regras>" é muito mais precisa do que esperar que o modelo encontre as regras em um bloco de texto.
Campos Obrigatórios: Ao exigir que a resposta do agente contenha tags específicas (ex: <analise>, <codigo_gerado>), o modelo as trata como um formulário a ser preenchido, garantindo que nenhuma parte crítica da resposta seja omitida.
Lição 2: A Ciência por Trás de "Gritar" com a IA (e Por Que Parar)
Todos nós já tentamos: quando uma instrução não funciona, nós a colocamos em maiúsculas. NEVER, MUST, REQUIRED. E, surpreendentemente, funciona. Mas por quê? A resposta está na Saliência Léxica e no funcionamento interno do mecanismo de atenção do Transformer.
O Mecanismo por Trás
O processo que faz palavras em maiúsculas "funcionarem" envolve três camadas:
Tokenização: NEVER e never são tokens diferentes para o modelo, com embeddings (representações vetoriais) distintos. O tokenizer (geralmente BPE - Byte Pair Encoding) quebra texto em subunidades diferentes para cada caso.
Dados de Treinamento: O modelo foi treinado em milhões de documentos técnicos (RFCs, especificações legais, documentação de segurança) onde palavras como MUST e SHALL têm um peso semântico real e indicam obrigatoriedade. O embedding de MUST está vetorialmente mais próximo de conceitos como "obrigação", "regra" e "compliance", enquanto must está mais próximo de "possibilidade" e "dedução casual".
O Efeito Softmax: O mecanismo de atenção usa a função Softmax para converter scores de relevância brutos em uma distribuição de probabilidade. A natureza exponencial do Softmax amplifica pequenas diferenças. Um score ligeiramente maior para NEVER (devido ao seu embedding) resulta em uma probabilidade de atenção desproporcionalmente maior.
O Problema da Saturação
No entanto, descobrimos um ponto de saturação. Usar muitas palavras em maiúsculas é como gritar em uma sala cheia de pessoas gritando: ninguém se destaca. A atenção é um recurso de soma zero; se tudo é importante, nada é importante. A saliência funciona por contraste.
Nossa regra prática: use no máximo 1-3 palavras de alta saliência por prompt, bem espaçadas. Para o resto, confie na estrutura.
Lição 3: O Poder do Espaçamento para "Resetar" a Atenção
Relacionado à saturação, descobrimos que o espaço em branco vertical não é apenas para legibilidade humana. Ele atua como um "reset cognitivo" para o mecanismo de atenção do modelo.
O Problema: Attention Bleeding
Quando várias regras importantes são agrupadas em um bloco de texto denso, elas competem pelo mesmo "orçamento" de atenção. Uma regra pode "roubar" a atenção da outra, diminuindo a eficácia geral.
A Solução: Attention Reset
Ao separar grupos de instruções com espaço em branco e cabeçalhos de seção, permitimos que o modelo trate cada seção como uma unidade de atenção semi-independente. Cada seção recebe um "orçamento de atenção" renovado.
Isso nos permite usar múltiplas palavras salientes (como NEVER ou CRITICAL) em um único prompt, desde que estejam em seções logicamente separadas. O modelo pode focar intensamente em NEVER na seção de autenticação e, em seguida, focar novamente em CRITICAL na seção de acesso a dados, sem que uma anule a outra.
Lição 4: Skills Reutilizáveis São a Base da Escalabilidade
Para escalar o desenvolvimento de agentes, percebemos que não poderíamos reescrever as mesmas boas práticas em cada prompt. A solução foi criar um sistema de "Skills": instruções reutilizáveis em formato Markdown que são automaticamente carregadas no contexto do agente.
Estrutura Recomendada de uma Skill
Uma Skill bem-sucedida segue uma estrutura rigorosa, servindo como um microcosmo de todas as lições anteriores:
Lição 5: Alternativas Estruturais Superam Saliência Léxica
Após extensivos testes, concluímos que técnicas estruturais são significativamente mais eficazes do que depender de palavras em maiúsculas. A tabela abaixo resume nossa comparação de efetividade:
Técnicas que Funcionam Melhor
Exemplos Concretos (Few-Shot): O modelo aprende melhor por demonstração do que por instrução. Mostrar um exemplo de código correto é mais efetivo do que descrever a regra.
Formato de Output Explícito: Especifique exatamente a estrutura esperada da resposta. Quando você define seções obrigatórias, o modelo as trata como campos a preencher.
Checklists como Contratos: Pedir que o modelo declare compliance ("Confirme cada item da checklist") aumenta significativamente a aderência às regras.
Negative Examples: Mostrar anti-patterns é tão efetivo quanto mostrar patterns corretos. O modelo aprende os limites do espaço de soluções.
Decomposição em Steps: Forçar o modelo a pensar em etapas cria checkpoints que garantem compliance em cada fase.
Conclusão
A jornada de desenvolvimento do Ring nos ensinou que a confiabilidade dos agentes de LLM não vem de encontrar "palavras mágicas", mas da aplicação de princípios de engenharia. Estrutura, separação de preocupações, e a compreensão dos mecanismos subjacentes como o Softmax são as chaves para passar de prompts que às vezes funcionam para sistemas de agentes que se comportam de forma previsível e robusta.
"A saliência léxica é o nível mais fraco de enforcement. Estrutura, exemplos e formato são muito mais robustos."
As principais lições podem ser resumidas em:
- Use estrutura XML para delimitar seções e criar campos obrigatórios
- Use saliência com moderação (1-3 palavras por prompt, bem espaçadas)
- Espaçe suas instruções para permitir "reset" de atenção entre seções
- Crie Skills reutilizáveis para escalar boas práticas
- Prefira técnicas estruturais (exemplos, checklists, steps) sobre CAPS
Essas lições formam a base do nosso framework de desenvolvimento de agentes e continuam a evoluir à medida que aprendemos mais sobre o comportamento desses sistemas fascinantes.
Explore o Projeto
O Ring é um projeto de código aberto e está disponível para consulta, uso e contribuição no GitHub. Explore nosso repositório para ver as skills, agentes e workflows em ação:
• Repositório Público do Ring: https://github.com/LerianStudio/ring*
Este artigo faz parte da série de documentação técnica do projeto Ring da Lerian Studio.