Gestione della finestra di contesto
Scopri come funziona la finestra di contesto da 270.000 token di Bob, come ogni categoria contribuisce all'utilizzo dei token e le best practice per mantenere le sessioni focalizzate ed efficienti in termini di costi.
Panoramica della finestra di contesto
Ogni sessione in Bob Shell ha una finestra di contesto — il budget di token per quella conversazione. Il limite è di 270.000 token. Tutto ciò che Bob carica viene conteggiato.
Cosa riempie la finestra
| Categoria | Cosa include |
|---|---|
| System prompt | Le istruzioni principali di Bob per la sessione |
| Definizioni degli strumenti | Schemi degli strumenti integrati e definizioni degli strumenti MCP connessi |
| Strumenti MCP | Istruzioni e descrizioni per gli strumenti forniti dai server MCP connessi |
| Rules | Istruzioni personalizzate dai file di regole del progetto e della modalità (ad esempio, AGENTS.md o .bob/rules-*) |
| Skills | Istruzioni dagli skill caricati da Bob per la conversazione |
| Messages | I tuoi prompt, le risposte di Bob e l'attività degli strumenti nella conversazione. Questo è il transcript conteggiato come token. |
L'output dei comandi e i risultati degli strumenti vengono conteggiati in Messages. I contenuti dei file non hanno una riga separata.
Il report dei token include due campi di riepilogo:
- Riservati per la risposta del modello: Token accantonati per la prossima risposta di Bob (tipicamente 20,0k).
- Spazio disponibile: Token liberi rimanenti.
Overhead di base
Le categorie fisse usano contesto ancora prima che tu inizi a lavorare con Bob. Anche un semplice "Rispondi brevemente con un saluto." totalizza circa 8,5k token. La maggior parte sono Definizioni degli strumenti (5,1k), System prompt (1,5k), Rules (830) e Skills (454). Solo 590 sono in Messages.
Bob reinvia l'intero stack di overhead a ogni prompt. Più server MCP o skill caricati aumentano Strumenti MCP, Definizioni degli strumenti e Skills prima che tu digiti.
Monitorare l'utilizzo dei token
Bob Shell riporta l'utilizzo dei token alla fine di ogni scambio. La tabella seguente mostra cosa influenza ogni categoria:
| Categoria | Cosa la fa crescere |
|---|---|
| System prompt | Caricato all'avvio della sessione. Rimane costante durante il lavoro normale. |
| Definizioni degli strumenti | Schemi degli strumenti integrati. Impostati all'avvio della sessione. Rimangono costanti durante il lavoro normale. |
| Strumenti MCP | Server MCP connessi e strumenti abilitati. Cresce quando aggiungi server o strumenti, non quando invii prompt. |
| Rules | File di regole del progetto e della modalità (ad esempio, AGENTS.md). Impostati all'apertura della sessione. |
| Skills | Skill caricati da Bob per la sessione. Possono aumentare se Bob attiva uno skill a metà conversazione. |
| Messages | I tuoi prompt, le risposte di Bob, letture di file, output degli strumenti e output dei comandi. Cresce a ogni turno e con l'esplorazione del repository. |
In uno scambio breve, le categorie fisse spesso usano la maggior parte del totale. Quando chiedi a Bob di leggere file o eseguire strumenti, Messages diventa solitamente la categoria più grande. Tieni d'occhio questo cambiamento.
Lo spazio disponibile diminuisce man mano che cresce una qualsiasi categoria. Riservati per la risposta del modello è accantonato per la prossima risposta di Bob. Non fa parte del totale usato sopra di esso.
Limiti dei token
Il limite massimo è di 270.000 token per sessione. Bob inizia a condensare prima di raggiungere il limite. La condensazione inizia tipicamente intorno a 190.000 token di utilizzo totale.
Condensazione automatica del contesto
Alla soglia di condensazione, Bob:
- Preserva il contesto più recente e rilevante.
- Riassume o rimuove i segmenti di conversazione più vecchi.
- Mantiene le istruzioni di sistema critiche, le definizioni degli strumenti, le regole e gli skill.
- Continua con il contesto condensato.
La condensazione è con perdita. I dettagli delle prime parti di Messages potrebbero non sopravvivere. Avvia una nuova sessione quando cambi argomento o quando Messages è abbastanza grande da compromettere la qualità.
Impatto sui Bobcoins
I Bobcoins tengono traccia dell'utilizzo dei token. Sia i token di input che quelli di output vengono conteggiati.
- Ogni messaggio invia di nuovo l'intero contesto attivo, incluso l'overhead fisso.
- Bob rielabora ciò che è già caricato a ogni invio.
- Le sessioni lunghe con Messages pesanti costano di più per ogni prompt successivo.
Best practice
La finestra di contesto non è uno storage. È la memoria di lavoro — ciò che Bob può usare a ogni passo. Controlla cosa ci entra. Azzera quando la sessione si riempie di output obsoleto. Verifica il risultato con i test, non solo con la risposta di Bob.
Definisci l'ambito della sessione e della conversazione
Usa una sessione per ogni obiettivo di lavoro e inizia con un prompt ristretto. Indica l'obiettivo, il risultato atteso e i vincoli prima di chiedere a Bob di esplorare il repository. Nomina file e funzioni esplicitamente. Evita richieste vaghe come "leggi tutto il repository" o "controlla il backend." Avvia una nuova sessione quando l'argomento cambia — il contenuto non correlato in Messages aumenta i costi e può confondere Bob.
Mantieni il contesto fisso leggero
Le categorie fisse consumano token prima che tu digiti qualcosa. Per mantenere basso quell'overhead:
- Mantieni le regole personalizzate e
AGENTS.mdbrevi — inserisci solo comandi di configurazione, test e stile (ad esempio,pnpm test,mvn verify). - Connetti solo i server MCP, gli strumenti e gli skill di cui il lavoro corrente ha bisogno. Disconnetti ciò che non stai usando e preferisci la configurazione MCP a livello di progetto rispetto a quella globale.
- Riserva Messages per evidenze situazionali specifiche di questa sessione — il bug, i log e i file rilevanti. Non ripetere le regole permanenti in ogni prompt.
Aggiungi contesto quando ne hai bisogno
Lascia che Bob cerchi e legga file mirati piuttosto che incollare grandi blocchi di contenuto nel prompt della chat. Fai riferimento a percorsi di file specifici e intervalli di righe nel tuo prompt ed evita riferimenti a directory ampie:
✓ Correggi la logica di validazione dell'email in src/utils/validation.ts righe 45-67
✗ Esamina tutto in src/, tests/ e docs/ e suggerisci miglioramentiLavora per fasi — trova i file probabili, ispeziona quelli rilevanti, pianifica, modifica e valida. Per letture ampie del repository, usa i subagent in modo che la sessione riceva risultati condensati piuttosto che ogni chiamata read_file che finisce in Messages. Quando le fonti sono in conflitto, fidati del codice in esecuzione e dei test piuttosto che dei commenti obsoleti o delle note del README vecchie.
Per ulteriori tattiche sui repository di grandi dimensioni, consulta Lavorare con progetti di grandi dimensioni.
Azzera quando Messages si riempie
Nel corso di una sessione lunga, Messages accumula contenuti di file ripetuti, piani abbandonati e output obsoleto degli strumenti. Avvia una nuova sessione quando l'obiettivo del lavoro cambia o quando la conversazione è abbastanza grande da compromettere la qualità. Mantieni vincoli, evidenze e domande aperte — rimuovi il resto.
Bob può anche condensare automaticamente i segmenti più vecchi, ma la condensazione è con perdita e i dettagli delle prime parti di Messages potrebbero non sopravvivere. Preferisci modifiche piccole e approvate rispetto a una singola esecuzione autonoma di grandi dimensioni in modo che le diff rimangano esaminabili e Bob rimanga in carreggiata.