# Dalle chiamate agli strumenti al computer per agenti: come cambia l’architettura Dal ciclo di chiamate agli strumenti a un computer che esegue attività reali: ambienti separati, stato salvato, permessi e avanzamento consultabile. Canonical page: https://beeuni.ai/blog/it/from-tool-calls-to-agent-computer Immagina di aggiungere al tuo prodotto un pulsante per confrontare fornitori. Un cliente sceglie alcuni preventivi e chiede un foglio di calcolo con prezzi, date di consegna e differenze nelle condizioni. Il primo prototipo invia il testo a un modello. Funziona con un preventivo breve. Poi un cliente presenta PDF scansionati, un foglio di calcolo e il link al sito di un fornitore. La funzione deve ora aprire i file, estrarre tabelle, consultare il sito, calcolare prezzi confrontabili e creare un foglio scaricabile. Il modello aiuta a decidere cosa fare. Serve anche un posto in cui eseguire i programmi che lo fanno. È qui che torna utile un computer per agenti. ## Cosa succede dopo che il modello chiede di eseguire un comando? Una chiamata a uno strumento è una richiesta del modello al tuo programma. Per esempio, il modello può chiedere di lanciare uno script che legge i preventivi. Il programma deve ancora fornire i file, installare il parser, eseguire lo script e restituire l’output. Se l’estrazione fallisce su una pagina scansionata, l’agente deve esaminare l’errore e provare un altro metodo disponibile. Puoi costruire questi passaggi da solo. Man mano che la funzione cresce, servono anche un browser, accesso ai file, output dei comandi e un modo per separare il lavoro dei clienti. Beeuni riunisce questi elementi in una sessione: l’agente lavora su un computer cloud dove può leggere file, scrivere codice, eseguire comandi e usare il browser. Per il confronto, l’agente può salvare le righe estratte, scrivere uno script di calcolo ed eseguirlo. Può visitare la pagina pubblica di un fornitore per verificare una condizione di consegna. Se un’unità o una data non è chiara, il risultato può segnalarlo per la revisione. Il cliente riceve un foglio di calcolo verificabile, con riferimenti alle fonti. ## Dal ciclo di chiamate agli strumenti al lavoro su un computer Il ciclo di chiamate agli strumenti continua a guidare il ragionamento: interroga il modello, esegue l’azione richiesta, restituisce ciò che è successo e ricomincia. Per il PDF, il computer esegue uno script di estrazione e restituisce codice di uscita, output ed errori. L’agente li legge prima di decidere il passo successivo. Un parser che fallisce, una tabella vuota e un’estrazione riuscita richiedono azioni diverse. Conserva in file separati il PDF originale, extracted.csv, lo script di calcolo e il foglio finale. Se i numeri sembrano sbagliati, puoi risalire attraverso quei file. Prima di cambiare il calcolo, chiedi all’agente di confrontare una riga estratta con la pagina originale. Così puoi correggere il passaggio che ha perso l’informazione. Uno strumento può anche avviare un processo che dura più della chiamata stessa. Una conversione di documenti può essere ancora in corso quando la richiesta scade. Il livello di esecuzione deve permettere di controllare quel processo e il suo output. Chiedere al modello di avviarlo di nuovo potrebbe creare due conversioni anziché risolvere il ritardo. ## Assegna ambienti di lavoro separati ad attività distinte Se due confronti condividono una cartella, ciascuno può sovrascrivere extracted.csv o installare una versione di un pacchetto incompatibile con l’altro. Ogni sessione Beeuni ha il proprio ambiente di esecuzione, che separa file e processi locali. Quando il lavoro usa un repository, il suo branch permette anche di esaminare le modifiche prima di accettarle nel branch predefinito. Le applicazioni condivise richiedono attenzione a parte. Se entrambe le sessioni possono aggiornare lo stesso record di acquisto, computer distinti non impediscono modifiche in conflitto in quell’applicazione. Decidi se il confronto può solo leggere i record o se un aggiornamento richiede approvazione. ## Decidi cosa deve restare dopo un arresto o un guasto La sessione salvata racconta ciò che ha fatto l’agente. Il disco contiene i file estratti e il foglio di calcolo. Un processo in esecuzione contiene lavoro non ancora scritto. Sono stati diversi: recuperare i messaggi non significa che una conversione riparta dall’istruzione a cui era arrivata. Un arresto normale conserva il disco del computer. Eliminare o perdere il computer richiede un altro percorso di recupero, usando la conversazione salvata e il lavoro nel repository quando disponibili. Salva i risultati importanti nel tuo archivio e invia al repository le modifiche da conservare. La [guida alle sessioni](/docs/it/work/sessions) spiega cosa mantiene ogni operazione. ## Imposta i permessi per le azioni importanti L’agente di confronto può dover leggere documenti dei fornitori, mentre fare un ordine richiede una decisione umana. Le [regole dei connettori](/docs/it/connect/connectors) di Beeuni possono consentire un’azione, richiedere approvazione o bloccarla. Configura l’azione stessa invece di affidarti solo a una frase nell’attività. Il computer isola il lavoro locale, ma gli strumenti collegati possono agire su un vero sistema di acquisti. Il tuo prodotto controlla anche quale cliente può aprire ciascun confronto e i suoi file. Una chiave API conservata sul server autentica l’applicazione con Beeuni. I tuoi controlli di accesso collegano quella richiesta alla persona autorizzata a vedere il risultato. ## Lascia proseguire le attività lunghe oltre una singola connessione Un cliente può chiudere la pagina mentre è in corso una conversione. Salva l’ID della sessione Beeuni con il confronto, così la pagina potrà ritrovare lo stesso lavoro al suo ritorno. I flussi di eventi mostrano l’avanzamento in diretta; i log salvati permettono di recuperare quanto accaduto. Un computer raggiungibile può essere occupato, aver finito o attendere una risposta: mostra lo stato dell’attività oltre alla disponibilità del computer. Prima di ripetere una richiesta interrotta, controlla cosa è successo. È importante soprattutto per le azioni esterne: un ordine potrebbe essere stato creato anche se la conferma non è mai arrivata. La [guida al backend per agenti](/blog/it/use-beeuni-as-your-agent-backend) spiega quali dati conservare nell’applicazione e come gestire le riconnessioni. ## Rendi gli errori facili da analizzare Supponiamo che il foglio generato abbia la colonna dei prezzi vuota. Apri i file e l’output dei comandi della sessione. Il parser PDF non ha restituito righe? Lo script cercava una colonna «Price» mentre il preventivo usava «Unit cost»? Il sito del fornitore richiedeva l’accesso? Ogni causa richiede una correzione diversa. L’agente lavora con file e programmi. Puoi quindi chiedergli di esaminare un CSV intermedio, correggere la corrispondenza tra colonne e ripetere il calcolo. Spesso è più utile che chiedere al modello di generare di nuovo la risposta finale senza sapere cosa è andato storto. ## Migliora il passaggio di cui puoi osservare la lentezza Questa funzione può impiegare tempo a preparare il computer, attendere il modello, estrarre i documenti e caricare i siti. Esamina un confronto reale prima di cambiare architettura. Se l’agente apre ripetutamente lo stesso PDF, salva il testo estratto e lavora su quello. Se uno script di calcolo è lento, esaminalo. Se il sito del fornitore è lento, cambiare modello non lo farà caricare più in fretta. Controlla il foglio dopo ogni modifica. Un’estrazione più rapida serve solo se continua a riportare correttamente prezzi e condizioni. Confronta gli stessi documenti con le stesse impostazioni del modello per capire se la modifica è stata utile. ## Cosa fornisce ora l’architettura Il modello continua a scegliere le azioni tramite un ciclo di chiamate agli strumenti. Intorno a esso, il servizio ora esegue programmi, separa attività, conserva il lavoro utile, applica permessi e mostra l’avanzamento. È questo il cambiamento di architettura alla base di un computer per agenti. Beeuni fornisce le interfacce di esecuzione e sessione affinché l’applicazione possa inviare un’attività e seguirla mentre viene svolta. Lo stesso approccio può servire a preparare dataset o testare un sito con il browser. Cambiano i file, i comandi e i risultati attesi. Il prodotto continua ad avviare una sessione, seguire il lavoro e presentare un risultato utilizzabile dal cliente. Parti da [Sessioni da codice](/docs/it/sdk/sessions) e [Autenticazione](/docs/it/sdk/auth). Per conoscere l’idea del prodotto, leggi [Che cos’è un computer AI?](/blog/it/what-is-an-ai-computer).