Torna al Blog
Tradotto dall'inglese
EngineeringAugust 22, 202618 min

Come costruire un agente AI aziendale: guida completa

Impara l'agente a 4 livelli: Memoria, Recupero (RAG/Graph), Strumenti e LangGraph. Stack, codice e ordine di costruzione contro le mezze risposte.

AI AgentsEnterprise AILangGraphRAGKnowledge GraphAgent OrchestrationVector DatabaseNeo4jQdrantLLM Reliability2026 AI ArchitectureRetrieval

By Hussain Nazary

Come costruire un agente AI aziendale: guida completa

TL;DR — Progetto Enterprise Agent 2026 Un agente demo è uno strumento di richiesta e ricerca. Un agente di produzione è composto da 4 livelli: Memoria/Stato → Recupero (RAG / RAG Graph / Knowledge Graph) → Strumenti (lettura vs scrittura con approvazione umana) → Orchestrazione (loop LangGraph con tentativi limitati + valutazione). RAG, RAG Graph e Knowledge Graph non sono prodotti separati: sono tre strumenti di recupero all'interno di un agente, instradati per domanda. Ordine di costruzione: RAG semplice → Ciclo RAG Graph → Knowledge Graph (solo per domande sulle relazioni) → azioni delimitate → valutazione/osservabilità - non piena autonomia il primo giorno. Stack 2026: LangGraph + Qdrant/Weaviate/pgctor + BGE-M3 + Neo4j + LangMem/Graphiti. Definizione rapida (per snippet in primo piano) Un agente AI aziendale è un ciclo di ragionamento (Pensa → Agisci tramite strumenti → Osserva → Decidi) costruito su 4 livelli: 1) Memoria e stato (AgentState), 2) Recupero (RAG / RAG Graph / Knowledge Graph), 3) Strumenti (schemi digitati, le azioni di scrittura richiedono l'approvazione umana), 4) Orchestration (LangGraph grafico di stato conMAX_ITERATIONS + is this actually done?posto di controllo). Predisposizione aziendale = residenza dei dati + valutazione + osservabilità + costi: progettato fin dal primo giorno.

Perché questo è importante nel 2026: Il recupero è il fallimento n. 1 dell'agente, non il LLM. I team che spediscono un "modello più grande" invece di un'architettura di recupero migliore spediscono agenti fragili. Questa guida vivente (ultima revisione agosto 2026) collega il nostro RAG Graph e il Knowledge Graph approfondimenti in un sistema zero-to-enterprise con struttura del codice, stack GitHub open source per livello e un ordine di creazione che evita di pagare per la complessità che non hai guadagnato.

Sommario

Il primo "agente" della maggior parte delle persone è un chatbot con un prompt di sistema e l'accesso a uno strumento di ricerca. Funziona in una demo. Cade a pezzi nel momento in cui qualcuno gli chiede qualcosa che richiede più di un passo, o nel momento in cui deve prendere una decisione invece di limitarsi a rispondere a una domanda.

Un agente che funziona davvero – il tipo di cui ci si può fidare per funzionare all’interno di un’azienda, su dati reali, prendendo decisioni reali – è un tipo di sistema completamente diverso. Questa guida ne crea uno da zero, utilizzando tutto ciò di cui una vera implementazione aziendale ha effettivamente bisogno: non solo un LLM con un prompt, ma memoria, strumenti, recupero, verifica e la capacità di giudizio per sapere quando non sa qualcosa.

Alla fine, i concetti RAG, RAG Graph e Knowledge Graph che potresti già conoscere non sono più tre sistemi separati: sono tre strumenti all'interno della cassetta degli attrezzi di un agente e saprai esattamente quando l'agente dovrebbe raggiungere e quale. In breve: Un agente di produzione è composto da quattro livelli: memoria/stato, recupero, strumenti e orchestrazione, non un prompt con uno strumento di ricerca allegato. RAG, RAG Graph e Knowledge Graph risiedono tutti all'interno del livello di recupero, selezionati in base alla domanda posta, non adottati all'ingrosso. Le azioni di scrittura necessitano dell'approvazione umana; un esplicito "è stato effettivamente fatto?" il checkpoint impedisce sia l'arresto prematuro che i cicli infiniti; e la preparazione aziendale (residenza dei dati, valutazione, osservabilità, costi) deve essere progettata fin dal primo giorno, non adattata dopo un incidente. Questa guida copre l'architettura completa, uno scheletro di codice funzionante, uno stack open source per ogni livello e un ordine di creazione che evita di aggiungere complessità prima che venga ottenuta.

Ultima revisione: agosto 2026. Questa guida viene mantenuta come riferimento vivente: i principi dell'architettura sono stabili; la sezione dello stack open source (Parte 9) è la parte che con maggiore probabilità necessiterà di aggiornamenti man mano che gli strumenti si evolvono.

Parte 1: Cosa significa realmente "Agente" (e cosa no)

Prima di costruire qualsiasi cosa, vale la pena essere precisi su una parola che viene usata in modo approssimativo.

Un chatbot con un prompt di sistema risponde alle domande. Chiedi, risponde, conversazione finita. Non ha memoria delle decisioni, non ha la capacità di intraprendere azioni in più fasi e non ha modo di verificare se la propria risposta fosse effettivamente giusta.

Un agente fa qualcosa di significativamente diverso: può decidere cosa fare, intraprendere azioni utilizzando strumenti, osservare i risultati di tali azioni e decidere cosa fare dopo in base a ciò che ha appena imparato — in un ciclo, finché l'attività non viene effettivamente completata, non solo finché non viene prodotta una risposta apparentemente plausibile.

Task
  ↓
Think: what does this need?
  ↓
Act: use a tool
  ↓
Observe: what came back?
  ↓
Think again: is this enough?  ──No──→ Act again
  ↓ Yes
Respond
Questo ciclo, spesso chiamato ciclo di ragionamento o, più formalmente, modelli come ReAct (Ragione + Atto) — è la definizione effettiva di un agente. Tutto il resto di questa guida riguarda il rendere il circuito affidabile, sicuro e sufficientemente utile da potersi affidare al lavoro reale.

Perché il "livello aziendale" modifica i requisiti

Il progetto di un agente del fine settimana deve funzionare una volta, per te, in una demo. Un agente aziendale deve:

  • Lavora correttamente su domande mai viste prima, non solo su quelle che hai testato.
  • Fallire in modo sicuro e visibile, invece di produrre con sicurezza una risposta sbagliata.
  • Rispettare i confini dei dati: chi può vedere cosa e dove possono risiedere i dati.
  • Essere debuggabile quando qualcosa va storto, settimane dopo che è andato storto.
  • Gestire la confusione del mondo reale: informazioni incomplete, richieste ambigue, fonti contrastanti.

Ogni sezione seguente si basa specificamente su questi cinque requisiti, non solo su "un agente che risponde".

Parte 2: I quattro livelli di cui ogni vero agente ha bisogno

Eliminando le scelte tecnologiche specifiche, ogni agente di livello produttivo è costituito da quattro strati impilati uno sopra l'altro.

┌─────────────────────────────────────┐
│   4. Orchestration (the workflow)    │
├─────────────────────────────────────┤
│   3. Tools (what it can DO)          │
├─────────────────────────────────────┤
│   2. Retrieval (what it KNOWS)       │
├─────────────────────────────────────┤
│   1. Memory & State (what it        │
│      REMEMBERS)                      │
└─────────────────────────────────────┘
Lo costruiremo dal basso verso l'alto, perché ogni strato dipende da quello sottostante.

Parte 3: Livello 1: memoria e stato

Un agente senza memoria ricalcola tutto da zero in ogni singolo passaggio, il che è lento, costoso e perde traccia di ciò che ha già capito tre passaggi fa. Gli agenti reali portano lo stato.

Due diversi tipi di memoria facili da confondere

La memoria (di lavoro) a breve termine è lo stato del compito corrente: cosa è stato chiesto, cosa è stato provato, cosa è stato trovato finora, cosa manca ancora. Questo vive solo per la durata di un'attività e scompare al termine.

La memoria a lungo termine persiste interamente in sessioni separate: fatti che l'agente dovrebbe ricordare su un utente, un progetto o una relazione con un cliente, giorni o mesi dopo.

A livello di codice, questo viene solitamente implementato come un oggetto stato che viene passato tra ogni passaggio del flusso di lavoro dell'agente e aggiornato man mano che procede:

AgentState:
  original_task: "..."
  steps_taken: [...]
  evidence_gathered: [...]
  tools_called: [...]
  current_confidence: "sufficient" | "insufficient"
Questo oggetto di stato è la spina dorsale a cui si collega tutto il resto. Ogni chiamata allo strumento legge da esso e vi riscrive. Senza di essa, un agente non ha modo di sapere se ha già provato qualcosa o di basarsi su una risposta parziale invece di ricominciare da capo.

Parte 4: Livello 2: recupero (ciò che l'agente sa effettivamente)

È qui che i precedenti approfondimenti su RAG, RAG Graph e Knowledge Graph smettono di essere post di blog separati e iniziano a essere componenti da cui selezioni, in base al tipo di conoscenza a cui il tuo agente deve accedere.

Non tutti gli agenti hanno bisogno di tutti e tre

Questo è l'errore più comune nella progettazione dell'agente: ricorrere all'architettura di recupero più sofisticata disponibile invece di quella richiesta dall'attività effettiva.

Se il tuo agente ha bisogno di...Raggiungi...
Rispondi alle domande da un set di documenti, un passaggio alla voltaRAG semplice
Rispondi a domande composte da più parti o comparative su numerosi documentiUn grafico RAG
Rispondi alle domande sulla relazione ("quale", "quanti", "traccia la connessione")Un Knowledge Graph, chiamato come strumento
Tutto quanto sopra, a seconda della domandaUn grafico RAG che può chiamare sia un archivio vettoriale che un grafico della conoscenza
Approfondimenti collegati: Flusso di lavoro RAG semplice e grafico RAG (scomposizione, convalida delle prove, riprova) → All'interno di un grafico RAG: come i sistemi di intelligenza artificiale imparano a controllare il proprio lavoro · Attraversamento delle relazioni e risoluzione delle entità → Spiegazione dei grafici della conoscenza: come l'AI impara a connettere il Punti · Tassonomia completa → Smetti di confondere RAG, RAG Graph e Knowledge Graph

Il livello di recupero non è "l'agente". È uno degli strumenti dell'agente, quello specificamente responsabile di rispondere "cosa ne so veramente?". Tutto quello che c'è nelle guide precedenti – suddivisione in blocchi, incorporamenti, risoluzione delle entità, convalida delle prove – risiede all'interno di questo livello.

Agent's Retrieval Tool
        ↓
  Question Analysis
        ↓
   ┌────┴────┐
   ↓         ↓
Vector    Knowledge
Search      Graph
   ↓         ↓
   └────┬────┘
        ↓
  Evidence Validation
        ↓
   Grounded Facts
L'intero blocco, ovvero tutto ciò che è stato trattato nelle precedenti guide RAG Graph e Knowledge Graph, è una chiamata a un unico strumento dal punto di vista dell'agente. Non è necessario che l'agente sappia come funziona internamente il recupero; ha solo bisogno di sapere che può porre una domanda a questo strumento e ottenere fatti fondati, o un onesto "prove trovate insufficienti".

Parte 5: Livello 3: strumenti (cosa può effettivamente fare l'agente)

Il recupero risponde alle domande. Gli strumenti eseguono azioni. Un agente aziendale che può solo rispondere alle domande è pur sempre solo una casella di ricerca più intelligente. Il passaggio che lo trasforma in qualcosa che "funziona per te" è dargli la capacità di fare effettivamente cose: inviare un'e-mail, creare un ticket, interrogare un database live, chiamare un'API interna, aggiornare un record.

Progettare strumenti che un agente possa effettivamente utilizzare bene

Ogni strumento necessita di tre cose chiaramente definite, altrimenti l'agente ne farà un uso improprio:

  • Una descrizione precisa di cosa fa esattamente e quando usarlo: descrizioni vaghe fanno sì che un agente chiami lo strumento sbagliato o lo strumento giusto con input sbagliati.
  • Uno schema di input ristretto e ben tipizzato: l'agente non dovrebbe mai dover indovinare quale formato si aspetta uno strumento.
  • Un output prevedibile e strutturato: se uno strumento a volte restituisce testo e a volte restituisce JSON e talvolta fallisce silenziosamente, l'agente non può utilizzare in modo affidabile il suo output nel passaggio successivo.

La distinzione fondamentale: strumenti di lettura vs. strumenti di scrittura

Ciò è estremamente importante per le implementazioni aziendali, in particolare:

  • Gli strumenti di lettura/recupero (ricerca in una knowledge base, ricerca di un record, controllo di uno stato) sono generalmente sicuri per consentire a un agente di chiamare liberamente: nessuna conseguenza nel mondo reale se ne chiama uno inutilmente.
  • Gli strumenti di scrittura/azione (inviare un'e-mail, eliminare un record, approvare una richiesta, spendere denaro) necessitano di un checkpoint con presenza umana prima dell'esecuzione, soprattutto all'inizio della vita di una distribuzione. L'agente propone l'azione; un essere umano lo conferma; solo allora viene eseguito.
    Agent decides: "I should send this email"
↓ Draft prepared, NOT sent ↓ Human reviews ↓ ┌─────┴─────┐ ↓ ↓ Approve Reject ↓ ↓ Sent Agent revises Questa singola scelta progettuale è spesso la differenza tra un team di agenti che realmente si fida della produzione e uno che viene spento dopo il primo errore imbarazzante.

Parte 6: Livello 4: orchestrazione (il flusso di lavoro effettivo)

Questo è lo strato che collega insieme memoria, recupero e strumenti nel ciclo di ragionamento della Parte 1 ed è esattamente la stessa categoria di cose del grafico RAG di prima, applicato solo a un compito più ampio di "rispondere a una domanda". Questo è più comunemente costruito con un framework di flusso di lavoro basato su grafici (LangGraph è la scelta standard qui), perché il comportamento di un agente reale non è una linea retta: si ramifica, si ripete e si rivede in base a ciò che apprende in ogni passaggio.

Task Received
      ↓
Understand & Plan
      ↓
   ┌──┴───────────────┐
   ↓                  ↓
Need info?         Need action?
   ↓                  ↓
Call retrieval     Call a tool
   ↓                  ↓
   └────────┬─────────┘
            ↓
    Evaluate progress
            ↓
   Task actually done?
      /          \
    No            Yes
    ↓              ↓
  Loop back     Respond
### Perché la fase di valutazione non è facoltativa

Proprio come la fase di convalida delle prove in un grafico RAG, un agente aziendale ha bisogno di un punto di controllo esplicito che chieda: l'attività è effettivamente completata o sembra semplicemente finita? Senza questo, gli agenti hanno una modalità di fallimento ben documentata di dichiarare prematuramente il successo, fermandosi dopo un risultato parziale perché nulla li obbliga a controllare il proprio lavoro.

Questo è anche il punto in cui contano i tentativi limitati. Un agente bloccato in un ciclo improduttivo, che chiama per sempre lo stesso strumento con input leggermente diversi, è una modalità di fallimento reale e comune. Ogni ciclo necessita di un numero massimo di iterazioni e di un fallback definito: se l'agente non riesce a completare l'attività dopo N tentativi, dovrebbe dirlo chiaramente, anziché ripetere il ciclo all'infinito o fabbricare un risultato per sfuggire al ciclo.

Come appare dal codice vero e proprio

Il diagramma sopra si mappa direttamente su una macchina a stati LangGraph. Questo è uno scheletro minimo: i veri nodi di produzione chiamerebbero le tue effettive funzioni di recupero e strumento, ma la forma seguente è l'intero modello:

from typing import TypedDict, Literal
from langgraph.graph import StateGraph, END

class AgentState(TypedDict):
    task: str
    steps_taken: list
    evidence: list
    iterations: int
    done: bool

MAX_ITERATIONS = 5

def plan(state: AgentState) -> AgentState:
    # LLM decides: retrieve more info, call a tool, or respond
    ...
    return state

def retrieve(state: AgentState) -> AgentState:
    # Calls the retrieval layer (RAG / RAG Graph / Knowledge Graph tool)
    ...
    return state

def call_tool(state: AgentState) -> AgentState:
    # Write actions pause here for human approval before executing
    ...
    return state

def evaluate(state: AgentState) -> AgentState:
    # The "is this actually done?" checkpoint from above
    state["iterations"] += 1
    ...
    return state

def route_after_evaluate(state: AgentState) -> Literal["plan", "respond"]:
    if state["done"] or state["iterations"] >= MAX_ITERATIONS:
        return "respond"
    return "plan"  # loop back — bounded by MAX_ITERATIONS

graph = StateGraph(AgentState)
graph.add_node("plan", plan)
graph.add_node("retrieve", retrieve)
graph.add_node("call_tool", call_tool)
graph.add_node("evaluate", evaluate)
graph.add_node("respond", lambda s: s)

graph.set_entry_point("plan")
graph.add_edge("plan", "retrieve")
graph.add_edge("plan", "call_tool")
graph.add_edge("retrieve", "evaluate")
graph.add_edge("call_tool", "evaluate")
graph.add_conditional_edges("evaluate", route_after_evaluate, {
    "plan": "plan",
    "respond": "respond",
})
graph.add_edge("respond", END)

agent = graph.compile()
> Link al modello: Questo scheletro di LangGraph rispecchia il flusso di lavoro di RAG Graph (convalida + tentativo limitato): stesso modello grafico, set di strumenti più ampio.

I due dettagli che vale la pena non saltare quando costruisci la versione reale:MAX_ITERATIONSè ciò che trasforma "loop fino al completamento" in "loop fino al completamento, o finché non è onesto riguardo al fatto" - non inviare mai un ciclo senza questo. Ecall_toolè dove appartiene il checkpoint di approvazione umana della Parte 5 per qualsiasi azione di scrittura: in LangGraph questo è tipicamente implementato con un'interruzione che mette in pausa il grafico e attende una conferma esterna prima che il nodo venga completato.

Parte 7: Mettere insieme l'intero agente

Ecco l'architettura completa, tutti e quattro i livelli assemblati in un unico sistema:

                    ┌─────────────────────┐
                    │   Incoming Task      │
                    └──────────┬───────────┘
                               ↓
                    ┌─────────────────────┐
                    │  ORCHESTRATION        │
                    │  (plan, loop, decide)  │
                    └──────────┬───────────┘
                               ↓
              ┌────────────────┼────────────────┐
              ↓                                  ↓
   ┌─────────────────────┐          ┌──────────────────────┐
   │   RETRIEVAL LAYER     │          │      TOOLS LAYER       │
   │  ┌─────┐  ┌────────┐ │          │  Read tools (free)     │
   │  │ RAG │  │Knowledge│ │          │  Write tools (needs    │
   │  │     │  │  Graph  │ │          │  human approval)       │
   │  └─────┘  └────────┘ │          └──────────────────────┘
   └─────────────────────┘
              ↓                                  ↓
              └────────────────┬─────────────────┘
                               ↓
                    ┌─────────────────────┐
                    │  STATE / MEMORY       │
                    │  (tracks everything    │
                    │   across the whole      │
                    │   task)                 │
                    └──────────┬───────────┘
                               ↓
                    ┌─────────────────────┐
                    │  Task complete?        │
                    │  No → loop back         │
                    │  Yes → respond          │
                    └─────────────────────┘
Nota cosa mostra effettivamente questo diagramma: il RAG Graph e il Knowledge Graph delle guide precedenti non rappresentano l'intero sistema: sono una scatola all'interno di una scatola più grande. L'agente è il livello di orchestrazione attorno a loro, che decide quando il recupero è la mossa giusta rispetto a quando invece è necessario intraprendere un'azione.

Parte 8: Le preoccupazioni specifiche dell'azienda che nessuno inserisce nei tutorial

È qui che si fermano la maggior parte dei tutorial sugli agenti e dove la maggior parte delle implementazioni reali vivono o muoiono.

Residenza dei dati e luogo in cui avviene il trattamento

Per i settori regolamentati (legale, sanitario, finanziario) o qualsiasi organizzazione soggetta al GDPR, il dove viene eseguito ogni livello conta tanto quanto il suo funzionamento. Ospitare autonomamente il livello di recupero (eseguendo il tuo modello di incorporamento, il tuo database vettoriale, il tuo modello di estrazione ottimizzato, la tua istanza Neo4j, sull'infrastruttura che controlli) significa che i dati del cliente non lasciano mai i tuoi confini in nessuna fase. Questa è una vera decisione architettonica, non un ripensamento: determina se puoi servire determinati clienti.

Valutazione: come fai a sapere che funziona davvero?

Un agente che "sembra funzionare" nei test casuali e un agente che è stato adeguatamente valutato hanno livelli di affidabilità molto diversi. Un vero e proprio set di valutazione significa:

  • Una raccolta curata di attività realistiche, con risultati noti e corretti, contro cui l'agente viene testato prima di ogni modifica significativa.
  • Il monitoraggio non si limita a "ha ottenuto la risposta giusta" ma "ha identificato correttamente quando non aveva informazioni sufficienti" - un agente che non dice mai "non lo so" non è più capace, è meno onesto.
  • Rieseguire regolarmente questo set di valutazione, non solo una volta all'avvio, poiché piccole modifiche a un prompt o a uno strumento possono interrompere silenziosamente il comportamento altrove.

Osservabilità: cosa succede quando qualcosa va storto alle 2 del mattino

Vedi: Configurazione completa di tracciamento/valutazioni/deriva in LLM Observability in Production — la disciplina che rileva la silenziosa deriva della qualità laddove i dashboard rimangono verdi.

Ogni transizione di stato, ogni chiamata allo strumento, ogni recupero e ogni punto decisionale deve essere registrato in modo che un essere umano possa ricostruirlo a posteriori. Questa è la differenza tra "l'agente ha commesso un errore e possiamo vedere esattamente perché" e "l'agente ha commesso un errore e non abbiamo idea di cosa sia successo". Un registro riproducibile e di sola aggiunta di ogni passaggio intrapreso da un agente in una determinata attività, non solo la risposta finale, non è piacevole da avere su scala aziendale; è ciò che rende il sistema debuggabile.

Costo, al volume di utilizzo reale

Un agente che esegue il loop, riprova e chiama più strumenti per attività può accumulare molte più chiamate LLM per richiesta dell'utente rispetto a un semplice chatbot. Prima di effettuare una distribuzione su vasta scala, misurare effettivamente: quante chiamate LLM richiede un'attività tipica, dall'inizio alla fine? Qual è il costo in base al volume di utilizzo previsto? Questo è lo stesso approccio al throughput e ai costi che conta quando si costruisce la pipeline di estrazione del knowledge graph: conoscere i numeri reali prima di ridimensionare, non dopo.

Parte 9: Lo stack open source, mappato su ogni livello

Tutto sopra è architettura. Questa sezione è la vera cassetta degli attrezzi: opzioni open source reali e auto-ospitabili per ciascuno dei quattro livelli, quindi smette di essere teorica.

Livello di orchestrazione

LangGraph è la scelta standard esattamente per il flusso di lavoro con ramificazione, loop e stato descritto nella Parte 6: è un framework di orchestrazione basato su grafici creato appositamente per questo modello, non un wrapper di agenti generale. Alternative che vale la pena conoscere: CrewAI (team multiagente basati sui ruoli, più veloce nella prototipazione, controllo meno dettagliato sulla logica di ramificazione) e AutoGen (framework di conversazione multiagente di Microsoft). Per la maggior parte dei flussi di lavoro aziendali a singolo agente con ramificazione reale e logica di ripetizione, LangGraph rimane la soluzione più diretta.

Livello di recupero: ricerca vettoriale

Per la ricerca vettoriale self-hosted, Qdrant è un punto di partenza efficiente dal punto di vista operativo per distribuzioni self-hosted a nodo singolo: un singolo binario, bassa latenza delle query e un'API pulita, motivo per cui viene visualizzato ripetutamente in distribuzioni sensibili alla conformità in cui gli incorporamenti vengono generati all'interno di un perimetro sicuro con un'interfaccia distribuita localmente. modello in modo che nessun dato lasci l'edificio in nessuna fase. Weaviate è l'alternativa più efficace se desideri moduli di ricerca ibrida e riclassificazione integrati nel database stesso anziché come servizi separati, e Milvus vale la pena considerare specificamente su scala di miliardi di vettori. Se stai già utilizzando PostgreSQL, pgvettoriale mantiene gli incorporamenti nello stesso database del resto dei tuoi dati, scambiando alcune prestazioni grezze con coerenza transazionale e un sistema in meno da gestire.

Per gli incorporamenti, modelli self-hostable come BGE-M3 o nomic-embed-text vengono eseguiti localmente tramite Ollama o sentence-transformers, evitando qualsiasi costo API per chiamata o dati che lasciano la tua infrastruttura, direttamente rilevante se la residenza dei dati è un requisito difficile.

Per il riclassificazione, BGE-reranker (pesi aperti, auto-ospitabile) è la scelta standard del codificatore incrociato open source; Cohere Rerank è l'opzione gestita equivalente se l'hosting autonomo non è un requisito.

Livello di recupero: costruzione del grafico della conoscenza

È qui che gli utensili sono maturati più velocemente. Alcune opzioni veramente diverse, non solo marchi concorrenti della stessa idea:

  • Ecosistema GraphRAG di Neo4j (il neo4j-graphrag-python pacchetto più LLM Knowledge Graph Builder) è il percorso proprietario se sei già impegnato con Neo4j come database grafico: gestisce la suddivisione in blocchi, l'estrazione di entità/relazioni e il caricamento in un'unica pipeline, con un'interfaccia utente di riferimento per visualizzare ciò che è stato estratto.
  • LightRAG è un'alternativa più leggera che suddivide in blocchi i documenti, utilizza un LLM per estrarre entità e relazioni, costruisce il grafico e combina automaticamente l'attraversamento del grafico con il recupero dei vettori. In particolare nel tuo caso, supporta modelli open source per ogni passaggio, quindi l'estrazione può essere eseguita interamente sull'infrastruttura locale per mantenere i dati sensibili in sede e da marzo 2026 supporta Neo4j, MongoDB, PostgreSQL e OpenSearch come backend di archiviazione.
  • Microsoft GraphRAG è l'opzione più pesante e più radicata a livello accademico: più efficace nel produrre riepiloghi a livello di comunità su grafici di grandi dimensioni, ma deve raggruppare nuovamente l'intero grafico quando arrivano nuovi dati, il che è importante se si eseguono frequenti aggiornamenti incrementali anziché ricostruzioni periodiche complete.

Nello specifico, per quanto riguarda la qualità di estrazione: benchmark indipendenti su ragionamenti specifici del dominio hanno riscontrato una reale diffusione dei costi di costruzione e della qualità tra questi strumenti: LightRAG e GraphRAG hanno entrambi mostrato costi simbolici elevati per la costruzione di grafici rispetto a metodi come HippoRAG o G-Retriever, quindi vale la pena sperimentare un campione reale dei tuoi documenti prima di impegnarsi in uno su larga scala, esattamente come trattato nella Parte 3 della guida al Knowledge Graph.

Strato di memoria

Questa categoria è stata effettivamente suddivisa in strumenti distinti a seconda di ciò che "memoria" deve significare per il tuo agente: vale la pena non scegliere quello di cui si parla di più, poiché risolvono problemi diversi:

  • LangMem è la prima scelta naturale se la tua orchestrazione è già LangGraph: l'integrazione è un SDK di prima parte anziché un plug-in di terze parti, quindi non aggiunge alcuna nuova infrastruttura o relazione con il fornitore. Il suo compromesso è un vero e proprio vincolo dell’ecosistema e un set di funzionalità più ristretto rispetto alle opzioni autonome di seguito.
  • Mem0 è l'opzione standalone più ampiamente adottata, che combina archiviazione di vettori, grafici e valori-chiave con l'estrazione automatica della memoria: un'impostazione predefinita ragionevole per scopi generali se si desidera che un agente ricordi le preferenze e i fatti dell'utente attraverso le sessioni senza un ragionamento temporale approfondito.
  • Graphiti (creato dal team Zep) è la scelta giusta in particolare quando i fatti cambiano davvero nel tempo e la storia conta: ogni bordo ha un intervallo di validità, quindi gestisce correttamente fatti come il ruolo di una persona che cambia da un'azienda all'altra nel tempo. Questa è una capacità significativamente diversa dalle altre opzioni, non solo una variante della stessa cosa.
  • Cognee si posiziona come un motore di memoria più modulare e nativo per i grafici: pipeline componibili per l'acquisizione e l'interrogazione della memoria, con supporto per più backend grafici. Vale la pena valutarlo se si desidera un maggiore controllo dell'architettura su come è strutturata la memoria anziché uno schema fisso.
  • Letta (in precedenza MemGPT) è la soluzione più efficace per gli agenti a lunga esecuzione che necessitano di un tiering esplicito della memoria in stile sistema operativo: decidere cosa rimanere nel contesto attivo rispetto a cosa viene spostato nell'archiviazione a lungo termine, anziché trattare la memoria come un archivio piatto.

Per la tua situazione specifica - self-hosted, orientato al GDPR, già nativo di LangGraph - il punto di partenza pratico è LangMem per la memoria a breve termine/di lavoro (poiché è già nativo per il tuo livello di orchestrazione) più Graphiti o Cognee per la memoria a lungo termine se i casi d'uso dei tuoi clienti coinvolgono fatti che cambiano nel tempo (modifiche contrattuali, aggiornamenti dello stato dei casi, evoluzione delle relazioni con i clienti) — entrambi sono completamente open source e ospitabili autonomamente senza che sia richiesta alcuna dipendenza dal cloud.

Un onesto avvertimento prima di scegliere qualsiasi cosa

Alcuni framework sono open-core con funzionalità avanzate, in particolare funzionalità di knowledge graph, protette da livelli a pagamento, quindi verifica cosa è effettivamente incluso nella licenza con cui intendi eseguire l'hosting autonomo prima di affidare decisioni sull'architettura a uno strumento specifico. Si tratta di un controllo di cinque minuti che salva una ricostruzione successiva.

Parte 10: Un ordine di costruzione realistico

Ecco l'ordine che funziona davvero: passare da un prototipo funzionante a qualcosa di pronto per l'azienda, senza creare troppo presto complessità inutili.

1. Inizia con un unico strumento e senza loop. Solo recupero, semplice RAG, risposta a domande dai documenti. Ottieni questo veramente affidabile prima di aggiungere qualsiasi altra cosa. 2. Aggiungi il ciclo di ragionamento, ma mantienilo negli strumenti di sola lettura. Lascia che sia l'agente a decidere quando recuperare e se ne ha abbastanza: questo è il modello RAG Graph di prima e vale la pena padroneggiarlo da solo prima di aggiungere strumenti di azione. 3. Aggiungi un grafico della conoscenza come strumento di recupero (Neo4j + GraphRAG / LightRAG), solo dopo aver osservato domande reali a cui il semplice recupero strutturalmente non può rispondere - vedi costruisci il progetto in Spiegazione dei grafici della conoscenza - domande sulle relazioni, non solo di ricerca. 4. Aggiungi strumenti di scrittura/azione, controllati dietro l'approvazione umana. Non lasciare che l'agente intraprenda azioni consequenziali in modo autonomo finché non avrai costruito una vera fiducia nel suo giudizio nelle fasi precedenti. 5. Aggiungi valutazione e osservabilità prima di ridimensionare l'utilizzo, non dopo che qualcosa è andato storto. Questa è la fase che la maggior parte dei team salta e quella che determina se i problemi vengono rilevati in anticipo o scoperti da un cliente arrabbiato. 6. Solo allora considerare la piena autonomia per le azioni di scrittura, e solo per le specifiche e ristrette categorie di azioni in cui il costo di un errore è veramente basso.

Parte 11: elenco di controllo pre-lancio

Una lista di controllo pratica e condensata: usala per controllare un agente prima che venga presentato agli utenti reali, non solo come riepilogo della lettura.

Architettura

  • [ ] Ogni strumento ha una descrizione precisa, uno schema di input tipizzato ristretto e un output strutturato prevedibile.
  • [ ] Gli strumenti di lettura e di scrittura sono esplicitamente separati nel codice, non solo nella documentazione.
  • [ ] Ogni strumento di scrittura/azione richiede l'approvazione umana prima dell'esecuzione.
  • [ ] Il ciclo di orchestrazione ha un numero massimo di iterazioni con una risposta di fallback definita e onesta.
  • [ ] Esiste un esplicito "questo compito è effettivamente completo?" nodo: l'agente non considera mai "prodotto un output" come equivalente a "risolto l'attività".

Recupero

  • [ ] Hai confermato quali strumenti di recupero (ricerca vettoriale, grafico della conoscenza o entrambi) soddisfano effettivamente le domande reali dei tuoi utenti, in base all'utilizzo osservato, non alle ipotesi.
  • [] La validazione delle prove esiste come un passo distinto prima della generazione; l'agente può dire "informazioni insufficienti" invece di rispondere sempre.
  • [ ] Se si utilizza un grafico della conoscenza, la risoluzione delle entità è stata testata su un campione reale dei dati, non solo sulla fase di estrazione.

Preparazione aziendale

  • [ ] Sai esattamente dove risiedono i dati di ogni livello e se ciò soddisfa i tuoi effettivi requisiti di conformità (non solo "conformità ai suoni self-hosted").
  • [ ] Esiste un vero e proprio set di valutazione - compiti realistici con risultati noti e corretti - e viene rieseguito prima che ogni modifica significativa venga spedita.
  • [ ] Ogni transizione di stato, chiamata di strumento e recupero viene registrato in un modo che un essere umano può ricostruire dopo il fatto, settimane dopo.
  • [ ] Hai misurato le chiamate LLM reali per attività e previsto il costo effettivo in base al volume di utilizzo previsto, senza stimarlo.
  • [ ] Le licenze sono state controllate per ogni framework nel tuo stack, in particolare per gli strumenti di memoria e grafici in cui le funzionalità avanzate sono talvolta protette da paywall anche nei progetti "open source".

Glossario

Agente: un sistema che decide cosa fare, intraprende azioni tramite strumenti, osserva i risultati e decide cosa fare successivamente in un ciclo, anziché produrre una risposta a un input.

Livello di orchestrazione: la logica del flusso di lavoro (comunemente incorporata in LangGraph) che governa la ramificazione, il looping e i nuovi tentativi nell'attività di un agente.

Livello di recupero: la parte di un agente responsabile della risposta "cosa so realmente a riguardo?", tipicamente composta da RAG, un grafico RAG e/o un grafico della conoscenza.

RAG (Retrieval-Augmented Generation) — Recuperare testo rilevante tramite la ricerca per similarità e consegnarlo a un modello linguistico da cui rispondere, in un unico passaggio lineare.

RAG Graph: un livello di flusso di lavoro LangGraph avvolto attorno ai componenti di RAG che aggiunge scomposizione, recupero parallelo, convalida delle prove e nuovi tentativi, migliorando l'affidabilità su domande composte da più parti senza migliorare gli incorporamenti, la riclassificazione o la generazione sottostanti.

Grafico della conoscenza: un archivio dati Neo4j di entità (nodi) e relazioni esplicite tipizzate (bordi) tra di loro, interrogate per attraversamento anziché per somiglianza.

Risoluzione dell'entità: il processo di riconoscimento che menzioni diverse ("Caso A", "Caso n. A-2019") si riferiscono alla stessa entità del mondo reale, quindi i fatti su di essa provenienti da documenti diversi si collegano in un nodo invece di rimanere disconnessi.

Convalida delle prove: un punto di controllo esplicito che giudica se le informazioni recuperate sono effettivamente sufficienti per rispondere a una domanda, prima che la generazione proceda.

Human-in-the-loop: un modello di progettazione in cui un agente propone un'azione ma un essere umano deve approvarla prima che venga eseguita, utilizzato per qualsiasi azione con conseguenze nel mondo reale.

Memoria di lavoro (a breve termine) — Stato che persiste solo per la durata di un compito: cosa è stato provato, cosa è stato trovato, cosa manca ancora.

Memoria a lungo termine: stato che persiste in sessioni separate: fatti relativi a un utente, progetto o relazione ricordati giorni o mesi dopo.

Fonti e ulteriori letture

Questa guida si basa sulla documentazione attuale degli strumenti e su benchmark indipendenti aggiornati ad agosto 2026:

  • Panoramica su LightRAG — RAG leggero basato su grafici con supporto di modelli open source in tutta la sua pipeline
  • GraphRAG-Bench — benchmark che confronta i costi e la qualità della costruzione di grafici con GraphRAG, LightRAG, HippoRAG e altri metodi

Articoli complementari a questa serie: Smetti di confondere RAG, RAG Graph e Knowledge Graph (confronto di architetture), All'interno di un grafico RAG: come i sistemi di intelligenza artificiale imparano a controllare il proprio lavoro e Spiegazione dei grafici della conoscenza: come l'intelligenza artificiale impara a connettere il Punti.

Punti chiave

  • Un agente è definito da un ciclo (pensa, agisci, osserva, decidi di nuovo) e non da un LLM che risponde alle domande con un prompt del sistema.
  • Ogni agente reale è costituito da quattro livelli: memoria/stato, recupero, strumenti e orchestrazione — e i concetti RAG, RAG Graph e Knowledge Graph risiedono tutti all'interno del livello di recupero, non come l'intero sistema.
  • Gli strumenti di lettura possono generalmente essere richiamati liberamente; gli strumenti di scrittura che agiscono nel mondo reale necessitano di un punto di controllo umano nel ciclo, soprattutto nelle prime fasi della distribuzione.
  • Un esplicito "questo compito è stato effettivamente svolto?" checkpoint, con tentativi limitati, è ciò che impedisce a un agente di uscire troppo presto o di eseguire un ciclo continuo.
  • La predisposizione aziendale non è una funzionalità che si aggiunge alla fine: la residenza, la valutazione, l'osservabilità e i costi dei dati devono essere progettati fin dall'inizio, non fissati dopo che qualcosa si rompe.
  • Costruisci in ordine: prima il recupero, poi il ciclo di ragionamento, poi il grafico della conoscenza se hai effettivamente bisogno di query sulle relazioni, poi le azioni delimitate, quindi la valutazione e l'osservabilità - prima, non dopo, il ridimensionamento dell'utilizzo.

Vuoi implementare questo nella tua organizzazione?

Aiutiamo i team a distribuire sistemi di IA pronti per la produzione. Condividi i tuoi requisiti e discuteremo del miglior approccio per il tuo caso d'uso.

Discuti il tuo Progetto

Articoli correlati

Continua a leggere

EngineeringKnowledge Graph: come l'AI collega i punti14 minEngineeringRAG Graph: come l'AI verifica il proprio lavoro13 minEngineeringRAG vs. Graph-RAG vs. Knowledge Graph12 min
FAQ

Domande frequenti

Risposte rapide alle domande frequenti su questo argomento.

Cosa distingue effettivamente un agente AI da un chatbot con un prompt di sistema?

Un chatbot risponde a una domanda per turno. Un agente esegue un ciclo di ragionamento: Pensa (di cosa ha bisogno?) -> Agisci tramite strumenti -> Osserva i risultati -> Decidi di nuovo - finché l'attività non viene effettivamente completata, non solo finché non viene prodotto del testo. Ogni agente affidabile necessita di memoria/stato, recupero, strumenti e orchestrazione (in genere LangGraph), non solo di un prompt + uno strumento di ricerca. Consulta i nostri approfondimenti sul grafico RAG e sul Knowledge Graph per sapere come si adatta il livello di recupero.

Quali sono i 4 livelli di cui ogni agente aziendale ha bisogno?

1) Memoria e stato: AgentState tiene traccia dell'attività, dei passaggi, delle prove, della fiducia nell'attività e, facoltativamente, della memoria a lungo termine. 2) Recupero: cosa sa: RAG semplice per le ricerche, RAG Graph (LangGraph: decompose + validate + retry) per più parti, Knowledge Graph (Neo4j) per domande sulle relazioni. 3) Strumenti: schemi tipizzati stretti; gli strumenti di lettura sono gratuiti, gli strumenti di scrittura necessitano dell'approvazione di persone coinvolte nel ciclo. 4) Orchestrazione: grafico di stato LangGraph con MAX_ITERAZIONI limitate + viene effettivamente eseguito? punto di controllo. Tutte le prime guide vivono all'interno del livello 2.

Quando un agente utilizza RAG rispetto a RAG Graph rispetto a Knowledge Graph?

Percorso per domanda: ricerca a passaggio singolo -> RAG semplice (Qdrant/Weaviate/pgvector + BGE-M3 + reranker). Multiparte/comparativo tra molti documenti -> Grafico RAG (scomposizione LangGraph, recupero parallelo, convalida delle prove, nuovo tentativo) - vedere All'interno di un grafico RAG. Domande sulle relazioni (quali/quanti/traccia) -> Traversamento del Knowledge Graph (Neo4j/Cypher, la risoluzione delle entità è la parte difficile) — vedere Spiegazione dei Knowledge Graph. Misto -> RAG Grafico che chiama sia vettore + grafico in parallelo. Non adottarli tutti e tre all'ingrosso.

Perché ogni agente ha bisogno che questa operazione venga effettivamente eseguita? checkpoint e MAX_ITERAZIONI?

Senza una fase di valutazione esplicita, gli agenti si fermano presto in caso di risultati parziali o eseguono un ciclo continuo richiamando lo stesso strumento con lievi variazioni: due principali errori di produzione. Il punto di controllo si chiede: il compito è sostanzialmente completo o semplicemente plausibile? MAX_ITERAZIONI (ad esempio, 5) trasforma il ciclo fino al completamento nel ciclo fino al completamento o al fallimento onesto, prevenendo cicli infiniti e forzando prove insufficienti invece di allucinazioni. LangGraph lo implementa come vantaggio condizionale dopo la valutazione.

Quale stack open source costruisce ogni livello nel 2026 (con GitHub)?

Orchestrazione: LangGraph (github.com/langchain-ai/langgraph), alternative CrewAI (crewAIInc/crewAI), AutoGen (microsoft/autogen). Ricerca vettoriale: Qdrant (qdrant/qdrant), Weaviate (weaviate/weaviate), Milvus (milvus-io/milvus), pgvettori (pgvettori/pgvettori). Incorporamenti: BGE-M3 (FlagOpen/FlagEmbedding) tramite Ollama/sentence-transformers; riclassificazione Riclassificazione BGE. Grafico della conoscenza: Neo4j + neo4j-graphrag-python, LightRAG (HKUDS/LightRAG), Microsoft GraphRAG (microsoft/graphrag). Memoria: LangMem (langchain-ai/langmem), Mem0 (mem0ai/mem0), Graphiti (getzep/graphiti), Cognee (topoteretes/cognee), Letta (letta-ai/letta). Tutti i collegamenti nella parte 9.

Come impedisci ai dati dei clienti di uscire dai tuoi confini (GDPR, residenza dei dati)?

Ospita autonomamente il livello di recupero: il tuo modello di incorporamento (BGE-M3 localmente), il tuo DB vettoriale (Qdrant), la tua estrazione (LightRAG/GraphRAG con LLM locali), il tuo Neo4j — sull'infrastruttura che controlli. Il luogo in cui viene eseguito ogni livello è una decisione relativa all'architettura, non un ripensamento. I nostri DB vettoriali vengono scelti perché gli incorporamenti vengono generati all'interno del perimetro sicuro, quindi nessun dato lascia l'edificio in nessuna fase. Verifica le licenze: alcuni framework di memoria/grafico sono open-core con livelli a pagamento.

Qual è l'ordine di costruzione realistico che evita un'ingegneria eccessiva?

1) Strumento singolo + nessun ciclo: semplice risposta RAG dai documenti. 2) Aggiungi un ciclo di ragionamento (strumenti di sola lettura): il modello del grafico RAG. 3) Aggiungi il grafico della conoscenza solo quando i registri mostrano che le domande sulle relazioni non sono riuscite. 4) Aggiungi strumenti di scrittura controllati dall'approvazione umana. 5) Aggiungi valutazione (attività d'oro + metrica non so) e osservabilità (log rigiocabile di sola aggiunta) prima del ridimensionamento. 6) Solo allora considerare l'autonomia per azioni di scrittura a basso rischio. Questo ordine è la Parte 10 della guida.

Come valuti e osservi un agente aziendale prima di ridimensionarlo?

Valutazione: attività curate con risultati noti e corretti, traccia non solo della correttezza ma dell'onestà (ha detto prove insufficienti quando appropriato), rieseguite prima di ogni modifica. Osservabilità: registra ogni transizione di stato, chiamata allo strumento, recupero e decisione, riproducibile settimane dopo. Costo: misura le chiamate LLM per attività end-to-end al volume previsto. Consulta Osservabilità LLM in produzione per la configurazione di tracciamento/valutazioni/deriva che rileva la mancata risposta silenziosa dei dashboard a metà risposta.

Next

Continue exploring

Cosa facciamo?

Leggi di più

Come lavoriamo?

Leggi di più

Partner

Leggi di più