# Speichermodell Verstehen Sie dauerhafte Fakten, Entscheidungen, Übergaben und Quellenzuordnungen, bevor Sie eine Integration auswählen. - Canonical: https://docs.xmemo.dev/de/docs/concepts/memory-model - Locale: de-DE - Content-Locale: de-DE - Canonical-Content-Digest: 9ffe2da573b664ce4e37254715ed959c138dfd6b89262c6d0a1bda8dd473291a - Edition-Digest: 878e71a41d2d35f5851ca5c0dacb1034dc397181c187c073840ac0484b21017c - Source-Revision: sha256:310bf66a9ffcf2384ebc6400fad1b1da9d01fa0cdadc9d129c9084e880334e73 ## Was XMemo speichert XMemo speichert dauerhaften Kontext, der auch nach Beendigung des aktuellen Chats oder Tasks nützlich bleibt: Projektfakten, Entscheidungen, Präferenzen, Korrekturen und Übergabenotizen. Flüchtiges Gesprächsrauschen, einmalige Antworten und rohe Tool-Ausgaben gehören nicht in den Speicher. - semantic — dauerhafte Fakten und Entscheidungen, die über Sitzungen hinweg gültig bleiben. - episodic — ein Geschehnis, gebunden an einen konkreten Zeitpunkt in einem Task oder einer Sitzung. - procedural — wie eine Aufgabe in diesem Projekt durchgeführt wird. - working — aktiver Zustand für den aktuell laufenden Task. - identity — stabile Informationen über den Eigentümer oder den Agenten selbst. ## Eine dauerhafte Erinnerung schreiben Ein dauerhafter Schreibvorgang erfordert den Inhalt, einen logischen Pfad, der ihn einem Projekt oder Namensraum zuordnet, und den Speichertyp. Der Pfad ist das Kriterium, nach dem spätere Abrufe filtern. ```ts remember({ content: "Use OAuth for hosted ChatGPT connections.", path: "projects/memory-os/decisions" }) ``` ## Speichertypen im SDK MemoryCandidate.memory_type akzeptiert denselben Satz über das TypeScript SDK, sodass ein normalisiertes Agentenereignis den Typ mitführt, unter dem es gespeichert werden soll. ```ts import { normalizeAgentEvent, toMemoryCandidate } from '@xmemo/client'; const event = normalizeAgentEvent( { type: 'command_completed', command: 'pytest', exit_code: 0, output: '12 passed' }, { source: 'shell', defaultAgentId: 'codex' }, ); console.log(toMemoryCandidate(event).memory_type); // episodic ``` ## Interaktiver Herkunfts- und Lebenszyklus-Walkthrough (Synthetische Demo) Eine schrittweise überprüfbare Lebenszyklus-Demonstration, die Speichererstellung, clientübergreifenden Abruf, Echtzeit-Benutzerkorrektur mit Versionsersetzung (v1 -> v2), Token-Budget-Schutz, Soft-Delete-Tombstone und isolierte synthetische Bereinigung zeigt. Jeder Schritt wird durch verwertbare Laufzeitnachweise ohne Offenlegung echter Benutzerspeicher gestützt: - Schritt 1 [STATE_1_CREATED_ACTIVE_V1]: Agent A (Claude Desktop) schreibt die anfängliche Präferenz mit unveränderlichem Autor, Instanz-Hash und Gerätemetadaten über tools.py::remember — Beleg: Status 200 OK, demo_mem_lifecycle_001@v1, active — Status: [SOURCE_BACKED_PUBLIC_CONTRACT (VERIFIED)] — Grenze: [DEMO_DATA: SYNTHETIC]. - Schritt 2 [STATE_2_ACCESSED_ATTRIBUTED]: Agent B (Codex CLI) im selben autorisierten Bereich ruft den Speicher mit Zitierbeleg und null clientübergreifender Abweichung über tools.py::recall sofort ab — Beleg: Status 200 OK, zitiert demo_mem_lifecycle_001@v1 — Status: [SOURCE_BACKED_PUBLIC_CONTRACT (VERIFIED)] — Grenze: [DEMO_DATA: SYNTHETIC]. - Schritt 3 [STATE_3_CORRECTED_SUPERSEDED_V2]: Benutzer korrigiert Besprechungsraum und -zeit über tools.py::update_memory. VersionController erstellt einen unveränderlichen Snapshot von v1 mit status='superseded' und stuft den aktiven Datensatz auf v2 hoch — Beleg: Status 200 OK, v2, übergeordnet v1, Diff: Room Orion -> Room Polaris — Status: [SOURCE_BACKED_PUBLIC_CONTRACT (VERIFIED)] — Grenze: [DEMO_DATA: SYNTHETIC]. - Schritt 4 [STATE_4_RETRIEVAL_FILTERED]: Nachfolgende recall-Abfrage wählt nur aktives v2 aus, während veraltetes v1 strikt aus dem LLM-Kontextfenster herausgefiltert wird, um Halluzinationen zu verhindern und das Token-Budget zu schonen — Beleg: Status 200 OK, v2 ausgewählt, ersetztes v1 ausgeschlossen — Status: [SOURCE_BACKED_PUBLIC_CONTRACT (VERIFIED)] — Grenze: [DEMO_DATA: SYNTHETIC]. - Schritt 5 [STATE_5_TOMBSTONE_DELETED]: Eigentümer markiert Faktum über tools.py::forget als gelöscht. Es wird sofort von Abrufkandidatenabfragen ausgeschlossen und in die Papierkorbansicht mit Wiederherstellungsaktion verschoben — Beleg: Status 200 OK, status: deleted, Kandidatenanzahl: 0 — Status: [SOURCE_BACKED_PUBLIC_CONTRACT (VERIFIED)] — Grenze: [DEMO_DATA: SYNTHETIC]. - Schritt 6 [STATE_6_RESET_PURGED]: Isolierte Einweg-Bereinigung (reset_synthetic_state) bereinigt Datensätze des Demobereichs auf genau 0 verbleibende Zeilen auf der Festplatte. Der Hard-Reset des persönlichen Kontos (POST /api/v1/me/memories/reset) ist strikt ausgeschlossen — Beleg: teardown_status: SUCCESS_PURGED, residual_rows: 0, account_hard_reset_called: FALSE — Status: [SOURCE_BACKED_PUBLIC_CONTRACT (VERIFIED)] — Grenze: [DEMO_DATA: SYNTHETIC]. ```text +------------------------------------------------------------------------------------------------------------------------+ | [PROVENANCE & LIFECYCLE 6-STATE STATE MACHINE: DISPOSABLE HARNESS WALKTHROUGH] | | | | Agent A (Claude Desktop) XMemo FastMCP & Engine Agent B (Codex CLI) Demo Owner (Supervising) | | [04f9b8c2 / MacBook] [VersionController / Scope] [e81d7a31 / Workstation] [user:demo_owner] | | | | | | | | (1) remember(sync in Orion) | | | | | -------------------------------------> | | | | | | [STATE 1: Created Active v1] | | | | <------------------------------------- | | | | | Receipt: mem-001@v1 | | | | | | | (2) recall(sync) | | | | | | <--------------------------- | | | | | | [STATE 2: Cited @v1] | | | | | | ---------------------------> | | | | | | Citation: mem-001@v1 | | | | | | | (3) update_memory(Polaris) | | | | | <---------------------------------------------------------- | | | | | [STATE 3: Bump v2, Supersede v1] | | | | | ----------------------------------------------------------> | | | | | Receipt: mem-001@v2 (parent: v1) | | | | | | | | | | | (4) recall(Polaris) | | | | | | <--------------------------- | | | | | | [STATE 4: Select v2, | | | | | | Filter superseded v1] | | | | | | ---------------------------> | | | | | | Citation: mem-001@v2 only | | | | | | | (5) forget(mem-001) | | | | | <---------------------------------------------------------- | | | | | [STATE 5: Tombstone / Trash View] | | | | | ----------------------------------------------------------> | | | | | Receipt: status=deleted | | | | | | | | | | | (6) reset_synthetic_state() | | | | | <---------------------------------------------------------- | | | | | [STATE 6: Teardown Purge] | | | | | Scope purged: 0 residual rows (account reset excluded) | | | | | ----------------------------------------------------------> | | | | | Teardown Status: SUCCESS_PURGED | | +------------------------------------------------------------------------------------------------------------------------+ ``` ## ChatGPT-Benutzer Geben Sie ChatGPT dauerhaften Zugriff auf Ihre XMemo-Präferenzen, Projektfakten, Entscheidungen und TODOs, ohne Bearer-Token in einen Chat einzufügen. Verbinden Sie den gehosteten XMemo-MCP-Server über den OAuth-Ablauf der ChatGPT-/OpenAI-App und genehmigen Sie anschließend die Berechtigungen memory:read und memory:write für Ihr XMemo-Konto. Speichern Sie eine synthetische Präferenz oder Projektnotiz, starten Sie einen neuen Chat und fordern Sie ChatGPT auf, diese vor der Fortsetzung der Arbeit über XMemo abzurufen. Wenn OAuth fehlschlägt oder Tools nicht angezeigt werden, melden Sie sich in der Host-App vom MCP-Server ab, verbinden Sie die XMemo-Server-URL erneut und versuchen Sie es noch einmal, bevor Sie direkte Token erstellen. ## Copilot- / Codex-Entwickler Übertragen Sie Repository-Entscheidungen, Programmierkonventionen, Bugfix-Notizen und den Aufgabenverlauf zwischen IDE- und CLI-Agenten. Verwenden Sie OAuth für VS Code / GitHub Copilot und Gemini CLI, sofern verfügbar. Behalten Sie für Copilot CLI, Codex, Cursor oder andere direkte MCP-Clients XMEMO_KEY in der lokalen Umgebung oder im Secret-Store und setzen Sie eine stabile XMEMO_AGENT_INSTANCE_ID. Erfassen Sie eine Codebasis-Entscheidung oder einen Bugfix und fordern Sie den nächsten IDE- oder CLI-Agenten auf, den relevanten XMemo-Kontext vor dem Bearbeiten abzurufen. Wenn Abrufe leer bleiben, überprüfen Sie den ausgewählten MCP-Konfigurationspfad, die Umgebungsvariable XMEMO_KEY für direkte Clients und veraltete OAuth-Anmeldedaten in der Host-App. ## Verantwortlicher für Team- / Enterprise-Pilotprojekte Evaluieren Sie geteilten Speicher mit Kontokontrollen, Quellenzuordnung, Export-/Lösch-Workflows und prüfersicheren Einrichtungsnachweisen. Erstellen oder betreten Sie den geschützten XMemo-Arbeitsbereich, laden Sie freigegebene Benutzer ein und verbinden Sie jeden Client über OAuth oder bereichsbezogene direkte Anmeldedaten gemäß den Bereitschafts-Badges. Lassen Sie ein Mitglied des Pilotprojekts eine synthetische Team-Erinnerung speichern, bestätigen Sie die Quellenzuordnung in XMemo und prüfen Sie anschließend Lösch-/Export- sowie Support-Pfade. Wenn ein Mitglied keine Verbindung herstellen kann, prüfen Sie Rollenberechtigungen, OAuth-Genehmigung, Client-Bereitschaftsstatus und Support-Hinweise, bevor Sie ein neues Token ausstellen. ## Betreiber autonomer Agenten Ermöglichen Sie es Headless- oder zeitgesteuerten Agenten, Fortschritte aufzuzeichnen, frühere Entscheidungen abzurufen und eine stabile, nicht-geheime Instanzidentität beizubehalten. Rufen Sie /api/v1/mcp/config/autonomous-agent ab. Bevorzugen Sie auth_modes.oauth, wenn der Runner OAuth + benutzerdefinierte Header unterstützt; verwenden Sie auth_modes.xmemo_key mit XMEMO_KEY aus einem Secret-Store nur für vollständig autonome Headless-Runner. Führen Sie eine synthetische Aufgabe aus, die den Fortschritt in XMemo schreibt, starten Sie den Runner neu und bestätigen Sie, dass er diesen Fortschritt unter Verwendung derselben XMEMO_AGENT_INSTANCE_ID abruft. Wenn sich die Zuordnung ändert oder Abrufe über Instanzen hinweg aufgeteilt werden, speichern Sie XMEMO_AGENT_INSTANCE_ID außerhalb von Git und stellen Sie sicher, dass der Runner diese nicht bei jedem Start neu generiert.