Architettura dell'Assistente AI: LLM, Memoria, Strumenti, Routing, Osservabilità

Un assistente AI in produzione non è “un LLM con un prompt”. È un sistema che accetta l’intento, mantiene lo stato, decide quando recuperare informazioni o agire ed espone sufficienti dettagli di runtime per eseguire il debug delle anomalie.

Questa visione a livello di sistema è ciò che il cluster AI Systems esplora quando gli assistenti vanno oltre una singola invocazione del modello.

OpenAI descrive gli agenti come applicazioni che pianificano, chiamano strumenti, collaborano e mantengono uno stato sufficiente per lavori multi-step, mentre Anthropic inquadra lo stesso problema come un’infrastruttura gestita che può eseguire file, comandi, accesso web e codice in modo sicuro.

L’architettura più pulita divide le responsabilità in cinque livelli: LLM, Memoria, Strumentazione (Tooling), Instradamento (Routing) e Osservabilità. Questa divisione corrisponde alle funzionalità esposte dalle API principali dei provider, da MCP, da runtime self-hosted come vLLM e llama.cpp e da veri sistemi assistenti come OpenClaw ed Hermes.

La memoria dovrebbe essere trattata come qualcosa di più del “contesto più lungo”. I sistemi di recupero trasformano la conoscenza esterna in memoria non parametrica esplicita — lo stesso spazio progettuale approfondito da Retrieval-Augmented Generation (RAG) — e sia le linee guida sul contesto di Anthropic che il paper “Lost in the Middle” avvertono che il semplice accumulare più token nel contesto non garantisce un recupero affidabile.

L’uso degli strumenti è un confine contrattuale, non magia. Le chiamate di funzione di OpenAI, l’uso degli strumenti di Anthropic e MCP si basano tutti sullo stesso pattern: il modello emette una richiesta strutturata, un runtime la esegue e il risultato fluisce di nuovo nella conversazione. Se quel confine è sciolto, l’assistente diventa impreciso.

Il mio pregiudizio è semplice: inizia con qualcosa di noioso. Un orchestratore, un percorso di memoria durevole, un trace per richiesta e una politica esplicita per l’esecuzione degli strumenti. I grafi multi-agente sono utili, ma solo dopo che puoi spiegare i casi di fallimento del tuo singolo agente senza indovinare.

Cos’è un sistema di assistente AI

Una definizione pratica è questa: un sistema di assistente AI è un runtime che trasforma l’intento dell’utente in una risposta o azione combinando un’interfaccia del modello, l’assemblaggio del contesto, l’esecuzione degli strumenti, la gestione dello stato e la telemetria. Ecco perché i documenti utili non sono solo le schede del modello. I documenti utili sono i riferimenti API, i contratti degli strumenti, le guide al recupero, i documenti di instradamento e i documenti di tracciamento. L’API Responses di OpenAI espone interazioni con stato, strumenti integrati e chiamate di funzione. L’API Claude di Anthropic espone l’accesso diretto ai Messaggi oltre agli Agenti Gestiti. OpenClaw ed Hermes vanno un passo oltre e mostrano cosa succede quando si mettono quelle capacità dietro gateway persistenti, canali, sessioni e memoria.

In altre parole, un sistema assistente ha un contratto più ampio di un completamento della chat. Un buon contratto interno assomiglia a questo:

AssistantRequest  = intento utente + identità + sessione + allegati + politica
AssistantResponse = risposta + azioni + citazioni + cambiamenti di stato + ID trace

Questo contratto è importante perché ogni disaccordo in produzione si riduce eventualmente a una di queste domande: quale contesto era visibile, quale strumento è stato eseguito, quale modello ha risposto, quale memoria è stata letta o scritta e dove il trace dice che il sistema ha speso tempo. OpenTelemetry definisce i trace come il percorso di una richiesta attraverso un’applicazione, che è esattamente l’astrazione di cui hanno bisogno gli assistenti seri. LangSmith e OpenLIT specializzano poi quell’idea per LLM, strumenti, archivi vettoriali e flussi di lavoro degli agenti.

Componenti principali e interfacce

La divisione dei componenti qui sotto è quella che trovo più durevole. È anche la divisione che si allinea meglio con le API ufficiali e i runtime open source che le persone operano realmente.

La tabella sopra è derivata dalle interfacce ufficiali dei provider, MCP, documenti dei database vettoriali e documenti runtime per vLLM, llama.cpp, OpenClaw ed Hermes.

Il livello LLM dovrebbe fare bene tre cose: consumare un contesto di lavoro corrente, emettere una risposta finale o una richiesta di azione strutturata e restituire metadati sufficienti per supportare i retry e il tracciamento. L’API Responses di OpenAI è esplicitamente progettata per interazioni con stato più strumenti integrati e chiamate di funzione. L’API Messages di Anthropic espone lo stesso ciclo principale attraverso blocchi tool_use e restituzioni tool_result, mentre Managed Agents ti offre un’infrastruttura ospitata se non vuoi costruire il ciclo tu stesso. I runtime self-hosted come vLLM e llama.cpp sono importanti perché preservano interfacce simili a quelle dei provider permettendoti di posizionare l’inferenza all’interno del tuo ambiente.

Il livello Memoria dovrebbe essere diviso mentalmente in tre categorie: memoria di lavoro, memoria simbolica durevole e memoria semantica ricercabile. Gli embedding di OpenAI restituiscono vettori che possono essere indicizzati e cercati; OpenAI Retrieval e File Search stratificano poi la ricerca semantica e per parole chiave sugli archivi vettoriali. Pinecone, Weaviate, pgvector e Milvus rappresentano quattro forme di archiviazione comuni: completamente gestita, vector-native open source, Postgres-native e database vettoriale distribuito. Hermes ed OpenClaw aggiungono un utile promemoria che non tutta la memoria appartiene a un archivio vettoriale: le note supportate da file, le promozioni revisionate e gli snapshot con ambito di sessione sono spesso il design più onesto. Sistemi di Memoria negli Assistenti AI mappa il modello cross-framework; Sistema di Memoria dell’Agente Hermes analizza la memoria centrale limitata e gli snapshot di sessione congelati in un prodotto.

Il livello Strumentazione è dove un assistente smette di essere un riassumitore e inizia a essere software. Le chiamate di funzione di OpenAI trattano gli strumenti come funzionalità definite da schema che il modello può decidere di invocare. Anthropic dice la stessa cosa in modo più esplicito: l’uso degli strumenti è un contratto tra la tua applicazione e il modello, e il modello non esegue mai nulla da solo. MCP generalizza quel contratto in un protocollo client-server dove gli host si connettono a uno o più server che espongono strumenti, prompt e risorse — lo stesso confine descritto passo dopo passo in Server MCP in Go. LangChain e LlamaIndex si inseriscono comodamente qui come librerie di orchestrazione: LangChain si concentra su un’architettura agente predefinita e integrazioni, mentre LlamaIndex si concentra sull’accesso ai dati aumentati dal contesto, motori di query e flussi di lavoro.

Il livello Instradamento esiste perché “quale modello?” non è mai l’unica domanda. Hai anche bisogno di “quale percorso provider, quale tenant, quale budget, quale classe di latenza e quale fallback?”. LiteLLM è utile perché i suoi documenti ufficiali sono sorprendentemente concreti: scelta ponderata, meno impegnato, instradamento basato sulla latenza, basato sui costi e failover limitati sono tutti pattern di primo livello. OpenClaw estende l’instradamento verso l’alto nell’isolamento dei canali e degli agenti, mentre Hermes lo estende verso il basso negli slot del modello per il lavoro principale e ausiliario come la riassumizione, la compressione del contesto e l’instradamento degli strumenti MCP. Questo è il modello mentale corretto: il router sceglie più di un modello, sceglie una corsia di esecuzione.

Il livello Osservabilità è ciò che impedisce all’architettura di trasformarsi in folklore. OpenTelemetry ti dà l’astrazione del trace. LangSmith ti dà visibilità end-to-end sui passaggi dell’applicazione LLM e supporta forme di distribuzione cloud, ibride e self-hosted. OpenLIT ti dà osservabilità AI nativa OpenTelemetry con opzioni di strumentazione zero-code e manuale, incluso supporto per LLM, framework agent, database vettoriali e GPU. Per metriche di produzione, trace e pattern SLO attraverso inferenza e flussi di lavoro degli agenti, vedi Osservabilità per Sistemi LLM. Se il tuo assistente non ha un trace per richiesta, uno span per chiamata al modello e una cronologia eventi per l’esecuzione degli strumenti, non hai davvero un’architettura. Hai delle vibrazioni.

Catturare, arricchire, rispondere

La sequenza che continua a comparire nei sistemi reali è catturare -> arricchire -> rispondere -> registrare. Framework diversi la avvolgono in modo diverso, ma il flusso è abbastanza stabile da trattarlo come la spina dorsale.

Il passaggio di cattura è solitamente più importante di quanto appaia. Sia OpenClaw che Hermes mettono un gateway persistente davanti all’assistente perché l’ingress non è solo inserimento di testo. Include metadati del canale, identità, autorizzazione, confini della sessione, messaggi diretti, gruppi, tick cron e semantiche di consegna. Se salti quel livello e ti affidi a un’astrazione di widget di chat grezza, alla fine lo aggiornerai comunque come middleware ad hoc.

Il passaggio di arricchimento è dove i sistemi maturi divergono dalle demo giocattolo. OpenAI Retrieval e File Search rendono il recupero esplicito attraverso archivi vettoriali e chiamate di ricerca. LlamaIndex formalizza lo stesso pattern attraverso connettori di dati, indici, motori di query e flussi di lavoro. Hermes va oltre dividendo il parco modelli in slot principali e ausiliari, scaricando lavori come compressione, riassumizione e instradamento su modelli più piccoli o specializzati. Questo è un pattern di design da rubare: non spendere i token del modello più costoso per faccende domestiche.

Il passaggio di risposta non è “generare testo”. È “chiudere il ciclo corrente”. Se il modello può rispondere direttamente, lo fa. Se ha bisogno di uno strumento, emette una richiesta strutturata. Il contratto di uso degli strumenti di Anthropic e la guida alle chiamate di funzione di OpenAI rendono questo esplicito. Il motivo per cui questo è importante architetturalmente è che gli output ora includono sia linguaggio che flusso di controllo. Il tuo oggetto risposta è in parte prosa e in parte piano di runtime.

Il passaggio di registrazione è dove appaiono le semantiche di coerenza. Pinecone separa i percorsi di scrittura e lettura e elabora le scritture dopo l’acknowledgement durevole. La memoria di Hermes viene iniettata come uno snapshot congelato per sessione in modo da preservare le prestazioni della cache di prefisso, il che significa che le nuove scritture non appaiono automaticamente nel prompt della sessione corrente. Il sistema Dreaming di OpenClaw promuove solo candidati revisionati e radicati in MEMORY.md, ed è opzionale piuttosto che sempre attivo. La lezione pratica è che la memoria raramente è davvero read-after-write attraverso ogni livello. Devi progettare per una visibilità a fasi.

OpenClaw ed Hermes come sistemi di riferimento

OpenClaw ed Hermes sono casi di riferimento utili perché non sono solo wrapper intorno a un’API del provider. Entrambi presentano un assistente come un sistema a lunga esecuzione con gateway, sessioni, strumenti, memoria e più backend di modello.

Questa mappatura si basa sui documenti e repository ufficiali di OpenClaw ed Hermes. OpenClaw documenta un’architettura gateway, instradamento multi-agente, supporto per provider personalizzati e self-hosted inclusi vLLM e Ollama, memoria attiva opzionale e promozione basata su Dreaming. Hermes documenta un gateway di messaggizzazione, un loop centrale AIAgent, slot modello principali e ausiliari, memoria integrata e integrazione MCP nativa.

La mia lettura leggermente opinionata è che entrambi i sistemi fanno lo stesso argomento architetturale con accenti diversi. OpenClaw è fortemente gateway-first. Hermes è fortemente agent-loop-first. Ma entrambi rifiutano l’idea superficiale che un assistente sia solo “prompt più modello”. Modellano canali, identità, semantiche di memoria, superfici degli strumenti e eterogeneità dei backend come preoccupazioni di primo livello. Questo è esattamente ciò che un’architettura di produzione dovrebbe fare.

Uno stack ibrido pratico ispirato da entrambi i sistemi assomiglia a questo:

edge:
  gateway: hermes o openclaw

routing:
  proxy: litellm
  policy: consapevole di latenza e budget
  tenancy: con ambito sessione e canale

llm:
  primary: openai responses o anthropic messages
  local_fallback: vllm
  local_dev: ollama o llama.cpp

memory:
  session: sqlite o postgres
  semantic: pgvector o weaviate
  embeddings: openai embeddings o ollama embeddings

tools:
  contract: strumenti json schema più mcp
  examples: filesystem, browser, ricerca web, API interne

observability:
  traces: opentelemetry
  ai_dashboards: openlit o langsmith
  evals: openai evals più set di regressione specifici dell'app

Questo stack è un pattern di distribuzione ragionata piuttosto che una blueprint prescritta dal vendor. Funziona perché le interfacce ufficiali si allineano: OpenAI e Anthropic espone API orientate agli strumenti, vLLM e llama.cpp emulano endpoint stile provider, Ollama gestisce modelli ed embedding locali, MCP standardizza gli strumenti esterni, LiteLLM gestisce l’instradamento e il failover, e le piattaforme compatibili con OpenTelemetry possono tracciare l’intero percorso.

Pattern, tabelle e compromessi

Ci sono alcuni pattern di assistente ripetibili che vale la pena nominare. Un assistente gestito mantiene la maggior parte del runtime all’interno delle API del provider. Un assistente retrieval-first tratta memoria e ricerca come il principale differenziale. Un assistente tool-first si comporta più come un operatore che come un chatbot. Un assistente gateway dà priorità all’accesso sempre attivo attraverso superfici di messaggizzazione. Una mesh di specialisti decompone il lavoro in più agenti o rotte. I documenti ufficiali di OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw ed Hermes supportano tutte versioni di questi pattern, anche se le nominano diversamente.

Il pattern mesh di specialisti cresce in una disciplina ingegneristica distinta man mano che il numero di agenti aumenta. Per i sei pattern di coordinazione canonici — orchestrator-worker, pipeline sequenziale, fan-out, gerarchico, swarm e mesh — con modalità di fallimento specifiche e un framework decisionale di produzione, vedi Pattern di Orchestrazione Multi-Agente.

Questa tabella dei pattern è una sintesi dai documenti dei provider, dei framework e dei sistemi di riferimento piuttosto che un’affermazione di un singolo vendor.

Note della tabella: OpenAI hosted File Search è uno strumento gestito, Anthropic offre un’infrastruttura gestita, Pinecone è un servizio vettoriale gestito, mentre vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith self-hosted e OpenLIT supportano tutti operazioni self-managed o ibride in misura variabile.

Note della tabella: Pinecone documenta un piano di controllo gestito e piani dati regionali. Weaviate documenta vettori e indici invertiti con più tipi di indice vettoriale. pgvector aggiunge ricerca esatta e del più vicino approssimativo a Postgres. Milvus si posiziona come un database vettoriale open source ad alte prestazioni e scalabile, con Zilliz Cloud come opzione gestita.

Note della tabella: OpenAI documenta Responses come la sua interfaccia avanzata per risposte con stato e strumenti integrati. Anthropic documenta l’API Messages e il contratto di uso degli strumenti separatamente da Managed Agents. vLLM espone un server compatibile con OpenAI più il supporto API Messages Anthropic. Ollama documenta flussi di lavoro embedding e modello locali. llama.cpp documenta route chat, risposte e embedding compatibili con OpenAI, più completamenti chat compatibili con Anthropic.

Questa matrice dei compromessi è un’inferenza architetturale dai documenti ufficiali, non un benchmark del vendor. La riga della coerenza è più importante di quanto molti post sul blog ammettano: Pinecone separa i percorsi di scrittura e lettura, Hermes congela la memoria nei prompt di avvio della sessione e OpenClaw promuove la memoria durevole attraverso revisioni a fasi. Questo significa che “memoria aggiornata” e “memoria visibile alla risposta corrente” sono spesso verità diverse.

Modalità di fallimento e mitigazioni

La maggior parte degli assistenti non fallisce perché il modello base è “cattivo”. Falliscono perché il sistema circostante mente al modello, lo priva del contesto giusto, lascia che gli strumenti derivino o rende il debug impossibile.

La base di prove per questa tabella è ampia ma coerente. I documenti strumenti di Anthropic rendono chiaro che l’uso degli strumenti è un confine contrattuale. OpenAI Guardrails include il rilevamento delle allucinazioni contro un knowledge base di riferimento tramite File Search. SelfCheckGPT mostra che l’auto-coerenza tra campioni può aiutare a rilevare affermazioni non supportate. I risultati “Lost in the Middle” e le linee guida sul contesto di Anthropic rafforzano entrambi la stessa lezione operativa: più token non rimuovono la necessità di curazione del contesto.

Lo stack di mitigazione preferito potrebbe essere noioso e ripetitivo: traccia ogni richiesta, versiona i prompt, valuta il recupero in modo indipendente, mantieni gli strumenti idempotenti ed esegui eval di regressione prima di cambiare rotte o politica di memoria. I documenti e il repo di OpenAI Evals sono brutali sul perché: senza evals, è difficile e dispendioso in termini di tempo capire come i cambiamenti del modello o del prompt influenzino il tuo caso d’uso. Questo si applica tanto ai router e al recupero quanto ai prompt.

Letture aggiuntive

Se vuoi andare più a fondo, ci sono le fonti primarie più utili da tenere aperte mentre si progetta o si revisiona un’architettura assistente.

• OpenAI: Panoramica Responses, Chiamate di Funzione, Uso degli Strumenti, Recupero, File Search, Evals e MCP per server strumenti remoti.

• Anthropic: Panoramica API, Uso degli Strumenti, il contratto di uso degli strumenti, Agenti Gestiti, Finestre di Contesto e il connettore MCP.

• MCP stesso: la Panoramica Architettura e la Specifica valgono la pena essere lette direttamente, perché spiegano host, client, server, strumenti, prompt, risorse, trasporti e negoziazione delle capacità in modo pulito. Per un confronto pratico di MCP con il protocollo Agent2Agent e quando un sistema multi-agente ha bisogno di entrambi i livelli, vedi A2A vs MCP: Gli Agenti AI Hanno Really Bisogno di Entrambi i Protocolli? e per i concetti A2A stessi — Schede Agente, ciclo di vita del task, messaggi, parti e artefatti — vedi Cos’è il Protocollo A2A? Schede Agente e Task Spiegati.

• Assistenti in background e proattivi: il livello strumentazione è solo una parte di come gli assistenti agiscono. Per come rendere un assistente che guarda, decide e agisce da solo — schedulatori, worker basati su code, protocolli claim, workflow durevoli e polling semantico — vedi Agenti Polling negli Assistenti AI: 11 Pattern di Implementazione.

• Protocollo A2A e adozione: una volta che gli agenti sono distribuiti in modo indipendente e hanno bisogno di collaborare oltre i confini di proprietà, A2A diventa rilevante. Per una visione pratica del 2026 di dove A2A ha realmente trazione, le domande di sicurezza che solleva e un framework decisionale per quando adottarlo, vedi Protocollo A2A Google nel 2026: Adozione, Hype e Realtà. Quando quegli agenti scambiano task a lunga esecuzione piuttosto che singoli turni di chat, Streaming A2A e Task Asincroni per Flussi di Lavoro Agenti a Lunga Esecuzione copre SSE, push e design input_required al confine del protocollo.

• Framework e instradamento: Panoramica LangChain, documenti contesto-augmentazione LlamaIndex, documenti instradamento LiteLLM, documenti osservabilità LangSmith.

• Runtime self-hosted e sistemi assistenti: vLLM, server llama.cpp, embedding Ollama, documenti e repo OpenClaw, documenti e repo Hermes.

• Archiviazione e osservabilità: Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• Paper di ricerca: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lost in the Middle e SelfCheckGPT.