Contesto a livelli: una gerarchia delle conoscenze per gli agenti AI

Un agente con un unico file di memoria piatto non dimentica le cose; non riesce a smettere di ricordare informazioni su cui non gli è stato chiesto di soffermarsi. La soluzione è un contesto a livelli in cui ogni strato di conoscenza entra attraverso un trigger diverso.

La modalità di fallimento non è l’oblio, ma l’esatto opposto. In un unico archivio piatto, ogni fatto vive nello stesso luogo, entra nel contesto nello stesso modo e, di conseguenza, è disponibile allo stesso modo — sempre. Chiedi all’agente di redigere una risposta a un’email di un cliente e, mentre la scrive, inizia a narrare la configurazione del router; chiedigli di risolvere un problema con un servizio e menziona il canone di sponsorizzazione citato il mese scorso. Il mucchio di memoria è un monolite: ogni modifica a un aspetto tocca tutti gli altri e l’impatto di ogni interrogazione è l’intero corpus.

Il consiglio standard è comportamentale: insegnare all’agente cosa è rilevante per l’argomento attuale. È l’equivalente software dello scrivere “prego di fare attenzione” su un muro portante — l’agente può essere istruito e si adeguerà in gran parte, fino al giorno in cui non lo farà. L’alternativa strutturale è una conoscenza che non può entrare in una conversazione a meno che l’attività che ne ha bisogno non stia già avvenendo. Questo articolo definisce tale struttura come una gerarchia di conoscenza a cinque livelli — cos’è ciascun livello, cosa ne innesca l’iniezione, cosa vi appartiene e dove fallisce — e la applica a una configurazione concreta multi-dominio: un profilo generale, uno per l’homelab, uno per questioni personali, uno per il lavoro e uno per l’istruzione.

Nomenclatura della gerarchia

Non esiste un termine standard dell’industria universale, quindi la definizione qui è esplicita. Una gerarchia della conoscenza è un’organizzazione stratificata di ciò che l’agente sa, in cui ogni strato differisce per tre proprietà: come entra nel contesto del modello, quanto è consentito che sia grande e quanto tempo è previsto resti corretto. A livello di architettura della conoscenza, i paradigmi adiacenti — PKM, RAG, wiki e sistemi di memoria — vengono confrontati in PKM vs RAG vs Wiki vs Sistemi di Memoria, e i contratti di runtime che gli assistenti implementano effettivamente sono mappati in Sistemi di Memoria negli Assistenti AI. Entrambi rientrano nel cluster Gestione della Conoscenza, che copre i fondamenti, i metodi e gli strumenti dei sistemi di conoscenza umana. Questo articolo aggiunge la classificazione basata sui trigger e il confine di profilo che rendono l’allocazione applicabile.

Due lignaggi spiegano la forma della gerarchia.

Il primo è la gerarchia di memoria del processore. Un processore non memorizza ogni byte di cui potrebbe aver bisogno nello stesso registro. Ha cache L1 — piccola, sempre residente, accessibile senza alcuna decisione —, L2, memoria principale e disco, dove ogni livello è più grande, più lento da raggiungere e accessibile solo quando i livelli superiori non hanno la risposta. La regola di progettazione non è “mantieni tutto veloce”. È la maggior parte dei dati conta raramente; paghi il costo di accesso solo quando conta. Un agente con un unico file di memoria piatto è un processore con tutto stipato nella L1: il file dei registri è enorme, quindi tutto è visibile, inclusi i byte che l’istruzione attuale non ha richiesto. MemGPT ha compiuto la stessa mossa per gli agenti, modellando la memoria come livelli con un movimento esplicito tra archivi veloci e lenti.

Il secondo è la tassonomia della memoria cognitiva, che divide la conoscenza in memoria procedurale (come fare le cose), memoria semantica (fatti sul mondo) e memoria episodica (cosa è successo, quando, a chi). La tassonomia conta perché le modalità di fallimento differiscono per tipo: la conoscenza procedurale che diventa obsoleta è un bug nel tuo flusso di lavoro, la conoscenza semantica che diventa obsoleta è un fatto errato e la conoscenza episodica che fuoriesce è un incidente di privacy. Una gerarchia organizzata per tipo di contenuto, non per posizione, ti dice quali fallimenti sono pericolosi.

L’asse organizzativo per questo articolo non è nessuno dei due sopra. Classifica la conoscenza in base a ciò che ne causa l’ingresso nel contesto. Il trigger di iniezione è il meccanismo e il meccanismo è ciò che puoi effettivamente applicare. Un sistema di agenti offre esattamente quattro trigger:

• Sempre. Iniettato in ogni turno, incondizionatamente.
• Trigger dell’attività. Caricato quando l’attività attuale corrisponde a una condizione dichiarata.
• Ricordo semantico. Riportato in superficie quando il messaggio attuale è simile a qualcosa di memorizzato.
• Riferimento esplicito. Recuperato perché un’attività cita il file o la query.

Ogni livello della gerarchia è definito dal trigger che lo alimenta. Questa è l’intera progettazione e il resto di questo articolo è un’elaborazione di una tabella.

I cinque livelli

Leggi la tabella lungo la colonna dei trigger, non in traverso. Il Livello 0 e il Livello 1 sono la cache L1: pagano per il privilegio di essere sempre residenti essendo minuscoli. Il Livello 2 è la cache delle istruzioni: prelevato su una condizione di ramo, l’attività che corrisponde al trigger dell’abilità. Il Livello 3 è il disco: può essere enorme perché nulla entra nel contesto finché un passo di un’attività non legge esplicitamente un file nominato. Il Livello 4 è quello ambiguo — è la memoria principale, acceduta per similarità, che è l’unico trigger nella lista che non coinvolga una decisione presa da te o dall’attività. La similarità è un gate probabilistico ed è per questo che ha bisogno dei controlli esterni più rigidi, forniti dalla sezione sui profili. L’immagine della cassettiera in cima a questo articolo codifica la stessa idea: più un livello è in alto, più liberamente il suo contenuto entra in una conversazione e la partizione di vetro segna dove finisce lo scaffale di un dominio.

Livello 0: identità

SOUL.md, o qualunque cosa il tuo agente chiami il suo prompt di sistema. Il suo compito è definire chi, non cosa: tono, valori, limiti di rifiuto e politica di memoria. La politica di memoria appartiene qui perché è l’unica istruzione che deve essere in vigore prima che venga consultata qualsiasi memoria. Un file di identità che inizia a elencare nomi di server, nomi di clienti o tariffe ha già fallito — è diventato contenuto del Livello 1 che indossa il distintivo del Livello 0 e ora entra in ogni conversazione, incluso quelle in cui non deve apparire.

Livello 1: memoria residente

I file di memoria persistenti: note generali e il profilo utente. Due regole governano questo livello e sono le regole che separano una gerarchia funzionante da un mucchio.

Primo, puntatori, non fatti. Se un fatto serve a un solo dominio, non appartiene qui. La voce corretta non è il fatto stesso ma un indicatore:

Fatti infrastruttura: wiki/infra/ + banca di memoria 'homelab'.
Clienti e contratti: wiki/business/clients/ + banca 'business'.

L’indicatore è neutrale rispetto al dominio, quindi è sicuro da portare ovunque. Il fatto a cui punta viene caricato solo dall’attività che ha nominato la destinazione.

Secondo, un budget rigido, applicato. Se l’archivio non ha un limite di caratteri, si riempie e il riempimento avviene sempre con l’argomento più recentemente discusso — quindi una settimana di infrastruttura evoca silenziosamente o circonda il contesto generale con infrastruttura. Un budget quasi pieno costringe al triage e il triage è l’unico meccanismo che mantiene questo livello onesto. L’implementazione di Hermes è un esempio funzionante: MEMORY.md limitato a 2.200 caratteri e USER.md a 1.375, iniettato come blocco congelato all’inizio della sessione, è documentato in Sistema di Memoria dell’Agente Hermes.

Livello 2: conoscenza procedurale

Le abilità sono il modo in cui l’agente codifica come: la procedura, le insidie e — criticamente per questo articolo — i puntatori nei livelli più profondi. Un’abilità per l’amministrazione dell’homelab nomina quale directory wiki contiene l’inventario e quale banca di memoria richiamare. Un’abilità per il lavoro con i clienti nomina l’archivio dei contratti e la banca aziendale. La descrizione dell’abilità è il suo trigger: è la condizione di ramo che decide se la procedura, e quindi i suoi puntatori, entrano affatto nel contesto.

Questo è il livello che rende la gerarchia operativa, perché è la giuntura tra “quale attività sta avvenendo” e “quale dati quell’attività può vedere”. Un’attività su un’email di un cliente carica l’abilità cliente; l’abilità cliente nomina la banca aziendale e la directory dei contratti; la banca homelab e la directory infrastruttura semplicemente non vengono mai riferite da un percorso che l’attività ha percorso.

La modalità di fallimento è l’infiltrazione di dati: incollare l’elenco dei clienti effettivo o la tabella degli IP effettiva nel corpo dell’abilità. Allora i dati sono sempre caricati quando lo è la procedura e il trigger della procedura è diventato il confine di esposizione dei dati. Le abilità trasportano il percorso verso i dati e nient’altro di sensibile.

Livello 3: dati di riferimento

La wiki, l’albero delle note, il sistema di riferimento. Questo è il livello con i vincoli più pochi e le sorprese più poche, perché è l’unico livello con un percorso di accesso deterministico: qualcosa entra nel contesto solo perché un passo di un’attività ha letto esplicitamente quel file. Tabelle, inventari, contratti, runbook, statistiche — le cose che conserveresti in un database o in un sistema di gestione delle configurazioni. Quando il corpus è mantenuto da un LLM, si applica il modello LLM Wiki: la sintesi avviene al momento dell’ingestione e il risultato è memorizzato come pagine strutturate e collegate.

La ragione per cui i dati di riferimento appartengono qui e non al Livello 4 è che la qualità del recupero è lo strumento sbagliato per le tabelle. Il ricordo semantico è eccellente per “cosa ha confermato il cliente X sulla scadenza” e terribile per “quale è la porta del servizio sull’host Y” — quest’ultimo ha esattamente una riga corretta e un reranker che restituisce i tre paragrafi più vicini è un passivo. La ricerca deterministica vince per i dati di riferimento; la similarità vince per gli episodi. Tienili separati e il modello di accesso di ciascun livello corrisponderà alla forma del suo contenuto.

La modalità di fallimento è l’obsolescenza, che è un problema di manutenzione, non di architettura: il registro devia dalla realtà e l’agente, facendo tutto il possibile, opera da una tabella sbagliata. La mitigazione è la stessa di cui ha bisogno qualsiasi sistema di riferimento — un singolo scrittore per file, registri delle modifiche e una cadenza di audit — più le pratiche di rilevamento delle deviazioni e verifica delle contraddizioni coperte in Manutenzione della LLM Wiki: Deviazioni, Contraddizioni e Revisione.

Livello 4: memoria recuperata

Un backend di memoria con richiamo automatico per turno: la memoria episodica e relazionale dell’agente. Decisioni e le loro date, “il cliente X ha confermato Y”, “abbiamo provato Z e non ha funzionato”. Questo è dove vive la parte dinamica e auto-organizzativa del sistema — e dove la questione di sicurezza diventa interessante, perché il ricordo semantico è un gate probabilistico e i gate probabilistici producono derrame.

“Domanda di fatturazione per il cliente X” e “quale host esegue il server di fatturazione” sono vicini nello spazio di embedding. Qualsiasi singola banca che contenga sia i registri del cliente che l’inventario dell’infrastruttura, con una probabilità non trascurabile, riporterà in superficie il secondo nel primo. Puoi restringere questo con tag e restrizioni di richiamo e dovresti — ma un filtro di tag su un corpus misto è una disciplina, non una struttura. La risposta strutturale è smettere di mescolare: una banca per dominio, in modo che il raggio di derrame di un richiamo sia, per costruzione, un dominio. Scegliere il backend stesso — politica di acquisizione, dipendenze, vincoli di self-hosting — è un confronto separato, coperto in Confronto dei Provider di Memoria per Agenti.

Due dettagli meccanici contano quando si collega questo livello. I percorsi di scrittura e quelli di lettura sono controlli separati: una banca può essere inclusa nel richiamo ed esclusa dalla ritenzione, ed è così che si costruisce un profilo che legge tutto e scrive in niente. E ogni banca dovrebbe portare la propria missione di ritenzione — una breve dichiarazione di cosa quella banca esiste per trattenere. Una banca aziendale con la missione “corrispondenza del cliente, termini contrattuali, stato delle negoziazioni; mai dettagli infrastrutturali” estrarrà di conseguenza, perché l’estrazione è una chiamata LLM che legge la missione. Il libro di ricette sulla personalizzazione di OpenAI tratta il consolidamento come la fase più sensibile e soggetta a errori di un ciclo di vita della memoria — la missione di ritenzione è il contratto che mantiene quella fase onesta.

Profili: il confine che rende la separazione strutturale

Finora, la gerarchia separa la conoscenza per livello — necessario ma non sufficiente. I cinque livelli sopra sono l’anatomia di un singolo agente. La domanda con cui questo articolo è iniziato riguarda i domini: homelab, personale, lavoro, istruzione e il contesto generale che li attraversa.

Il meccanismo per la separazione dei domini è il profilo — un’istanza completa e indipendente dell’agente: il proprio file di identità, la propria memoria residente, la propria directory di abilità, i propri lavori schedulati e, decisivamente, il proprio collegamento delle banche di memoria. Un profilo non è un tag su una conversazione; è un sistema separato che per caso condivide una macchina. Quando esegui agent -p homelab, ottieni un processo il cui intero percorso dal Livello 0 al Livello 4 è limitato al dominio homelab e il cui pool di richiamo non può contenere la banca aziendale perché la banca aziendale non è nella sua configurazione.

Questa è la differenza tra le due risposte al problema della perdita di dati. “Non divulgare l’infrastruttura nelle conversazioni aziendali” è un’istruzione del prompt — una probabilità. “Il pool di richiamo del profilo aziendale non include la banca infrastruttura” è una configurazione — una garanzia. La gerarchia ti dice cosa va dove; il confine di profilo è ciò che rende l’allocazione non aggirabile dall’interno della conversazione.

L’esempio pratico, cinque domini:

Due celle in quella tabella fanno il grosso del lavoro.

La riga della banca del profilo comune è “nessuna, sola lettura”. La conversazione generale è dove poni domande trasversali, quindi dovrebbe poter vedere i fatti richiamati di ogni dominio — ma non deve scrivere in nessuno di essi. La chiacchierata in una sessione generale è esattamente il materiale che non vuoi estrarre nella memoria durevole di un dominio e il collegamento in sola lettura rimuove la scelta dal modello del tutto. Se il collegamento del backend supporta liste di banche solo richiamo (separate dalle banche di scrittura), questa è una riga di configurazione per banca di dominio; se non lo supporta, il profilo comune richiama da una banca generale dedicata e accetti una visione inter-dominio più debole.

Le righe di richiamo dei profili di dominio sono vuote. Ciascun profilo di dominio vede esattamente una banca. Il profilo homelab non richiamerà mai un termine contrattuale di un cliente, non perché gli è stato detto di non farlo, ma perché il termine non è nel pool che interroga. Questa è la separazione bidirezionale per cui vale l’intero esercizio: funziona simmetricamente per costruzione, senza alcuna istruzione coinvolta in nessuna direzione.

Seguono tre conseguenze operative e sono il motivo per cui l’approccio a profilo costa più dell’approccio a singolo agente ma ne vale la pena per chiunque i cui domini siano genuinamente disgiunti.

• Il trigger diventa la superficie. Se il lavoro homelab avviene in un terminale che avvii con -p homelab e il lavoro con i clienti avviene su un account di messaggistica instradato al profilo di lavoro, allora quale cappello stai indossando è una proprietà di come hai invocato l’agente, non un flag che devi ricordare di dichiarare. Lo sviamento — eseguire accidentalmente attività dei clienti nel contesto homelab — diventa visibile come eseguire la shell sbagliata.
• Il lavoro schedulato eredita il confine. I lavori cron e i sotto-compiti delegati girano all’interno di quale profilo li possiede. Un controllo infrastruttura notturno schedulato nel profilo homelab non può far deviare contenuto aziendale nella banca homelab, perché non lo possiede mai.
• Il filesystem è condiviso e questo è il limite onesto. I profili separano il contesto, non l’accesso. Il terminale di ogni profilo può leggere i file di ogni profilo; il confine protegge le conversazioni, non i dischi. Quindi i livelli che contengono materiale genuinamente sensibile hanno bisogno della loro disciplina: credenziali in un file di ambiente o in un archivio di segreti piuttosto che in testo normale wiki, la wiki al di fuori di qualsiasi repository pubblico e permessi per directory dove il sistema operativo aiuta. Tratta il confine di profilo come un firewall per il contesto — eccellente nel suo compito — e non lasciarlo scambiare per un firewall per i dati.

Bootstrap da un mucchio piatto

La gerarchia è di solito raggiunta dal basso: un agente che è iniziato con un file di memoria e ora mantiene tutto in esso. L’ordine di migrazione conta, perché ogni passo è economico solo dopo che il precedente è completato.

Primo, separa il pool di richiamo. Creare una banca di memoria per dominio è una modifica di configurazione, non una riscrittura dei contenuti — ed è il passo con la leva più alta, perché la perdita di dati dal richiamo si ferma il giorno in cui le banche si separano. I contenuti possono migrare dopo; il confine non dovrebbe attenderli.

Secondo, budgeta il Livello 1. Imposta un limite di caratteri sui file residenti, poi audita ciò che è già in essi rispetto al limite. I fatti specifici del dominio diventano puntatori verso dove risiederanno; ciò che rimane è ciò che si applica genuinamente a ogni sessione.

Terzo, dai una destinazione ai fatti degradati. Una directory wiki per dominio, con la disciplina del singolo scrittore e del registro delle modifiche, riceve ciò che il Livello 1 rilascia. Le abilità prendono i puntatori verso di essa per ultimi, perché un’abilità che nomina una directory che non esiste ancora è peggio di nessuna abilità.

Dove la gerarchia marcisce

L’architettura è buona solo quanto la sua manutenzione e ogni livello marcisce in modo caratteristico.

Il Livello 1 si riempie per primo. È il livello con il percorso di scrittura più conveniente (“ricorda semplicemente questo”), quindi è il primo ad accumulare fatti di dominio in incognito. Il budget rende questo visibile: quando l’archivio è al 90% pieno, auditalo per voci che dovrebbero essere puntatori. La correzione è sempre la stessa mossa — degrada i fatti al Livello 3, promuovi l’indicatore.

Il Livello 2 si insinua per secondo. Le abilità sono dove le procedure e i dati vogliono vivere insieme, perché “la procedura riferisce costantemente i dati” sembra ragionevole al momento della scrittura. Il controllo è meccanico: se il corpo di un’abilità contiene una tabella che è la fonte di verità per qualsiasi cosa, appartiene alla wiki e l’abilità dovrebbe trasportare un percorso.

Il Livello 4 devia silenziosamente. La memoria recuperata è orientata all’aggiunta e auto-esplicativa, quindi gli episodi obsoleti non sono mai corretti, solo superati. L’intestazione del richiamo (“queste memorie sono contesto storico, non fatti verificati”) è la mitigazione standard. La mitigazione più pulita è la stessa usata dal Livello 3: quando un episodio diventa un fatto durevole (“il cliente ha firmato in questa data a questi termini”), viene scritto nel sistema di riferimento, dove è visibile e modificabile, e la banca mantiene solo la narrazione. Una variante più acuta di questa deviazione — l’inferenza propria dell’agente riscritta come evidenza — è trattata in Cicli di Memoria Auto-Rinforzanti negli Agenti AI.

I profili si moltiplicano. Cinque profili sono gestibili; quindici sono una flotta. La disciplina è che un nuovo profilo appare solo quando appare un nuovo dominio — non per un nuovo progetto, un nuovo strumento o un nuovo umore. La separazione a livello di progetto è a cosa serve la struttura delle directory del livello di riferimento; la separazione a livello di dominio è a cosa servono i profili. Confondere i due è come la gente finisce con una menagerie di profili e nessuna storia di richiamo chiara.

La conclusione: una regola di allocazione

Metti ogni pezzo di conoscenza nel livello più superficiale il cui trigger corrisponde al suo bisogno: fatti sempre necessari nella memoria residente come puntatori, procedure nelle abilità, dati di riferimento nei file, episodi in una banca — e metti la banca di ogni dominio dietro un profilo che nessun altro profilo di dominio possa richiamare. L’agente si comporta allora come un sistema ben progettato: la giusta conoscenza è presente perché la giusta attività l’ha richiesta, la conoscenza sbagliata è assente perché nulla nella conversazione aveva un percorso verso di essa e l’unica cosa che potrebbe unirle è una modifica della configurazione — qualcosa che fai deliberatamente e che quindi puoi vedere quando accade.

Il mucchio piatto non era mai un fallimento di disciplina. Era un’architettura in cui ogni fato condivide un trigger e quel trigger è “sempre”. Spezza il trigger a pezzi, e le perdite smettono di essere una questione del giudizio del modello. Smettono di essere possibili.

Riferimenti

• PKM vs RAG vs Wiki vs Sistemi di Memoria — il confronto fondamentale tra archivi di conoscenza personale, pipeline di recupero e memoria degli agenti
• Sistemi di Memoria negli Assistenti AI — lo stack di memoria di runtime dentro il quale questa gerarchia si inserisce
• Recupero vs Rappresentazione nei Sistemi di Conoscenza — perché la forma del tuo archivio determina cosa può rispondere
• Hub della Memoria dei Sistemi AI