Mémoire

Donnez à vos agents une mémoire qui survit à une seule conversation. L’état de session contient cette conversation ; la mémoire est le stockage à long terme qu’un agent consulte au début d’un tour et auquel il écrit au fur et à mesure qu’il apprend — ainsi, la session suivante connaît déjà l’utilisateur.

Cette section vous guide depuis le début : les deux types de mémoire que ADK-Rust propose, les types fondamentaux, les backends, le graphe de connaissances bi-temporel et la manière de tout connecter à un agent.

Vous découvrez ADK-Rust ? Lisez d’abord l’Introduction et Sessions et état — la mémoire est le pendant persistant de la session éphémère.

Deux types de mémoire

ADK-Rust fournit deux modèles de mémoire complémentaires derrière le même trait MemoryService, afin qu’un agent puisse utiliser l’un ou l’autre via une seule interface :

Vous n'avez pas besoin de choisir globalement — choisissez pour chaque agent selon que vous avez besoin d'un rappel de type transcription ou d'un modèle propre et interrogeable de l'utilisateur.

Modèle mental

  Agent turn
     │  search_memory(query)         ← recall relevant context at turn start
     ▼
  adk_core::Memory                   ← the interface the agent sees
     │  (MemoryServiceAdapter bridges to…)
     ▼
  MemoryService                      ← add_session / search / delete_user …
     ├─ InMemoryMemoryService        (dev)
     ├─ Sqlite/Postgres/Redis/…      (semantic store)
     └─ GraphMemoryService           (bi-temporal knowledge graph)

• Un MemoryService est le backend de stockage : il stocke des entrées (ou des nœuds de graphe) et répond aux search.
• Un MemoryServiceAdapter l'enveloppe comme un adk_core::Memory, limité à un (app_name, user_id, project_id?), qui est ce que le search_memory d'un agent appelle réellement.
• Le Runner contient le Memory et le met à la disposition de l'agent ; les outils de mémoire permettent à l'agent de rechercher et de gérer délibérément la mémoire.

Installation

# Semantic store — pick the backend you need
adk-memory = { version = "2.1.0", features = ["sqlite-memory"] }

# Bi-temporal knowledge graph
adk-memory = { version = "2.1.0", features = ["graph-memory"] }

Démarrage rapide en 60 secondes

Stockez quelques souvenirs et recherchez-les ensuite :

use adk_memory::{InMemoryMemoryService, MemoryService, MemoryEntry, SearchRequest};
use adk_core::Content;
use chrono::Utc;

# async fn run() -> anyhow::Result<()> {
let memory = InMemoryMemoryService::new();

memory.add_session("support", "alice", "s1", vec![
    MemoryEntry { content: Content::new("user").with_text("I prefer email over phone"),
                  author: "user".into(), timestamp: Utc::now() },
]).await?;

let hits = memory.search(SearchRequest {
    app_name: "support".into(), user_id: "alice".into(),
    query: "how should we contact this customer?".into(),
    ..Default::default()
}).await?;

for entry in hits.entries { println!("{:?}", entry.content); }
# Ok(()) }

Dans un véritable agent, vous n’appelez pas search manuellement — vous rattachez le service au Runner et laissez l’agent se rappeler et organiser les souvenirs lui-même.

Où aller ensuite

1. Concepts — MemoryEntry, le trait MemoryService, la recherche, le périmètre du projet et l’effacement conforme au RGPD.
2. Backends — les six magasins, les indicateurs de fonctionnalités et la manière de choisir.
3. Graphe de connaissances — GraphMemoryService et pourquoi la temporalité bitemporelle est importante.
4. Outils et agents — intégrer la mémoire aux agents ; remember/relate et les outils de mémoire.