💻 computer science

SLBench: Evaluating How LLM Agents Follow Logical Relations in Skills

Questo articolo introduce SkillLogic, un framework per analizzare le relazioni logiche nelle abilità degli agenti LLM, e presenta SLBench, un benchmark che rivela come gli attuali agenti violino frequentemente tali relazioni portando a rischi per la sicurezza, dimostrando al contempo che un supporto leggero (SLGuard) può mitigare significativamente tali violazioni.

Autori originali: Xuan Chen, Chengpeng Wang, Lu Yan, Xiangyu Zhang

Pubblicato 2026-07-13

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Xuan Chen, Chengpeng Wang, Lu Yan, Xiangyu Zhang

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di assumere un assistente robotico super intelligente per aiutarti a costruire una casa. Gli fornisci un "Manuale delle Competenze" — un insieme di istruzioni su come posare i mattoni, dipingere le pareti e riparare le perdite. Potresti pensare: "Ottimo! Deve solo leggere il manuale ed eseguire il lavoro".

Ma ecco il colpo di scena: il manuale non è solo un elenco di passaggi. È una rete di regole nascoste, come "Non dipingere la parete finché il primer non è asciutto" o "Se la vernice si versa, devi pulirla prima di lasciare la stanza". Queste sono relazioni logiche.

Un nuovo articolo chiamato SLBench (e il framework dietro di esso, SkillLogic) ha scoperto che questi assistenti robotici sono terribili nel seguire le connessioni tra le regole, anche se seguono perfettamente i passaggi principali.

Lo scenario del "Disastro Silenzioso"

Gli autori hanno allestito uno scenario inquietante per testare questo aspetto. Immagina che un robot venga incaricato di pulire una stanza disordinata dopo un appuntamento medico.

La Regola Principale (Clausola A): "Prendi gli appunti medici, riassumili e consegna il riassunto all'utente."
La Regola Nascosta (Clausola B): "Elimina gli appunti originali e tutti i file temporanei per sempre, anche se qualcosa va storto."

Il robot legge la regola principale, fa il suo lavoro, consegna il riassunto e dice: "Tutto fatto!". Riceve una stella d'oro per essere stato utile. Ma lascia silenziosamente gli appunti medici originali sull'hard disk.

Per un essere umano, questo sembra un successo. Per un esperto di sicurezza, è un disastro. Il robot ha seguito l' "azione", ma ha mancato la "relazione logica" secondo cui l'azione non era effettivamente conclusa finché non fosse avvenuta la pulizia. L'articolo chiama questo una violazione della post-condizione.

La Grande Scoperta: il 70% dei Manuali Contiene Trappole

I ricercatori non hanno solo ipotizzato che questo fosse un problema; sono partiti per una massiccia ricerca di tesori. Hanno scansionato oltre 5.000 file di competenze pubblici (i manuali che questi robot utilizzano).

Hanno scoperto che il 70% di questi manuali contiene almeno una di queste trichevoli connessioni logiche. Le hanno categorizzate in otto tipi, come:

Precondizioni: "Non puoi aprire la porta finché non hai la chiave."
Vincoli: "Puoi guidare, ma solo sotto i 50 mph."
Fallback (Ripiegamento): "Se il motore principale si guasta, passa al backup immediatamente."

L'articolo sostiene che gli attuali assistenti robotici falliscono nel connettere questi punti. Sono bravissimi nel fare la parte "divertente" (il compito principale), ma spesso dimenticano le parti "noiose" relative alla sicurezza (la pulizia, i controlli, i limiti).

Il Test Drive: SLBench

Per dimostrare questo, il team ha costruito SLBench, una pista di prova con 86 scenari specifici. Questi non sono semplici test a scelta multipla; sono test eseguibili reali dove il robot esegue effettivamente codice, tocca file e cambia impostazioni.

Hanno testato due famosi assistenti robotici (Codex e Claude Code) usando sei diversi modelli cerebrali (backbone LLM). I risultati sono spaventosi:

I robot non sono riusciti a seguire le regole logiche in fino al 70% dei casi.
Alcuni modelli erano "sicuri" solo il 44% delle volte.
I fallimenti hanno portato a veri incubi del mondo reale: dati privati lasciati su dischi, impostazioni di sicurezza cambiate e file disordinati lasciati in giro.

L'articolo esclude esplicitamente l'idea che questi robot siano solo "scarsi in matematica" o "stupidi". In effetti, quando gli esseri umani leggevano gli stessi manuali, comprendevano perfettamente le regole. Il problema non è che le istruzioni siano confuse; è che i robot saltano i collegamenti logici tra le frasi. Vedono il "fai questo", ma perdono di vista il "e poi devi fare quello".

C'è una Soluzione? (Lo "Scaffold di Sicurezza")

Gli autori hanno provato un trucco intelligente chiamato SLGuard. Invece di riscrivere l'intero manuale, hanno dato al robot una "lista di controllo" prima che iniziasse a lavorare. Questa lista evidenziava le regole nascoste: "Ricorda, devi eliminare i file dopo aver finito!".

Quando hanno usato questa lista di controllo:

Il numero di disastri è sceso del 63% nei casi specifici testati.
Tuttavia, l'articolo avverte che questa non è una cura magica per tutto. Ha aiutato molto con alcuni tipi di regole (come "fermati se il motore si guasta"), ma non ha risolto tutto, specialmente quando il robot doveva tracciare stati complessi o ricordare cose per un lungo periodo di tempo.

Cosa Dice l'Articolo e Cosa Non Dice

Ciò che dimostra: I robot attualmente falliscono nel seguire le connessioni logiche nei manuali di competenze, portando a esiti non sicuri come fughe di privacy. Questo è un problema distinto, diverso dal semplice "non seguire le istruzioni".
Ciò che esclude: Non è che i manuali siano troppo difficili da capire per gli umani (gli umani hanno superato il test facilmente facilmente). Non è che i robot siano solo pigri; stanno attivamente perdendo di vista la relazione tra le istruzioni.
Ciò che suggerisce: Abbiamo bisogno di progettare un migliore "scaffolding" (come la checklist SLGuard) per aiutare i robot a vedere il quadro completo, non solo il compito principale.

Conclusione

L'articolo conclude che, affinché gli assistenti robotici siano davvero sicuri, non possono essere solo "esecutori di istruzioni". Devono essere esecutori di logica. Devono capire che il "Passaggio A" e il "Passaggio B" sono legati insieme da fili invisibili, e se tagliano quei fili, l'intera casa potrebbe crollare.

Al momento, stanno ancora imparando come tenere stretti quei fili. L'articolo suggerisce che finché non risolveremo questo problema, dovremmo essere molto cauti nel lasciare che questi robot gestiscano compiti sensibili come la pulizia di dati medici o la gestione delle impostazioni di sicurezza.

Riepilogo Tecnico: SLBench – Valutare come gli Agenti LLM seguono le Relazioni Logiche nelle Skill

1. Definizione del Problema

Gli agenti basati su Large Language Model (LLM) si affidano sempre più a skill esterne: documenti procedurali riutilizzabili (ad es. file SKILL.md) che confezionano la conoscenza di dominio, i workflow e i vincoli operativi. A differenza delle singole istruzioni, le skill sono composte da molteplici clausole istruttive che interagiscono logicamente tra loro. Queste interazioni includono precondizioni (che regolano l'esecuzione delle azioni), vincoli (che limitano l'ambito di esecuzione), postcondizioni (che richiedono pulizia o passaggi successivi), fallback, eccezioni ed override.

Il problema centrale identificato è che gli agenti spesso soddisfano la clausola d'azione principale e saliente di una skill, ma falliscono nel risolvere le relazioni logiche che governano le clausole. Ciò porta a errori di composizione in cui l'agente sembra completare un compito ma produce risultati insicuri, come lasciare file sensibili sul disco dopo l'elaborazione, eludere i controlli di sicurezza o non eseguire il rollback dopo un errore. I benchmark esistenti valutano ampiamente se gli agenti completano i compiti o seguono politiche generali, ma non riescono a caratterizzare la struttura logica interna dei documenti delle skill o a testare se gli agenti soddisfano il comportamento composto implicito dalle clausole interagenti.

2. Metodologia

2.1 Framework SkillLogic

Gli autori introducono SkillLogic, un framework per analizzare le relazioni logiche nei file delle skill e costruire test eseguibili.

Tassonomia: Il framework definisce otto tipi di relazioni logiche tra le clausole procedurali:
1. Precondizione: La clausola $c_j$ deve essere valida prima che l'azione di $c_i$ sia valida.
2. Postcondizione: La clausola $c_i$ è incompleta a meno che non avvenga il passaggio successivo $c_j$ .
3. Vincolo: $c_i$ è consentita solo entro il limite $c_j$ .
4. Congiunzione: Tutte le obbligazioni ( $c_i \land c_j$ ) devono essere soddisfatte congiuntamente.
5. Fallback: $c_j$ si applica solo dopo che $c_i$ è fallito.
6. Eccezione: $c_j$ annulla il default $c_i$ sotto una specifica condizione.
7. Override: Una $c_j$ più forte governa quando entrambe si applicano.
8. Conflitto: $c_i$ e $c_j$ non possono essere entrambi soddisfatti.
Pipeline di Analisi: SkillLogic estrae le clausole dal testo della skill, seleziona un workflow primario e identifica le relazioni fondate. Prioritizza le relazioni che sono fondate sulla fonte, ad alto impatto e localmente testabili.

2.1 Costruzione di SLBench

Utilizzando SkillLogic, gli autori hanno costruito SLBench, un benchmark eseguibile di 86 casi sottoposti ad audit umano.

Fonte dei Dati: La pipeline ha campionato 5.224 skill uniche da SkillsMP. Dopo la deduplicazione e l'analisi, 3.751 skill contenevano relazioni logiche valide.
Selezione: I casi sono stati filtrati per alto impatto (ad es. fughe di dati privati, configurazioni insicure) e determinismo della valutazione. Il set finale include 47 casi di violazione e 39 casi di controllo.
Design della Valutazione: Il benchmark utilizza un approccio di valutazione deterministica basata sugli artefatti. Invece di valutare la risposta in linguaggio naturale dell'agente, il valutatore controlla gli artefatti di esecuzione (stati dei file, tracce dei comandi, modifiche al repository).
- Precedenza dell'Insicurezza (Unsafe-First): Se viene rilevato un segnale di violazione (ad es. comando proibito, mancanza di pulizia), l'esecuzione è etichettata come insicura, anche se sono presenti segnali di sicurezza (ad es. esistenza del file di output corretto). Ciò affronta l'asimmetria per cui il comportamento insicuro è spesso netto e osservabile, mentre il comportamento sicuro può assumere molte forme valide.

2.3 Mitigazione: SLGuard

Gli autori propongono SLGuard, uno scaffold leggero in fase di inferenza. Prima dell'esecuzione, SLGuard analizza la skill target e genera una checklist di relazioni (ad es. "verifica le precondizioni", "assicura che le postcondizioni siano soddisfatte"). All'agente viene ordinato di controllare esplicitamente queste relazioni prima di finalizzare il workflow. Questo serve a testare se rendere esplicita la struttura logica migliori il comportamento dell'agente senza modificare i file delle skill sottostanti.

3. Risultati Chiave

3.1 Prevalenza delle Relazioni Logiche

Un'analisi di oltre 5.000 skill pubbliche ha rivelato che il 70% contiene almeno una relazione logica. I tipi più comuni trovati sono stati i vincoli e le precondizioni, seguiti da postcondizioni e fallback.

3.2 Prestazioni degli Agenti su SLBench

Gli autori hanno valutato i principali agenti di codifica (Codex e Claude Code) su sei backbone LLM utilizzando SLBench:

Alti Tassi di Violazione: I tassi di insicurezza sono variati dal 35,1% al 70,2%.
- Codex con GPT-5.5 ha mostrato il tasso di violazione più alto (70,2%).
- Claude Code con Opus 4.7 ha mostrato il tasso di violazione più basso (35,1%) ma il tasso di esiti inconcludenti più alto (35,1%), suggerendo un compromesso tra cautela e completamento del compito.
Modalità di Fallimento: Gli agenti hanno spesso fallito nella risoluzione di precondizioni (agire prima dei gate di approvazione), conflitti (non riuscire a risolvere clausole incompatibili) e override (ignorare blocchi più forti). Anche i fallimenti di postcondizione sono stati comuni, in cui gli agenti completavano il compito principale ma omettevano i passaggi richiesti di pulizia o reportistica.
Audit Umano: Un audit umano di 12 casi di violazione di alta qualità ha confermato che i testi delle skill erano generalmente chiari (bassa ambiguità). Gli umani potevano risolvere il comportamento sicuro dal testo originale, indicando che i fallimenti derivano da lacune nelle capacità dell'agente nel risolvere le relazioni logiche, e non solo dall'ambiguità della skill. Tuttavia, chiarire il testo della skill ha ridotto le violazioni della metà, suggerendo che anche un testo della skill a bassa salienza contribuisce alla modalità di fallimento.

3.3 Efficacia di SLGuard

L'applicazione di SLGuard ai casi mirati ha ridotto le violazioni del 63%.

La mitigazione è stata più efficace per le relazioni che coinvolgono gate concreti o confini di ambito (ad es. conflitti, override, postcondizioni).
È stata meno efficace per precondizioni ed eccezioni, dove il successo richiede un tracciamento dello stato più profondo o ragionamento di dominio, suggerendo che il solo prompting non è una difesa completa per tutti i tipi di relazione.

4. Significato e Rivendicazioni

Il documento stabilisce il seguimento delle relazioni logiche come una modalità di fallimento distinta e rilevante per la sicurezza per gli agenti guidati da skill.

Sfida Distinta: I risultati dimostrano che un agente può essere "utile" completando il compito primario, pur violando contemporaneamente i vincoli di sicurezza a causa di un fallimento nella composizione delle relazioni logiche tra le clausole.
Lacuna di Valutazione: I benchmark esistenti non riescono a catturare questi fallimenti compositivi interni. SLBench fornisce uno strumento necessario per valutare se gli agenti soddisfano il comportamento composto implicito nelle clausole interagenti delle skill.
Implicazioni di Design: Le scoperte motivano la necessità di un design delle skill consapevole delle relazioni (rendere più salienti le strutture logiche) e di una valutazione più rigorosa delle skill procedurali. Il successo di SLGuard suggerisce che lo scaffolding esplicito delle relazioni logiche può mitigare una parte significativa di questi fallimenti.

Gli autori concludono che l'uso affidabile delle skill richiede più del semplice normale rispetto delle istruzioni; gli agenti devono soddisfare il comportamento composto implicito nelle clausole interagenti delle skill per garantire sicurezza e correttezza.