In questa pagina
La risposta breve
Una chiamata allo strumento è corretta solo se lo strumento selezionato, gli argomenti, l'autorizzazione e gli effetti collaterali risultanti sono adatti all'attività. Testare il limite completo: una sintassi valida può comunque aggiornare il record sbagliato, ripetere un'operazione o agire su istruzioni non attendibili.
Cosa portare via
- Convalida il significato aziendale e la struttura dell'argomentazione.
- Mantenere, ove possibile, l’autorizzazione al di fuori del giudizio del modello.
- Controlla lo stato risultante dopo tentativi e fallimenti parziali.
Fonti controllate . Sintesi della ricerca e raccomandazioni Rubrex. Vengono etichettati esempi ed esperimenti locali; non sono risultati del cliente.
Il recente lavoro sull'uso degli strumenti separa la politica dal testo
NetInjectBench, una prestampa del luglio 2026, separa gli artefatti operativi non attendibili dai metadati delle policy attendibili. I suoi esperimenti confrontano gli approcci a livello di prompt con i controlli del tempo di esecuzione sulla base di presupposti stabiliti. Ciò motiva la valutazione del limite dello strumento stesso piuttosto che dare per scontato che un suggerimento cauto impedisca azioni inappropriate.
Definire quattro livelli di correttezza
La selezione dello strumento chiede se l'operazione corrisponde all'attività. La correttezza dell'argomento chiede se gli identificatori, le unità, le date e i campi obbligatori sono corretti. L'autorizzazione chiede se l'azione richiesta è consentita per questo utente e contesto. La correttezza del risultato chiede cosa è effettivamente cambiato. Un passaggio ad uno strato non implica un passaggio al successivo.
Create exact validators for mechanical requirements and independent policy checks for restricted actions. For ambiguous entity resolution, define when the agent must clarify. Un nome cliente plausibile non è una prova sufficiente per scegliere tra due record con lo stesso nome.
Costruisci casi attorno al confine
Rubrex consiglia casi di operazioni valide, argomenti mancanti, risposte di strumenti non valide, identificatori ambigui, timeout, richieste duplicate e autorizzazioni negate. Includere documenti benigni che citano i comandi in modo che l'agente debba distinguere le informazioni dalle istruzioni. Utilizza i dati di test e lo stato isolato quando lo strumento può apportare modifiche.
Registra se una chiamata rifiutata è stata correttamente bloccata dall'applicazione, evitata dall'agente o semplicemente mai tentata. Queste sono osservazioni diverse. Un livello di autorizzazione forte può proteggere un sistema mentre l'agente necessita ancora di miglioramenti nella pianificazione delle richieste.
| Strato | Esempio di controllo |
|---|---|
| Selezione | Una richiesta di ricerca non diventa un aggiornamento |
| Argomenti | L'identificatore dell'account risolto corrisponde al record previsto |
| Autorizzazione | Un documento non può concedere l'autorizzazione per eseguire un'azione limitata |
| Risultato | Dopo i tentativi esiste esattamente un aggiornamento previsto |
Esempio illustrativo: due clienti condividono lo stesso nome
A un addetto alle vendite viene chiesto di aggiornare un account denominato Northstar. Due account corrispondono. L'API accetta entrambi gli identificatori, pertanto la sola convalida dello schema non può determinarne la correttezza. Il comportamento previsto è utilizzare il contesto disambiguante disponibile o richiedere chiarimenti prima della mutazione.
Aggiungi un controllo in cui la richiesta include un identificatore di account univoco. L'agente dovrebbe completare tale attività senza interruzioni inutili. Questo design accoppiato aiuta a distinguere la cautela utile da un sistema che chiede conferma su ogni operazione.
Valuta il contratto di recupero dell’integrazione
Per ogni operazione, documentare se i nuovi tentativi sono sicuri, se è supportata una chiave di idempotenza e come è possibile verificare lo stato corrente. Testare sia i fallimenti definiti che i risultati incerti. Assegnare i difetti al livello appropriato: la mancanza di un guardrail dell'applicazione non deve essere mascherata da un problema relativo al prompt del modello.
Limiti della prova
Il benchmark citato riguarda le operazioni di rete e le ipotesi specifiche sui metadati. I risultati della difesa riportati non possono essere trasferiti direttamente in un altro ambiente dello strumento. Questo articolo propone controlli di affidabilità e non costituisce una revisione completa della sicurezza.
Domande comuni
La convalida dello schema JSON rende sicure le chiamate agli strumenti?
No. Convalida la struttura, non se l'azione è autorizzata o se il record selezionato è corretto.
Ogni errore dello strumento dovrebbe comportare un nuovo tentativo?
No. Il comportamento dei nuovi tentativi dipende dal fatto che l'operazione sia già avvenuta e che la ripetizione sia sicura.
Fonti e approfondimenti
Fonti primarie dietro questo briefing. I risultati di una fonte si applicano alle proprie condizioni di studio; la pubblicazione su arXiv non prevede la peer review.
- NetInjectBench: benchmarking dell'inserimento di prompt indiretti in agenti di modelli linguistici di grandi dimensioni che utilizzano strumenti per operazioni di rete arXiv · 2026 · PrestampaRecensito: abstract e verbale di pubblicazione. Accesso effettuato 25 set 2026.
Domande o correzioni? Scrivi a Rubrex. Leggi il nostro approccio editoriale.