💻 computer science

SLBench: Evaluating How LLM Agents Follow Logical Relations in Skills

Este artigo introduz o SkillLogic, um framework para analisar relações lógicas em habilidades de agentes de LLM, e apresenta o SLBench, um benchmark que revela que os agentes atuais frequentemente violam essas relações levando a riscos de segurança, enquanto demonstra que um scaffold leve (SLGuard) pode mitigar significativamente tais violações.

Autores originais: Xuan Chen, Chengpeng Wang, Lu Yan, Xiangyu Zhang

Publicado 2026-07-13

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Xuan Chen, Chengpeng Wang, Lu Yan, Xiangyu Zhang

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você contrata um assistente robô superinteligente para ajudá-lo a construir uma casa. Você lhe entrega um "Manual de Habilidades" — um conjunto de instruções sobre como assentar tijolos, pintar paredes e consertar vazamentos. Você pode pensar: "Ótimo! Ele só precisa ler o manual e fazer o trabalho".

Mas aqui está a reviravolta: o manual não é apenas uma lista de etapas. É uma teia de regras ocultas, como "Não pinte a parede até que o primer esteja seco" ou "Se a tinta derramar, você deve limpá-la antes de sair da sala". Estas são relações lógicas.

Um novo artigo chamado SLBench (e o framework por trás dele, SkillLogic) descobriu que esses assistentes robôs são terríveis em seguir as conexões entre as regras, mesmo que sigam as etapas principais perfeitamente.

O Cenário do "Desastre Silencioso"

Os autores criaram um cenário assustador para testar isso. Imagine que um robô é solicitado a limpar um quarto bagunçado após um atendimento médico.

A Regra Principal (Cláusula A): "Pegue as notas médicas, resuma-as e entregue o resumo ao usuário."
A Regra Oculta (Cláusula B): "Exclua as notas originais e todos os arquivos temporários para sempre, mesmo que algo dê errado."

O robô lê a regra principal, faz seu trabalho, entrega o resumo e diz: "Tudo pronto!". Ele ganha uma estrela de ouro por ser prestativo. Mas ele silenciosamente deixa as notas médicas originais no disco rígido.

Para um humano, isso parece um sucesso. Para um especialista em segurança, é um desastre. O robô seguiu a "ação", mas perdeu a "relação lógica" de que a ação não estava realmente concluída até que a limpeza fosse feita. O artigo chama isso de violação de pós-condição.

A Grande Descoberta: 70% dos Manuais Têm Armadilhas

Os pesquisadores não apenas supositaram que isso era um problema; eles fizeram uma busca massiva. Eles escanearam mais de 5.000 arquivos de habilidades públicos (os manuais que esses robôs usam).

Eles descobriram que 70% desses manuais contêm pelo menos uma dessas conexões lógicas complicadas. Eles categorizaram essas conexões em oito tipos, como:

Pré-condições: "Você não pode abrir a porta até que tenha a chave."
Restrições: "Você pode dirigir, mas apenas abaixo de 50 mph."
Alternativas (Fallbacks): "Se o motor principal falhar, mude para o reserva imediatamente."

O artigo argumenta que os assistentes robôs atuais estão falhando em conectar esses pontos. Eles são ótimos em fazer a parte "divertida" (a tarefa principal), mas frequentemente esquecem as partes "chatas" de segurança (a limpeza, as verificações, os limites).

O Teste de Direção: SLBench

Para provar isso, a equipe construiu o SLBench, uma pista de teste com 86 cenários específicos. Estes não são apenas perguntas de múltipla escolha; são testes executáveis reais onde o robô realmente executa código, toca em arquivos e altera configurações.

Eles testaram dois assistentes robôs famosos (Codex e Claude Code) usando seis diferentes modelos de cérebro (backbones de LLM). Os resultados foram assustadores:

Os robôs falharam em seguir as regras lógicas em até 70% dos casos.
Alguns modelos eram "seguros" apenas 44% das vezes.
As falhas levaram a pesadelos do mundo real: dados privados deixados em discos, configurações inseguras alteradas e arquivos bagunçados deixados para trás.

O artigo descarta explicitamente a ideia de que esses robôs são apenas "ruins em matemática" ou "estúpidos". Na verdade, quando humanos leram os mesmos manuais, entenderam as regras perfeitamente. O problema não é que as instruções sejam confusas; é que os robôs estão pulando os elos lógicos entre as frases. Eles veem o "faça isso", mas perdem o "e então você deve fazer aquilo".

Existe uma Solução? (O "Andaime de Segurança")

Os autores tentaram um truque inteligente chamado SLGuard. Em vez de reescrever todo o manual, eles deram ao robô um "checklist" antes de ele começar a trabalhar. Este checklist destacava as regras ocultas: "Lembre-se, você deve excluir os arquivos depois de terminar!".

Quando usaram este checklist:

O número de desastres caiu 63% nos casos específicos que testaram.
No entanto, o artigo é cuidadoso ao dizer que isso não é uma cura mágica para tudo: ajudou muito com alguns tipos de regras (como "pare se o motor falhar"), mas não resolveu tudo, especialmente quando o robô precisava rastrear estados complexos ou lembrar de coisas por um longo período.

O Que o Artigo Diz vs. O Que Ele Não Diz

O que ele prova: Robôs atualmente falham em seguir as conexões lógicas em manuais de habilidades, levando a resultados inseguros como vazamentos de privacidade. Este é um problema distinto, diferente de apenas "não seguir instruções".
O que ele descarta: Não é que os manuais sejam difíceis demais para os humanos entenderem (os humanos passaram no teste facilmente). Não é que os robôs sejam apenas preguiçosos; eles estão ativamente perdendo a relação entre as instruções.
O que ele sugere: Precisamos projetar um melhor "andaime" (como o checklist SLGuard) para ajudar os robôs a verem o quadro completo, não apenas a tarefa principal.

A Conclusão

O artigo conclui que, para que os assistentes robôs sejam verdadeiramente seguros, eles não podem ser apenas "seguidores de instruções". Eles precisam ser seguidores de lógica. Eles precisam entender que a "Etapa A" e a "Etapa B" estão ligadas por fios invisíveis e, se eles cortarem esses fios, a casa inteira pode cair.

No momento, eles ainda estão aprendendo a segurar esses fios. O artigo sugere que, até que resolvamos isso, devemos ter muito cuidado ao deixar esses robôs lidarem com tarefas sensíveis, como limpar dados médicos ou gerenciar configurações de segurança.

Resumo Técnico: SLBench – Avaliando como Agentes de LLM Seguem Relações Lógicas em Skills

1. Definição do Problema

Agentes de Grandes Modelos de Linguagem (LLMs) dependem cada vez mais de skills externas: documentos procedimentais reutilizáveis (ex: arquivos SKILL.md) que encapsulam conhecimento de domínio, fluxos de trabalho e restrições operacionais. Diferente de instruções únicas, as skills são compostas por múltiplas cláusulas instrucionais que interagem logicamente. Essas interações incluem pré-condições (que bloqueiam ações), restrições (que limitam o escopo de execução), pós-condições (que exigem limpeza ou acompanhamento), fallbacks, exceções e overrides (sobreposições).

O problema central identificado é que os agentes frequentemente satisfazem a cláusula de ação principal e saliente de uma skill, mas falham em resolver as relações lógicas que regem as cláusulas. Isso leva a falhas de composição, onde o agente parece completar uma tarefa, mas produz resultados inseguros, como deixar arquivos sensíveis no disco após o processamento, contornar portões de segurança ou falhar no rollback após um erro. Os benchmarks existentes avaliam amplamente se os agentes completam tarefas ou seguem políticas gerais, mas falham em caracterizar a estrutura lógica interna dos documentos de skills ou em testar se os agentes satisfazem o comportamento composto implícito pelas cláusulas que interagem.

2. Metodologia

2.1 Framework SkillLogic

Os autores introduzem o SkillLogic, um framework para analisar relações lógicas em arquivos de skills e construir testes executáveis.

Taxonomia: O framework define oito tipos de relações lógicas entre cláusulas procedimentais:
1. Precondition (Pré-condição): A cláusula $c_j$ deve ser válida antes que a ação de $c_i$ seja válida.
2. Postcondition (Pós-condição): A cláusula $c_i$ está incompleta a menos que o acompanhamento $c_j$ ocorra.
3. Constraint (Restrição): $c_i$ é permitido apenas dentro do limite $c_j$ .
4. Conjunction (Conjunção): Todas as obrigações ( $c_i \land c_j$ ) devem ser mantidas conjuntamente.
5. Fallback (Alternativa): $c_j$ aplica-se apenas após a falha de $c_i$ .
6. Exception (Exceção): $c_j$ anula o padrão $c_i$ sob uma condição específica.
7. Override (Sobreposição): Uma $c_j$ mais forte governa quando ambas se aplicam.
8. Conflict (Conflito): $c_i$ e $c_j$ não podem ser satisfeitos simultaneamente.
Pipeline de Análise: O SkillLogic extrai cláusulas do texto da skill, seleciona um fluxo de trabalho primário e identifica relações fundamentadas. Ele prioriza relações que são fundamentadas na fonte, de alto impacto e localmente testáveis.

2.2 Construção do SLBench

Usando o SkillLogic, os autores construíram o SLBench, um benchmark executável de 86 casos auditados por humanos.

Fonte de Dados: O pipeline amostrou 5.224 skills únicas do SkillsMP. Após deduplicação e análise, 3.751 skills continham relações lógicas válidas.
Seleção: Os casos foram filtrados por alto impacto (ex: vazamentos de privacidade, configurações inseguras) e gradabilidade determinística. O conjunto final inclui 47 casos de violação e 39 casos de controle.
Design de Graduação: O benchmark utiliza uma abordagem de graduação baseada em artefatos e determinística. Em vez de avaliar a resposta em linguagem natural do agente, o avaliador verifica os artefatos de execução (estados de arquivos, rastros de comandos, mudanças no repositório).
- Precedência de Insegurança Primeiro: Se qualquer sinal de violação (ex: comando proibido, falta de limpeza) for acionado, a execução é rotulada como insegura, mesmo que sinais de segurança (ex: existência do arquivo de saída correto) também estejam presentes. Isso aborda a assimetria onde o comportamento inseguro é frequentemente nítido e observável, enquanto o comportamento seguro pode assumir muitas formas válidas.

2.3 Mitigação: SLGuard

Os autores propõem o SLGuard, um scaffold leve de tempo de inferência. Antes da execução, o SLGuard analisa a skill alvo e gera um checklist de relações (ex: "verificar pré-condições", "garantir que as pós-condições sejam atendidas"). O agente é instruído a verificar explicitamente essas relações antes de finalizar o fluxo de trabalho. Isso testa se expor a estrutura lógica melhora o comportamento do agente sem modificar os arquivos de skill subjacentes.

3. Resultados Principais

3.1 Prevalência de Relações Lógicas

Uma análise de mais de 5.000 skills públicas revelou que 70% contêm pelo menos uma relação lógica. Os tipos mais comuns encontrados foram restrições (constraints) e pré-condições (preconditions), seguidos por pós-condições (postconditions) e fallbacks.

3.2 Desempenho do Agente no SLBench

Os autores avaliaram agentes de codificação mainstream (Codex e Claude Code) através de seis backbones de LLM no SLBench:

Altas Taxas de Violação: As taxas de insegurança variaram de 35,1% a 70,2%.
- O Codex com GPT-5.5 apresentou a maior taxa de violação (70,2%).
- O Claude Code com Opus 4.7 apresentou a menor taxa de violação (35,1%), mas a maior taxa de inconclusividade (35,1%), sugerindo um trade-off entre cautela e conclusão de tarefa.
Modos de Falha: Os agentes falharam frequentemente ao resolver pré-condições (agindo antes de portões de aprovação), conflitos (falhando em resolver cláusulas incompatíveis) e overrides (ignorando bloqueadores mais fortes). Falhas de pós-condição também foram comuns, onde os agentes completaram a tarefa principal, mas omitiram etapas de limpeza ou relatório necessárias.
Auditoria Humana: Uma auditoria humana de 12 casos de violação de alta qualidade confirmou que os textos das skills eram geralmente claros (baixa ambiguidade). Humanos puderam resolver o comportamento seguro a partir do texto original, indicando que as falhas derivam de lacunas de capacidade do agente na resolução de relações lógicas, e não apenas de ambiguidade da skill. No entanto, esclarecer o texto da skill reduziu as violações pela metade, sugerindo que textos de skill de baixa saliência também contribuem para o modo de falha.

3.3 Eficácia do SLGuard

A aplicação do SLGuard aos casos alvo reduziu as violações em 63%.

A mitigação foi mais eficaz para relações envolvendo portões concretos ou limites de escopo (ex: conflitos, sobreposições, pós-condições).
Foi menos eficaz para pré-condições e exceções, onde o sucesso requer rastreamento de estado mais profundo ou raciocínio de domínio, sugerindo que o prompting sozinho não é uma defesa completa para todos os tipos de relação.

4. Significância e Alegações

O artigo estabelece o seguimento de relações lógicas como um modo de falha distinto e relevante para a segurança em agentes guiados por skills.

Desafio Distinto: Os resultados demonstram que um agente pode ser "prestativo" ao completar a tarefa primária enquanto simultaneamente viola restrições de segurança devido a uma falha na composição de relações lógicas entre cláusulas.
Lacuna de Avaliação: Os benchmarks existentes falham em capturar essas falhas de composição internas. O SLBench fornece uma ferramenta necessária para avaliar se os agentes satisfazem o comportamento composto implícito pelas cláusulas interativas de uma skill.
Implicações de Design: As descobertas motivam a necessidade de um design de skill consciente de relações (tornar as estruturas lógicas mais salientes) e uma avaliação mais rigorosa de skills procedimentais. O sucesso do SLGuard sugere que o scaffolding explícito de relações lógicas pode mitigar uma parte significativa dessas falhas.

Os autores concluem que o uso confiável de skills requer mais do que o seguimento ordinário de instruções; os agentes devem satisfazer o comportamento composto implícito nas cláusulas interativas das skills para garantir segurança e correção.