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

Un assistente AI di produzione non è “un LLM con un prompt”. È un sistema che accetta l’intento, mantiene lo stato, decide quando recuperare dati o agire, ed espone abbastanza dettagli runtime per debuggare i fallimenti.

Questa prospettiva di sistema è ciò che il cluster AI Systems esamina quando gli assistenti vanno oltre una singola invocazione del modello.

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

L’architettura più pulita suddivide le responsabilità in cinque livelli: LLM, Memoria, Strumenti, Routing e Osservabilità. Questa suddivisione corrisponde alle capacità esposte dalle API principali dei provider, da MCP, da runtime self-hosted come vLLM e llama.cpp, e da sistemi di assistenti reali come OpenClaw e Hermes.

La memoria dovrebbe essere trattata come qualcosa di più di “un contesto più lungo”. I sistemi di recupero trasformano la conoscenza esterna in memoria non parametrica esplicita — lo stesso spazio di design coperto in profondità da Generazione Aumentata dal Recupero (RAG) — e sia le linee guida sul contesto di Anthropic che il paper “Lost in the Middle” avvertono che il semplice infoltimento di più token nel contesto non garantisce un recupero affidabile.

L’uso degli strumenti è un confine di contratto, non magia. La function calling di OpenAI, l’uso degli strumenti di Anthropic e MCP si basano tutti sullo stesso pattern: il modello emette una richiesta strutturata, qualche runtime la esegue e il risultato torna nella conversazione. Se quel confine è disordinato, l’assistente diventa disordinato.

Il mio orientamento è semplice: iniziare in modo noioso. Un orchestratore, un percorso di memoria durevole, un tracciato 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 fare ipotesi.

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 un’azione combinando un’interfaccia del modello, l’assemblaggio del contesto, l’esecuzione degli strumenti, la gestione dello stato e la telemetria. È per questo che le documentazioni utili non sono solo le schede del modello. Le documentazioni utili sono riferimenti API, contratti degli strumenti, guide di recupero, documentazioni di routing e documentazioni di tracciamento. La Responses API di OpenAI espone interazioni statuali, strumenti integrati e function calling. L’API Claude di Anthropic espone l’accesso diretto ai Messages così come gli Agenti Gestiti. OpenClaw e 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 di assistente ha un contratto più ampio di una chat completion. Un buon contratto interno somiglia a questo:

AssistantRequest  = intento utente + identità + sessione + allegati + politica
AssistantResponse = risposta + azioni + citazioni + modifiche di stato + id tracciamento

Questo contratto è importante perché ogni disaccordo in produzione si riduce in definitiva a una di queste domande: quale contesto era visibile, quale strumento ha eseguito, quale modello ha risposto, quale memoria è stata letta o scritta, e dove il tracciamento dice che il sistema ha speso tempo. OpenTelemetry definisce i tracciamenti 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, store vettoriali e flussi di lavoro degli agenti.

Componenti e interfacce principali

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

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

Il livello LLM dovrebbe fare tre cose bene: consumare un contesto di lavoro attuale, emettere una risposta finale o una richiesta di azione strutturata, e restituire abbastanza metadati per supportare retry e tracciamento. La Responses API di OpenAI è esplicitamente progettata per interazioni statuali più strumenti integrati e function calling. La Messages API di Anthropic espone lo stesso ciclo principale attraverso blocchi tool_use e restituzioni tool_result, mentre gli Agenti Gestiti ti offrono un’impalcatura hostizzata se non vuoi costruire tu stesso il ciclo. I runtime self-hosted come vLLM e llama.cpp sono importanti perché preservano interfacce familiari stile-provider permettendoti di collocare l’inferenza nel tuo stesso ambiente.

Il livello Memoria dovrebbe essere suddiviso mentalmente in tre contenitori: memoria di lavoro, memoria simbolica durevole e memoria semantica ricercabile. Gli embedding di OpenAI restituiscono vettori che possono essere indicizzati e ricercati; OpenAI Retrieval e File Search aggiungono poi ricerca semantica e per parole chiave sopra gli store vettoriali. Pinecone, Weaviate, pgvector e Milvus rappresentano quattro forme di storage comuni: completamente gestita, vettoriale nativa open-source, nativa Postgres e database vettoriale distribuito. Hermes e OpenClaw aggiungono un utile promemoria che non tutta la memoria appartiene a uno store vettoriale: note basate su file, promozioni revisionate e snapshot a scope di sessione sono spesso il design più onesto. Sistemi di Memoria negli Assistenti AI mappa il modello cross-framework; Sistema di Memoria di Hermes Agent approfondisce la memoria di base limitata e gli snapshot di sessione congelati in un singolo prodotto.

Il livello Strumenti è dove un assistente smette di essere un riassuntore e inizia a essere software. La function calling di OpenAI tratta gli strumenti come funzionalità definite da schema che il modello può decidere di richiamare. 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 espone strumenti, prompt e risorse — lo stesso confine descritto passo per passo in Server MCP in Go. LangChain e LlamaIndex si collocano comodamente qui come librerie di orchestrazione: LangChain si concentra su un’architettura di agente predefinita e integrazioni, mentre LlamaIndex si concentra sull’accesso ai dati aumentato dal contesto, motori di query e flussi di lavoro.

Il livello Routing 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é le sue documentazioni ufficiali sono rinfrescantemente concrete: scelta ponderata, meno occupato, basato su latenza, routing basato sui costi e failover limitati sono tutti pattern di primo livello. OpenClaw estende il routing verso l’alto nell’isolamento di canale e agente, mentre Hermes lo estende verso il basso in slot di modello per lavoro principale e ausiliario come riassunzione, compressione del contesto e routing degli strumenti MCP. È il modello mentale giusto: 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 tracciamento. LangSmith ti dà visibilità end-to-end sui passi di applicazione LLM e supporta forme di distribuzione cloud, ibrida e self-hosted. OpenLIT ti dà osservabilità AI nativa OpenTelemetry con opzioni di instrumentazione senza codice e manuale, inclusa il supporto per LLM, framework di agenti, database vettoriali e GPU. Per metriche di produzione, tracciamenti e pattern SLO attraverso flussi di lavoro di inferenza e agenti, vedi Osservabilità per Sistemi LLM. Se il tuo assistente non ha un tracciamento per richiesta, uno span per chiamata di modello e nessuna cronologia degli eventi per l’esecuzione degli strumenti, non hai davvero un’architettura. Hai vibrazioni.

Cattura, arricchisci, rispondi

La sequenza che continua a comparire nei sistemi reali è cattura -> arricchisci -> rispondi -> registra. I framework diversi la avvolgono in modo diverso, ma il flusso è abbastanza stabile da essere trattato come colonna vertebrale.

Il passo di cattura è di solito più importante di quanto appaia. Sia OpenClaw che Hermes mettono un gateway persistente davanti all’assistente perché l’ingresso non è solo ingresso di testo. Include metadati del canale, identità, autorizzazione, confini di sessione, messaggi diretti, gruppi, tick cron e semantica di consegna. Se salti quel livello e fai affidamento su un’astrazione grezza di widget chat, alla fine lo riaggiornerai comunque come middleware ad hoc.

Il passo di arricchimento è dove i sistemi maturi divergono dalle demo giocattolo. OpenAI Retrieval e File Search rendono esplicito il recupero attraverso store 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 suddividendo lo statuto del modello in slot principali e ausiliari, scaricando lavori come compressione, riassunzione e routing a modelli più piccoli o più specializzati. È un pattern di design da rubare: non spendere i tuoi token di modello più costosi per faccende.

Il passo di risposta non è “genera testo”. È “chiudi il ciclo attuale”. Se il modello può rispondere direttamente, lo fa. Se ha bisogno di uno strumento, emette una richiesta strutturata. Il contratto di uso-strumenti di Anthropic e la guida function-calling di OpenAI rendono questo esplicito. La ragione per cui questo è importante architettonicamente è che le uscite ora includono sia linguaggio che flusso di controllo. Il tuo oggetto risposta è in parte prosa e in parte piano runtime.

Il passo di registrazione è dove emergono le semantiche di coerenza. Pinecone separa i percorsi di scrittura e lettura e processa le scritture dopo il riconoscimento durevole. La memoria di Hermes è iniettata come uno snapshot congelato per sessione in modo che possa preservare le prestazioni della cache del prefisso, il che significa che nuove scritture non compaiono automaticamente nel prompt di sessione attuale. Il sistema Dreaming di OpenClaw promuove solo candidati revisionati e radicati in MEMORY.md, ed è opt-in piuttosto che sempre attivo. La lezione pratica è che la memoria raramente è davvero read-after-write attraverso ogni livello. Devi progettare per visibilità a stadi.

OpenClaw e Hermes come sistemi di riferimento

OpenClaw e Hermes sono casi di riferimento utili perché non sono solo wrapper attorno a un’API provider. Entrambi presentano un assistente come un sistema a lungo termine con gateway, sessioni, strumenti, memoria e più backend di modelli.

Questo mapping è radicato nelle documentazioni e nei repo ufficiali di OpenClaw e Hermes. OpenClaw documenta un’architettura gateway, routing multi-agente, supporto per provider custom e self-hosted inclusa vLLM e Ollama, memoria attiva opzionale e promozione basata su Dreaming. Hermes documenta un gateway di messaggistica, un loop centrale AIAgent, slot di modello principali e ausiliari, memoria integrata e integrazione MCP nativa.

La mia lettura leggermente opinabile è che entrambi i sistemi fanno la stessa argomentazione architettonica 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à, semantica della memoria, superfici degli strumenti e eterogeneità del backend come preoccupazioni di primo livello. È esattamente ciò che dovrebbe fare un’architettura di produzione.

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

edge:
  gateway: hermes or openclaw

routing:
  proxy: litellm
  policy: sensibile a latenza e budget
  tenancy: a scope di sessione e canale

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

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

tools:
  contract: json schema tools plus mcp
  examples: filesystem, browser, web search, internal APIs

observability:
  traces: opentelemetry
  ai_dashboards: openlit or langsmith
  evals: openai evals plus app-specific regression sets

Questo stack è un pattern di distribuzione ragionata piuttosto che una蓝图 prescritto 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 e embedding locali, MCP standardizza gli strumenti esterni, LiteLLM gestisce routing e 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 dentro le API dei provider. Un assistente retrieval-first tratta memoria e ricerca come il principale differenziatore. 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 messaggistica. Una mesh di specialisti scompone il lavoro in più agenti o percorsi. Le documentazioni ufficiali di OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw e Hermes supportano tutti versioni di questi pattern, anche se li nominano in modo diverso.

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 modi di fallimento specifici e un framework decisionale di produzione, vedi Pattern di Orchestrazione Multi-Agente.

Questa tabella dei pattern è una sintesi dalle documentazioni dei provider, delle documentazioni dei framework e dei sistemi di riferimento piuttosto che una affermazione di un singolo vendor.

Note della tabella: OpenAI hosted File Search è uno strumento gestito, Anthropic offre un’impalcatura 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 diversi gradi.

Note della tabella: Pinecone documenta un piano di controllo gestito e piani dati regionali. Weaviate documenta indici vettoriali e invertiti con più tipi di indice vettoriale. pgvector aggiunge ricerca del vicino esatta e approssimativa a Postgres. Milvus si posiziona come 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 statuali e strumenti integrati. Anthropic documenta la Messages API e il contratto di uso-strumenti separatamente dagli Agenti Gestiti. vLLM espone un server OpenAI-compatibile più supporto per la API Messages di Anthropic. Ollama documenta flussi di lavoro di embedding e modelli locali. llama.cpp documenta route chat, risposte e embedding OpenAI-compatibili, più chat completions Anthropic-compatibili.

Questa matrice dei compromessi è un’inferenza architettonica dalle documentazioni ufficiali, non un benchmark di un vendor. La riga sulla coerenza è più importante di quanto ammettano molti post di blog: 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 revisione a stadi. Ciò significa che “memoria aggiornata” e “memoria visibile alla risposta attuale” sono spesso verità diverse.

Modi di fallimento e mitigazioni

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

La base di evidenza per questa tabella è ampia ma coerente. Le documentazioni sugli strumenti di Anthropic rendono chiaro che l’uso degli strumenti è un confine di contratto. OpenAI Guardrails include il rilevamento delle allucinazioni contro una base di conoscenza di riferimento tramite File Search. SelfCheckGPT mostra che l’auto-coerenza tra campioni può aiutare a rilevare affermazioni non supportate. I risultati di “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 curatela del contesto.

Lo stack di mitigazione preferito potrebbe essere noioso e ripetitivo: traccia ogni richiesta, versiona i prompt, valuta il recupero indipendentemente, mantieni gli strumenti idempotenti ed esegui valutazioni di regressione prima di cambiare percorsi o politica di memoria. Le documentazioni e il repo Evals di OpenAI sono diretti sul perché: senza valutazioni, è difficile e dispendioso in tempo capire come le modifiche al modello o al prompt influiscano sul tuo caso d’uso. Questo si applica ai router e al recupero tanto quanto ai prompt.

Ulteriori letture

Se vuoi approfondire, ci sono le fonti primarie più utili da tenere aperte mentre progetti o revisioni un’architettura di assistente.

• OpenAI: Panoramica di Responses, Function Calling, Uso di Strumenti, Retrieval, File Search, Evals e MCP per server di strumenti remoti.

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

• MCP stesso: la Panoramica dell’Architettura e la Specifica vale la pena leggerle 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 davvero bisogno di entrambi i protocolli? e per i concetti di A2A stessi — Agent Card, ciclo di vita dei task, messaggi, parti e artefatti — vedi Cos’è il Protocollo A2A? Agent Card e Task Spiegati.

• Assistenti di background e proattivi: il livello degli strumenti è solo una parte di come gli assistenti agiscono. Per come fare sì che un assistente guardi, decida e agisca da solo — scheduler, worker basati su code, protocolli di claim, flussi di lavoro durevoli e polling semantico — vedi Agenti di Polling negli Assistenti AI: 11 Pattern di Implementazione.

• Autorità decisionale: per quali decisioni un modello dovrebbe fare, raccomandare o solo informare — i cinque ruoli decisionali, il routing basato sulla fiducia al livello più piccolo competente e le porte di approvazione dimensionate per il raggio di esplosione — vedi LLM Decisionali: Quando un Modello Dovrebbe Decidere — e Quando Non Dovrebbe.

• Protocollo A2A e adozione: una volta che gli agenti sono distribuiti indipendentemente e hanno bisogno di collaborare attraverso confini di proprietà, A2A diventa rilevante. Per una vista pratica 2026 di dove A2A ha effettivamente trazione, le domande di sicurezza che solleva e un framework decisionale per quando adottarlo, vedi Google A2A Protocol in 2026: Adozione, Hype e Realtà. Quando quegli agenti scambiano task a lungo termine piuttosto che singoli turni di chat, A2A Streaming e Task Asincroni per Flussi di Lavoro di Agenti a Lungo Termine copre SSE, push e progettazione input_required al confine del protocollo.

• Framework e routing: Panoramica di LangChain, documentazioni di contesto-aumento di LlamaIndex, documentazioni di routing di LiteLLM, documentazioni di osservabilità di LangSmith.

• Runtime self-hosted e sistemi di assistente: vLLM, server llama.cpp, embedding Ollama, documentazioni e repo di OpenClaw, documentazioni e repo di Hermes.

• Storage 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.