Skip to main contentSkip to footer
Context Hubs

Caricamento del Contesto a Livelli

Gli agenti non dovrebbero scandagliare tutto per default. Un buon runtime li fa ispezionare il contesto progressivamente, caricando solo cio che serve.

Uno dei modi piu rapidi per rendere un agente lento, costoso e meno affidabile e dargli troppo contesto troppo presto. Il caricamento a livelli trasforma la scoperta del contesto in un processo guidato, invece di lasciare il runtime davanti a un dump indistinto di file.

Fatti chiave

Zone di contesto
Identita, inbox, aree, progetti, knowledge, archive
Modello di caricamento
L0 .abstract.md, L1 .overview.md, L2 full file
Obiettivo
Ispezione progressiva invece di retrieval indiscriminato
Failure comune
Contesto stantio o sovraccaricato
Usa con
Hub filesystem, risorse MCP, memoria agentica
Cosa appartiene a un context hub per sistemi agentici?

Un buon context hub separa per chi il sistema sta lavorando, cosa e arrivato di recente, quale lavoro e in corso, quale conoscenza di riferimento e stabile e cosa dovrebbe finire in archivio. Un pattern pratico e una root versionata `context-hub/` con `0-identity`, `1-inbox`, `2-areas`, `3-projects`, `4-knowledge` e `5-archive`. Questo rende il retrieval ispezionabile e impedisce al runtime di trattare ogni file come ugualmente rilevante.

Perche il caricamento a livelli conta cosi tanto?

Il caricamento a livelli protegge latenza, attenzione e giudizio. Gli agenti dovrebbero iniziare da file `L0 .abstract.md` per il routing rapido, passare agli `L1 .overview.md` quando un ramo diventa rilevante e aprire file completi `L2` solo quando prove o azioni richiedono davvero quel dettaglio in piu. MCP puo esporre questi livelli come risorse o prompt, ma la forma del context hub resta utile anche quando il runtime legge direttamente da repository o filesystem.

Costruisci il contesto come modello operativo durevole

Quando il contesto ha zone stabili e livelli di caricamento, gli agenti possono ragionare su cio che sanno, su cio che non hanno ancora ispezionato e su cio che dovrebbe restare fuori scope finche il task non giustifica un'espansione.

Forma del context-hub

Un pattern pratico di filesystem e una root versionata `context-hub/` con zone numerate stabili per identita, cattura, lavoro attivo, conoscenza di riferimento e materiale completato.

0-identity: missione, obiettivi, valori e per chi appartiene il lavoro
1-inbox: cattura non ordinata, nuove richieste e interrupt
2-areas / 3-projects / 4-knowledge / 5-archive: lavoro continuo, lavoro a termine, reference e completato
L0 e L1 a caricamento progressivo

Usa file `.abstract.md` compatti per il routing rapido e `.overview.md` per struttura, stato, workflow e relazioni prima di caricare rami piu pesanti.

Routing rapido prima di tutto
Rendi visibili i marker di obsolescenza
Evita di caricare grandi file in anticipo
L2 full file solo quando lavori davvero

Passa dagli `.overview.md` ai sorgenti completi solo dopo che task, blocker o esigenza di evidenza rendono necessaria l'espansione.

Overview per framing situazionale
Full file solo per azione o verifica
Registra cosa e stato aperto per auditabilita

Continua nel ramo runtime

Questo ramo e pensato come libreria coerente. Usa le altre guide per completare il modello operativo oltre il singolo topic.

Perche non usare retrieval su tutto?

Perche un retrieval indiscriminato puo comunque riportare materiale rumoroso, stantio o irrilevante. Il caricamento a livelli offre un percorso di ispezione migliore.

Vale solo per filesystem markdown?

No. Lo stesso pattern funziona per document store, risorse MCP, knowledge base interne e repository strutturati.

Gli agenti possono saltare il livello overview?

Si, per task molto piccoli o espliciti. Ma come regola generale, partire dagli overview riduce lo spreco di contesto.

Continua nel ramo runtime

Questo ramo e pensato come libreria coerente. Usa la landing runtime per ritrovare il quadro generale e continua verso i principi quando devi riallineare il modello operativo alla dottrina.