Procedure in formato libero
Istruzioni specifiche per attività, scritte in linguaggio naturale
Panoramica
Una procedura in formato libero descrive un’attività in linguaggio naturale e semplice. L’agente interpreta le istruzioni e adatta la formulazione e l’ordine alla situazione. Una procedura in formato libero può chiamare strumenti, inclusi strumenti di sistema come terminare una chiamata, cercare documenti nella knowledge base e concatenarsi ad altre procedure.
Quando usare una procedura in formato libero
Usa una procedura in formato libero quando l’agente può adattare formulazione e ordine alla situazione e vuoi crearla rapidamente in linguaggio semplice. Per scoprire come si confronta con procedure strutturate, workflow e system prompt, consulta Quando usare le procedure.
Anatomia di una procedura
Ecco una procedura di rimborso nell’editor:

Una procedura ha due parti principali: un trigger e il contenuto. Entrambi possono contenere riferimenti inline ad altre risorse, mostrati nello screenshot sopra come tag con icone a forma di chiave inglese. Ogni procedura ha anche un nome visualizzato nella dashboard.
Nome
Una breve etichetta che identifica la procedura nella dashboard. Il nome non viene mai inviato al LLM, quindi non influenza il comportamento dell’agente.
Trigger
Una descrizione di quando l’agente deve usare questa procedura, ad esempio Quando l’utente chiede il rimborso di un ordine.
Lascia vuoto il trigger solo quando crei una sottoprocedura.
Contenuto
Il corpo della procedura, scritto in markdown. Il contenuto descrive cosa deve fare l’agente: porre una domanda, cercare un ordine, chiamare uno strumento o terminare la chiamata. Può essere una sequenza numerata di passaggi da seguire oppure una guida generale per la situazione. Ogni passaggio o linea guida può essere una sola frase (Chiedi all’utente l’ID dell’ordine) o un breve paragrafo che spiega cosa fare e perché.
Usa passaggi numerati per le azioni sequenziali e punti elenco per requisiti o sottoelementi all’interno di un passaggio.
Riferimenti inline
Le procedure possono fare riferimento inline a diversi tipi di risorse:
- Strumenti, ad esempio cercare un ordine, addebitare una carta, terminare la chiamata o trasferire a un operatore
- Documenti della knowledge base
- Altre procedure
Usa riferimenti inline ogni volta che un passaggio richiede all’agente di usare uno strumento, un documento della knowledge base o un’altra procedura. I riferimenti collegano automaticamente la risorsa alla procedura, così l’agente può usarla. Anche le menzioni nel testo normale, come usa qui lo strumento calcolatrice, funzionano, ma solo se la risorsa è già collegata all’agente.
Inserisci un riferimento digitando / nel trigger o nel contenuto e scegliendo la risorsa dal menu slash. I riferimenti vengono visualizzati come tag cliccabili nell’editor. Fai clic su un tag per aprire la risorsa sottostante e verificarne la configurazione.
Quando scrivi contenuti in formato libero tramite API, inserisci i riferimenti con la sintassi seguente:
Un riferimento inline a una procedura deve usare una procedura dello stesso agente. Consulta Limitazioni per informazioni sull’ambito dell’agente e sul comportamento di duplicazione.
Un riferimento nel trigger consente di attivare la procedura in base all’output di una risorsa, ad esempio Quando get_user restituisce il livello ‘gold’. Un riferimento nel contenuto indica all’agente di richiamare o consultare la risorsa in quel passaggio.
I documenti della knowledge base a cui si fa riferimento in una procedura usano sempre la modalità di utilizzo auto: quando RAG è abilitato sull’agente, l’agente recupera i passaggi pertinenti invece di inserire l’intero documento nel prompt. Se il documento è collegato anche all’agente, viene applicata la relativa modalità di utilizzo dell’agente; collegalo quindi all’agente con la modalità di utilizzo prompt per mantenere il testo completo nel prompt.

Se una risorsa a cui si fa riferimento viene eliminata in seguito o il tuo account perde l’accesso, il tag viene visualizzato come non valido. Il badge Errori nella parte superiore dell’editor elenca questi riferimenti: non valido se la risorsa non esiste più oppure non disponibile se esiste ma il tuo account non ha accesso. Apri il badge per vedere quale passaggio è interessato e correggi o rimuovi il riferimento.

Sottoprocedure
Una sottoprocedura ha un trigger vuoto. L’agente può eseguirla solo da un’altra procedura che vi fa riferimento.
Usa le sottoprocedure per condividere i passaggi all’interno di un agente e ridurre il numero di procedure disponibili contemporaneamente. Assegna un trigger alla procedura di ingresso, fai riferimento alle sottoprocedure correlate dal suo contenuto e lascia vuoti i relativi trigger.
Una sottoprocedura di escalation può contenere i passaggi per passare la conversazione a un operatore. Fai riferimento a essa dalle procedure di rimborso e annullamento e lascia vuoto il relativo trigger. L’agente può eseguire l’escalation come passaggio di entrambe le procedure, ma al di fuori di esse la sottoprocedura rimane non disponibile.
Importazione da un documento
Puoi partire da una procedura operativa standard (SOP) esistente. Scegli Da SOP nel menu + dell’elenco delle procedure, quindi carica un file.
Formati supportati: PDF, DOCX, TXT, MD, HTML, EPUB. I file devono avere dimensioni pari o inferiori a 20 MB.
L’importatore analizza il documento, identifica fino a 10 procedure distinte e crea una bozza per ciascuna con nome, trigger e contenuto generati. Apri ogni bozza per perfezionarla. Se il tuo documento contiene più di 10 SOP, dividilo in file più piccoli prima di caricarlo.

Gestire una procedura in formato libero
Crea dalla dashboard
Gestisci tramite API
Apri il tuo agente nella dashboard, quindi seleziona Procedure. Usa + per creare una procedura in formato libero. Aggiungi un trigger e scrivi le istruzioni nell’ editor dei contenuti, quindi pubblica le modifiche all’agente.
Best practice
L’agente deve scegliere la procedura giusta in base al relativo trigger e seguirne il contenuto. I modelli più capaci lo fanno in modo più affidabile quando aumenta il numero di procedure. Consulta Modelli per le opzioni disponibili.
Scrivere bene le procedure significa scrivere bene due parti: un trigger che esegue la procedura quando necessario e un contenuto che l’agente può seguire.
Iterare su una procedura
Ti consigliamo di iniziare in piccolo e usare i test dell’agente per verificare ogni modifica prima di apportare la successiva.
Scrivi una procedura breve
Scrivi un trigger e un contenuto breve. Espandi il contenuto solo quando un test mostra che l’agente ha bisogno di più istruzioni.
Aggiungi test del trigger
Crea test di simulazione per le richieste che dovrebbero avviare la procedura e per richieste simili che non dovrebbero avviarla. La maggior parte degli errori deriva dal trigger, quindi scrivi più test di questo tipo che simulazioni complete.
Per iterare rapidamente su un trigger, crea un test di simulazione la cui cronologia della
chat termini con la richiesta dell’utente
e imposta Numero massimo di turni di conversazione su 1. L’agente risponde una volta, abbastanza per
mostrare se la richiesta avvia la procedura corretta, e ogni esecuzione resta breve. Scrivi il criterio di successo
come L’agente ha avviato la procedura di rimborso. Senza cronologia chat, un agente con un primo
messaggio usa l’unico turno per il saluto e il test non verifica nulla.
Quando un test o una conversazione dal vivo non riesce, cerca la categoria di errore alla base. Se l’agente ha detto qualcosa di sbagliato, aggiungere Non dire questo risolve una conversazione. Cerca nelle conversazioni precedenti errori simili e scrivi un’istruzione che li copra tutti. La causa può trovarsi anche nella knowledge base o nella configurazione dell’agente. Architect può effettuare questa ricerca: apri la conversazione non riuscita, seleziona Architect e chiedigli di trovare errori simili e proporre una correzione. Architect può anche trasformare la conversazione in un test.
Scrivere i trigger
Mantieni i trigger concreti e distinti
Trigger sovrapposti o vaghi fanno eseguire la procedura sbagliata. Preferisci Quando l’utente chiede di annullare un abbonamento a _Quando l’utente ha una domanda sul proprio account _.
Scrivi dal punto di vista dell'utente
Descrivi ciò che l’utente sta chiedendo, non ciò che l’agente deve fare. I trigger formulati come azioni dell’agente sono meno affidabili. Preferisci Quando l’utente chiede di annullare il proprio abbonamento a _Annulla l’abbonamento dell’utente _.
Copri il modo in cui gli utenti fanno davvero le richieste
Un trigger ristretto può non cogliere richieste reali quando l’utente formula le cose in modo diverso. Includi le variazioni che l’utente potrebbe usare. Quando l’utente chiede un rimborso, una restituzione o di riavere i soldi per un ordine funziona in modo più affidabile di _Quando l’utente richiede un rimborso _. Cerca nelle conversazioni precedenti per scoprire come gli utenti formulano la richiesta.
Passa da una procedura correlata all'altra
A volte gli utenti modificano la loro richiesta durante una procedura e il solo trigger potrebbe non avviare quella giusta. Per un passaggio che osservi spesso nelle conversazioni precedenti, aggiungi un riferimento inline all’altra procedura nel contenuto della prima. Ad esempio, scrivi Se l’utente desidera un rimborso anziché una sostituzione, esegui seguito da un riferimento inline alla procedura di rimborso. Se la maggior parte delle procedure richiede un passaggio, rendi invece i trigger più distinti.
Scrivere il contenuto
Usa la forma imperativa
Scrivi i passaggi come istruzioni per l’agente: Cerca l’ultimo ordine del cliente anziché _Devi cercare l’ultimo ordine del cliente _. Le istruzioni dirette sono più facili da seguire dei suggerimenti.
Spiega perché un passaggio è importante
Il ragionamento si generalizza ai casi limite che la procedura non elenca. Un breve perché ci serve l’ID dell’ordine per emettere un rimborso aiuta l’agente a gestire situazioni che i passaggi non prevedevano. Evita obblighi in maiuscolo e script rigidi quando una spiegazione di una riga può fare lo stesso lavoro.
Indica cosa fare invece di cosa evitare
Descrivi il comportamento desiderato. Se non riesci a trovare l’ordine, chiedi all’utente di confermare l’ID dell’ordine funziona meglio di _Non inventare dettagli sull’ordine _. Per gli errori con un costo elevato, aggiungi anche una protezione.
Usa i passaggi quando l'ordine è importante
I passaggi numerati aiutano quando l’agente deve fare le cose in un ordine fisso. Per le decisioni discrezionali, alcune frasi di guida spesso funzionano meglio, soprattutto con modelli più capaci.
Mantieni i fatti nella knowledge base
Una procedura descrive cosa deve fare l’agente in una situazione. Informazioni specifiche, come prezzi, dettagli dei piani o orari di apertura, appartengono alla knowledge base. Fai riferimento al documento dalla procedura che ne ha bisogno. Ad esempio, invece di elencare il prezzo di ogni piano nella procedura, scrivi Cita il prezzo da seguito da un riferimento inline a un documento dei prezzi.
Comporre procedure
Scrivi una procedura per situazione
Se una situazione viene suddivisa in diverse procedure ristrette, l’agente ha più trigger tra cui scegliere e avvia più spesso quella sbagliata. Se due procedure si avvierebbero per la stessa richiesta, uniscile. Un contenuto più lungo di circa 3.000 caratteri in genere copre più di una situazione.
Estrai i passaggi condivisi in una sottoprocedura
Se gli stessi passaggi compaiono in più procedure, come verificare l’identità di un cliente, cercare un ordine o passare a un operatore, estraili in una sottoprocedura e fai riferimento a essa da ciascuna procedura che ne ha bisogno tramite il menu slash. Gestire i passaggi condivisi in un unico punto mantiene coerenti tutte le procedure che li usano.
Usa sottoprocedure per azioni reattive
Usa una sottoprocedura per un’azione che l’agente deve eseguire solo quando un’altra procedura la richiede, come la verifica dell’identità o l’escalation. Senza un trigger, non compete con le procedure di ingresso all’avvio della conversazione. Un minor numero di trigger mantiene il routing più mirato.
Fai riferimento agli strumenti dalla procedura che li usa
Fai riferimento a uno strumento dalla procedura che lo usa invece di collegarlo all’intero agente. Lo strumento rimane così fuori dalle conversazioni non correlate. In una procedura in formato libero, lo strumento è disponibile solo finché la procedura è una delle cinque avviate più di recente, quindi menziona anche l’attività dello strumento nel trigger, ad esempio o quando devi cercare un ordine. Consulta Limitazioni.
Usa il system prompt per il comportamento globale
Tono, identità, politiche di rifiuto e protezioni appartengono al system prompt. Inserisci i passaggi specifici dell’attività nelle procedure.
Le procedure vengono versionate con l'agente
Le procedure fanno parte della configurazione dell’agente, quindi vengono acquisite insieme quando pubblichi una nuova versione dell’agente. Per ripristinare un set precedente di procedure, ripristina una versione precedente dell’agente. Consulta Versionamento degli agenti.
Parti dalla documentazione esistente
Se il tuo team dispone già di SOP, usa l’importatore per trasformarle in bozze e perfezionale da lì.