Speicher-Backends

Alle Backends implementieren dasselbe MemoryService trait, sodass Sie eines auswählen können, indem Sie ein Feature-Flag aktivieren und es konstruieren — Ihr Agent-Code ändert sich nicht. Es gibt sechs.

Auf einen Blick

(Das bi-temporale GraphMemoryService ist ein siebter Aspekt, der auf einer eigenen Seite behandelt wird — Knowledge graph.)

InMemory — hier starten

Keine Einrichtung. Alles bleibt im Prozess und verschwindet beim Beenden.

use adk_memory::InMemoryMemoryService;
let memory = InMemoryMemoryService::new();

Perfekt für die Entwicklung und die Testsuite; tauschen Sie es mit einer einzigen Codezeile gegen ein dauerhaftes Backend aus, da das Trait identisch ist.

SQLite — eine Datei

Dauerhaft, Einzeldatei, kein Server. Großartig für Desktop-Apps und Single-Node-Dienste.

use adk_memory::SqliteMemoryService;
let memory = SqliteMemoryService::new("sqlite://memory.db").await?;
// or build from an existing pool: SqliteMemoryService::from_pool(pool)

Postgres + pgvector — semantische Suche für die Produktion

Das Backend für echte Ähnlichkeitssuche. Es speichert Embeddings in pgvector und lässt Sie die Indexstrategie wählen.

use adk_memory::{PostgresMemoryService, VectorIndexType};

let memory = PostgresMemoryService::builder(pool, embedding_provider)
    .vector_index(VectorIndexType::Hnsw { m: 32, ef_construction: 128 })  // or IvfFlat / None
    .build()
    .await?;

VectorIndexType::None führt eine exakte (Brute-Force-)Suche durch – gut für kleine Datensätze; Hnsw (die Standardeinstellung) und IvfFlat skalieren auf große. Die Vektorsuche benötigt einen Embedding-Anbieter.

Redis, MongoDB, Neo4j

Verwenden Sie diese, wenn Sie die Infrastruktur bereits betreiben:

use adk_memory::{RedisMemoryService, RedisMemoryConfig};
use std::time::Duration;

let memory = RedisMemoryService::new(RedisMemoryConfig {
    url: "redis://localhost:6379".into(),
    ttl: Some(Duration::from_secs(60 * 60 * 24 * 30)),   // optional expiry
}).await?;

MongoMemoryService::new(...) und Neo4jMemoryService::new(...) folgen der gleichen Form. Alle respektieren die (app, user, project) Isolation aus Konzepte.

Embeddings

Backends, die eine Vektor-Ähnlichkeit durchführen (Postgres, optional Mongo), müssen Text in Vektoren umwandeln. Stellen Sie ein EmbeddingProvider bereit:

#[async_trait]
pub trait EmbeddingProvider: Send + Sync {
    async fn embed(&self, texts: &[String]) -> Result<Vec<Vec<f32>>>;
}

Schlüsselwort-Backends (InMemory, SQLite, Redis) benötigen keines. Passen Sie das Embedding- Modell, das Sie indizieren, an das an, mit dem Sie abfragen.

Migrationen

Die SQL-gestützten Dienste führen versionierte, idempotente Migrationen aus, um ihr Schema zu erstellen und zu aktualisieren, sodass die Bereitstellung einer neuen Version keine manuelle DDL erfordert. Rufen Sie beim Start die migrate() des Dienstes auf (oder lassen Sie die Konstruktion dies übernehmen).

Auswahl

• Erstellung / Testen → InMemory.
• Einzelner Knoten, soll persistent sein → SQLite.
• Echter semantischer Abruf in großem Maßstab → Postgres + pgvector.
• Sie betreiben bereits Redis / Mongo / Neo4j → dieses Backend.
• Sie möchten ein abfragbares Modell des Benutzers, kein Transkript → GraphMemoryService.

Weiter: Wissensgraph →