Speicher

Geben Sie Ihren Agents einen Speicher, der über eine einzelne Unterhaltung hinaus Bestand hat. Der Sitzungsstatus enthält diese Unterhaltung; der Speicher ist der Langzeitspeicher, aus dem ein Agent zu Beginn eines Durchlaufs liest und in den er beim Lernen zurückschreibt – sodass die nächste Sitzung den Benutzer bereits kennt.

Dieser Abschnitt führt Sie von Grund auf durch das Thema: die zwei Arten von Speicher, die ADK-Rust anbietet, die zentralen Typen, die Backends, den bi-temporalen Wissensgraphen und die Einbindung all dessen in einen Agenten.

Neu bei ADK-Rust? Lesen Sie zuerst die Einführung und Sitzungen und Status – der Speicher ist das persistente Gegenstück zur flüchtigen Sitzung.

Zwei Arten von Speicher

ADK-Rust stellt zwei sich ergänzende Speichermodelle hinter demselben MemoryService-Trait bereit, sodass ein Agent beide über eine einzige Schnittstelle verwenden kann:

Du musst dich nicht global festlegen – wähle dies pro Agent danach aus, ob du eine erinnerungsartige Wiedergabe oder ein sauberes, abfragbares Modell des Benutzers benötigst.

Das mentale Modell

  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)

• Ein MemoryService ist das Speicher-Backend: Es speichert Einträge (oder Graphknoten) und beantwortet search.
• Ein MemoryServiceAdapter kapselt es als adk_core::Memory, mit dem Geltungsbereich eines (app_name, user_id, project_id?), den der search_memory eines Agents tatsächlich aufruft.
• Der Runner enthält Memory und stellt ihn dem Agent zur Verfügung; Speicher-Tools ermöglichen es dem Agent, den Speicher gezielt zu durchsuchen und zu kuratieren.

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"] }

Schnellstart in 60 Sekunden

Speichere ein paar Erinnerungen und rufe sie wieder ab:

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(()) }

In einem echten Agenten rufst du search nicht von Hand auf – du hängst den Dienst an den Runner an und lässt den Agenten die Erinnerungen selbst abrufen und verwalten.

Wie es weitergeht

1. Konzepte – MemoryEntry, das MemoryService-Trait, Suche, Projektabgrenzung, DSGVO-Löschung.
2. Backends – die sechs Speicher, Feature-Flags und die Auswahl des passenden Speichers.
3. Wissensgraph – GraphMemoryService und warum die bitemporale Modellierung wichtig ist.
4. Tools und Agenten – Einbindung des Speichers in Agenten; remember/relate und die Speicher-Tools.