Active Memory è un sub-agent di memoria bloccante opzionale, di proprietà del plugin, che viene eseguito prima della risposta principale per le sessioni conversazionali idonee. Esiste perché la maggior parte dei sistemi di memoria è capace ma reattiva. Si affidano all’agente principale per decidere quando cercare nella memoria, oppure all’utente per dire cose come “remember this” o “search memory.” A quel punto, il momento in cui la memoria avrebbe reso naturale la risposta è già passato. Active Memory offre al sistema una possibilità limitata di far emergere memoria pertinente prima che venga generata la risposta principale.Documentation Index
Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Avvio rapido
Incolla questo inopenclaw.json per una configurazione con impostazioni predefinite sicure — plugin attivo, limitato
all’agente main, solo sessioni di messaggi diretti, eredita il modello della sessione
quando disponibile:
plugins.entries.active-memory.enabled: trueattiva il pluginconfig.agents: ["main"]abilita Active Memory solo per l’agentemainconfig.allowedChatTypes: ["direct"]lo limita alle sessioni di messaggi diretti (abilita esplicitamente gruppi/canali)config.model(opzionale) fissa un modello dedicato per il richiamo; se non impostato eredita il modello della sessione correnteconfig.modelFallbackviene usato solo quando non viene risolto alcun modello esplicito o ereditatoconfig.promptStyle: "balanced"è il valore predefinito per la modalitàrecent- Active Memory viene comunque eseguito solo per sessioni chat interattive persistenti idonee
Raccomandazioni sulla velocità
La configurazione più semplice consiste nel lasciareconfig.model non impostato e permettere ad Active Memory di usare
lo stesso modello che usi già per le risposte normali. Questo è il valore predefinito più sicuro
perché segue il provider, l’autenticazione e le preferenze di modello esistenti.
Se vuoi che Active Memory sembri più veloce, usa un modello di inferenza dedicato
invece di prendere in prestito il modello della chat principale. La qualità del richiamo conta, ma la latenza
conta più che nel percorso della risposta principale, e la superficie degli strumenti di Active Memory
è ristretta (chiama solo gli strumenti disponibili di richiamo della memoria).
Buone opzioni di modelli veloci:
cerebras/gpt-oss-120bper un modello di richiamo dedicato a bassa latenzagoogle/gemini-3-flashcome fallback a bassa latenza senza cambiare il modello principale della chat- il tuo normale modello di sessione, lasciando
config.modelnon impostato
Configurazione di Cerebras
Aggiungi un provider Cerebras e indirizza Active Memory a esso:chat/completions per il
modello scelto — la sola visibilità in /v1/models non lo garantisce.
Come vederlo
Active Memory inserisce un prefisso di prompt non attendibile nascosto per il modello. Non espone tag grezzi<active_memory_plugin>...</active_memory_plugin> nella
normale risposta visibile al client.
Attivazione/disattivazione della sessione
Usa il comando del plugin quando vuoi mettere in pausa o riprendere Active Memory per la sessione chat corrente senza modificare la configurazione:plugins.entries.active-memory.enabled, il targeting degli agenti o altra configurazione
globale.
Se vuoi che il comando scriva la configurazione e metta in pausa o riprenda Active Memory per
tutte le sessioni, usa la forma globale esplicita:
plugins.entries.active-memory.config.enabled. Lascia
plugins.entries.active-memory.enabled attivo così il comando rimane disponibile per
riattivare Active Memory in seguito.
Se vuoi vedere cosa sta facendo Active Memory in una sessione dal vivo, attiva i
toggle di sessione che corrispondono all’output che desideri:
- una riga di stato di Active Memory come
Active Memory: status=ok elapsed=842ms query=recent summary=34 charsquando/verbose on - un riepilogo di debug leggibile come
Active Memory Debug: Lemon pepper wings with blue cheese.quando/trace on
/trace raw, il blocco tracciato Model Input (User Role)
mostrerà il prefisso nascosto di Active Memory come:
Quando viene eseguito
Active Memory usa due gate:- Opt-in di configurazione
Il plugin deve essere abilitato e l’id dell’agente corrente deve comparire in
plugins.entries.active-memory.config.agents. - Idoneità runtime rigorosa Anche quando abilitato e mirato, Active Memory viene eseguito solo per sessioni chat interattive persistenti idonee.
Tipi di sessione
config.allowedChatTypes controlla quali tipi di conversazioni possono eseguire Active
Memory.
Il valore predefinito è:
config.allowedChatIds e
config.deniedChatIds dopo aver scelto i tipi di sessione consentiti.
allowedChatIds è una allowlist esplicita di id conversazione risolti. Quando
non è vuota, Active Memory viene eseguito solo quando l’id conversazione della sessione è in
quella lista. Questo restringe tutti i tipi di chat consentiti insieme, inclusi i messaggi
diretti. Se vuoi tutti i messaggi diretti più solo gruppi specifici, includi
gli id dei peer diretti in allowedChatIds oppure mantieni allowedChatTypes focalizzato sul
rollout di gruppo/canale che stai testando.
deniedChatIds è una denylist esplicita. Ha sempre la precedenza su
allowedChatTypes e allowedChatIds, quindi una conversazione corrispondente viene saltata
anche quando il suo tipo di sessione sarebbe altrimenti consentito.
Gli id provengono dalla chiave di sessione persistente del canale: ad esempio Feishu
chat_id / open_id, id chat Telegram o id canale Slack. La corrispondenza è
senza distinzione tra maiuscole e minuscole. Se allowedChatIds non è vuoto e OpenClaw non riesce a risolvere un
id conversazione per la sessione, Active Memory salta il turno invece di
indovinare.
Esempio:
Dove viene eseguito
Active Memory è una funzionalità di arricchimento conversazionale, non una funzionalità di inferenza a livello di piattaforma.| Superficie | Esegue Active Memory? |
|---|---|
| UI di controllo / sessioni persistenti di chat web | Sì, se il plugin è abilitato e l’agente è mirato |
| Altre sessioni di canale interattive sullo stesso percorso chat persistente | Sì, se il plugin è abilitato e l’agente è mirato |
| Esecuzioni headless one-shot | No |
| Esecuzioni Heartbeat/in background | No |
Percorsi interni generici agent-command | No |
| Esecuzione di sub-agent/helper interni | No |
Perché usarlo
Usa Active Memory quando:- la sessione è persistente e rivolta all’utente
- l’agente ha una memoria a lungo termine significativa da cercare
- continuità e personalizzazione contano più del determinismo grezzo del prompt
- preferenze stabili
- abitudini ricorrenti
- contesto utente a lungo termine che dovrebbe emergere naturalmente
- automazione
- worker interni
- attività API one-shot
- luoghi in cui una personalizzazione nascosta sarebbe sorprendente
Come funziona
La forma runtime è: Il sub-agent di memoria bloccante può usare solo gli strumenti di richiamo della memoria configurati. Per impostazione predefinita sono:memory_searchmemory_get
plugins.slots.memory è memory-lancedb, il valore predefinito è invece memory_recall.
Imposta config.toolsAllow quando un altro provider di memoria espone un
contratto di strumento di richiamo diverso.
Se la connessione è debole, dovrebbe restituire NONE.
Modalità di query
config.queryMode controlla quanta conversazione vede il sub-agent di memoria bloccante.
Scegli la modalità più piccola che risponde comunque bene alle domande di follow-up;
i budget di timeout dovrebbero crescere con la dimensione del contesto (message < recent < full).
- message
- recent
- full
Viene inviato solo il messaggio utente più recente.Usa questa modalità quando:
- vuoi il comportamento più veloce
- vuoi il bias più forte verso il richiamo di preferenze stabili
- i turni di follow-up non hanno bisogno di contesto conversazionale
3000 a 5000 ms per config.timeoutMs.Stili di prompt
config.promptStyle controlla quanto il sub-agente di memoria bloccante sia proattivo o rigoroso
nel decidere se restituire memoria.
Stili disponibili:
balanced: predefinito generico per la modalitàrecentstrict: il meno proattivo; ideale quando vuoi pochissima contaminazione dal contesto vicinocontextual: il più favorevole alla continuità; ideale quando la cronologia della conversazione dovrebbe contare di piùrecall-heavy: più disposto a far emergere memoria su corrispondenze più deboli ma comunque plausibiliprecision-heavy: preferisce aggressivamenteNONEa meno che la corrispondenza non sia ovviapreference-only: ottimizzato per preferiti, abitudini, routine, gusti e fatti personali ricorrenti
config.promptStyle non è impostato:
config.promptStyle esplicitamente, quell’override ha la precedenza.
Esempio:
Criteri di fallback del modello
Seconfig.model non è impostato, Active Memory prova a risolvere un modello in questo ordine:
config.modelFallback controlla il passaggio di fallback configurato.
Fallback personalizzato facoltativo:
config.modelFallbackPolicy viene mantenuto solo come campo di compatibilità
deprecato per configurazioni meno recenti. Non modifica più il comportamento a runtime.
Strumenti di memoria
Per impostazione predefinita, Active Memory consente al sub-agente di recall bloccante di chiamarememory_search e memory_get. Questo corrisponde al contratto integrato di memory-core.
Quando plugins.slots.memory seleziona memory-lancedb e
config.toolsAllow non è impostato, Active Memory mantiene il comportamento LanceDB esistente
e usa invece memory_recall.
Se usi un altro plugin di memoria, imposta config.toolsAllow sui nomi esatti degli strumenti
registrati da quel plugin. Active Memory elenca questi strumenti nel prompt di recall
e passa lo stesso elenco al sub-agente incorporato. Se nessuno degli strumenti
configurati è disponibile, oppure il sub-agente di memoria fallisce, Active Memory
salta il recall per quel turno e la risposta principale continua senza contesto di memoria.
toolsAllow accetta solo nomi concreti di strumenti di memoria. I caratteri jolly, le voci
group:* e gli strumenti dell’agente core come read, exec, message e
web_search vengono ignorati prima dell’avvio del sub-agente di memoria nascosto.
Nota sul comportamento predefinito: Active Memory non include più memory_recall nella
allowlist predefinita di memory-core. Le configurazioni memory-lancedb esistenti continuano a funzionare
quando plugins.slots.memory è impostato su memory-lancedb. Un toolsAllow esplicito
sovrascrive sempre il valore predefinito automatico.
memory-core integrato
La configurazione predefinita non richiede untoolsAllow esplicito:
Memoria LanceDB
Il pluginmemory-lancedb incluso espone memory_recall. Selezionare lo
slot di memoria è sufficiente perché Active Memory usi quello strumento di recall:
Lossless Claw
Lossless Claw è un plugin di motore di contesto con i propri strumenti di recall. Installalo e configuralo prima come motore di contesto; consulta Motore di contesto. Poi consenti ad Active Memory di usare gli strumenti di recall di Lossless Claw:lcm_expand in toolsAllow per il sub-agente principale di Active Memory.
Lossless Claw lo usa come strumento di espansione delegata di livello inferiore.
Opzioni avanzate
Queste opzioni non fanno intenzionalmente parte della configurazione consigliata.config.thinking può sovrascrivere il livello di thinking del sub-agente di memoria bloccante:
config.promptAppend aggiunge istruzioni operatore aggiuntive dopo il prompt predefinito di Active
Memory e prima del contesto della conversazione:
promptAppend con un toolsAllow personalizzato quando un plugin di memoria non core richiede
un ordine degli strumenti specifico del provider o istruzioni per modellare le query.
config.promptOverride sostituisce il prompt predefinito di Active Memory. OpenClaw
aggiunge comunque il contesto della conversazione in seguito:
NONE
oppure un contesto compatto di fatti utente per il modello principale.
Persistenza delle trascrizioni
Le esecuzioni del sub-agente di memoria bloccante di Active Memory creano una vera trascrizionesession.jsonl durante la chiamata al sub-agente di memoria bloccante.
Per impostazione predefinita, quella trascrizione è temporanea:
- viene scritta in una directory temporanea
- viene usata solo per l’esecuzione del sub-agente di memoria bloccante
- viene eliminata immediatamente al termine dell’esecuzione
config.transcriptDir.
Usalo con attenzione:
- le trascrizioni del sub-agente di memoria bloccante possono accumularsi rapidamente nelle sessioni intense
- la modalità di query
fullpuò duplicare molto contesto della conversazione - queste trascrizioni contengono contesto del prompt nascosto e memorie richiamate
Configurazione
Tutta la configurazione di Active Memory si trova sotto:| Chiave | Tipo | Significato |
|---|---|---|
enabled | boolean | Abilita il plugin stesso |
config.agents | string[] | ID degli agenti che possono usare la memoria attiva |
config.model | string | Riferimento facoltativo al modello del sotto-agente di memoria bloccante; se non impostato, la memoria attiva usa il modello della sessione corrente |
config.allowedChatTypes | ("direct" | "group" | "channel")[] | Tipi di sessione che possono eseguire Active Memory; per impostazione predefinita usa sessioni in stile messaggio diretto |
config.allowedChatIds | string[] | Allowlist facoltativa per conversazione applicata dopo allowedChatTypes; gli elenchi non vuoti falliscono in modalità chiusa |
config.deniedChatIds | string[] | Denylist facoltativa per conversazione che prevale sui tipi di sessione consentiti e sugli ID consentiti |
config.queryMode | "message" | "recent" | "full" | Controlla quanta conversazione vede il sotto-agente di memoria bloccante |
config.promptStyle | "balanced" | "strict" | "contextual" | "recall-heavy" | "precision-heavy" | "preference-only" | Controlla quanto il sotto-agente di memoria bloccante è propenso o rigoroso quando decide se restituire memoria |
config.toolsAllow | string[] | Nomi concreti degli strumenti di memoria che il sotto-agente di memoria bloccante può chiamare; il valore predefinito è ["memory_search", "memory_get"], oppure ["memory_recall"] quando plugins.slots.memory è memory-lancedb; wildcard, voci group:* e strumenti dell’agente core vengono ignorati |
config.thinking | "off" | "minimal" | "low" | "medium" | "high" | "xhigh" | "adaptive" | "max" | Override avanzato del ragionamento per il sotto-agente di memoria bloccante; valore predefinito off per la velocità |
config.promptOverride | string | Sostituzione avanzata dell’intero prompt; non consigliata per l’uso normale |
config.promptAppend | string | Istruzioni extra avanzate aggiunte al prompt predefinito o sovrascritto |
config.timeoutMs | number | Timeout rigido per il sotto-agente di memoria bloccante, limitato a 120000 ms |
config.setupGraceTimeoutMs | number | Budget di configurazione extra avanzato prima della scadenza del timeout di recupero; valore predefinito 0 e limite a 30000 ms. Vedi tolleranza per l’avvio a freddo per la guida all’aggiornamento a v2026.4.x |
config.maxSummaryChars | number | Numero massimo totale di caratteri consentiti nel riepilogo della memoria attiva |
config.logging | boolean | Emette log della memoria attiva durante l’ottimizzazione |
config.persistTranscripts | boolean | Mantiene su disco le trascrizioni del sotto-agente di memoria bloccante invece di eliminare i file temporanei |
config.transcriptDir | string | Directory relativa delle trascrizioni del sotto-agente di memoria bloccante nella cartella delle sessioni dell’agente |
| Chiave | Tipo | Significato |
|---|---|---|
config.maxSummaryChars | number | Numero massimo totale di caratteri consentiti nel riepilogo della memoria attiva |
config.recentUserTurns | number | Turni utente precedenti da includere quando queryMode è recent |
config.recentAssistantTurns | number | Turni assistente precedenti da includere quando queryMode è recent |
config.recentUserChars | number | Numero massimo di caratteri per turno utente recente |
config.recentAssistantChars | number | Numero massimo di caratteri per turno assistente recente |
config.cacheTtlMs | number | Riutilizzo della cache per query identiche ripetute (intervallo: 1000-120000 ms; valore predefinito: 15000) |
config.circuitBreakerMaxTimeouts | number | Salta il recupero dopo questo numero di timeout consecutivi per lo stesso agente/modello. Si reimposta dopo un recupero riuscito o dopo la scadenza del cooldown (intervallo: 1-20; valore predefinito: 3). |
config.circuitBreakerCooldownMs | number | Per quanto tempo saltare il recupero dopo l’attivazione del circuit breaker, in ms (intervallo: 5000-600000; valore predefinito: 60000). |
Configurazione consigliata
Inizia conrecent.
/verbose on per la
normale riga di stato e /trace on per il riepilogo di debug di active-memory invece
di cercare un comando di debug active-memory separato. Nei canali di chat, queste
righe diagnostiche vengono inviate dopo la risposta principale dell’assistente anziché prima.
Poi passa a:
messagese vuoi una latenza inferiorefullse decidi che il contesto extra vale un sotto-agente di memoria bloccante più lento
Tolleranza per l’avvio a freddo
Prima di v2026.5.2 il plugin estendeva silenziosamente il tuotimeoutMs configurato di
altri 30000 ms durante l’avvio a freddo, così il riscaldamento del modello, il caricamento dell’indice di embedding e
il primo recupero potevano condividere un budget più ampio. v2026.5.2 ha spostato questa tolleranza
dietro una configurazione esplicita setupGraceTimeoutMs: il tuo timeoutMs configurato
ora è il budget predefinito, a meno che tu non scelga esplicitamente di abilitarla.
Se hai aggiornato da v2026.4.x e hai impostato timeoutMs su un valore ottimizzato per il
vecchio mondo con tolleranza implicita (il valore iniziale consigliato timeoutMs: 15000 è un
esempio), imposta setupGraceTimeoutMs: 30000 per estendere l’hook di costruzione del prompt e
i budget del watchdog esterno riportandoli ai valori effettivi precedenti alla v5.2:
setupGraceTimeoutMs, così il plugin non estende più silenziosamente
le configurazioni da 15000 ms a 45000 ms sulla corsia principale.”
Il runner di richiamo integrato usa lo stesso budget di timeout effettivo, quindi
setupGraceTimeoutMs copre sia il watchdog esterno di costruzione del prompt sia
l’esecuzione di richiamo bloccante interna.
Per i Gateway con risorse limitate in cui la latenza di cold start è un compromesso noto,
funzionano anche valori più bassi (5000-15000 ms): il compromesso è una probabilità maggiore
che il primissimo richiamo dopo un riavvio del Gateway restituisca un risultato vuoto mentre
il warm-up termina.
Debugging
Se Active Memory non compare dove ti aspetti:- Conferma che il plugin sia abilitato in
plugins.entries.active-memory.enabled. - Conferma che l’id dell’agente corrente sia elencato in
config.agents. - Conferma che stai eseguendo il test tramite una sessione di chat interattiva persistente.
- Attiva
config.logging: truee osserva i log del Gateway. - Verifica che la ricerca in memoria funzioni con
openclaw memory status --deep.
maxSummaryChars
- abbassa
queryMode - abbassa
timeoutMs - riduci il numero di turni recenti
- riduci i limiti di caratteri per turno
Problemi comuni
Active Memory si appoggia alla pipeline di richiamo del plugin di memoria configurato, quindi la maggior parte delle sorprese di richiamo sono problemi del provider di embedding, non bug di Active Memory. Il percorso predefinitomemory-core usa memory_search e memory_get; lo
slot memory-lancedb usa memory_recall. Se usi un altro plugin di memoria,
conferma che config.toolsAllow nomini gli strumenti che quel plugin registra effettivamente.
Il provider di embedding è cambiato o ha smesso di funzionare
Il provider di embedding è cambiato o ha smesso di funzionare
Se
memorySearch.provider non è impostato, OpenClaw rileva automaticamente il primo
provider di embedding disponibile. Una nuova chiave API, l’esaurimento della quota o un
provider ospitato soggetto a rate limit possono cambiare quale provider viene risolto tra
un’esecuzione e l’altra. Se non viene risolto alcun provider, memory_search può degradare
a un recupero solo lessicale; gli errori di runtime dopo che un provider è già stato selezionato
non eseguono automaticamente il fallback.Fissa esplicitamente il provider (e un fallback opzionale) per rendere la selezione
deterministica. Vedi Ricerca in memoria per l’elenco completo
dei provider e gli esempi di pinning.Il richiamo sembra lento, vuoto o incoerente
Il richiamo sembra lento, vuoto o incoerente
- Attiva
/trace onper mostrare nella sessione il riepilogo di debug Active Memory di proprietà del plugin. - Attiva
/verbose onper vedere anche la riga di stato🧩 Active Memory: ...dopo ogni risposta. - Osserva i log del Gateway per
active-memory: ... start|done,memory sync failed (search-bootstrap)o errori di embedding del provider. - Esegui
openclaw memory status --deepper ispezionare il backend di ricerca in memoria e lo stato dell’indice. - Se usi
ollama, conferma che il modello di embedding sia installato (ollama list).
Il primo richiamo dopo il riavvio del Gateway restituisce `status=timeout`
Il primo richiamo dopo il riavvio del Gateway restituisce `status=timeout`
Su v2026.5.2 e versioni successive, se la configurazione a cold start (warm-up del modello + caricamento
dell’indice di embedding) non è terminata quando parte il primo richiamo, l’esecuzione
può raggiungere il budget
timeoutMs configurato e restituire status=timeout
con output vuoto. I log del Gateway mostrano active-memory timeout after Nms
intorno alla prima risposta idonea dopo un riavvio.Vedi Grace di cold start in Configurazione consigliata per il
valore setupGraceTimeoutMs consigliato.