Bewertung und Vergleich

Dimensionen der Architekturbewertung

Die Bewertung von Agenten-Gedächtnissystemen erfordert den Blick über oberflächliche Vektorsuchen hinaus auf die Produktionskernarchitektur: Datenmodell, Mandantenisolationsgrenzen, Konsistenzgarantien, Protokollkonformität, Latenz und Maschinenlesbarkeit.

• Speichermodell: Hybride relationale Metadaten mit Vektoreinbettungen im Vergleich zu reinen flachen Vektorspeichern. Die relationale Basis gewährleistet exaktes Filter-Pushdown, unveränderliche Prüfprotokolle und deterministische Bereichspartitionierung.
• Mandantenisolation: Hardware- oder servererzwungene Mandantenpartitionen im Vergleich zu filternden Metadaten auf Anwendungsebene. Geteilte Agentenräume erfordern kryptografisch signierte Raumbindungen.
• Konsistenzgarantien: Read-Your-Writes-Konsistenz über verteilte Tool-Aufrufe hinweg im Vergleich zu Fenstern eventualer Konsistenz, die in kontinuierlichen Agentenschleifen Halluzinationen verursachen.
• Protokollkonformität: Native Model Context Protocol (MCP) Streamable HTTP-Endpunkte im Vergleich zu proprietären Wrappern, die pro Framework eigene SDK-Adapter erfordern.
• Maschinenlesbarkeit: Strukturierte, deterministische JSON-Antworten, die strikt den Tool-Schemas entsprechen, ohne Konversationstext oder prosaische Anhänge.

Was bei jeder Speicherebene zu bewerten ist

Bewerten Sie jedes Agenten-Gedächtnissystem anhand von sieben grundlegenden Produktionsdimensionen: Scope-Isolation, Aufrufer-Attribution, Lebenszyklus-Löschung, Protokollintegration, Nebenläufigkeits-Ratenbegrenzungen, reproduzierbare Benchmarks und planabhängige Funktionen.

• Scope-Isolation: Fragen Sie jeden Anbieter, wie Benutzer-, Sitzungs-, Agenten- und Workspace-Speicher partitioniert werden. XMemo erzwingt eine 4-stufige orthogonale Scope-Hierarchie (user, session, agent, team/space) mit erstklassiger Projektisolation an der Speichergrenze (siehe /docs/concepts/scopes und /docs/concepts/projects).
• Zurechnung und Herkunft: Fragen Sie jeden Anbieter, ob jede Schreib- und Änderungsoperation auf eine verifizierte Aufruferidentität und ein Quellereignis zurückgeführt werden kann. XMemo erfasst Aufruferzurechnung, Agenteninstanz-Fingerabdrücke und Herkunfts-Metadaten in Prüfprotokollen und bewahrt den Versionsverlauf (superseded-Versionen) mit Aktualisierungs-DAGs auf (siehe /docs/concepts/agent-instance-identity und /docs/concepts/memory-model).
• Löschung und Export: Fragen Sie jeden Anbieter, wie die Plattform Tombstone-Soft-Deletion, permanente Inhaltsredaktion und Massendatenexport unterstützt. XMemo bietet gesteuerte Lebenszyklus-Zustände (active, archived, deleted), Soft-Delete mit Wiederherstellung, permanente Inhaltsredaktion und strukturierten JSON-Export (siehe /docs/concepts/memory-deletion und /docs/api/memory).
• MCP- und REST-Integration: Fragen Sie jeden Anbieter, ob die Speicherebene native Unterstützung für das Model Context Protocol (MCP) neben standardmäßigen REST-Endpunkten bietet. XMemo stellt einen nativen Streamable HTTP MCP-Server bereit, der einen eingefrorenen Standardwerkzeugkatalog neben authentifizierten REST-Endpunkten unter /v1/ bereitstellt (siehe /docs/mcp/overview und /docs/api/authentication).
• Ratenbegrenzungen: Fragen Sie jeden Anbieter, wie Anfragedurchsatz und Nebenläufigkeitsgrenzen erzwungen und an Clients kommuniziert werden. XMemo erzwingt eine Laufzeit-Ratenbegrenzung über die api-authentication-Schicht statt veröffentlichter statischer Quoten, und Clients dürfen keine festen Quotenannahmen treffen (siehe /docs/api/authentication).
• Reproduzierbare Benchmarks: Fragen Sie jeden Anbieter, ob Behauptungen zu Retrieval-Genauigkeit und Latenz mit offenen Testumgebungen und deterministischen Datensätzen unabhängig überprüfbar sind. XMemo veröffentlicht repository-eigene Benchmark-Verträge mit deterministischen Golden-Set-Datensätzen (recall_golden_set.jsonl) und unveränderlichen Ausführungsaufzeichnungen, die In-Memory-Auswertungen strikt von Netzwerk-I/O trennen (siehe /docs/guides/evaluate#reproducible-benchmark-methodology).
• Planabhängige Funktionen: Fragen Sie jeden Anbieter, welche Hintergrundprozesse und erweiterten Funktionen in der Basis-Laufzeit enthalten sind und welche von kommerziellen Stufen abhängen. XMemo umfasst Kernspeicherfunktionen, Suche, Recall und das reflect-Tool mit 5 Aktionen in der Basis-Laufzeit, während geplante Dream-Hintergrundreflexion funktionsgesteuert und plan- bzw. berechtigungsabhängig ist (Voreinstellungen: manual, daily oder weekly; siehe /docs/concepts/how-xmemo-works und /docs/concepts/dream-reflection).

{
  "evaluation_checklist": {
    "dimensions": [
      {
        "dimension": "Scope isolation",        "question": "How are user, session, agent, and workspace memories segregated?",        "xmemo_answer": "4-tier orthogonal scope hierarchy (user, session, agent, team/space) enforced at storage boundary (/docs/concepts/scopes)"      },
      {
        "dimension": "Attribution and provenance",        "question": "Can every memory mutation be traced to a specific caller and event?",        "xmemo_answer": "Caller attribution and agent instance fingerprints recorded in audit logs with version history (/docs/concepts/agent-instance-identity)"      },
      {
        "dimension": "Deletion and export",        "question": "Does the system support soft deletion, hard redaction, and data export?",        "xmemo_answer": "Tombstone soft-deletion with restoration, hard redaction, and structured export (/docs/concepts/memory-deletion)"      },
      {
        "dimension": "MCP and REST integration",        "question": "Is the memory layer accessible via native MCP as well as HTTP REST?",        "xmemo_answer": "Native Streamable HTTP MCP server with frozen tool catalog and authenticated REST endpoints (/docs/mcp/overview)"      },
      {
        "dimension": "Rate limits",        "question": "How are request quotas communicated and enforced?",        "xmemo_answer": "Runtime rate limiting governed by api-authentication without hard-coded client quotas (/docs/api/authentication)"      },
      {
        "dimension": "Reproducible benchmarks",        "question": "Are retrieval accuracy and performance metrics independently verifiable?",        "xmemo_answer": "Open repository-owned benchmark harness with deterministic golden set datasets and run traces (/docs/guides/evaluate#reproducible-benchmark-methodology)"      },
      {
        "dimension": "Plan-dependent features",        "question": "Which features are core runtime versus gated by tier entitlements?",        "xmemo_answer": "Core operations and 5-action reflect tool in base runtime; background Dream reflection is plan/entitlement-dependent (/docs/concepts/dream-reflection)"      }
    ]
  }
}

Szenariobasierter Auswahlleitfaden

Bewerten Sie Ihre Workload-Topologie, Teamstruktur und Governance-Anforderungen, um das passende Speicherarchitekturmuster auszuwählen.

• Multi-Agenten-Workflows über mehrere Umgebungen: Wählen Sie eine Speicherebene mit nativer MCP-Unterstützung, geteilten Projekt-Scopes und clientübergreifender Synchronisation, wenn Sie Agenten über Claude Code, Cursor, ChatGPT, Codex und Gemini CLI hinweg orchestrieren.
• Regulierte und Unternehmens-Arbeitsbereiche: Bevorzugen Sie Architekturen mit orthogonalen Gültigkeitsbereich-Hierarchien (user, session, agent, team/space), Prüfprotokollen zur Aufruferzurechnung und hardware- oder servererzwungenen Mandantengrenzen.
• Hochgradig nebenläufige autonome Schleifen: Wählen Sie Architekturen mit versionierten Aktualisierungsbäumen, optimistischem Sperren und Read-Your-Writes-Konsistenz, um widersprüchliche Aktualisierungen und veraltete Speicherhalluzinationen zu verhindern.

Reproduzierbare Benchmark-Methodik

XMemo bietet ein offenes, repository-eigenes Benchmark-Framework zur Bewertung von Abrufgenauigkeit und Governance-Vorgaben unter kontrollierten Bedingungen. Das System unterscheidet strikt zwischen interner synthetischer Bewertung, realer Produktionslatenz und verifizierten öffentlichen Angaben.

• Methodik-Vertrag: Benchmarks folgen einem festen, reproduzierbaren Methodenvertrag mit deterministischen Golden-Datensätzen und aufgezeichneten Verifizierungsspuren.
• Interne synthetische Benchmarks: Werden hermetisch über scripts/benchmark_runner.py mit tests/data/recall_golden_set.jsonl (SHA-256 7533FBDC...) ausgeführt, um die reine In-Memory-Abrufqualität und Ranking-Logik ohne Netzwerk- oder Datenbank-I/O zu messen.
• Reale Produktionslatenz: Die End-to-End-Latenz umfasst TLS-Handshake, Netzwerktransit, Datenbanktransaktionen und Mandantenisolationsaufwand. Sie variiert je nach Bereitstellungstopologie (Cloud-SaaS vs. selbst gehostetes Docker) und geografischer Distanz und wird nicht durch synthetische In-Memory-Werte repräsentiert.
• Öffentliche Leistungsangaben: Alle ausgewiesenen Kennzahlen müssen eine unveränderliche benchmark_run_id sowie den Rohprüfbericht aus Verifizierungsläufen referenzieren. Unverifizierte Herstellerangaben und synthetische Abkürzungen sind von den Baseline-Zusicherungen ausgeschlossen.
• Fehlerfallanalyse: Dokumentierter Randfall, bei dem gleichnamige Entitäten ('config.py' in zwei unterschiedlichen Projektbereichen) ohne explizite Projektbereichsqualifizierung in Ranking-Konflikte gerieten; gelöst durch Hinzufügen expliziter Projektbereichsbeschränkungen.

# Execute reproducible retrieval benchmark against golden set
python scripts/benchmark_runner.py \
  --track standard \
  --dataset tests/data/recall_golden_set.jsonl \
  --cache-state COLD_CACHE \
  --output reports/custom_run_raw.json

Migration zu XMemo

Die Migration von herkömmlichen Key-Value-, Vektor- oder externen Speichersystemen zu XMemo erfolgt in vier strukturierten Phasen.

• Phase 1: Exportieren Sie bestehende Speicherelemente als JSON Lines mit text, user_id, session_id und created_at-Zeitstempeln.
• Phase 2: Mappen Sie Bezeichner auf die XMemo-Bereichshierarchie (user_id auf owner, session_id auf agent_instance_id oder project_id) und kategorisieren Sie Fakten nach Beständigkeit.
• Phase 3: Importieren Sie über das Batch-Tool remember oder die REST-API (/v1/memories) mit entsprechenden Bereichs- und Herkunftsattributen.
• Phase 4: Validieren Sie die Abrufgenauigkeit und Mandantenisolationsgrenzen mit recall_context, bevor Sie Agenten-Schreibberechtigungen aktivieren.

import requests

def migrate_legacy_record(legacy_item, api_key):
    payload = {
        "content": legacy_item["content"],
        "path": f"migration/{legacy_item.get('id', 'item')}",
        "scope": "project" if legacy_item.get("project_id") else "user",
        "metadata": {"source": "legacy_migration", "original_id": legacy_item.get("id")}
    }
    response = requests.post(
        "https://xmemo.dev/v1/memories",
        headers={"Authorization": f"Bearer {api_key}"},
        json=payload
    )
    response.raise_for_status()
    return response.json()

Bekannte Einschränkungen und Betriebsgrenzen

Um Fehlanwendungen zu vermeiden, beachten Sie die Betriebsgrenzen und bewussten Architekturentscheidungen von XMemo.

• Keine relationale Universaldatenbank: XMemo ist für Agentenfakten, -zustände und -fähigkeiten optimiert und ersetzt keine primäre Anwendungsdatenbank für beliebige SQL-Transaktionen.
• Kein unstrukturierter Datei-Dump: Dokumente von mehr als 32 KB sollten in Knowledge Bases indiziert werden, anstatt als einzelne Inline-Speichereinträge abgelegt zu werden.
• Dream-Reflexionszyklus: Die reflect-API- und MCP-Tool-Oberfläche stellt keinen Scheduler bereit; Hintergrund-Dream-Scheduling ist Feature-Flag- und plan-/berechtigungsabhängig (Voreinstellungen: manual [Standard], daily um 03:00 Uhr lokaler Eigentümerzeit oder weekly), und die Konsolidierung erfolgt nicht synchron zu Schreibvorgängen.
• Ratenbegrenzungen: Gehostete Endpunkte erzwingen Laufzeit-Ratenbegrenzungen gemäß api-authentication statt veröffentlichter statischer Quoten; Clients dürfen keine Quotenannahmen fest einprogrammieren.