marm-memory

Beiträge sind willkommen! Durchsuchen Sie offene Issues, um beizutragen, oder treten Sie dem MARM Discord bei, um Workflows auszutauschen, Hilfe bei der Einrichtung zu erhalten und sich mit anderen Entwicklern zu vernetzen.

Inhaltsverzeichnis

• Schnellstart

• Warum MARM Memory

• Leistungs- und Skalierungsbenchmarks

• MCP-Client-Einrichtung

• Runtime-CLI-Befehle

• Komplette MCP-Tool-Suite

• MARM verwenden: Reden, nicht Tools aufrufen

• MARM Memory verstehen

• Wissensgraphen: Code & Konzepte

• Architektur & Interna

• Fehlerbehebung

• Mitwirken

• Projektdokumentation

Related MCP server: Memory Crystal MCP Server

Schnellstart

1. Installieren und initialisieren Sie mit Ihren bevorzugten Agenten-Profilen:

pip install marm-mcp-server
marm-memory init --g-claude --g-codex --g-gemini

Auch verfügbar: --g-qwen und --g-kiro. Führen Sie ohne Flags aus, um in Ihrem aktuellen Projektordner statt im Home-Verzeichnis zu installieren

1. Übergeben Sie die Aufgabe an Ihren KI-Begleiter. Sagen Sie Ihrem Agenten:

„Verwende die Fähigkeit marm-init, um MARM einzurichten.“

1. Interagieren: Ihr Agent übernimmt die gesamte Einrichtung (Python/Docker, HTTP/STDIO, Schlüssel und Client-Konfigurationen) interaktiv direkt in Ihrem Chat.

Manuelle Einrichtung

Bevorzugen Sie es, selbst einzurichten:

Ersetzen Sie „agent“ durch den CLI-Befehl Ihres Clients (z. B. claude, gemini oder qwen). Für Codex verwenden Sie stattdessen codex mcp add marm-memory --url http://localhost:8001/mcp.

• ⚡ Schnellster HTTP-Start: Führen Sie marm-memory fast-start-http aus, um die lokale Laufzeit zu starten, die Konsole zu öffnen und sie sofort im Browser zu öffnen.

• 🖥️ Web-Konsole: Führen Sie marm-memory console aus, um die lokale UI-App sofort anzuzeigen (kein Node.js erforderlich).

• ⚙️ Lebenszyklus-Management: Verwalten Sie den Hintergrund-Daemon mit status, logs --follow, restart und stop.

• 💡 Schnell-Flags: Verwenden Sie --no-console oder --no-browser, um Starts einzuschränken. Führen Sie marm-memory --help für eine vollständige Befehlsliste aus.

Warum MARM Memory

Ihre KI vergisst alles. MARM Memory nicht.

marm-memory gibt Ihren Agenten einen privaten, gemeinsamen Speicher für den Kontext, der normalerweise zwischen Chats verloren geht: Entscheidungen, Recherchen, Fehlerbehebungen, Notizen und Projekthistorie. Wechseln Sie von Claude Code zu Codex oder Gemini, ohne den bereits gesammelten Kontext zu verlieren.

Es bringt drei Dinge zusammen:

• 🧠 Kernspeicher (7 Tools) speichert Gespräche, Notizen, Notizbucheinträge und Zusammenfassungen, sodass sie durchsuchbar bleiben.

• 💻 Code-Graph (5 Tools) kartiert Ihr Repository, sodass Agenten Symbole finden, Codepfade verfolgen und das Projekt verstehen können, ohne es erneut lesen zu müssen. Richten Sie es einmal auf ein Repository aus und es hält sich während Ihrer Arbeit selbst aktuell.

• 🧩 Konzept-Graph (2 Tools) verbindet Personen, Entscheidungen, Fehler und Ideen aus Ihren gespeicherten Erinnerungen, mit Verweisen auf relevanten Code, falls verfügbar. Er baut sich selbst auf, während Sie Erinnerungen speichern.

Alle 14 Tools funktionieren über HTTP und STDIO. Ihre Agenten teilen sich denselben lokalen Speicher über Sitzungen hinweg, anstatt jedes Mal von vorne zu beginnen. Die integrierte Konsole ermöglicht es Ihnen, das Gespeicherte zu sehen und zu verwalten.

Wie es funktioniert

Siehe Leistungs- und Skalierungsbenchmarks für Abruflatenz, Parallelität und Schreibkostenzahlen sowie Architektur & Interna für die Mechanismen hinter jeder Ebene.

Runtime-CLI-Befehle

marm-memory ist der lokale Laufzeit-Manager, der mit dem Python-Paket installiert wird. Dies sind die normalen Betriebsbefehle; verwenden Sie marm-memory <befehl> --help für Flags und befehlsspezifische Beispiele.

Tägliche Runtime-Arbeit

marm-memory fast-start-http                # start HTTP, Console, and open the browser
marm-memory start                          # start or reuse the managed HTTP runtime
marm-memory start --profile swarm          # shared multi-agent preset
marm-memory stop                           # stop the managed runtime safely
marm-memory restart                        # restart the managed runtime
marm-memory status                         # inspect runtime, database, queue, and graph status
marm-memory logs --follow                  # follow bounded runtime logs
marm-memory console                        # start or reuse the bundled local Console

Transports und Einrichtung

marm-memory http                           # run HTTP in the foreground
marm-memory stdio                          # run the strict local MCP STDIO transport
marm-memory init                           # install the MARM skill into detected agents (project scan)
marm-memory init --g-claude                # install the skill into the home-folder claude directory
marm-memory doctor                         # diagnose the local install
marm-memory key init                       # create or reuse ~/.marm/.env without displaying the key
marm-memory key path                       # print the managed key-file path
marm-memory key reveal                     # explicitly display the managed key
marm-memory console --import-key           # open an authenticated local Console session
marm-memory upgrade --check                # compare the installed package with PyPI
marm-memory uninstall                      # preview package removal; always preserves ~/.marm

Wissen, Projekte und Wartung

marm-memory knowledge status               # Indexers, models, and how far behind automatic indexing is
marm-memory knowledge build --all          # Rebuild the whole concept graph (new memories index themselves)
marm-memory knowledge auto off             # Stop indexing memories automatically (on, off, status)
marm-memory projects list                  # List all tracked workspaces
marm-memory projects index <path>          # Add a repo to the code graph (kept current after that)
marm-memory projects status                # Inspect target repo graph readiness
marm-memory projects auto off              # Stop re-indexing repos automatically (on, off, status)
marm-memory maintenance status             # Check internal database optimization state
marm-memory maintenance embeddings migrate # Upgrade old 384-dim vectors to 512-dim
marm-memory maintenance chunks rechunk     # Recalibrate long memory text splits

Docker-Befehle sind unten separat dokumentiert, da sie explizite Daten-Mounts, Netzwerk-Exposition und Schlüssel-Handhabungsentscheidungen erfordern.

Leistungs- und Skalierungsbenchmarks

MARM ist zuerst auf schnellen Abruf optimiert, selbst wenn der Speicher wächst und lange Erinnerungen im Hintergrund in Blöcke aufgeteilt werden.

Diese Messungen verwenden den fastembed-gestützten Encoder jinaai/jina-embeddings-v2-small-en und eine lokale SQLite-Datenbank zum Wegwerfen. Jeder zeitlich gemessene Pfad ruft den ausgelieferten MARMMemory-Code auf, keine benchmark-lokale Neuimplementierung. Die Abschnitte 1-4 sind Zeitmessungen von einem einzelnen Durchlauf von scripts/benchmarking/performance/bench_hotpath.py auf lokaler Hardware; absolute Millisekunden variieren je nach Maschine, behandeln Sie daher die Skalierungsform als Signal. Abschnitt 5 ist ein separater Genauigkeits-Benchmark (run_eval.py) und berichtet zwei Durchläufe, aus dem dort angegebenen Grund.

1. Abruf-Latenz-Skalierung

Ende-zu-Ende-Latenz von recall_similar (beinhaltet Query-Kodierung).

Die Lauf-zu-Lauf-Varianz bei kleinem $N$ ist größer als der Abstand zwischen benachbarten Größen, weshalb hier N = 250 langsamer liest als N = 500. Behandeln Sie den Trend ab N = 1.000 aufwärts als das reale Signal.

2. Encoder + Parallelität

• Kaltes Modell laden: 893ms

• Warmer Encode: Median 3,8ms, p95 4,3ms

• Gleichzeitiger Abruf: 10 gesammelte Abrufe wurden in 151,5ms abgeschlossen vs. 176,0ms seriell (gather/serial = 0,86). Interpretieren Sie das nicht als Parallelität: Wiederholte Durchläufe desselben Benchmarks landen irgendwo zwischen 0,63 und 0,86, daher ist das Verhältnis nicht stabil genug, um einen Geschwindigkeitsvorteil zu behaupten. Der Pfad ist standardmäßig um die gemeinsam genutzte Encoder- und SQLite-Arbeit serialisiert, und jeder scheinbare Gewinn ist Messrauschen.

3. Schreibzeit-Aufnahmekosten

• Konsolidierung aus: Median 6,5ms, p95 7,6ms

• Konsolidierung an: Median 58,1ms, p95 106,5ms

• Kompromiss: Deduplizierung/Clustering zum Schreibzeitpunkt erhöht die medianen Kosten um das 9,0-fache, damit der Abruf schnell bleibt und der Speicher mit der Zeit sauberer bleibt. Die Konsolidierung ist standardmäßig deaktiviert.

4. Abruf-Skalierung: Vollständiger Scan vs. Produktions-Hybrid

Warum der Recall flach bleibt, während das Gedächtnis wächst: Statt jeden Vektor zu scannen, verwendet der Produktions-Recall einen FTS-Keyword-Pre-Filter, um den Kandidatenpool einzugrenzen, und bewertet dann neu mit einer gemischten semantischen + BM25 + zeitlichen Bewertung. Beide Benchmark-Spalten repräsentieren authentische asynchrone Codepfade, die mit vorberechneten Vektoren zeitlich gemessen wurden, um die Retrieval-Geschwindigkeit vom reinen Encoding-Overhead zu isolieren. Die Tests werden abwechselnd ausgeführt, um vollständig unvoreingenommene Cache-Bedingungen zu gewährleisten.

Der vollständige Scan wächst etwa linear mit $N$, während der hybride Recall weitaus langsamer wächst, sodass der Vorteil mit der Sitzungsgröße weiter zunimmt. Bei sehr kleinen $N$ ist der Pre-Filter seinen Overhead nicht wert, und der hybride ist langsamer.

5. LoCoMo Abrufgenauigkeit

Alle 10 LoCoMo-Unterhaltungen werden über marm_log_entry (5.882 Erinnerungen) aufgenommen, dann werden die Top-5-Ergebnisse von marm_smart_recall gegen 1.977 belegannotierte Fragen bewertet. Es wird kein Antwortgenerierungsmodell oder LLM-Richter verwendet.

Die Leistungssteigerungen sind auf die gemischte Abrufpipeline und den lokalisierten Vektorraum beschränkt, was eine hohe Multi-Hop-Abrufgenauigkeit gewährleistet, ohne auf Cloud-gehostete LLM-Richter angewiesen zu sein. Reproduzieren Sie den vollständigen Benchmark mit scripts/benchmarking/accuracy/locomo/run_eval.py.

6. vs Mitbewerber: Architektur

MARM zielt auf eine bestimmte Nische: lokales Gedächtnis für MCP-verbundene Codierungsagenten, nicht allgemeines Personalisierungsgedächtnis oder eine vollständige Agentenlaufzeit. So unterscheidet es sich architektonisch von etablierten Namen im KI-Agentengedächtnis:

Haftungsausschlüsse & Genauigkeit: Die Wettbewerbslandschaft verändert sich schnell. Die obige Matrix spiegelt die grundlegenden architektonischen Merkmale zum Stand Q3 2026 wider, basierend auf öffentlichen Dokumentationen und READMEs, nicht auf internen Tests jedes Systems. Falls sich ein Datenpunkt zu einem alternativen Framework geändert hat oder falsch dargestellt wird, öffnen Sie bitte ein Issue oder reichen Sie einen Pull Request ein, um die Tabelle zu aktualisieren. Wir begrüßen aktiv Korrekturen von Betreuern vergleichbarer Projekte.

MCP-Client-Setup für HTTP & STDIO

Manuelle pip-Installation

pip install marm-mcp-server

Verwenden Sie diese Faustregel, um Ihr Setup zu wählen

• Lokales HTTP/STDIO = schnellstes Einzelmaschinen-Setup.

• Docker HTTP = gemeinsam genutzter / immer verfügbarer Server (Schlüssel erforderlich).

• Docker STDIO = privater containerisierter lokaler Gebrauch (kein HTTP-Schlüssel).

Hinweis für Schwarm-/Multi-Agent: Die Schreibwarteschlange ist standardmäßig aktiviert, um Speicherschreibvorgänge über einen Worker zu serialisieren. Für gemeinsam genutzte HTTP-Bereitstellungen verwenden Sie marm-memory start --profile swarm (200 RPM) oder --profile swarm-max (600 RPM). --profile trusted deaktiviert die Ratenbegrenzung vollständig für private Bereitstellungen. STDIO ist immer noch am besten für private Einzel-Agenten-/lokale Nutzung. Siehe Schwarm- & Multi-Agent-Voreinstellungen für die vollständige Tabelle.

„Agent“ bezieht sich auf Claude, Gemini, Grok, Qwen oder jeden MCP-Client. Codex verwendet --url anstelle von --transport, um MCP-Tools hinzuzufügen.

pip install marm-mcp-server
marm-memory start
# Stuck on client setup? Open a Q&A thread: https://github.com/Lyellr88/marm-memory/discussions
# most agents use this --transport command
"agent" mcp add --transport http marm-memory http://localhost:8001/mcp
codex mcp add marm-memory --url http://localhost:8001/mcp

Der standardmäßige pip/lokale Start ist ohne Konfiguration: MARM bindet an localhost und benötigt keinen Schlüssel, es sei denn, Sie legen ihn mit SERVER_HOST=0.0.0.0 offen.

pip install marm-mcp-server
python -m marm_mcp_server.server_stdio
# most agents use this --transport command
"agent" mcp add --transport stdio marm-memory-stdio marm-mcp-stdio
codex mcp add marm-memory-stdio -- marm-mcp-stdio

Ersetzen Sie marm-mcp-stdio durch python -m marm_mcp_server.server_stdio, wenn Sie eine virtuelle Umgebung oder ein pfadbasiertes Setup verwenden. Funktioniert mit Claude Code, Cursor, VS Code, Qwen und Gemini CLI. STDIO bleibt ein einzelner lokaler Prozess ohne Port und ohne API-Schlüssel und stellt dieselben 14 Tools wie HTTP bereit.

Verwenden Sie HTTP, wenn mehrere Agenten einen gemeinsamen MARM-Server verwenden müssen. STDIO ist immer noch am besten für private Einzel-Agenten-Nutzung, da jeder Client seinen eigenen lokalen Prozess besitzt.

# HTTP shared server, normal multi-agent use
marm-memory start --profile swarm

# HTTP shared server, heavier private swarm
marm-memory start --profile swarm-max

# HTTP trusted private lab/server, rate limiting disabled
marm-memory start --profile trusted

# STDIO remains keyless/private and does not use swarm flags
marm-mcp-stdio

Docker-HTTP erfordert einen API-Schlüssel, da es MARM als Netzwerkserver bereitstellt; STDIO bleibt lokal zum Client-Prozess und benötigt keinen Schlüssel.

Wenn Sie MARM über pip installiert haben, kann die Produkt-CLI dasselbe Setup sicher in der Vorschau anzeigen oder ausführen. Sie verwendet standardmäßig einen Loopback-Port, bewahrt ~/.marm, speichert den generierten Schlüssel in ~/.marm/.env anstatt in der Shell-Historie und weigert sich, einen vorhandenen Container zu ersetzen.

marm-memory docker command                 # preview the exact HTTP command
marm-memory docker run                     # create the managed HTTP container
marm-memory docker stdio-command           # print a Docker STDIO client command
marm-memory docker status
marm-memory docker logs --follow
marm-memory docker stop

# Optional: mount repositories read-only for code indexing.
marm-memory docker run --repo /absolute/path/to/repository

# Optional: preview or explicitly write a Compose configuration.
marm-memory docker compose
marm-memory docker compose --yes

Die HTTP-Befehle run, command und compose akzeptieren dieselben operativen Flags:

Zum Beispiel:

# Shared local server with a custom data path and two repositories for indexing.
marm-memory docker command \
  --profile swarm \
  --data-dir /srv/marm-data \
  --repo /srv/projects/api \
  --repo /srv/projects/web

# Execute the reviewed command, pulling the image first.
marm-memory docker run --profile swarm --data-dir /srv/marm-data --pull

Docker STDIO ist getrennt von Docker HTTP: marm-memory docker stdio-command verwendet docker run -i --rm, hat keinen Port und keinen Bearer-Key, mountet aber trotzdem das Datenverzeichnis, sodass der SQLite-Speicher nach dem Beenden des kurzlebigen Containers erhalten bleibt. Verwenden Sie bei Bedarf --data-dir und --tag mit diesem Befehl. Es gibt keine separaten Befehle docker key oder docker mount; --env-file und --data-dir machen diese Entscheidungen im generierten HTTP-Befehl explizit.

marm-memory docker pull lädt nur ein Image herunter. marm-memory docker maintenance embeddings migrate wird gegen denselben Daten-Mount ausgeführt und verweigert, während der verwaltete HTTP-Container läuft. Der Helfer ist nur mit dem per pip installierten Befehl marm-memory verfügbar; Nur-Docker-Benutzer können die untenstehenden Rohbefehle verwenden.

# Step 1: generate key (do not add < > around the key)
docker run --rm lyellr88/marm-mcp-server:latest --generate-key

# Step 2: run server
docker pull lyellr88/marm-mcp-server:latest
docker run -d --name marm-mcp-server \
  -p 127.0.0.1:8001:8001 \
  -e SERVER_HOST=0.0.0.0 \
  -e MARM_API_KEY=your-generated-key \
  -v ~/.marm:/home/marm/.marm \
  lyellr88/marm-mcp-server:latest

# Step 3: connect client
"agent" mcp add --transport http marm-memory http://localhost:8001/mcp --header "Authorization: Bearer your-generated-key"

# PowerShell: set this before starting/restarting Codex
$env:MARM_API_KEY="your-generated-key"
codex mcp add marm-memory --url http://localhost:8001/mcp --bearer-token-env-var MARM_API_KEY

# Quick auth smoke test
curl -i -H "Authorization: Bearer $env:MARM_API_KEY" http://127.0.0.1:8001/mcp

--bearer-token-env-var akzeptiert den Namen der Umgebungsvariable, nicht den rohen Schlüssel. Starten oder starten Sie Codex aus derselben Shell neu, nachdem Sie $env:MARM_API_KEY gesetzt haben. Für lokale Docker-Smoke-Tests ist MARM_API_KEY=test in Ordnung und vermeidet Shell-Escape-Probleme; verwenden Sie für echte Bereitstellungen einen generierten Schlüssel. Ein 406 Not Acceptable vom Smoke-Test GET /mcp bedeutet, dass die Authentifizierung den MCP-Endpunkt erreicht hat; 401 Unauthorized bedeutet, dass der Schlüssel fehlt oder nicht übereinstimmt.

# --swarm: write queue on, 200 RPM - recommended for multi-agent shared servers
docker run -d --name marm-mcp-server \
  -p 127.0.0.1:8001:8001 \
  -e SERVER_HOST=0.0.0.0 \
  -e MARM_API_KEY=your-generated-key \
  -v ~/.marm:/home/marm/.marm \
  lyellr88/marm-mcp-server:latest --swarm

Docker-Graph-Tools laufen innerhalb des Containers, daher können sie Host-Pfade nicht sehen, es sei denn, Sie mounten sie bei docker run.

$env:MARM_API_KEY="test"

# The second -v line mounts your repo; adjust the host path to your project
docker run -d --name marm-mcp-server `
  -p 127.0.0.1:8001:8001 `
  -e SERVER_HOST=0.0.0.0 `
  -e MARM_API_KEY=$env:MARM_API_KEY `
  -v ~/.marm:/home/marm/.marm `
  -v C:\Users\lyell\Desktop\marm-memory:/workspace/marm-memory `
  lyellr88/marm-mcp-server:latest

Indizieren Sie dann den Container-Pfad, nicht den Windows-Host-Pfad:

marm_graph_index(repo_path="/workspace/marm-memory")

Graph-Tools müssen den Container-Pfad verwenden. Mounts können nicht zu einem bereits laufenden Container hinzugefügt werden; stoppen und starten Sie den Container mit dem Repository-Mount neu, wenn Sie Docker-Graph-Indizierung wünschen.

Docker STDIO enthält die gleichen integrierten marm-graph-Tools; kein zusätzliches Image oder Installationsschritt erforderlich.

docker run --rm -i \
  -v ~/.marm:/home/marm/.marm \
  --entrypoint python \
  lyellr88/marm-mcp-server:latest \
  -m marm_mcp_server.server_stdio

• Docker HTTP benötigt einen Schlüssel; Docker STDIO nicht.

• Wenn Sie 401 erhalten, überprüfen Sie die Schlüsselübereinstimmung und den Client-Neustart nach Änderungen an Umgebungsvariablen.

• Für vollständige Schlüsseleinrichtung, Rotation und Fehlerbehebung: INSTALL-DOCKER.md

Verbinden Sie Ihren Client

Starten Sie den Server (python -m marm_mcp_server), dann verbinden Sie Ihren Client unten. Jeder Block geht von der standardmäßigen lokalen Installation aus (kein Schlüssel). Für Docker oder exponierte Server fügen Sie den Authorization: Bearer-Header hinzu, der im aufklappbaren Bereich jedes Clients gezeigt wird.

claude mcp add --transport http marm-memory http://localhost:8001/mcp

Claude Code unterstützt HTTP, SSE und STDIO über claude mcp add; verwenden Sie HTTP für MARM. Für STDIO: claude mcp add --transport stdio marm-memory-stdio marm-mcp-stdio.

Fügen Sie in Ihrem Arbeitsbereich zu .vscode/mcp.json hinzu. Verwenden Sie marm-memory-local für direkte Python-Installationen; marm-memory-docker für Docker oder exponierten/Schlüssel-Modus.

{
  "inputs": [
    {
      "type": "promptString",
      "id": "marm-api-key",
      "description": "MARM API Key for Docker or exposed server mode",
      "password": true
    }
  ],
  "servers": {
    "marm-memory-local": {
      "type": "http",
      "url": "http://localhost:8001/mcp"
    },
    "marm-memory-docker": {
      "type": "http",
      "url": "http://localhost:8001/mcp",
      "headers": {
        "Authorization": "Bearer ${input:marm-api-key}"
      }
    }
  }
}

Öffnen Sie .vscode/mcp.json, klicken Sie auf Start über dem gewünschten Server, dann verwenden Sie Copilot Agent oder eine beliebige Erweiterung, die das native MCP-Register von VS Code nutzt.

Fügen Sie in Ihrem Arbeitsbereich zu .cursor/mcp.json hinzu. Cursor verwendet mcpServers, nicht das servers-Root von VS Code.

{
  "mcpServers": {
    "marm-memory-local": {
      "type": "http",
      "url": "http://localhost:8001/mcp"
    },
    "marm-memory-docker": {
      "type": "http",
      "url": "http://localhost:8001/mcp",
      "headers": {
        "Authorization": "Bearer ${env:MARM_API_KEY}"
      }
    }
  }
}

Für den Docker/Schlüssel-Modus starten Sie Cursor mit gesetztem MARM_API_KEY in der Umgebung.

Codex verwendet codex mcp add oder TOML-Konfiguration unter ~/.codex/config.toml (%USERPROFILE%\.codex\config.toml unter Windows).

# Direct Python install - no key needed
codex mcp add marm-memory --url http://localhost:8001/mcp

# Docker or SERVER_HOST=0.0.0.0 - key required (set MARM_API_KEY in your shell first)
codex mcp add marm-memory --url http://localhost:8001/mcp --bearer-token-env-var MARM_API_KEY

[mcp_servers."marm-memory"]
url = "http://localhost:8001/mcp"
enabled = true
bearer_token_env_var = "MARM_API_KEY"

# Direct Python install - no key needed
gemini mcp add --transport http marm-memory http://localhost:8001/mcp

# Docker or SERVER_HOST=0.0.0.0 - key required
gemini mcp add --transport http marm-memory http://localhost:8001/mcp --header "Authorization: Bearer your-generated-key"

Äquivalente ~/.gemini/settings.json (Benutzerbereich) oder Projekt .gemini/settings.json:

{
  "mcpServers": {
    "marm-memory": {
      "httpUrl": "http://localhost:8001/mcp",
      "headers": {
        "Authorization": "Bearer your-generated-key"
      }
    }
  }
}

# Direct Python install - no key needed
qwen mcp add --transport http marm-memory http://localhost:8001/mcp

# Docker or SERVER_HOST=0.0.0.0 - key required
qwen mcp add --transport http marm-memory http://localhost:8001/mcp --header "Authorization: Bearer your-generated-key"

Äquivalente .qwen/settings.json (Projekt) oder ~/.qwen/settings.json (Benutzer):

{
  "mcpServers": {
    "marm-memory": {
      "httpUrl": "http://localhost:8001/mcp",
      "headers": {
        "Authorization": "Bearer your-generated-key"
      }
    }
  }
}

xAI verbindet sich von seiner eigenen Infrastruktur, daher wird localhost nicht funktionieren. Setzen Sie MARM hinter HTTPS und setzen Sie MARM_API_KEY.

{
  "type": "mcp",
  "server_url": "https://your-marm-domain.example.com/mcp",
  "server_label": "marm-memory",
  "authorization": "Bearer your-generated-key"
}

Vollständige Plattform-Walkthroughs, Schlüsseleinrichtung und OS-spezifische Hinweise: Windows · macOS · Linux · Docker/Schlüssel-Modus · Andere Plattformen

Verwenden Sie einen Client, der nicht aufgeführt ist? Erstellen Sie ein Issue und lassen Sie es uns wissen; Client-Adapter sind eine erstklassige Funktionsanfrage.

Anforderungen

• Python: 3.10 oder höher

• SQLite3: In Python enthalten (keine separate Installation erforderlich)

• Speicher: ~100 MB Minimum für die Ersteinrichtung, skaliert mit der Größe der Speicherdatenbank

• RAM: 512 MB Minimum (variiert je nach gleichzeitigen Clients und Datenbankgröße)

• Betriebssystem: Windows, macOS, Linux

Datenort

• Ort: ~/.marm/ (Linux/macOS) oder %USERPROFILE%\.marm\ (Windows)

• Inhalt: SQLite-Datenbank mit allen Erinnerungen, Sitzungen und Notizbüchern; der Konzeptgraph lebt in einer eigenen ~/.marm/index/-Datenbank

• Backup: Kopieren Sie das gesamte Verzeichnis ~/.marm/, um alle Daten zu erhalten

• Datenschutz: Alles bleibt auf Ihrem Rechner, keine Cloud-Synchronisation oder externer Speicher

Installation überprüfen

Verwenden Sie den MCP-Server-Health-Endpunkt für den schnellsten Live-Check:

curl http://localhost:8001/health

Erwartete Ausgabe enthält Serverversion, Funktionsverfügbarkeit (Status der semantischen Suche), Datenbankverbindungsstatus und Dienst-Health-Status.

Vollständiges MCP-Tool-Suite (14 Tools)

💡 Profi-Tipp: Sie müssen diese Tools nicht manuell aufrufen! Sagen Sie Ihrem KI-Agenten einfach in natürlicher Sprache, was Sie möchten:

• "Claude, protokolliere diese Sitzung als 'Projekt Alpha' und füge diese Unterhaltung als 'Datenbankdesign-Diskussion' hinzu"

• "Merke dir diesen Code-Snippet für später in deinem Notizbuch"

• "Suche nach dem, was wir gestern über Authentifizierung besprochen haben"

Der KI-Agent wird automatisch die entsprechenden Tools verwenden. Manueller Tool-Zugriff ist für Power-User verfügbar, die direkte Kontrolle wünschen.

🧠 Kernspeicher (7 Tools)

🕸️ Code-Graph (5 Tools)

🧩 Konzept-Graph (2 Tools)

Alle 14 Tools sind sowohl über HTTP als auch STDIO verfügbar. Hinter der Tool-Oberfläche kümmert sich der Server automatisch um Lebenszyklus-Setup, Protokollaktualisierung, Docs-Indizierung, Datumskontext, Zusammenfassungs-Cache-Wartung, Schreibwarteschlangen-Handling, Konzept-Indizierung, Code-Neuindizierung bei Repository-Änderungen, Projekt-/Plattform-Zuordnung und Health-Checks; nichts davon verbraucht die Aufmerksamkeit oder Tokens des Agenten. Die beiden Graph-Engines starten träge bei der ersten Verwendung und blockieren niemals die 7 Kernspeicher-Tools, falls sie nicht starten können. Siehe Architektur & Interna für die Mechanismen.

MARM verwenden: Reden, nicht Tools aufrufen

MARM erledigt Lebenszyklus-Arbeiten intern. Docs und Sitzungszustand werden beim ersten echten Tool-Aufruf initialisiert, und verpackte Docs werden mit Quell-Datei-Hash-Verfolgung in den marm_system-Speicher-Namespace indiziert, sodass Ihr Agent MARM-Nutzungsfragen aus dem Speicher selbst beantworten kann.

Beispiel-Workflow: KI-übergreifendes Forschungsprojekt

Ein realistischer Workflow, der MARM in Aktion zeigt. Szenario: Sie recherchieren Authentifizierungsmuster für ein neues Projekt mit mehreren KI-Clients.

Phase 1: Sitzung starten (Claude)

You: "Claude, create a MARM session called 'auth-research-2025-01'"
Claude calls: marm_log_entry(entry="Session: auth-research")
Result: Session routed to auth-research-[today]. MARM lifecycle/docs initialize automatically.

Phase 2: Recherche erfassen (Claude)

You: "Summarize OAuth2 vs JWT for API authentication and save it"
Claude calls: marm_log_entry(entry="Research: OAuth2 is token-based with refresh cycles, better for delegated access. JWT is stateless, good for microservices...", session_name="auth-research-2025-01")
Result: Research captured in the active session log and marked for summary-cache refresh

Phase 3: Wiederverwendbare Referenz hinzufügen (Claude)

You: "Save a JWT validation code snippet to my notebooks as 'jwt-validation-pattern'"
Claude calls: marm_notebook(action="add", name="jwt-validation-pattern", data="def verify_jwt(token):\n  # validation logic...")
Result: Reusable snippet stored for future projects

Phase 4: Kontext abrufen (Gemini)

You: "Gemini, what authentication approaches did we research? Activate the JWT pattern."
Gemini calls: marm_smart_recall("authentication patterns", search_all=True)
Gemini calls: marm_notebook(action="use", names="jwt-validation-pattern")
Result: Gemini sees previous research + has JWT code available as context

Phase 5: Synthese & Zusammenfassung (Qwen)

You: "Qwen, pull everything from the auth research and create a summary"
Qwen calls: marm_smart_recall("authentication", session_name="auth-research-2025-01", limit=20)
Qwen calls: marm_summary(session_name="auth-research-2025-01")
Result: Qwen generates an implementation guide from all captured research

Phase 6: Sitzung beenden (Claude)

You: "Log final decision - we're using JWT for APIs, and OAuth2 for user auth"
Claude calls: marm_log_entry(entry="DECISION: JWT for API auth, OAuth2 for user flows. Rationale: stateless APIs + delegated user access", session_name="auth-research-2025-01")
Result: Decision logged and searchable by all future AI clients

Ergebnis: Drei verschiedene KI-Clients haben kollaborativ ein Thema recherchiert, Erkenntnisse geteilt und Entscheidungen dokumentiert. Alles ohne das Projekt jedem neuen KI erneut erklären zu müssen.

Fortgeschrittene Muster

Project Structure:
├── project-name-planning/          # Initial design and requirements
├── project-name-development/       # Implementation details
├── project-name-testing/           # QA and debugging notes
├── project-name-deployment/        # Production deployment
└── project-name-retrospective/     # Lessons learned

Wissensdatenbank-Schleife:

1. Erfassen: Verwenden Sie marm_log_entry für strukturierte Sitzungserkenntnisse

2. Organisieren: Erstellen Sie thematische Sitzungen für Wissensbereiche

3. Synthetisieren: Regelmäßige marm_summary zur Wissenskonsolidierung

4. Anwenden: Konvertieren Sie Zusammenfassungen in marm_notebook(action="add", ...)-Einträge

Multi-KI-Kollaboration: Jede KI arbeitet in dedizierten Sitzungen an ihren Stärken, nutzt marm_smart_recall, um auf der Arbeit der anderen aufzubauen, und eine kollaborative Sitzung kombiniert dann die Erkenntnisse.

• Sitzungsbenennung: Fügen Sie den LLM-Namen für Querverweise hinzu

• Strategisches Protokollieren: Fokussieren Sie auf wichtige Entscheidungen, Lösungen, Entdeckungen, Konfigurationen

• Globale Suche: Verwenden Sie search_all=True, um über alle Sitzungen zu suchen

• Natürliche Sprachsuche: "Authentifizierungsprobleme mit JWT-Tokens" schlägt "auth error"

• Gestaffelte Abruftiefe: detail=1 gibt eine kurze Zusammenfassungsansicht (~200 Zeichen) zurück, detail=2 eine größere Kontextansicht (~500 Zeichen), detail=3 den vollständigen Speicherinhalt

• Notebook-Stapelung: Kombinieren Sie mehrere Einträge für komplexe Arbeitsabläufe

• Kompaktierung: Lassen Sie MARM Kompaktierungskandidaten anzeigen, verwenden Sie dann marm_compaction, um Zusammenfassungen zu stufen, zu überprüfen, anzuwenden oder zu verwerfen

• Sitzungslebenszyklus: Start → Arbeiten → Referenz → Überprüfen Sie die gestufte Kompaktierung, wenn MARM darum bittet

MARM-Gedächtnis verstehen

Zwei Suchen, zwei sehr unterschiedliche Probleme, ein Werkzeug:

User: "I discussed machine learning algorithms yesterday"
MARM Search: Finds related memories about "ML models", "neural networks", "AI training"

User: "What was the COMPACTION_TRIGGER_COUNT setting?"
MARM Search: Finds the exact config memory even if the rest of the text differs

Die erste Abfrage betrifft Bedeutung, daher bewertet MARM Kandidaten mit lokalen Vektor-Einbettungen neu – RAG-artige semantische Suche ohne gehostete Vektordatenbank. Die zweite ist syntaxförmig (ein Konfigurationsschlüssel), daher erkennt MARM das automatisch und leitet es stattdessen durch deterministisches exaktes Matching. Diese exakte Abrufspur ist der Unterschied zwischen einem Gedächtnissystem, das in Demos funktioniert, und einem, das die Fragen beantwortet, die Entwickler tatsächlich stellen: Konfigurationsschlüssel, CLI-Flags, Dateipfade, API-Namen, Fehlerstrings. Rein semantische Gedächtnissysteme scheitern genau bei solchen Abfragen.

MARM verwendet Filter→Rerank-Hybrid-Abruf plus eine exakte Abrufspur:

1. Exakte Spur (exact_mode="auto", die Standardeinstellung): Konfigurationsschlüssel, CLI-Flags, Dateipfade, API-/Werkzeugnamen, gepunktete Namespaces, HTTP-Routen, URLs und zitierte Befehlsstrings werden erkannt und durch deterministisches FTS5 BM25 mit einem LIKE-Fallback geleitet. Keine Einbettungen beteiligt, daher sind die Ergebnisse stabil und wörtlich.

2. Filter→Rerank-Spur: Natürlichsprachige Abfragen ziehen zuerst eine begrenzte Kandidatenmenge aus dem FTS-Index (FTS_CANDIDATE_LIMIT, Standard 200), dann bewerten semantische Einbettungen diese Kandidaten nach Bedeutung neu. Konservative zeitliche Gewichtung gibt frischeren Erinnerungen einen moderaten Schub, wenn Übereinstimmungen ansonsten nahe beieinanderliegen.

3. Begrenzter semantischer Fallback: Wenn die FTS-Abdeckung schwach oder unbrauchbar ist, fällt MARM auf einen begrenzten semantischen Scan zurück (RECALL_SCAN_LIMIT). Wenn die Antwort recall_scan_truncated=true enthält, hat der Fallback sein Limit erreicht; verengen Sie die Sitzung/Abfrage oder erhöhen Sie die Umgebungsvariable für größere Speicher.

4. Chunk-bewusste Bewertung: Lange Erinnerungen (etwa 180+ Wörter) werden intern als überlappende Chunk-Zeilen eingebettet, und der Abruf kollabiert Chunk-Scores zurück zu einer übergeordneten Erinnerung unter Verwendung des am besten passenden Chunks. Sowohl die Rerank-Spur als auch die Fallback-Spur sind chunk-bewusst.

Deshalb bleibt die Abruflatenz nahezu flach, während der Speicher wächst (siehe Benchmarks): Die semantische Neubewertung bewertet immer eine begrenzte Menge, anstatt jede Einbettung zu scannen.

Exakte Abrufkontrolle: exact_mode="auto" ist normalerweise richtig. Verwenden Sie exact_mode="exact", wenn eine Abfrage wörtlichen Text wie RECALL_SCAN_LIMIT, --generate-key oder settings.py entsprechen muss. Verwenden Sie exact_mode="semantic", wenn eine syntaxähnliche Abfrage dennoch als bedeutungsbasierter Abruf behandelt werden soll.

Speichertypen & Klassifizierung

1. Kontextprotokolle – Automatisch klassifizierte Konversationserinnerungen

2. Manuelle Einträge – Explizit gespeicherte wichtige Informationen

3. Notebook-Einträge – Wiederverwendbare Anweisungen und Wissen

4. Sitzungszusammenfassungen – Komprimierter Konversationsverlauf

MARM kategorisiert Inhalte beim Schreiben automatisch: Code (Programmier-Snippets und technische Diskussionen), Projekt (Arbeitsgespräche und Planung), Buch (Literatur, Lernmaterialien, Forschung) und Allgemein (alles andere).

Projekt- & Plattformzuordnung

MARM speichert nullable project- und platform-Spalten für Erinnerungen, Protokolleinträge und Notebook-Einträge. Das Projekt wird aus dem Arbeitsverzeichnis und die Plattform vom verbindenden Client (Claude Code, VS Code, Cursor, ...) erkannt; MARM_PROJECT und MARM_PLATFORM überschreiben die Erkennung. marm_smart_recall(project=..., platform=...) begrenzt den Abruf, ohne das standardmäßige ungefilterte Verhalten zu ändern, sodass ein gemeinsamer Server mehrere Projekte ohne Kreuzkontamination halten kann.

Wissensgraphen: Code & Konzepte

MARM enthält zwei Graphsysteme, die den Speicher ergänzen: einen Codegraphen, der die Struktur Ihres Repositorys versteht, und einen Konzeptgraphen, der versteht, worum es in Ihren gespeicherten Erinnerungen geht. Wenn beide für dasselbe Projekt indiziert sind, verlinken Konzeptentitäten auf Codesymbole.

Codegraph: Repo-Indizierung und Code-Lookup

marm-graph ist in beide Transporte integriert. Es indiziert ein Repository einmal und ermöglicht es Agenten dann, Codestrukturfragen zu stellen, ohne wiederholt Dateien zu scannen:

Use marm_graph_index to index this repository.
Then use marm_code_lookup when you need symbols, files, or source snippets.
Use marm_graph_trace for call paths, marm_graph_architecture for an overview, and marm_graph_impact for change-risk checks.

Der empfohlene Agenten-Workflow: einmal indizieren, dann marm_code_lookup vor breiten Dateilesevorgängen, marm_graph_trace, wenn Aufrufer/Aufgerufene oder Datenflusskontext wichtig sind, marm_graph_architecture zur Orientierung und marm_graph_impact vor riskanten Refactorings. Eine Graphabfrage ersetzt Dutzende von grep/read-Zyklen, was die Token-Ersparnis ausmacht.

Sobald ein Repository indiziert ist, hält MARM es von selbst aktuell. Ein Hintergrund-Poller bemerkt, wenn sich das Repo geändert hat, und indiziert es neu, sodass keine manuelle Neuindizierung nach einem Commit erforderlich ist. Während Sie nicht committete Arbeit haben, aktualisiert es jeden Zyklus, da keine billige Prüfung wiederholte Bearbeitungen einer bereits geänderten Datei sehen kann. Um nur auf Anfrage zu indizieren, stattdessen:

marm-mcp-server projects auto off

Ein Agent kann dasselbe mit marm_graph_index(action="auto_off") tun, und action="auto_status" berichtet, was überwacht wird und wann jedes Projekt zuletzt indiziert wurde. Der Schalter bleibt über Neustarts hinweg erhalten und schlägt die Umgebungsvariable GRAPH_AUTO_INDEX.

Unter der Haube ist die Engine codebase-memory-mcp (MIT), eine null-Abhängigkeits-Statik-Binärdatei, die 158 Sprachen durch tree-sitter mit Hybrid-LSP-Typauflösung für die wichtigsten parst, ein durchschnittliches Repository in Sekunden indiziert und Symbolsuche und Aufrufverfolgung in deutlich unter einer Sekunde beantwortet. Gemessen an einem 149.107-Knoten-Graphen über die persistente Verbindung, die MARM hält: Symbolsuche 146ms, Aufrufverfolgung 67ms und die vollständige Architekturübersicht 1,23s, was die eine Abfrage ist, die nicht unter einer Sekunde liegt. MARM pinnt eine bestimmte Version, überprüft ihr Werkzeugschema beim Start und leitet den Upstream-Werkzeugsatz durch 5 fokussierte MCP-Werkzeuge, sodass die Modelloberfläche klein bleibt. Die Graph-Backend startet verzögert bei der ersten Graph-Werkzeugnutzung, sodass Speicher-, Protokoll-, Notebook- und Zusammenfassungswerkzeuge weiterhin schnell starten. In Docker ist die Engine-Binärdatei in das Image eingebacken; lokale pip-Installationen laden sie bei der ersten Graph-Nutzung herunter (~269MB, einmalig).

Degradierter Modus: Wenn die Graph-Engine nicht startet (kein Netzwerk für den Erststart-Download, Festplatte voll, Schema-Drift) oder GRAPH_ENABLED=false gesetzt ist, geben Graph-Werkzeuge {"status": "error", "message": "graph backend unavailable"} zurück, während die anderen 9 Werkzeuge normal weiterarbeiten. Graph-Fehler können das Gedächtnis niemals lahmlegen.

Konzeptgraph: Worum es in Ihren Erinnerungen geht

MARM extrahiert einen Wissensgraphen aus den gespeicherten Erinnerungen und erzeugt typisierte Entitäten (Konzepte, Entscheidungen, Muster, Fehler, Werkzeuge, Personen, Organisationen), die durch typisierte Beziehungen (behebt, implementiert, hängt_ab_von, verwendet, verursacht, ersetzt, erweitert) verbunden sind. Dies geschieht automatisch: Das Speichern einer Erinnerung stellt sie in die Warteschlange, und ein Hintergrundarbeiter fügt sie etwa 30 Sekunden später zum Graphen hinzu. marm_concept_build ist weiterhin für einen vollständigen oder begrenzten Neuaufbau verfügbar. Sobald ein Graph vorhanden ist, fügt marm_smart_recall begrenzte verwandte Entitäten, Beziehungen und verknüpften Code als graph_context-Sidecar hinzu, ohne die primäre Speicherbewertung zu ändern. marm_concept_recall bleibt für die explizite Graph-Erkundung verfügbar:

marm_concept_recall(query="write queue")            → the entity, its relationships, linked code symbols
marm_concept_recall(query="related to SQLite", depth=3) → multi-hop traversal of everything connected

So verwenden Sie es:

• Standardmäßig automatisch: Neue Erinnerungen erreichen den Graphen ohne einen Tool-Aufruf. Setzen Sie CONCEPT_AUTO_INDEX=false, um nur zu manuellen Builds zurückzukehren. Dies stoppt den Worker, behält aber die Aufzeichnung von Warteschlangenzeilen bei, sodass beim Wiedereinschalten alles aufgegriffen wird, was während der Deaktivierung geschrieben wurde; CONCEPT_INDEX_DEBOUNCE_SECONDS (30) und CONCEPT_INDEX_BATCH_SIZE (20) steuern das Tempo.

• Sicher auf beiden Transports gleichzeitig: Ein geleastes Lock in der Speicherdatenbank verhindert, dass ein Neubau in einem Prozess Graphtabellen löscht, während ein anderer Prozess darauf schreibt. Ein Build, der den Graphen als belegt vorfindet, meldet dies, anstatt zu kollidieren.

• Fehler erreichen niemals Ihre Erinnerungen: Die Indizierung läuft auf einer dauerhaften Warteschlange außerhalb des Schreibpfads. Extraktionsprobleme werden wiederholt, eine Erinnerung, die wiederholt fehlschlägt, wird mit ihrem Fehler abgelegt, und die Erinnerung selbst wird währenddessen normal gespeichert und abgerufen.

• Das Abarbeiten eines Rückstaus kostet etwas Abrufgeschwindigkeit: Die Entitätsextraktion ist CPU-intensiv. Während der Worker also eine Warteschlange abarbeitet, steigt der gemessene mediane Abruf von ~8ms auf ~16ms bei einem realen Korpus von 768 Erinnerungen. Schreibvorgänge sind nicht betroffen. Dies gilt nur, solange ein Rückstau abgebaut wird, was für die meisten Menschen einmalig nach dem Upgrade-Neubau der Fall ist. Reproduzieren Sie es mit scripts/benchmarking/performance/bench_concept_worker.py --from-live.

• Build für den Rückstau: marm_concept_build, begrenzt auf eine session_name, project oder search_all=True, indiziert Erinnerungen, die vor der Existenz der automatischen Indizierung gespeichert wurden, und baut nach einem Upgrade neu auf, das eines erfordert.

• Bisher zweimal aktualisiert: Graphen, die vor der Plattformattribution erstellt wurden, oder bevor Kompaktierungsquellen die indizierten Zeilen ersetzten, erfordern marm_concept_build(search_all=True). Ein vollständiger Build sichert und setzt nur die abgeleitete Konzeptdatenbank zurück; gezielte Builds weigern sich, die Plattformzugehörigkeit zu erraten.

• Gesamter Geltungsbereich, seitenweise: Builds lesen jede Erinnerung im Geltungsbereich. CONCEPT_BUILD_ROW_CAP (Standard 500) ist die Seitengröße. Eine Verringerung führt dazu, dass ein Build mehr, kleinere Seiten liest, anstatt den Rest zu überspringen.

• Kompaktierte Sitzungen: Die ursprünglichen Erinnerungen werden indiziert und die generierte Zusammenfassung nicht, sodass Konzepte dort verbleiben, wo sie tatsächlich angegeben wurden.

• Abruf schlägt offen fehl: Ein fehlender, leerer, inkompatibler oder nicht verfügbarer Konzeptgraph blockiert niemals den normalen Erinnerungsabruf. Die Antwort meldet den Graphstatus separat.

• Code-Querverweise: Wenn der Codegraph dasselbe Projekt indiziert hat, werden Konzeptentitäten, die mit Codesymbolen übereinstimmen, verknüpft, wodurch „was wir entschieden haben“ mit „wo es im Code lebt“ verbunden wird.

• Gebündelte Extraktionslaufzeit: Die spaCy-Laufzeit und das englische Extraktionsmodell werden mit MARM ausgeliefert, laden aber nur bei der ersten Extraktion, die jetzt kurz nach dem Speichern der ersten Erinnerung erfolgt, anstatt wenn Sie einen Build ausführen. Wenn eine beschädigte oder unvollständige Installation sie nicht verfügbar macht, verschlechtern sich beide Konzept-Tools sauber, während der Kernspeicher verfügbar bleibt; führen Sie marm-memory knowledge status aus und installieren Sie MARM bei Bedarf neu.

• Isolierte Speicherung: Der Konzeptgraph lebt in einer eigenen SQLite-Datenbank (~/.marm/index/marm_index.db) mit einem eigenen Verbindungspool, sodass Konzeptgraph-Schreibvorgänge niemals die Produktionsspeicherdatenbank blockieren oder beschädigen können.

• Konsolenatlas: Die MARM-Konsole rendert den vollständigen Atlas mit bis zu 750 Entitäten und 6.000 gespeicherten Beziehungen. Größere Graphen verwenden eine deterministische, verbundene Stichprobe von bis zu 600 Entitäten und 4.000 aggregierten visuellen Kanten, die deutlich als Stichprobe gekennzeichnet ist.

Dies schließt die Lücke in der sitzungsübergreifenden Struktur, die die flache Erinnerungssuche offen lässt: Sitzungen organisieren Erinnerungen, aber der Konzeptgraph verbindet sie, sodass „was von der Schreibwarteschlange abhängt“ beantwortbar ist, selbst wenn die Antwort fünf Sitzungen von drei verschiedenen Agenten umfasst.

Architektur & Interna

Alles oben Genannte läuft auf einer kleinen Anzahl durchdachter Mechanismen. Dieser Abschnitt ist die vollständige Karte, sodass Sie (oder Ihr Agent) nie raten müssen, was der Server tut.

Speicher-Engine

• SQLite im WAL-Modus unter ~/.marm/marm_memory.db mit einem Verbindungspool (5 Verbindungen). WAL hält Leser während Schreibvorgängen entsperrt, was wichtig ist, wenn mehrere Agenten gleichzeitig abrufen, während einer schreibt.

• FTS5-Volltextindex (memories_fts) wird als externe Inhaltstabelle über der Erinnerungstabelle verwaltet und treibt sowohl die exakte Spur (BM25) als auch die Filterstufe des hybriden Abrufs an.

• Chunk-Speicher: Erinnerungen über ~180 Wörter werden in überlappende 150-Token-Chunks (50-Token-Überlappung) in einer memory_chunks-Tabelle aufgeteilt, jeder mit eigener Einbettung. Der Abruf bewertet Chunks und reduziert sie auf die übergeordnete Erinnerung.

• Einbettungen stammen vom fastembed-gestützten jinaai/jina-embeddings-v2-small-en-Encoder: 33 Millionen Parameter, 512 Dimensionen, ein 8.192-Token-Kontextfenster und eine Apache-2.0-Lizenz. Es erfordert keine separaten Abfrage-/Dokumenttext-Präfixe. Der Encoder wird träge bei der ersten semantischen Verwendung geladen und hinter einem Lock serialisiert, sodass gleichzeitige Kodierungen einander nicht beschädigen können. Wenn er nicht verfügbar ist, sind Schreibvorgänge dennoch erfolgreich; Erinnerungen werden ohne Einbettungen gespeichert, bis er geladen ist. Die semantische Bewertung läuft als einzelner NumPy-Batch (Matrix-Kosinus) und nicht als Python-Schleife.

• Der Konzeptgraph erhält eine eigene Datenbank (~/.marm/index/marm_index.db) und einen eigenen Pool, der dieselbe Pool-Implementierung wiederverwendet, aber niemals Verbindungen mit dem Speicher teilt. Bewusste Isolation: Ein experimenteller Graph-Build darf nicht in der Lage sein, den Produktions-WAL zu blockieren. Die einzige Ausnahme ist die Indizierungswarteschlange, die sich absichtlich in der Speicherdatenbank befindet, damit eine Erinnerung und ihre Indizierungsaufgabe gemeinsam festgeschrieben werden; der Graph selbst bleibt abgeleitet und wegwerfbar.

Schreibpfad

• Serialisierte Schreibwarteschlange (standardmäßig aktiviert): Alle Erinnerungsschreibvorgänge fließen durch einen internen asynchronen Worker, wodurch SQLite-Schreibkonflikte bei Multi-Agent-Last vermieden werden. Die Warteschlange ist generisch; Kompaktierungsanwendungen durchlaufen denselben Worker, sodass es genau einen Schreiber gibt, unabhängig davon, welches Subsystem schreibt. MAX_QUEUE_SIZE begrenzt sie.

• Schreibzeitliche Konsolidierung (optional, CONSOLIDATION_ENABLED=1) führt zwei Schichten aus, bevor eine Erinnerung landet:

  • Schicht 1, exakte Deduplizierung: Ein SHA-256-Hash des normalisierten Inhalts wird innerhalb der Sitzung überprüft; Hash-Treffer werden gegen den tatsächlichen Inhalt verifiziert, bevor dedupliziert wird, sodass eine Hash-Kollision eine neue Zeile speichert, anstatt unterschiedliche Inhalte stillschweigend zusammenzuführen.

  • Schicht 2, semantische Zusammenführung: Nahe Duplikate oberhalb von CONSOLIDATION_THRESHOLD Kosinus-Ähnlichkeit werden zusammengeführt, anstatt akkumuliert zu werden. Dies blockiert niemals einen Schreibvorgang; wenn der Encoder nicht verfügbar ist, wird der Schreibvorgang unkonsolidiert fortgesetzt.

  • Der Kompromiss ist gemessen und veröffentlicht: etwa 9-fache mediane Schreibkosten (58ms vs. 6,5ms) im Austausch für einen Speicher, der sauber bleibt, da Lesevorgänge die Erinnerungsarbeitslast dominieren. Siehe Abschnitt 3 der obigen Benchmarks.

• Konzeptindizierung ist ein dauerhafter Postausgang: Ein Schreibvorgang zeichnet eine Indizierungsaufgabe in derselben Transaktion wie die Erinnerung auf, sodass eine Erinnerung nicht ohne eine existieren kann. Ein Hintergrundworker leert diese Warteschlange und schreibt den Konzeptgraphen. Nichts im Schreibpfad wartet auf die Extraktion, und ein Prozess, der während der Extraktion abgebrochen wird, verliert keine Arbeit, da die Aufgabe eine Zeile und keine In-Memory-Aufgabe ist. Beide Transports betreiben einen Worker, sodass sie sich über ein geleastes Lock in der Speicherdatenbank koordinieren, anstatt über ein prozessinternes Lock, das sie nicht umfassen würde.

• Kompaktierung (optional, COMPACTION_ENABLED=1) ist Schicht 3: Nach genügend Schreibvorgängen in einer Sitzung erkennt ein Hintergrunddurchlauf Cluster verwandter Erinnerungen unter Verwendung von Kosinus-Ähnlichkeit plus Union-Find-komponenten, begrenzt durch minimale Clustergröße, Mindestalter und eine Gnadenfrist für aktive Sitzungen, sodass nie in Arbeit befindliche Vorgänge kompaktiert werden. MARM injiziert dann eine begrenzte Anfrage, die den verbundenen Agenten auffordert, jeden Cluster zusammenzufassen: candidates → stage → review → apply oder discard. Quell-Erinnerungs-IDs werden beim Anwenden beibehalten, sodass kompaktierte Zusammenfassungen auf ihre Originale zurückverfolgbar bleiben. Gestaffelte Zusammenfassungen laufen ab (COMPACTION_STAGING_TTL_HOURS), Erinnerungen sind begrenzt und haben eine Abkühlungsbeschränkung, und die Injektion hat ein Byte-Budget. Das Design ist ehrlich, wofür LLMs gedacht sind: MARM erkennt, der Agent fasst zusammen, und eine für Menschen überprüfbare Staging/Apply/Discard-Schleife begrenzt den destruktiven Schritt.

Abrufpfad

Behandelt in Understanding MARM Memory: exakte Spur (FTS5 BM25 + LIKE-Fallback), Filter→Reranking (begrenzte FTS-Kandidaten → Batch-semantisches Reranking → zeitliche Mischung), begrenzter semantischer Fallback mit explizitem Kürzungsflag und Chunk-Collapse-Bewertung. Die Abruftiefe (detail=1/2/3) steuert, wie viel von jeder Erinnerung zurückgegeben wird, und jede MCP-Antwort durchläuft einen 1MB-Antwortbegrenzer, der Inhalte intelligent kürzt, anstatt das Protokoll zu brechen.

Code-Graph-Subprozess-Protokoll

Die gebündelte Graph-Engine läuft als überwachter Kindprozess, nicht als Import:

• Transport: Newline-getrenntes JSON-RPC 2.0 über stdio des Kindes, mit einem verifizierten Handshake (initialize → Serverversion erfassen → initialized-Notification).

• Umschlagssorgfalt: Antworten werden nach dem ersten JSON-parsebaren Inhaltselement durchsucht, anstatt Index 0 anzunehmen, da der vorgelagerte Binärprozess eine Update-Notiz voranstellen kann. Tool-Fehler treten als result.isError auf, nicht als JSON-RPC-Fehler, und werden in saubere {"status": "error"}-Dictionaries mit dem eigenen Behebungsvorschlag des vorgelagerten Prozesses umgewandelt.

• Serialisierung: Ein Lock schützt jede Lese-Schreib-Rundreise auf der einzelnen stdin-Pipe; asynchrone Aufrufer gehen durch asyncio.to_thread, sodass die Ereignisschleife niemals auf Subprozess-E/A blockiert.

• Absturzwiederherstellung: stderr wird in einem Hintergrundthread abfließen gelassen, Kind-EOF/-Absturz wird erkannt, und der Prozess wird beim nächsten Aufruf transparent neu gestartet. Timeouts werden bewusst nicht als Abstürze behandelt; ein langer Indexlauf kann noch arbeiten, und ihn zu töten, würde laufende Arbeit zerstören.

• Überwachung: Ein fauler Singleton-Supervisor besitzt den Client für die Prozesslebensdauer. Der Start wird durch den ersten Graph-Tool-Aufruf oder durch den Auto-Index-Poller ausgelöst, wenn die Engine-Binärdatei bereits heruntergeladen ist, steigt niemals in die MCP-Schicht auf und überprüft das Tool-Schema der gepinnten Binärdatei, sodass vorgelagerte Abweichungen beim Start und nicht während des Aufrufs erkannt werden.

• Auto-Neuindizierung ist Git-Signatur-abgefragt, nicht dateisystemüberwacht: Eine Hintergrundaufgabe vergleicht den HEAD und den Dirty-Status jedes indizierten Repositorys, berechnet durch Ausführen von git außerhalb der Engine, sodass ein Leerlauf-Check kein Engine-Lock kostet. Ein Commit löst eine Neuindizierung aus. Solange der Baum schmutzig ist, wird das Repository in jedem Zyklus neu indiziert, da git status meldet, welche Dateien sich geändert haben, und nicht, was in ihnen ist, sodass wiederholte Bearbeitungen einer bereits geänderten Datei byteidentische Ausgaben erzeugen, die kein billigerer Fingerabdruck unterscheiden kann. Git wird mit deaktiviertem core.fsmonitor und einer bereinigten Umgebung ausgeführt, da diese Einstellung ein Programm benennt, das Git andernfalls aus einem überwachten Repository zeitgesteuert ausführen würde.

• Ein Tor für jede Store-Mutation: Manuelle Indizes auf allen drei Oberflächen, der Poller und die Projektlöschung durchlaufen alle eine einzelne geleaste Zeile in der Speicherdatenbank. HTTP und STDIO sind separate Prozesse mit separaten Engine-Kindern über einem gemeinsamen Engine-Store, sodass ein prozessinternes Lock sie nicht umfassen kann. Das Lease wird freigegeben, wenn der Engine-Aufruf tatsächlich zurückkehrt, und nicht, wenn sein Aufrufer aufhört zu warten: Eine abgebrochene Anfrage kann den Store nicht an einen anderen Prozess übergeben, während die Engine noch darauf schreibt.

Sicherheit & Ratenbegrenzung

• Zwei-Modus-Authentifizierungstor: Schlüssellos auf Loopback (127.0.0.1), MARM_API_KEY (Bearer) obligatorisch, sobald der Server netzwerkexponiert ist (SERVER_HOST=0.0.0.0, Docker). --generate-key erzeugt einen. Standardmäßig sicher, kein Einrichtungsaufwand lokal.

• IP-basierte Ratenbegrenzung mit gleitenden Fenstern und temporären Sperren, abgestimmt über CLI-Voreinstellungen anstelle eines Konfigurationslabyrinths (Tabelle unten).

• Lokal zuerst: Alles lebt unter ~/.marm/; keine Cloud-Synchronisation, keine Telemetrie, kein externer Speicher.

• Anmutiges Herunterfahren: SIGTERM/SIGINT-Handler leeren und schließen den Verbindungspool sauber, und ein internes Ereignissystem führt Automatisierungs-Callbacks mit pro-Callback-Fehlerisolierung und Timeouts aus, sodass ein schlechter Hook den Server nicht blockieren kann.

Schwarm- & Multi-Agent-Voreinstellungen

Die Schreibwarteschlange serialisiert Speicherschreibvorgänge unabhängig von der Voreinstellung; die Schwarm-Flags passen die HTTP-Ratenbegrenzung zusätzlich an. Die Warteschlange steuert die Schreibreihenfolge; Konsolidierung und Kompression sind separate Speicherverwaltungsebenen. Dieser Stack (WAL + Pooling + ein serialisierter Schreiber + RPM-Voreinstellungen) ist bewusst auf „SQLite, viele Agenten, eine Maschine“ beschränkt; verteilter Multi-Knoten-Speicher liegt außerhalb des aktuellen Designs.

Selbstwartende Dokumentation

Gepackte Dokumentationen werden beim Start in den Speicher-Namespace marm_system indiziert und alle 50 Tool-Aufrufe aktualisiert, wobei eine Quell-Datei-Hash-Verfolgung verwendet wird, sodass unveränderte Dokumente übersprungen und geänderte oder gelöschte Zeilen neu indiziert werden. Verbundene Agenten können MARM-Nutzungsfragen mit marm_smart_recall beantworten, anstatt dass Sie ihnen Dokumentationen einfügen.

Konfigurationsreferenz

Fehlerbehebung

Der Jina v2 Small Standard verwendet standardmäßig 512-dimensionale Embeddings; ältere all-MiniLM-L6-v2-Daten sind 384-dimensional und müssen neu eingebettet werden. Stoppen Sie jeden MARM HTTP- und STDIO-Prozess und führen Sie dann aus:

marm-memory maintenance embeddings migrate

Es bettet Speicher, Chunks und alle vorhandenen Concept-Graph-Vektoren neu ein (Notebook-Notizen enthalten keine Embeddings mehr), meldet den Fortschritt, überprüft beide Datenbanken und ist nach einer Unterbrechung fortsetzbar. Es weigert sich zu starten, wenn ein HTTP-Server läuft; STDIO-Prozesse können nicht zuverlässig erkannt werden und müssen manuell gestoppt werden.

Chunked Memories reparieren

Erinnerungen über 500 Wörter werden auch als kleinere Chunks gespeichert. Die Chunk-Größe hat sich zwischen den Versionen geändert, und die obige Migration bettet Chunks neu ein, ohne sie neu zu splitten, sodass ältere Chunks veraltete Grenzen behalten. Stoppen Sie jeden MARM-Prozess und führen Sie dann aus:

marm-memory maintenance chunks rechunk

Es splittet veraltete Chunks neu, füllt fehlende Chunks aus einer unterbrochenen Schreibaktion auf und entfernt Chunks von Erinnerungen, die jetzt unter dem Schwellenwert liegen. Bereits korrekte Erinnerungen werden ohne Laden des Encoders übersprungen, sodass erneutes Ausführen nichts kostet. Gleicher Live-Server-Schutz wie oben, zusätzlich verweigert es, wenn gespeicherte Vektoren nicht zum konfigurierten Embedding-Modell passen: In diesem Fall zuerst migrieren. Der Abruf funktioniert auch ohne dies, nur weniger genau bei langen Erinnerungen.

Server startet nicht

• Python-Version prüfen: python --version (muss 3.10+ sein)

• Prüfen, ob Port 8001 belegt ist: lsof -i :8001 (macOS/Linux) oder netstat -ano | findstr :8001 (Windows)

• Auf Berechtigungsfehler im Home-Verzeichnis prüfen (~/.marm/ muss les- und schreibbar sein)

• Siehe plattformspezifische Fehlerbehebung: INSTALL-DOCKER.md, INSTALL-WINDOWS.md, INSTALL-MACOS.md, INSTALL-LINUX.md

STDIO-Verbindung schlägt fehl

• Stellen Sie sicher, dass marm-mcp-stdio nach der pip-Installation in Ihrem PATH ist: marm-mcp-stdio --help

• Alternativ verwenden Sie: python -m marm_mcp_server.server_stdio

• Überprüfen Sie die Dokumentation des KI-Clients auf STDIO-Transportanforderungen

• Versuchen Sie die direkte Ausführung, um Fehlermeldungen zu sehen: python -m marm_mcp_server.server_stdio

KI-Client kann keine Verbindung zu MARM herstellen

• Überprüfen Sie, ob der Server läuft, mit curl http://localhost:8001/health

• Prüfen Sie, ob die Firewall Port 8001 blockiert

• Für STDIO: verwenden Sie marm-mcp-stdio (Konsolenskript) oder python -m marm_mcp_server.server_stdio

• Starten Sie sowohl Server als auch KI-Client neu

Tools werden im KI-Client nicht angezeigt

• Überprüfen Sie den HTTP-Modus mit curl http://localhost:8001/health

• Überprüfen Sie die Server-Logs auf Initialisierungsfehler

• Trennen Sie die Verbindung des KI-Clients und stellen Sie sie erneut her, um die Tool-Liste zu aktualisieren

• Sowohl HTTP als auch STDIO stellen 14 Tools bereit: 7 Kern-Speicher-/Logging-/Notebook-/Kompaktierungstools, 5 gebündelte Code-Graph-Tools und 2 Concept-Graph-Tools

Graph-Tools geben graph backend unavailable zurück

• Bestätigen Sie, dass GRAPH_ENABLED nicht auf false gesetzt ist (betrifft sowohl HTTP als auch STDIO; Graph-Tools haben volle Parität über beide Transporte hinweg)

• Die erste Graph-Nutzung kann länger dauern, während der festgelegte Codebase-Memory-Engine startet oder lokal heruntergeladen wird

• In Docker ist die Graph-Engine-Binärdatei im Image enthalten; lokale pip-Installationen können sie bei der ersten Graph-Nutzung abrufen

• Kern-Speicher-Tools funktionieren weiterhin, selbst wenn der Graph-Start fehlschlägt

Concept-Tools geben entities_extracted: 0 zurück

• Stellen Sie zunächst sicher, dass ein scoped Concept-Build tatsächlich Erinnerungen mit extrahierbaren Entitäten enthält.

• Führen Sie marm-memory knowledge status aus; wenn es eine fehlende Laufzeit oder ein fehlendes Modell meldet, reparieren Sie die Installation mit python -m pip install -U --force-reinstall marm-mcp-server.

Neue Erinnerungen werden im Graph nicht angezeigt

• Führen Sie marm-memory knowledge status aus. index_queue.pending gibt an, wie viele Erinnerungen warten; index_queue.parked gibt an, wie viele aufgegeben haben. auto_index: false bedeutet, dass die Indizierung ausgeschaltet ist.

• Warten Sie das Debounce-Intervall (standardmäßig 30 Sekunden) plus die Extraktionszeit ab. Ein Schreib-Burst wird als ein Durchlauf indiziert, nicht pro Erinnerung.

• Überprüfen Sie, dass CONCEPT_AUTO_INDEX nicht auf false, 0, no oder off gesetzt ist.

• Ein Graph, der auf eine Neuerstellung wartet, wird nicht indiziert. Wenn die Konsole oder marm-memory knowledge status rebuild_required meldet, führen Sie marm_concept_build(search_all=True) einmal aus; wartende Erinnerungen werden danach aufgenommen.

• Die automatische Indizierung deckt nur Erinnerungen ab, die seit dem Upgrade geschrieben wurden. Führen Sie einmal einen Build aus, um alle älteren einzubringen.

• Eine Erinnerung, die dreimal bei der Extraktion fehlschlägt, wird geparkt, anstatt endlos wiederholt zu werden. Der Grund wird mit der Aufgabe aufgezeichnet.

Code-Änderungen werden im Code-Graph nicht angezeigt

• Führen Sie marm-memory projects auto status aus. enabled: false bedeutet, dass die automatische Neuindizierung ausgeschaltet ist; source: override bedeutet, dass ein gespeicherter Schalter sie ausgeschaltet hat, nicht die Umgebung.

• Das Repository muss einmal indiziert werden, bevor es überwacht wird. marm-memory projects list zeigt an, was eingeschrieben ist.

• Warten Sie das Intervall (standardmäßig 30 Sekunden) plus die Indexzeit ab. Ein Commit wird bei der nächsten Prüfung aufgenommen.

• Ein Projekt, das aus der Konsole gelöscht wurde, bleibt absichtlich unterdrückt, sodass eine veraltete Überwachungsliste es nicht neu erstellen kann. Eine explizite Indizierung schreibt es erneut ein.

• Die automatische Indizierung benötigt die Graph-Engine, die inaktiv bleibt, bis die Engine-Binärdatei heruntergeladen wurde. Jeder Graph-Tool-Aufruf lädt sie einmal herunter.

Ein Index gibt index_in_progress zurück

• Ein anderer MARM-Prozess hält das Indexierungs-Gate, normalerweise der Poller des anderen Transports oder ein Konsolen-Index-Job. Das Löschen eines Projekts meldet dasselbe, da ein Löschen während einer Indizierung rückgängig gemacht würde. Führen Sie es in einem Moment erneut aus.

Ein Build gibt build_in_progress zurück

• Ein anderer MARM-Prozess schreibt den Graphen, normalerweise der Indexierungs-Worker des anderen Transports. Builds sind kurz, es sei denn, es handelt sich um einen vollständigen Neubau; führen Sie es in einem Moment erneut aus.

Ein Build gibt lock_lost zurück

• Der Build war lange genug blockiert, dass ein anderer Prozess den Graphen übernommen hat, sodass er abgebrochen wurde, anstatt parallel zu schreiben. Normalerweise ein angehaltener Rechner oder eine Debugger-Pause. Was vor dem Abbruch indiziert wurde, bleibt erhalten, und ein erneuter Build schließt den Rest ab.

Erinnerungen werden nicht gespeichert

• Überprüfen Sie, ob das Verzeichnis ~/.marm/ existiert und Schreibrechte hat

• Überprüfen Sie den verfügbaren Speicherplatz

• Testen Sie mit einer einfachen Erinnerung: Bitten Sie die KI, eine einzelne Zeile zu speichern, und überprüfen Sie mit marm_log_show

• Für den HTTP-Modus überprüfen Sie die Server-Gesundheit mit curl http://localhost:8001/health

Suche gibt keine Ergebnisse zurück

• Überprüfen Sie, ob Erinnerungen existieren: verwenden Sie marm_log_show, um Einträge aufzulisten

• Verwenden Sie search_all=True, um in allen Sitzungen zu suchen

• Versuchen Sie einfachere, allgemeinere Suchanfragen

• Warten Sie einige Sekunden; die erste semantische Suche lädt das ML-Modell

Erinnerungen erscheinen und verschwinden dann

• Überprüfen Sie, ob MARM neu gestartet wurde oder abgestürzt ist (Daten bleiben in ~/.marm/ erhalten)

• Überprüfen Sie, ob der Speicherplatz nicht vollgelaufen ist

• Überprüfen Sie die System-Logs auf Datenbankfehler

Verlorene oder beschädigte Daten

• Stoppen Sie den Server sofort

• Überprüfen Sie das Verzeichnis ~/.marm/ auf Sicherungskopien (falls Sie sie erstellt haben)

• Stellen Sie aus dem Backup wieder her: Kopieren Sie Ihr Backup ~/.marm/ zurück in das Home-Verzeichnis

• Starten Sie den Server neu

Datenbank gesperrt Fehler

• Schließen Sie alle KI-Client-Verbindungen

• Stoppen Sie den Server: Strg+C

• Sichern Sie das gesamte Datenbankverzeichnis: cp -r ~/.marm ~/.marm.backup

• Überprüfen Sie, ob Prozesse die Datenbank halten: lsof ~/.marm/marm_memory.db (macOS/Linux) oder Task-Manager (Windows)

• Wenn ein Prozess die Sperre hält, beenden Sie ihn

• Überprüfen Sie die Datenbankintegrität: sqlite3 ~/.marm/marm_memory.db "PRAGMA integrity_check;"

• Wenn die Integritätsprüfung fehlschlägt, stellen Sie aus Ihrem Backup wieder her

• Wenn die Integritätsprüfung bestanden wird, sollte die Sperre freigegeben sein; starten Sie den Server neu

Langsame Suchergebnisse

• Die erste Suche ist langsamer (Modell wird von der Festplatte geladen); nachfolgende Suchen sind schneller

• Große Datenbanken (1000+ Erinnerungen) können einige Sekunden dauern

• Suchen einschränken: verwenden Sie limit=10 anstelle unbegrenzter Ergebnisse

• Verwenden Sie marm_summary, um alte Sitzungen zu komprimieren

Server verbraucht zu viel Speicher

• Notizbücher mit vielen Einträgen können sich ansammeln; verwenden Sie marm_notebook(action="clear"), um aktive Einträge zu bereinigen

• Schließen Sie ungenutzte KI-Client-Verbindungen

• Verwenden Sie marm_compaction(action="review"), um bereitgestellte Komprimierungszusammenfassungen zu überprüfen, wenn die Komprimierung aktiviert ist

Fragen zu Speicherverhalten, Transporten, unterstützten Clients, Komprimierung und Backup finden Sie im FAQ.

Sternenverlauf

Mitwirken

MARM heißt Mitwirkende auf jeder Ebene willkommen. Code hilft, aber genauso Dokumentation, Setup-Notizen, Client-Tests, Fehlerberichte, Benchmarks und echtes Workflow-Feedback von Menschen, die täglich KI-Tools verwenden.

Gute Möglichkeiten, um zu helfen:

• Testen Sie MARM mit mehr MCP-Clients, IDE-Agenten und Betriebssystemen

• Verbessern Sie Dokumentation, Screenshots, Beispiele und plattformspezifische Setup-Notizen

• Melden Sie Fehler oder verwirrende Installationsschritte mit klaren Reproduktionsdetails

• Teilen Sie Speicher-Workflows, Agentengewohnheiten und Tool-Ideen aus der Praxis

• Schauen Sie sich offene Issues an

💡 Möchten Sie Ihren Namen auf dieser Liste sehen? Schauen Sie sich unseren CONTRIBUTING.md-Leitfaden an, um loszulegen!

Treten Sie der MARM-Community bei

Helfen Sie mit, die Zukunft des KI-Gedächtnisses zu bauen – keine Programmierkenntnisse erforderlich!

Verbinden: MARM Discord | GitHub Discussions

Lizenz & Nutzungshinweis

Copyright © 2026 Ryan A. Lyell. MARM wird unter der Apache 2.0 Lizenz veröffentlicht (siehe NOTICE für die Urheberrechtsangabe), und Forks, Experimente und Integrationen sind willkommen. MARM enthält auch Open-Source-Komponenten von Drittanbietern wie codebase-memory-mcp unter MIT; siehe THIRD_PARTY_NOTICES.md für die Quellenangabe. Wenn Sie darauf aufbauen, machen Sie bitte inoffizielle Versionen leicht von den vom offiziellen MARM-Repository veröffentlichten Releases unterscheidbar, damit die Benutzer wissen, was sie installieren.

Projektdokumentation

Nutzungsanleitungen

• README.md – Diese Datei: vollständige Nutzungsanleitung, Tool-Referenz, Workflows und Architektur

• PROTOCOL.md – MCP-Betriebsprotokoll

• FAQ.md – Antworten auf häufige Fragen zur Verwendung von MARM

MCP-Server-Installation

• INSTALL-DOCKER.md – Docker-Bereitstellung (empfohlen)

• INSTALL-WINDOWS.md – Installationsanleitung für Windows

• INSTALL-MACOS.md – Installationsanleitung für macOS

• INSTALL-LINUX.md – Installationsanleitung für Linux

• INSTALL-PLATFORMS.md – Plattform-Installationsanleitung

Projektinformationen

• CONTRIBUTING.md – So können Sie zu MARM beitragen

• CHANGELOG.md – Versionsverlauf und Aktualisierungen

• ACKNOWLEDGMENTS.md – Mitwirkende und Danksagungen

• ROADMAP.md – Geplante Funktionen und Entwicklungsfahrplan

• LICENSE – Apache 2.0 Lizenzbedingungen