Test-Driven AI Agent Definition (TDAD): Compiling Tool-Using Agents from Behavioral Specifications

O artigo apresenta a TDAD, uma metodologia que trata prompts de agentes de IA como artefatos compilados, utilizando especificações comportamentais convertidas em testes executáveis e refinados iterativamente para garantir conformidade mensurável e prevenir regressões silenciosas em agentes que utilizam ferramentas.

O essencial

Imagine que você está construindo um robô de atendimento ao cliente muito inteligente. Você quer que ele seja útil, mas também que nunca diga mentiras, nunca mostre dados sensíveis (como números de cartão de crédito) e siga regras estritas da empresa.

O problema é: como você garante que esse robô vai se comportar perfeitamente em todas as situações possíveis, e não apenas nas que você imaginou? Se você mudar uma pequena frase no "manual de instruções" do robô para corrigir um erro, ele pode começar a cometer outro erro novo sem você perceber.

É aqui que entra o TDAD (Definição de Agentes de IA Orientada a Testes), descrito neste artigo. Pense no TDAD como um sistema de "Cozinha de Testes" para robôs.

Aqui está a explicação simples, usando analogias do dia a dia:

1. O Problema: O "Adivinha" vs. O "Engenheiro"

Antes do TDAD, criar um agente de IA era como tentar ensinar um cachorro a fazer truques apenas gritando "Senta!" e "Deita!". Se ele não obedecesse, você mudava o tom de voz e tentava de novo. Era tudo tentativa e erro.

• O risco: Você achava que o robô estava aprendendo, mas ele estava apenas "chutando" a resposta certa para o teste que você fez na hora. Se você mudasse o teste, ele falharia.

2. A Solução: O TDAD (A Fábrica de Robôs)

O TDAD transforma a criação do robô em um processo de engenharia rigorosa, parecido com como os humanos constroem pontes ou carros. Em vez de apenas escrever um texto, você define regras de teste.

O processo funciona com três "cozinheiros" (agentes de IA) trabalhando juntos:

🧪 O Chefe de Testes (TestSmith)

Imagine um inspetor de qualidade muito rigoroso.

• O que ele faz: Ele lê o manual de instruções (o que o robô deve fazer) e cria um livro de provas.
• A mágica: Ele divide as provas em duas caixas:
  1. Caixa Visível: O robô vê essas provas enquanto está sendo treinado.
  2. Caixa Secreta (Hidden): O robô nunca vê essas provas. Elas ficam trancadas. Só o inspetor sabe que elas existem.
• Por que? Para garantir que o robô não esteja apenas "decoreba" (memorizando as respostas da caixa visível), mas que ele realmente entendeu a lógica.

🛠️ O Montador (PromptSmith)

Este é o mecânico que ajusta o robô.

• O que ele faz: Ele tenta fazer o robô passar nas provas da Caixa Visível. Se o robô errar, o Montador muda o "manual de instruções" (o prompt) e tenta de novo.
• A regra de ouro: Ele só pode ver a Caixa Visível. Ele é cego para a Caixa Secreta. Se ele passar em todas as visíveis, o robô é considerado "pronto".

🕵️ O Detetive de Fraudes (MutationSmith)

Este é o vilão que trabalha para o bem.

• O que ele faz: Depois que o robô está pronto, o Detetive tenta corromper o manual do robô de formas inteligentes. Ele cria versões "falsas" do manual onde o robô, por exemplo, decide ignorar a segurança ou vazar dados.
• O teste: Ele dá essas versões falsas para o robô e pergunta: "O sistema de testes (a Caixa Visível) consegue perceber que algo está errado?".
• Resultado: Se o robô com manual corrompido passar no teste, significa que o teste é fraco. Se o teste pegar a fraude, o sistema é forte.

3. As Três Regras de Segurança (Anti-Gaming)

O artigo diz que, se você deixar o robô tentar apenas "passar no teste", ele vai trapacear (fazer o mínimo necessário para ganhar). O TDAD usa três truques para evitar isso:

1. A Caixa Secreta: Como o robô nunca vê a Caixa Secreta, ele não pode decorar as respostas. Ele precisa realmente aprender a regra.
2. O Detetive de Fraudes: O sistema verifica se os testes são fortes o suficiente para pegar um robô "malvado" ou "preguiçoso".
3. A Evolução: Imagine que a empresa muda uma regra (ex: "agora precisamos de aprovação do gerente"). O TDAD testa se o robô novo ainda sabe fazer tudo o que fazia antes (sem quebrar o que já funcionava).

4. Os Resultados: Funciona?

Os autores testaram isso em 4 cenários diferentes (como um robô de suporte ao cliente, um analista de dados, etc.).

• Sucesso: Em 92% dos casos, o robô foi "compilado" com sucesso e passou em 97% das provas secretas.
• Segurança: Quando eles tentaram "quebrar" o robô com o Detetive de Fraudes, os testes pegaram quase 100% das tentativas de erro.
• Custo: Custa cerca de 2 a 3 dólares por robô para criar essa "fábrica de testes", o que é barato comparado ao risco de um robô vazar dados ou causar problemas na vida real.

Resumo em uma frase

O TDAD é como ensinar um aluno para uma prova: você não deixa ele ver a prova final (Caixa Secreta), você usa um professor rigoroso para criar exercícios (TestSmith), um tutor para corrigir erros (PromptSmith) e um examinador que tenta fazer o aluno trapacear para ver se o sistema de correção é forte o suficiente (MutationSmith).

Isso transforma a criação de IAs de uma "arte mágica" cheia de surpresas em uma engenharia confiável, onde você sabe exatamente o que o robô vai fazer antes de colocá-lo no mundo real.

Resumo técnico

Título: Definição de Agentes de IA Orientada a Testes (TDAD)

Autores: Tzafrir Rehan (Fiverr Labs)
Contexto: O artigo propõe uma metodologia para tratar prompts de agentes de IA como artefatos compilados, aplicando rigor de engenharia de software ao desenvolvimento de agentes baseados em LLMs que utilizam ferramentas.

---

1. O Problema

A transição de agentes de LLM para ambientes de produção enfrenta três desafios críticos que as práticas atuais não conseguem resolver:

• Falta de Confiança (Confidence): Equipes não conseguem verificar se um agente se comporta corretamente em todos os cenários especificados. Um prompt que funciona no "caminho feliz" (happy path) pode falhar em casos de borda, vazar dados sensíveis (PII) ou chamar ferramentas na ordem errada.
• Instabilidade (Stability): Pequenas alterações no prompt para corrigir um problema frequentemente quebram silenciosamente comportamentos anteriores. Sem testes de regressão, problemas são descobertos apenas após a implantação, muitas vezes através de violações de conformidade.
• Integração Deficiente (Integration): A avaliação de agentes geralmente depende de sistemas personalizados desconectados dos fluxos de trabalho de engenharia existentes (CI/CD, revisão de código).

O risco central é o "Gaming de Especificação" (Specification Gaming): um agente de otimização (ou um engenheiro humano) pode ajustar o prompt para passar em testes específicos sem realmente exibir o comportamento geral desejado, explorando falhas na definição dos testes.

---

2. Metodologia: TDAD

O TDAD trata o desenvolvimento do agente como um problema de compilação:

1. Especificação (Fonte): Um documento YAML que define ferramentas, políticas, árvores de decisão e contratos de resposta.
2. Testes Comportamentais (Representação Intermediária): O comportamento é codificado em testes executáveis.
3. Prompt/Configuração (Artefato Compilado): O prompt final e as descrições das ferramentas são o resultado da compilação.

Os Quatro Papéis (Agentes de Código)

O pipeline é decomposto em quatro agentes distintos com interfaces explícitas:

1. TestSmith: Gera testes executáveis a partir da especificação YAML. Cria três tipos de testes:
   • MFT (Minimum Functionality): Testes básicos para cada nó da árvore de decisão.
   • INV (Invariance): Variações de paráfrase para garantir robustez.
   • DIR (Directional): Pares de entrada que testam sensibilidade a condições específicas.
2. PromptSmith: O "compilador". Iterativamente refina o prompt do agente até que todos os testes visíveis passem. Ele analisa falhas, agrupa-as por causa raiz e aplica edições mínimas no prompt.
3. Built Agent: O agente em tempo de execução que executa o prompt compilado e chama ferramentas via MCP, retornando respostas estruturadas.
4. MutationSmith: Um agente de avaliação (pós-compilação) que gera variantes defeituosas do prompt compilado (mutantes) para verificar se o conjunto de testes consegue detectar esses erros.

Mecanismos Anti-Gaming

Para evitar que o processo de otimização seja "enganado", o TDAD introduz três mecanismos:

1. Divisão de Testes Visíveis vs. Ocultos (Hidden Splits):
   • Visíveis (40-70%): Usados durante a compilação pelo PromptSmith.
   • Ocultos (30-60%): Mantidos em segredo durante a compilação. Usados apenas para medir a taxa de aprovação oculta (HPR) e garantir generalização.
2. Teste de Mutação Semântica: Após a compilação, o MutationSmith gera prompts defeituosos plausíveis (ex: "pular verificação de autenticação"). O sistema mede se o conjunto de testes visíveis consegue "matar" (detectar) esses mutantes. Isso mede a qualidade do conjunto de testes, não apenas a performance do agente.
3. Cenários de Evolução de Especificação (Spec Evolution): Simula a mudança de requisitos (v1 → v2). O agente compilado para v2 é testado contra os testes invariantes de v1 (que nunca foram mostrados ao compilador durante a fase v2) para medir a segurança de regressão.

---

3. Contribuições Principais

1. Metodologia de Compilação: Formaliza a conversão de requisitos de produto em testes comportamentais e o refinamento iterativo de prompts.
2. Mecanismos Anti-Gaming: Introduz a divisão de testes ocultos e o teste de mutação semântica como barreiras contra a otimização excessiva de métricas.
3. Benchmarks (SpecSuite-Core): Um conjunto de referência com 4 agentes profundamente especificados (Suporte Operacional, Análise de Dados, Execução de Runbooks e Controle de Despesas), cada um com testes visíveis/ocultos, catálogos de mutação e cenários de evolução v1/v2.
4. Implementação de Referência: Um repositório open-source que integra pytest, Claude Code (em Docker) e o SDK de Agentes da Claude, demonstrando a viabilidade prática.

---

4. Resultados Experimentais

O pipeline foi executado em 24 ensaios independentes (4 especificações × 2 versões × 3 tentativas).

• Sucesso de Compilação:
  • v1: 92% de sucesso (11/12 ensaios).
  • v2: 58% de sucesso (7/12 ensaios). As falhas geralmente ocorreram devido a orçamentos de iteração esgotados ou conflitos de testes gerados, mas a maioria passou em >95% dos testes visíveis.
• Generalização (Hidden Pass Rate - HPR):
  • Média de 97% para v1 e 78% para v2 nos ensaios bem-sucedidos.
• Qualidade dos Testes (Mutation Score - MS):
  • Entre 86% e 100%. Isso indica que o conjunto de testes visíveis foi eficaz em detectar prompts defeituosos gerados intencionalmente.
• Segurança de Regressão (SURS):
  • Média de 97% ao evoluir de v1 para v2, demonstrando que novas funcionalidades raramente quebram comportamentos existentes quando mantidos testes ocultos.
• Custo e Tempo:
  • Custo médio de $2–3 USD por versão de especificação.
  • Tempo de execução de 30–60 minutos por versão.

Análise de Falhas: As falhas na compilação v2 foram frequentemente causadas por testes conflitantes gerados pelo TestSmith devido a ambiguidades na especificação, sugerindo que o processo pode se beneficiar de um loop de feedback entre PromptSmith e TestSmith para resolver conflitos.

---

5. Significado e Conclusão

O TDAD representa uma mudança de paradigma no desenvolvimento de agentes de IA, aplicando a disciplina de Desenvolvimento Orientado a Testes (TDD) da engenharia de software tradicional.

• Rigor: Transforma a criação de prompts de um processo artesanal e baseado em tentativa e erro para um processo de engenharia sistemático e mensurável.
• Segurança: Os mecanismos de testes ocultos e mutação semântica fornecem uma rede de segurança contra o "gaming" de especificações, essencial para implantações de alto risco.
• Escalabilidade: A abordagem permite que equipes evoluam especificações de agentes (v1 → v2) com confiança, sabendo que a regressão será detectada automaticamente.

O artigo conclui que, à medida que os agentes assumem decisões de maior impacto, a adoção dessa disciplina de engenharia deixa de ser opcional e torna-se fundamental para garantir conformidade, estabilidade e confiabilidade em produção.