Un nodo di configurazione che collega un Memory Provider a un nodo Agent in modalità grafo. Consente all'agente di leggere i turni di conversazione precedenti dalla memoria persistente e di scrivere nuovi turni dopo ogni risposta, conferendo all'agente una memoria continua attraverso più esecuzioni del workflow.
memory
· Solo modalità grafo
Per impostazione predefinita, ogni esecuzione del nodo Agent è senza stato — non ha conoscenza di ciò che l'agente ha detto o fatto nelle
esecuzioni precedenti. Il nodo Memory cambia questo. Quando è collegato a un Agent tramite la porta memory_in,
Flusso effettuerà automaticamente:
L'impostazione Ambito controlla il namespace sotto il quale i turni vengono archiviati e recuperati. Questo determina cosa l'agente "ricorda" — se condivide la memoria tra tutte le esecuzioni, all'interno di un singolo workflow, all'interno di una singola esecuzione, o solo all'interno di un singolo step.
I Memory Provider vengono configurati separatamente in Impostazioni → Memory Provider. I backend supportati includono Redis, SQLite, PostgreSQL, vector store e Mem0.
| Campo | Stato | Descrizione |
|---|---|---|
| Memory Provider | Obbligatorio | Seleziona tra i Memory Provider che hai configurato in Impostazioni → Memory Provider. Il provider determina il backend di archiviazione usato per leggere e scrivere i turni. |
| Ambito | Obbligatorio | Controlla la chiave del namespace usata per isolare la memoria. Consulta la tabella di Riferimento Ambiti qui sotto per i dettagli completi. |
| Namespace | Opzionale | Una stringa personalizzata per restringere ulteriormente il namespace della memoria. Ad esempio, potresti usare un ID utente o un ID thread di conversazione per creare una memoria per-utente all'interno di un workflow condiviso. |
| Leggi ultimi N turni | Opzionale | Il numero di turni di conversazione più recenti da iniettare nel contesto dell'agente prima dell'esecuzione. Il valore predefinito è 10. Impostarlo troppo alto aumenta la lunghezza del prompt e i costi API; impostarlo troppo basso potrebbe far perdere all'agente contesto rilevante. |
| Max Token | Opzionale | Un budget di token per la memoria iniettata. Se i turni recuperati superano questo limite, Flusso elimina prima i turni più vecchi fino a quando la cronologia rientra nel budget. Lascia vuoto per nessun limite. |
| Ambito | La memoria è condivisa tra | Ideale per |
|---|---|---|
agent |
Tutte le esecuzioni di questo workflow (per chiave step dell'agente) | Assistenti di lunga durata che dovrebbero ricordare il contesto attraverso più sessioni, come un assistente personale di produttività o un bot di supporto clienti. |
workflow |
Tutte le esecuzioni di questo workflow | Contesto condiviso a cui tutti gli agenti di un workflow possono contribuire e da cui possono leggere, indipendentemente da quale esecuzione ha prodotto i turni. |
run |
Una singola esecuzione del workflow | Ragionamento multi-turno all'interno di una singola esecuzione, dove è necessario che l'agente ricordi step precedenti nella stessa esecuzione ma ricominci da zero ogni volta. |
step |
Uno step all'interno di un'esecuzione | Contesto completamente isolato per-step. Raramente necessario, ma utile quando vuoi che ogni chiamata dell'agente sia completamente indipendente anche all'interno della stessa esecuzione. |
Questo esempio collega un nodo Memory a un Agent in modo che l'assistente ricordi la cronologia della conversazione tra le sessioni.
agent. Imposta Leggi ultimi N turni su 20. Nel campo Namespace, inserisci {{ trigger.output.user_id }} per creare un archivio di memoria separato per utente.
memory_in (Mm) sul tuo nodo Agent.
{{ trigger.output.user_id }}. Senza questo, tutti gli utenti condivideranno lo stesso pool di memoria.
memory_in. Se hai bisogno di memoria da più ambiti, gestisci l'unione in uno step personalizzato prima dell'esecuzione dell'agente.