--- term: 'Agente IA' seoTitle: 'Agente IA: il ciclo, i tool, affidabilità, sicurezza' headline: 'Che cos''è un agente IA?' slug: agente-ia category: ai-modern-stack shortDefinition: 'Un agente IA è un sistema guidato da un LLM che persegue un obiettivo in un ciclo: ragiona, chiama un tool, osserva il risultato e ripete.' relatedTerms: - llm-api - model-context-protocol-mcp - cloud-code-serverless-functions - access-control-lists-acl contrastsWith: - llm-api aboutTerms: - 'The Agent Loop (ReAct)' - 'Tools & Function Calling' - 'Agent Memory' faq: - question: 'Che cos''è un agente IA in parole semplici?' answer: 'Un sistema software che usa un modello di linguaggio per capire e portare a termine da solo un obiettivo in più passi – pianificando, usando tool e agendo, invece di limitarsi a conversare. La differenza rispetto a un chatbot è l''autonomia: decide da sé la sequenza dei passi e agisce sul mondo attraverso i tool.' - question: 'Qual è la differenza tra un agente IA e un chatbot?' answer: 'Un chatbot risponde – elabora un messaggio e si ferma. Un agente agisce – ragiona sull''obiettivo, decide quali tool usare, li chiama, osserva i risultati e continua finché il compito non è concluso. Un chatbot parla del rimborso di un ordine; un agente lo rimborsa.' - question: 'Come funziona il ciclo di un agente?' answer: 'Riceve un obiettivo, ragiona sul passo successivo, chiama un tool, osserva il risultato, ragiona di nuovo – e ripete fino al termine del compito o fino a un limite di passi o di costo. Questo ciclo ragiona-agisci-osserva è il pattern ReAct, ed è ciò che rende un agente agentico invece che conversazionale.' - question: 'Che cosa sono i tool e il function calling?' answer: 'I tool sono funzioni esterne – chiamate API, query sul database, esecuzione di codice – che l''agente può invocare. Il function calling è il meccanismo: il modello emette una chiamata JSON strutturata che nomina un tool e i suoi argomenti, il codice applicativo la esegue e il risultato torna al modello. Il modello non esegue mai il tool; si limita a richiederlo.' - question: 'Che cos''è la memoria di un agente?' answer: 'Ne esistono due tipi. La memoria a breve termine è quanto entra nella context window – i passi recenti e lo stato di lavoro. La memoria a lungo termine è conoscenza persistita in un database o in un vector store e recuperata da una sessione all''altra. Il ciclo ha bisogno di entrambe: la finestra per ragionare adesso, lo store per ricordare dopo.' - question: 'Gli agenti IA sono affidabili e pronti per la produzione?' answer: 'I singoli passi sono spesso affidabili; le catene lunghe no. Se ogni passo riesce nel 95 % dei casi, dieci passi riescono circa nel 60 % e venti circa nel 36 % – gli errori si accumulano. Gli agenti in produzione tengono le catene corte, verificano i risultati, mettono le azioni irreversibili dietro un''approvazione umana e restringono ciò che i tool possono fare.' - question: 'Quando conviene non usare un agente IA?' answer: 'Quando il compito è deterministico e ben definito, un semplice workflow o del codice ordinario costa meno, è più rapido ed è più affidabile. Gli agenti ripagano la propria complessità solo quando il percorso non si può scrivere in anticipo – l''autonomia va aggiunta quando migliora il risultato in modo dimostrabile, non per impostazione predefinita.' - question: 'Che rapporto c''è tra MCP e gli agenti IA?' answer: 'Il Model Context Protocol è uno standard aperto che definisce come un agente scopre e chiama tool e dati, sostituendo le integrazioni una tantum con un''interfaccia comune. MCP è l''impianto tra l''agente e i suoi tool; i tool restano funzioni del backend, quelle che fanno il lavoro vero.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)' url: 'https://arxiv.org/abs/2210.03629' - name: 'Building Effective Agents — Anthropic' url: 'https://www.anthropic.com/engineering/building-effective-agents' - name: 'LLM-Powered Autonomous Agents — Lilian Weng' url: 'https://lilianweng.github.io/posts/2023-06-23-agent/' - name: 'Confused Deputy Attacks on Autonomous AI Agents — Cloud Security Alliance' url: 'https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-agent-confused-deputy-prompt-injection/' - name: 'AI agent — Wikipedia' url: 'https://en.wikipedia.org/wiki/AI_agent' cta: title: 'Il tuo backend è il guardrail dell''agente' text: 'Su Back4app i tool di un agente sono funzioni Cloud Code che girano sotto la sessione dell''utente: le ACL decidono che cosa l''agente può toccare, così un agente dirottato non può superare i permessi dell''utente stesso.' linkText: 'Inizia gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-10-13' translationKey: ai-agent --- **Un agente IA è un sistema guidato da un LLM che persegue un obiettivo in un ciclo: ragiona, chiama un tool, osserva il risultato e ripete.** Una semplice [chiamata a un LLM](/glossary/it/api-di-llm/) risponde e si ferma; un agente avvolge quella chiamata in un ciclo di controllo con **tool** (funzioni che può invocare), **memoria** (stato da un passo all'altro) e abbastanza **autonomia** per scegliere la propria sequenza di azioni. Il cambio di prospettiva decisivo per chi sviluppa backend è il fatto più banale e meno detto sugli agenti: **i "tool" di un agente sono gli endpoint del proprio backend** – quando un agente "usa un tool" sta chiamando un'API scritta in casa, il che fa del backend, non del prompt, il luogo in cui la sicurezza vive davvero. ## Punti chiave | Domanda | Risposta | | --- | --- | | Il ciclo | Ragiona → agisci (chiama un tool) → osserva → ripeti fino al termine (ReAct) | | Le quattro parti | Modello (ragionamento) · tool (azioni) · memoria (stato) · orchestrazione (il ciclo) | | vs. un chatbot | Un chatbot *parla* del compito; un agente lo *fa* | | La verità scomoda | L'affidabilità si accumula *al ribasso* – 95 % per passo è circa 60 % su 10 passi | | Il confine di sicurezza | È il backend a imporre che cosa i tool possono fare – non la buona condotta del modello | ## Come funziona il ciclo di ragionamento (ReAct) di un agente IA ```text OBIETTIVO: "Rimborsa il mio ultimo ordine e inviami la conferma" ┌────────────────────────────────────────────────────────────┐ │ 1 REASON modello: "mi serve l'ultimo ordine dell'utente" │ │ 2 ACT chiama il tool: find_orders(user, last=1) │ │ 3 OBSERVE risultato: ordine #1187, 42 $, consegnato │ │ 4 REASON "ammissibile – si rimborsa" │ │ 5 ACT chiama il tool: refund_order(1187) │◄─ ogni ACT colpisce │ 6 OBSERVE risultato: rimborsato │ IL PROPRIO backend │ 7 REASON "ora si invia l'e-mail all'utente" │ │ 8 ACT chiama il tool: send_email(...) │ │ 9 REASON "fatto" → risposta finale │ └────────────────────────────────────────────────────────────┘ Il modello non esegue mai un tool. Ne RICHIEDE uno (nome + argomenti); il codice applicativo lo esegue e restituisce il risultato al passo di ragionamento successivo. ``` I tool di quel ciclo, lato backend – ad ambito ristretto, soggetti ai permessi, eseguiti come l'utente: **JavaScript:** ```javascript // JavaScript — Cloud Code (cloud/main.js) // An agent's "tool" is a backend function — scoped, permissioned, auditable Parse.Cloud.define('refundOrder', async (req) => { // Runs under the CALLING USER's session — ACLs gate everything. // A hijacked agent can't exceed what this user may already do. const asUser = { sessionToken: req.user.getSessionToken() }; const order = await new Parse.Query('Order').get(req.params.orderId, asUser); // ACLs apply via the session token: not your order → this throws, agent or not if (order.get('amount') > 100) throw 'Refunds over $100 need human approval'; order.set('status', 'refunded'); await order.save(null, asUser); return { refunded: order.id }; // the tool result the model reasons over next }); // The backend, not the prompt, is the security boundary. ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // The agent loop runs server-side; the tools it may call are YOUR functions final result = await ParseCloudFunction('runAgent') .execute(parameters: {'goal': 'Refund my last order and email me'}); print(result.result); // The agent reasoned, chose the refundOrder tool, and called it — // but the ACLs on Order decided whether it was ALLOWED to succeed. ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // The agent loop runs server-side; the tools it may call are YOUR functions let result: [String: Any] = try await Cloud.run( name: "runAgent", parameters: ["goal": "Refund my last order and email me"]) print(result) // The agent reasoned, chose the refundOrder tool, and called it — // but the ACLs on Order decided whether it was ALLOWED to succeed. ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // The agent loop runs server-side; the tools it may call are YOUR functions val params = mapOf("goal" to "Refund my last order and email me") val result = ParseCloud.callFunction>("runAgent", params) println(result) // The agent reasoned, chose the refundOrder tool, and called it — // but the ACLs on Order decided whether it was ALLOWED to succeed. ``` ## I quattro componenti essenziali di un agente IA ```mermaid flowchart LR accTitle: I quattro componenti di un agente IA accDescr: Un agente IA combina un modello di linguaggio per ragionare, tool che può invocare per agire, memoria a breve e a lungo termine per lo stato e un ciclo di orchestrazione che alterna ragionamento, azione e osservazione fino a raggiungere l'obiettivo. I tool sono funzioni e API del backend. M["Modello
(nucleo di ragionamento)"] --> O["Ciclo di orchestrazione
ragiona → agisci → osserva"] T["Tool
(API / funzioni proprie)"] --> O MEM["Memoria
breve termine (finestra)
lungo termine (database)"] --> O O -->|"chiamate ai tool"| BE[("Backend
+ dati")] BE -->|"risultati"| O ``` La [scomposizione canonica](https://lilianweng.github.io/posts/2023-06-23-agent/) è modello + pianificazione + memoria + uso dei tool, ma la versione operativa è più semplice: un **modello** ragiona, i **tool** agiscono (e sono funzioni del backend), la **memoria** conserva lo stato – a breve termine nella [context window](/glossary/it/api-di-llm/), a lungo termine in un [database o in un vector store](/glossary/it/database-vettoriale/) – e il **ciclo di orchestrazione** lega il tutto, sul modello del [pattern ReAct](https://arxiv.org/abs/2210.03629) che intreccia ragionamento e azione. ## Agente vs. chatbot vs. chiamata a un LLM vs. workflow | | Chiamata a un LLM | Chatbot | Workflow | Agente IA | | --- | --- | --- | --- | --- | | Fa | Risponde una volta | Conversa | Esegue passi fissi | Sceglie i propri passi | | Flusso di controllo | Nessuno | A turni | **Percorsi di codice predefiniti** | **Diretto dal modello** | | Compie azioni | No | No | Sì, da copione | Sì, decise a runtime | | Prevedibile | Per chiamata | In parte | **Deterministico** | **Probabilistico** | | Adatto a | Domande e risposte, estrazione | Chat di supporto | Processi noti | Obiettivi aperti | La distinzione che conta di più, e che quasi nessun glossario traccia: **un workflow è [orchestrazione](/glossary/api-orchestration/) attraverso percorsi di codice predefiniti; un agente lascia che il modello diriga il proprio percorso.** [Le indicazioni di Anthropic](https://www.anthropic.com/engineering/building-effective-agents) sono nette sulla conseguenza – la maggior parte dei compiti che *sembrano* richiedere un agente è servita meglio da un workflow deterministico, e l'agentività si aggiunge solo quando il percorso davvero non si può scrivere in anticipo. ## Affidabilità: gli errori si accumulano al ribasso La sezione onesta che le pagine dei fornitori evitano. Gli agenti sono impressionanti sul singolo passo e fragili sulla catena, perché **il successo si moltiplica**: se ogni passo riesce con probabilità *p*, un compito di *n* passi riesce con probabilità circa *pⁿ*. ```text successo per passo 10 passi 20 passi 95 % ~60 % ~36 % 90 % ~35 % ~12 % 85 % ~20 % ~4 % Una demo che azzecca un passo impressionante non è un sistema che ne azzecca venti. Nel mondo reale un agente multi-passo e cross-sistema riesce spesso nel 20–40 % dei casi. ``` Questo calcolo detta il playbook di produzione: **tenere le catene corte**, **verificare i risultati** tra un passo e l'altro invece di fidarsi, **mettere le azioni irreversibili** (inviare, eliminare, addebitare, pubblicare) dietro un'approvazione umana e **limitare il ciclo** con tetti di passi e di costo, così che un agente confuso fallisca a poco prezzo invece che a prezzo d'oro. L'affidabilità non è una proprietà del modello di cui attendere il miglioramento; è un'architettura che si impone. ## La superficie di attacco Un agente che può *agire* può essere *ingannato per farlo agire*, e questo lo rende una superficie di attacco davvero nuova. La **prompt injection** trasforma le istruzioni presenti nell'input del modello in azioni reali – e la variante pericolosa è quella *indiretta*: una pagina web, un'e-mail o un ticket di supporto avvelenati che l'agente legge possono portare istruzioni che poi esegue con le credenziali di casa. L'**agente confuso** (confused deputy) è la forma che prende il danno: un agente dotato di permessi ampi, manipolato perché ne abusi a vantaggio di chi attacca. Le contromisure sono vecchia disciplina di sicurezza puntata su un attore nuovo – **credenziali a privilegio minimo, limitate all'utente** (all'agente non va mai dato più di quanto l'utente del compito abbia già), **tool negati per impostazione predefinita e ad ambito stretto**, sandboxing e barriere umane su tutto ciò che è irreversibile. L'inquadramento più importante di tutti: **è il backend, non il prompt, a costituire il confine di sicurezza.** Un prompt si può iniettare; una [verifica dei permessi](/glossary/it/liste-di-controllo-degli-accessi-acl/) lato server non si fa convincere a smettere di applicarsi. ## Progettare tool che un agente non possa usare male Poiché i tool *sono* il backend, progettarli è sicurezza del backend con il volume alzato. Ogni tool va reso **idempotente** dove possibile (un rimborso ritentato non deve rimborsare due volte), **ad ambito stretto** (un'azione chiara, non accesso grezzo al database), **soggetto ai permessi** (gira sotto l'identità dell'utente e le sue [ACL](/glossary/it/liste-di-controllo-degli-accessi-acl/) si applicano) e **chiaro nello schema** – le descrizioni che il modello legge per decidere *se* e *come* chiamare un tool meritano la stessa cura dei prompt, perché una descrizione vaga è un bug che il modello troverà. Vanno esposte *azioni*, non tabelle: `refund_order(id)` con i propri controlli, mai `run_sql(query)`. ## Casi d'uso tipici - **Operazioni verso i clienti** – un agente che risolve una richiesta di supporto dall'inizio alla fine tramite tool soggetti ai permessi, con barriera umana su rimborsi e cancellazioni. - **Assistenti di codice** – leggere un repository, lanciare tool, iterare verso una modifica sottoposta a revisione. - **Ricerca e sintesi** – retrieval e riassunto in più passi, quando il percorso non è noto in anticipo. - **Flussi di dati con discernimento** – passi che richiedono ragionamento tra l'uno e l'altro, non solo una [pipeline](/glossary/api-orchestration/) fissa. - **Pianificazione e coordinamento** – obiettivi che attraversano più sistemi, ciascuno raggiunto con un tool ad ambito ristretto. ## Conviene costruire un agente? Matrice decisionale | Situazione | Che cosa scegliere | | --- | --- | | I passi sono noti in anticipo | Un [workflow](/glossary/api-orchestration/) – deterministico, testabile | | Una singola domanda o estrazione | Una semplice [chiamata a un LLM](/glossary/it/api-di-llm/) | | Obiettivo aperto, percorso deciso a runtime | Un agente – è il suo terreno | | Azioni irreversibili dentro il ciclo | Un agente *con barriere di approvazione umana* | | Molti tool riusati tra agenti e modelli | Standardizzarli con [MCP](/glossary/it/mcp/) | | L'affidabilità è critica per la sicurezza | Catene corte, verifica – oppure lasciar perdere l'automazione | ## Limiti e trade-off - **L'autonomia scambia affidabilità con capacità.** La libertà che permette a un agente di affrontare obiettivi aperti è la stessa che fa accumulare gli errori – va delimitata deliberatamente. - **I cicli costano soldi e tempo.** Ogni iterazione sono altre chiamate al modello; gli agenti sono per costruzione più lenti e più costosi di una chiamata singola – entrambe le cose vanno limitate e monitorate. - **Il non determinismo resiste ai test.** Un workflow si collauda con test unitari; un agente si *valuta* statisticamente, su molte esecuzioni, perché lo stesso input può prendere percorsi diversi. - **Il raggio d'impatto sono le credenziali.** Un agente è sicuro quanto il permesso più stretto concesso ai suoi tool; un accesso troppo ampio è l'incidente che attende il suo momento. - **Impressionante ≠ affidabile.** Una demo convincente è una catena fortunata; la produzione è il lavoro noioso di guardrail, barriere e percorsi corti. ## Gli agenti IA su Back4app Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. La tesi "i tool sono funzioni del backend" è tutta l'integrazione: i tool di un agente sono [funzioni Cloud Code](/glossary/it/cloud-code-funzioni-serverless/) e, poiché girano sotto la sessione dell'utente chiamante, le [ACL e i permessi di classe](/glossary/it/liste-di-controllo-degli-accessi-acl/) della piattaforma filtrano ogni lettura e ogni scrittura che l'agente tenta – come mostrano le schede di codice, un agente dirottato o vittima di prompt injection *non può superare i permessi dell'utente stesso*, perché il raggio d'impatto dell'agente confuso è limitato dal controllo degli accessi e non dalla buona condotta del modello. Il resto segue: esporre azioni ad ambito ristretto (`refundOrder`), non dati grezzi; tenere la [chiave del modello lato server](/glossary/it/sicurezza-delle-chiavi-api/); standardizzare la superficie dei tool con [MCP](/glossary/it/mcp/) quando più agenti la condividono; e lasciare che il backend dica no. L'agente propone; il backend dispone – ed è esattamente dove deve vivere la sicurezza di un sistema autonomo.