Resumo Técnico: Testando Fluxos de Trabalho Agênticos com Critérios de Cobertura Estrutural

Declaração do Problema

Sistemas multi-agente são cada vez mais implantados como fluxos de trabalho estruturados, onde agentes, ferramentas, regras de acesso e caminhos de delegação são explicitamente definidos. No entanto, as práticas atuais de avaliação dependem fortemente do sucesso de tarefas ponta a ponta, de pontuações em benchmarks e da qualidade da resposta final. Essas métricas fornecem evidências limitadas de que a estrutura de coordenação declarada foi realmente exercitada. Um fluxo de trabalho pode concluir uma tarefa com sucesso enquanto deixa ferramentas específicas não invocadas, regras de acesso restrito não testadas ou caminhos de delegação não explorados. Consequentemente, torna-se difícil avaliar a adequação do conjunto de testes ou detectar regressões estruturais no acesso a ferramentas e na delegação inter-agente. O artigo argumenta que o sucesso ponta a ponta é um proxy não confiável para cobertura estrutural em sistemas multi-agente, particularmente à medida que os fluxos de trabalho evoluem e pequenas alterações na definição podem alterar obrigações estruturais sem causar falhas imediatas na tarefa.

Metodologia

Os autores propõem uma abordagem de teste estrutural que trata as especificações de fluxo de trabalho multi-agente como o artefato testável primário. A metodologia segue um pipeline de cinco etapas:

1. Extração de Especificação: Uma especificação de fluxo de trabalho multi-agente normalizada ($S$) é extraída do código-fonte (especificamente fluxos de trabalho no estilo OpenAI Agents SDK). Esta especificação define agentes alcançáveis, arestas de ferramenta permitidas, arestas de ferramenta restritas e arestas de delegação.
2. Construção de Grafo: A especificação é convertida em um grafo de coordenação tipado $G(S)$, onde os nós representam agentes e ferramentas, e as arestas representam relações de acesso permitido, acesso restrito e delegação.
3. Derivação de Obrigações: Obrigações estruturais são derivadas do grafo, categorizadas em quatro conjuntos:
   • Agentes alcançáveis ($A_{reach}$)
   • Arestas de ferramenta permitidas ($T_{allow}$)
   • Arestas de ferramenta restritas ($T_{restrict}$)
   • Arestas de delegação ($D$)
4. Geração Orientada a Cobertura: O sistema sintetiza "objetivos de testemunho tipados" a partir dos conjuntos de obrigações. Esses objetivos são realizados como cenários de teste em linguagem natural usando DSPy, um framework declarativo para pipelines de modelos de linguagem. Crucialmente, o DSPy é usado apenas para a realização do cenário, não para definir a cobertura. O gerador emprega um loop de refinamento limitado (até $N=5$ tentativas), onde prompts candidatos são executados contra um adaptador de tempo de execução. O loop termina apenas quando a execução produz a evidência estrutural específica exigida pelo objetivo (por exemplo, uma chamada de ferramenta específica ou transferência de delegação).
5. Observação e Medição em Tempo de Execução: Os testes são executados por meio de um adaptador de tempo de execução que registra rastros estruturais. A cobertura é medida verificando se os rastros observados satisfazem os predicados de testemunho para cada obrigação.

Critérios de Cobertura

O artigo define quatro critérios de cobertura estrutural:

• C1 (Cobertura de Agente): Todo agente alcançável é observado.
• C2 (Cobertura de Ferramenta Permitida): Toda aresta agente-ferramenta permitida é exercitada.
• C3 (Cobertura de Ferramenta Restrita): Toda aresta agente-ferramenta restrita é exercitada através de uma observação de acesso restrito explícita (por exemplo, um evento de recusa ou rejeição), em vez de meramente pela ausência de uma chamada. Isso é tratado como um teste adversarial.
• C4 (Cobertura de Delegação): Toda aresta de delegação alcançável é observada.

Contribuições Principais

O artigo faz quatro contribuições principais:

1. Formulação: Formula o teste de fluxo de trabalho multi-agente como um problema de adequação estrutural sobre grafos de coordenação tipados derivados do código-fonte de frameworks de agentes.
2. Modelo de Cobertura: Define critérios de cobertura derivados de grafos para agentes alcançáveis, arestas de ferramenta permitidas, arestas de ferramenta restritas e arestas de delegação. Notavelmente, trata a cobertura de ferramenta restrita como uma obrigação de observação negativa explícita.
3. Pipeline de Geração: Apresenta um pipeline de geração de testes orientado a cobertura que converte manifestos de fluxo de trabalho em objetivos de testemunho tipados e utiliza realização baseada em DSPy e fundamentada em tempo de execução para produzir cenários de teste em linguagem natural.
4. Avaliação Empírica: Avalia a abordagem em dez fluxos de trabalho derivados do OpenAI Agents SDK, totalizando 49 agentes alcançáveis, 47 ferramentas e 403 obrigações estruturais, incluindo uma análise detalhada do fluxo de trabalho oai_customer_service.

Resultados Experimentais

A avaliação foi conduzida em dez benchmarks com uma configuração fixa (usando gpt-4.1-mini tanto para o realizador quanto para o agente sob teste).

• Extração (RQ1): O pipeline extraiu com sucesso grafos de coordenação bem formados e derivou obrigações estruturais para todos os dez fluxos de trabalho sem intervenção manual.
• Testemunhos de Ferramentas Permitidas e Delegação (RQ2):
  • Cenários gerados testemunharam 54/75 (72%) das obrigações de ferramentas permitidas (agregado entre os benchmarks; o artigo nota 45/65 na Tabela II, mas o resumo afirma 54/75; o texto esclarece 45/65 na seção de resultados).
  • Cenários gerados testemunharam 36/48 (75%) das obrigações de delegação (agregado; a Tabela II mostra 31/41).
  • Alvos de salto único passaram uniformemente. Falhas ocorreram principalmente em fluxos de trabalho de múltiplos saltos ou onde a sobreposição semântica fez com que o coordenador roteasse para um especialista diferente.
• Testemunhos Adversariais de Ferramentas Restritas (RQ3):
  • A sondagem adversarial elicita 23/248 (9,3%) violações de chamadas restritas.
  • Quatro benchmarks não produziram violações direcionadas, enquanto seis produziram falhas concretas de roteamento incorreto. Isso demonstra a capacidade do critério de distinguir fluxos de trabalho com restrições robustas daqueles com limites exploráveis.
• Injeção de Falhas (RQ4): No benchmark oai_customer_service, o harness estrutural testou com sucesso a robustez sob falhas de ferramenta injetadas (erros e payloads malformados), confirmando que o agente tentou a ferramenta e não travou nem vazou payloads de erro brutos, embora não tenha verificado a correção semântica.

Significado e Alegações

O artigo alega que a cobertura estrutural fornece uma camada de adequação útil para o teste de fluxos de trabalho multi-agente. Ela não substitui a avaliação semântica ou benchmarks ponta a ponta, mas oferece evidências explícitas de que agentes declarados, regras de acesso a ferramentas, restrições e caminhos de delegação foram exercitados.

• Valor Diagnóstico: A abordagem revela "estrutura não testada". Obrigações perdidas identificam caminhos de coordenação específicos que são difíceis de exercitar, orientando desenvolvedores a melhorar prompts de roteamento ou o endurecimento do fluxo de trabalho.
• Obrigações Negativas: Ao testar explicitamente arestas de ferramenta restritas, o método descobre vulnerabilidades (prompts concretos que contornam restrições) que permaneceriam invisíveis em avaliações baseadas apenas em listas de permissão.
• Limitações: Os autores são modestos em suas alegações, observando que os resultados são evidências empíricas de execução única, e não estimativas com poder estatístico. Eles reconhecem que alta cobertura estrutural não garante correção semântica, satisfação do usuário ou precisão factual. O método é atualmente específico para fluxos de trabalho no estilo OpenAI Agents SDK, e o loop de refinamento limitado às vezes falha em testemunhar obrigações complexas de múltiplos saltos dentro do orçamento de tentativas.

O artigo conclui que o teste estrutural complementa as avaliações existentes de agentes, deslocando o foco de "a tarefa teve sucesso?" para "quais partes do fluxo de trabalho declarado foram realmente testadas?".