Agent-Memory verwenden

Jede Managed-Agents-Session („session", Sitzung) startet standardmäßig mit einem frischen Kontext. Wenn eine Session endet, ist jeglicher Zustand, den der Agent aufgebaut hat, verloren. Memory Stores ermöglichen es dem Agenten, Informationen über Sessions hinweg mitzunehmen: Nutzerpräferenzen, Projektkonventionen, frühere Fehler und Domänenkontext.



Überblick

Ein Memory Store („memory store", Gedächtnisspeicher) ist eine auf den Workspace beschränkte Sammlung von Textdokumenten, die für Claude optimiert ist. Wenn du einen Store an eine Session anhängst, wird er als Verzeichnis innerhalb der Sandbox der Session eingebunden. Der Agent liest und schreibt ihn mit denselben Datei-Tools, die er für den Rest des Dateisystems verwendet, und eine Notiz, die jeden Mount beschreibt, wird automatisch zum System-Prompt hinzugefügt und teilt dem Agenten mit, wo er nachsehen soll. Das Agent-Toolset ist für diese Interaktionen erforderlich; stelle sicher, dass du es bei der Agent-Erstellung aktivierst.

Jede Memory („memory", Gedächtniseintrag) in einem Store wird über einen Pfad adressiert und kann direkt über die API oder die Claude Console gelesen und bearbeitet werden, was Feinabstimmung, Import und Export ermöglicht.

Jede Änderung an einer Memory erzeugt eine unveränderliche Memory-Version („memory version"), die dir einen Audit-Trail und eine zeitpunktgenaue Wiederherstellung für alles bietet, was der Agent schreibt.



Einen Memory Store erstellen

Gib dem Store einen name und eine description. Die Beschreibung wird an den Agenten weitergegeben und teilt ihm mit, was der Store enthält.

store_id=$(ant beta:memory-stores create \
  --name "User Preferences" \
  --description "Per-user preferences and project context." \
  --transform id --raw-output)

Die id des Memory Stores (memstore_...) ist das, was du beim Anhängen des Stores an eine Session übergibst.



Mit Inhalten vorbefüllen (optional)

Befülle einen Store vorab mit Referenzmaterial, bevor ein Agent läuft:

ant beta:memory-stores:memories create \
  --memory-store-id "$store_id" \
  --path "/formatting_standards.md" \
  --content "All reports use GAAP formatting. Dates are ISO-8601..." \
  > /dev/null



Einen Memory Store an eine Session anhängen

Memory Stores werden im resources[]-Array der Session angehängt, wenn die Session erstellt wird. Anders als Datei-Ressourcen können Memory Stores nur zum Zeitpunkt der Session-Erstellung angehängt werden; das Hinzufügen oder Entfernen eines Stores bei einer laufenden Session wird nicht unterstützt.

Füge optional instructions hinzu, um sessionspezifische Hinweise dazu zu geben, wie der Agent diesen Store verwenden soll. Sie werden dem Agenten zusammen mit name und description des Stores angezeigt und sind auf 4.096 Zeichen begrenzt.

Du kannst auch access konfigurieren. Der Standardwert ist read_write (im folgenden Beispiel explizit gezeigt), aber read_only wird ebenfalls unterstützt.

ant beta:sessions create <<YAML
agent: $agent_id
environment_id: $environment_id
resources:
  - type: memory_store
    memory_store_id: $store_id
    access: read_write
    instructions: User preferences and project context. Check before starting any task.
YAML

Pro Session werden maximal 8 Memory Stores unterstützt. Hänge mehrere Stores an, wenn verschiedene Teile des Gedächtnisses unterschiedliche Eigentümer oder Zugriffsregeln haben. Häufige Gründe:

• Gemeinsam genutztes Referenzmaterial: ein schreibgeschützter Store, der an viele Sessions angehängt ist (Standards, Konventionen, Domänenwissen), getrennt vom eigenen Read-Write-Store jeder Session.
• Abbildung auf die Struktur deines Produkts: ein Store pro Endnutzer, pro Team oder pro Projekt, während eine einzige Agent-Konfiguration gemeinsam genutzt wird.
• Unterschiedliche Lebenszyklen: ein Store, der jede einzelne Session überdauert, oder einer, den du nach eigenem Zeitplan archivieren möchtest.



Wie der Agent auf Memory zugreift

Jeder angehängte Store wird innerhalb der Sandbox der Session als Verzeichnis unter /mnt/memory/ eingebunden. Der Verzeichnisname ist der Anzeigename des Stores, bereinigt zu einem dateisystemsicheren Slug (kleingeschrieben; Folgen nicht-alphanumerischer Zeichen werden zu einem einzelnen Bindestrich), sodass ein Store namens „Demo Memory" unter /mnt/memory/demo-memory/ eingebunden wird. Der genaue Pfad wird im Feld mount_path der Memory-Store-Ressource der Session zurückgegeben; lies ihn von dort aus, anstatt ihn selbst zu konstruieren. Der Agent liest und schreibt den Store mit dem standardmäßigen Agent-Toolset. Schreibvorgänge unter dem Mount-Pfad werden in den Store zurückgeschrieben und bleiben über Sessions hinweg, die ihn gemeinsam nutzen, synchron; Schreibvorgänge auf jeden anderen Pfad unter /mnt/memory/ schlagen fehl, da die Sandbox dieses übergeordnete Verzeichnis schreibgeschützt einbindet. Eine kurze Beschreibung jedes Mounts (Anzeigename, Mount-Pfad, Zugriffsmodus, description des Stores und etwaige instructions) wird automatisch zum System-Prompt hinzugefügt.

access wird auf Dateisystemebene durchgesetzt: Ein read_only-Mount lehnt Schreibvorgänge ab, während Schreibvorgänge auf einen read_write-Mount Memory-Versionen erzeugen, die der Session zugeordnet werden.

Die Lese- und Schreibvorgänge des Agenten erscheinen im Event-Stream als gewöhnliche agent.tool_use- und agent.tool_result-Events für das jeweilige Tool, das den Mount berührt hat.



Memories anzeigen und bearbeiten

Memory Stores können direkt über die API verwaltet werden. Nutze dies, um Review-Workflows aufzubauen, fehlerhafte Memories zu korrigieren oder Stores vorzubefüllen, bevor eine Session läuft.



Memories auflisten

Liste die Memories in einem Store auf. Ergebnisse werden in einer stabilen, serverseitig definierten Reihenfolge zurückgegeben.

• path_prefix beschränkt die Liste auf ein Verzeichnis. Es muss mit / enden und gleicht ganze Pfadsegmente ab, sodass path_prefix=/notes/ /notes/todo.md zurückgibt, aber nicht /notes-archive/todo.md.
• depth steuert, wie tief die Auflistung unterhalb von path_prefix geht: Lass es weg (oder übergib 0), um den gesamten Teilbaum aufzulisten, oder übergib 1, um nur die unmittelbaren Kinder aufzulisten. Andere Werte geben einen 400-Fehler zurück.

ant beta:memory-stores:memories list \
  --memory-store-id "$store_id" \
  --path-prefix "/"

Siehe die Referenz zu „List memories" für vollständige Parameter und das Antwortschema.



Eine Memory lesen

Das Abrufen einer einzelnen Memory gibt den vollständigen Inhalt zurück.

ant beta:memory-stores:memories retrieve \
  --memory-store-id "$store_id" \
  --memory-id "$mem_id"

Siehe die Referenz zu „Retrieve a memory" für vollständige Parameter und das Antwortschema.



Eine Memory erstellen

memories.create erstellt eine Memory unter einem gegebenen path. Create überschreibt nicht; um eine bestehende Memory zu ändern, verwende memories.update.

mem=$(ant beta:memory-stores:memories create \
  --memory-store-id "$store_id" \
  --path "/preferences/formatting.md" \
  --content "Always use tabs, not spaces." \
  --format json)
mem_id=$(jq -r '.id' <<< "$mem")
mem_sha=$(jq -r '.content_sha256' <<< "$mem")

Siehe die Referenz zu „Create a memory" für vollständige Parameter und das Antwortschema.



Eine Memory aktualisieren

memories.update ändert eine bestehende Memory anhand ihrer ID. Du kannst content, path (eine Umbenennung) oder beides ändern. Das Beispiel benennt eine Memory in einen Archivpfad um:

ant beta:memory-stores:memories update \
  --memory-store-id "$store_id" \
  --memory-id "$mem_id" \
  --path "/archive/2026_q1_formatting.md" \
  > /dev/null

Siehe die Referenz zu „Update a memory" für vollständige Parameter und das Antwortschema.



Sichere Inhaltsänderungen (optimistische Nebenläufigkeit)

Um einen gleichzeitigen Schreibvorgang nicht zu überschreiben, übergib eine content_sha256-Vorbedingung. Die Aktualisierung wird nur angewendet, wenn der gespeicherte Inhalts-Hash noch mit dem übereinstimmt, den du gelesen hast; bei einer Abweichung lies die Memory erneut und versuche es gegen den aktuellen Zustand erneut.

ant beta:memory-stores:memories update \
  --memory-store-id "$store_id" \
  --memory-id "$mem_id" \
  --content "CORRECTED: Always use 2-space indentation." \
  --precondition "{type: content_sha256, content_sha256: $mem_sha}" \
  > /dev/null



Eine Memory löschen

ant beta:memory-stores:memories delete \
  --memory-store-id "$store_id" \
  --memory-id "$mem_id" \
  > /dev/null

Siehe die Referenz zu „Delete a memory" für vollständige Parameter und das Antwortschema.



Memory-Änderungen auditieren

Jede Mutation einer Memory erzeugt eine unveränderliche Memory-Version (memver_...). Verwende die Versions-Endpunkte, um zu auditieren, wer was wann geändert hat, um einen früheren Snapshot zu inspizieren oder wiederherzustellen und um sensible Inhalte mit Redact aus der Historie zu entfernen.

Versionen gehören zum Store (nicht zur einzelnen Memory) und bleiben auch dann erhalten, wenn die Memory selbst gelöscht wird, sodass der Audit-Trail vollständig bleibt. Versionen werden 30 Tage lang aufbewahrt; die jüngsten Versionen werden jedoch unabhängig vom Alter immer behalten, sodass Memories, die sich selten ändern, möglicherweise eine Historie über 30 Tage hinaus behalten. Der Live-Aufruf memories.retrieve gibt immer die neueste Version zurück; die Versions-Endpunkte liefern dir die aufbewahrte Historie.

Es gibt keinen dedizierten Restore-Endpunkt; um zurückzurollen, rufe die gewünschte Version ab und schreibe ihren content mit memories.update zurück (oder mit memories.create, falls die übergeordnete Memory gelöscht wurde, da Versionen ihre übergeordnete Memory überdauern).

Frühere Memory-Versionen werden möglicherweise nach 30 Tagen gelöscht. Um die Memory-Historie länger aufzubewahren, exportiere Versionen über die API.



Versionen auflisten

Liste die Versionshistorie eines Stores auf, neueste zuerst. Das Beispiel filtert auf die Historie einer einzelnen Memory:

versions=$(ant beta:memory-stores:memory-versions list \
  --memory-store-id "$store_id" \
  --memory-id "$mem_id" \
  --format json)
# `list --format json` gibt ein JSON-Objekt pro Element aus.
jq -r '"\(.id): \(.operation)"' <<< "$versions"
version_id=$(jq -rs '.[1].id' <<< "$versions")

Siehe die Referenz zu „List memory versions" für vollständige Parameter und das Antwortschema.



Eine Version abrufen

Das Abrufen einer einzelnen Version gibt dieselben Felder wie die Listenantwort zurück, plus den vollständigen content-Body.

ant beta:memory-stores:memory-versions retrieve \
  --memory-store-id "$store_id" \
  --memory-version-id "$version_id"

Siehe die Referenz zu „Retrieve a memory version" für vollständige Parameter und das Antwortschema.



Eine Version schwärzen (Redact)

Redact entfernt Inhalte aus einer historischen Version, während der Audit-Trail (wer was wann getan hat) erhalten bleibt. Verwende es für Compliance-Workflows wie das Entfernen geleakter Secrets, personenbezogener Daten (PII) oder für Löschanfragen von Nutzern.

Eine Version, die der aktuelle Head einer Live-Memory ist, kann nicht geschwärzt werden. Schreibe zuerst eine neue Version (oder lösche die Memory) und schwärze dann die alte.

ant beta:memory-stores:memory-versions redact \
  --memory-store-id "$store_id" \
  --memory-version-id "$version_id"

Siehe die Referenz zu „Redact a memory version" für vollständige Parameter und das Antwortschema.



Memory Stores verwalten

Zusätzlich zu create unterstützen Memory Stores retrieve, update, list, archive und delete.



Stores auflisten

Liste die Stores im Workspace auf. Archivierte Stores sind standardmäßig ausgeschlossen; übergib include_archived: true, um sie einzuschließen.

ant beta:memory-stores list --include-archived

Siehe die Referenz zu „List memory stores" für vollständige Parameter und das Antwortschema.



Einen Store archivieren

Das Archivieren macht einen Store schreibgeschützt und verhindert, dass er an neue Sessions angehängt wird. Archivieren ist eine Einbahnstraße; es gibt kein Entarchivieren.

ant beta:memory-stores archive --memory-store-id "$store_id"

Siehe die Referenz zu „Archive a memory store" für vollständige Parameter und das Antwortschema.

Um einen Store zusammen mit all seinen Memories und Versionen dauerhaft zu entfernen, verwende memory_stores.delete.



Best Practices für die Memory-Verwaltung

Wenn ein Store sein Limit von 2.000 Memories erreicht, schlagen Schreibvorgänge für neue Memories fehl: sowohl direkte memories.create-Aufrufe als auch Dateischreibvorgänge des Agenten auf nicht zugeordnete Pfade. Bestehende Memories bleiben lesbar und bearbeitbar. Die folgenden Praktiken helfen dir, deutlich unter dem Limit zu bleiben und dich geordnet zu erholen, falls du es erreichst.

• Verwende fokussierte Stores. Statt eines großen Allzweck-Stores verwende kleinere, zweckgebundene Stores: einen pro Nutzer, einen für gemeinsam genutztes Domänenwissen und einen für projektspezifischen Kontext. Jeder Store hat sein eigenes Limit von 2.000 Memories, sodass eng gefasste Stores die Wahrscheinlichkeit verringern, dass ein einzelner voll wird.

• Verdichte oder bereinige, bevor der Store voll wird. Lösche veraltete oder redundante Memories mit memories.delete. Du kannst auch eine Dreaming-Session ausführen, die fragmentierte Inhalte in einem separaten neuen Ausgabe-Store konsolidiert, anstatt das Original zu verändern. Stelle deine Sessions auf diesen Ausgabe-Store um und archiviere oder lösche dann das Original.

• Hänge einen neuen Store an, wenn es sinnvoll ist. Wenn ein Store über seinen nützlichen Umfang hinausgewachsen ist, hänge einen frischen für neue Inhalte an und hänge das Original mit read_only-Zugriff an. Der Agent kann aus beiden lesen, während er nur in den neuen schreibt.

• Beschränke den Schreibzugriff, wo es angemessen ist. Sessions, die nur gemeinsam genutztes Referenzmaterial lesen, benötigen kein read_write. Wenn der Schreibzugriff auf Sessions beschränkt bleibt, die tatsächlich neue Memories hinzufügen, lässt sich leichter nachvollziehen, woher das Wachstum kommt.