TencentDB Agent Memory Anleitung (2026): L0–L3 Schichtspeicher für AI Agents

Zuletzt aktualisiert: 6. August 2026. Installationsbefehle und Konfigurationsfelder wurden anhand des TencentDB-Agent-Memory-Repositories, der npm-Plugin-Dokumentation und der Tencent-Cloud-Memory-Anleitung geprüft.

Wer einen AI Agent mit OpenClaw, Hermes oder einem eigenen Framework gebaut hat, kennt das Muster: In der dritten Runde vergisst er Ihren Swift-Styleguide; nach zwanzig Tool-Aufrufen explodiert der Kontext und er erfindet Dateipfade; in einer neuen Session erklären Sie das Projekt von vorn.

Die üblichen Fixes – alles in eine Vektordatenbank werfen oder aggressiv zusammenfassen – tauschen ein Problem für ein anderes. Tencent's Open-Source-Projekt TencentDB Agent Memory (MIT, 2026) geht einen anderen Weg: symbolischer Kurzzeitspeicher plus vier Schichten Langzeitgedächtnis (L0–L3), standardmäßig mit lokalem SQLite + sqlite-vec und ohne Cloud-Pflicht zum Start. Dieser Leitfaden ist für iOS-, Flutter- und AI-Entwickler geschrieben, die zuerst das Modell verstehen, dann das Plugin installieren und erst danach entscheiden, ob Memory auf dem Laptop oder auf einem Cloud Mac dauerhaft online bleiben soll.

Einleitung: Warum Agents ständig „vergessen“

Lang laufende Agent-Fehler sind selten ein IQ-Problem des Modells. Sie sind ein Kontext-Management-Problem. Eine einzige Wide-Search- oder SWE-bench-ähnliche Aufgabe kann Hunderttausende Tokens zurückliefern – JSON-Payloads, Seiteninhalte, Compiler-Logs. Alles im Fenster halten treibt Kosten und Latenz; blind löschen bedeutet, dass der Agent in der nächsten Runde Suchen wiederholt oder die falsche Datei bearbeitet.

TencentDB Agent Memory zielt genau auf diesen Zielkonflikt: das Wichtige merken und eine vollständige Evidenzkette zum Nachprüfen behalten. Öffentliche Benchmarks im OpenClaw-Plugin-Szenario berichten bis zu ~61 % Token-Einsparung bei Kurzzeitaufgaben und PersonaMem-Langzeitgenauigkeit von 48 % auf 76 %. Ihre Zahlen variieren je nach Modell und Task – die Richtung ist klar: Schichtung plus Offload schlägt eine flache Vektor-Historie.

Für Kvmkit-Leser zeigt sich der Stack in zwei typischen Formen: (1) OpenClaw-Memory-Plugin auf dem Mac während Sie in Cursor oder Claude Code coden; (2) Flutter auf Windows, Gateway plus lokale MLX-Inferenz auf einem Cloud-Mac-mini – Memory-Dienst und Xcode-Builds auf demselben stabilen Knoten.

Wenn Sie bereits Agent-Workflows mit MCP-Tools betreiben, ist Memory die fehlende Schicht zwischen „was kann ich tun?“ und „was haben wir schon getan?“. Ohne sie wirkt jeder neue Chat wie ein frischer Mitarbeiter ohne Onboarding – produktiv im ersten Satz, orientierungslos ab Runde drei.

Kernkonzepte: Schichtspeicher und symbolischer Kurzzeit-Offload

Das Projekt lehnt explizit ab, „jede Runde in Embeddings zu schneiden und auf Retrieval zu hoffen“. Langzeitseite ist eine semantische Pyramide; Kurzzeitseite ein Mermaid-Aufgaben-Canvas. Beides unterstützt progressive Disclosure: Nur die High-Level-Struktur landet im Modellkontext; bei Bedarf drillt man per Index in die Rohdaten.

Langzeitschichten (L0 → L3)

• L0 Conversation – Rohdialog und Tool-Spuren, unveränderliche Evidenzbasis;
• L1 Atom – strukturierte Fakten aus dem Chat (Daten, Präferenzen, Stack-Wahl);
• L2 Scenario – Atom-Cluster zu Szenario-Blöcken (z. B. „iOS-CI-Code-Signing“);
• L3 Persona – übergreifendes Nutzerprofil in lesbarem persona.md für Recall vor der nächsten Session.

Recall startet standardmäßig mit Persona und Scenario, dann Atom oder L0-Rohtext – ähnlich wie man zuerst „dieser Kollege bevorzugt SwiftUI“ erinnert, bevor man Chat-Logs durchscrollt.

Kurzzeitspeicher: Mermaid-Offload

Tool-Logs landen in refs/*.md, der Kontext hält ein leichtes Mermaid-Diagramm mit node_id-Markern. Der Agent rechnet über Symbole; wirkt ein Knoten verdächtig, grep per node_id und holt das vollständige Original-Log – 100 % nachverfolgbar, ohne Megabytes stdout zurück ins Fenster zu pressen.

Parallel MCP-Tools einbinden? Memory neben einem Leitfaden wie GitHub MCP Server einrichten: Windows, Linux & macOS installieren – Tools antworten „was kann ich tun?“; Memory antwortet „was haben wir getan und wer ist dieser Nutzer?“.

Praxis: OpenClaw-Plugin und Gateway-Deployment

Der schnellste Weg ist das OpenClaw-Plugin (Node.js ≥ 22.16). Die Befehle laufen in macOS- oder Linux-Terminals; unter Windows WSL2 oder Gateway auf einem Cloud Mac hosten.

Option A: OpenClaw Zero-Config (empfohlen zum Einstieg)

# Plugin installieren
openclaw plugins install @tencentdb-agent-memory/memory-tencentdb
openclaw gateway restart

In ~/.openclaw/openclaw.json aktivieren:

{
  "memory-tencentdb": {
    "enabled": true
  }
}

Standard-Backend ist lokales SQLite. Das Plugin übernimmt Dialogaufzeichnung, Memory-Extraktion, Szenario-Clustering, Persona-Generierung und Recall in der nächsten Runde. Upgrade mit openclaw plugins update @tencentdb-agent-memory/memory-tencentdb – lose Semver-Bereiche können das Plugin still deaktivieren.

Kurzzeit-Kompression aktivieren (Plugin ≥ 0.3.4)

Offload einschalten und contextEngine-Slot registrieren:

{
  "memory-tencentdb": {
    "config": {
      "offload": { "enabled": true }
    }
  },
  "plugins": {
    "slots": {
      "contextEngine": "memory-tencentdb"
    }
  }
}

scripts/openclaw-after-tool-call-messages.patch.sh aus dem Repo ausführen (nach OpenClaw-Upgrades erneut). Ohne diesen Patch werden Tool-Ergebnisse oft nicht korrekt offloadet – häufige Ursache für „Plugin installiert, aber Tokens nicht gesunken“.

Option B: Hermes Docker All-in-One

Für Hermes Agent einen Memory-Container bauen und starten (Gateway auf Port 8420):

cd TencentDB-Agent-Memory/docker/opensource
docker build -f Dockerfile.hermes -t hermes-memory .
docker run -d --name hermes-memory -p 8420:8420 \
  -e MODEL_API_KEY="your-api-key" \
  -v hermes_data:/opt/data hermes-memory
curl http://localhost:8420/health

Antwort {"status":"ok"} oder degraded reicht zum Weitermachen. Das Image bringt standardmäßig einen DeepSeek-V3.2-Endpunkt mit – bei diesem Modell reicht oft nur der API-Key.

Option C: Custom Agent + Python SDK (Cloud-Pfad)

Wenn das Team Tencent-Cloud-Managed-Memory braucht, Memory-Instanz in der Konsole anlegen und SDK installieren:

pip install tencentdb-agent-memory-sdk

Mit dem Async-Client Sessions schreiben und Atom-Memories abrufen (Felder laut Konsole). Geeignet für Python-Orchestrierung mit mehreren Agents und gemeinsamem Team-Memory – persönliche Tests brauchen die Cloud nicht.

Abnahme-Checkliste

• Nach drei Gesprächsrunden prüfen, ob persona.md oder Szenario-Dateien existieren;
• Mit Offload die Token-Kurve auf derselben SWE-Task vor/nach vergleichen;
• Agent zu einem alten Tool-Ergebnis zitieren lassen – Recovery per node_id in refs/ verifizieren;
• Bei endlosen Tool-Calls zuerst Kimi K3 Tool Calls Schleife: Stopp-Anleitung 2026 zur Message-Chain prüfen, nicht gleich das Memory-Plugin beschuldigen.

Kopplung mit Cloud Mac und Apple Silicon

Ein Memory-Gateway ist ein dauerhaft laufender Dienst: Port lauschen, SQLite lesen/schreiben, Extraktion und Recall im Hintergrund. Laptop-Sleep, Windows-Update-Neustarts und instabile Heimnetze wirken wie plötzliches Vergessen. Realistischeres Layout für iOS-Teams:

• Lokal – Cursor oder Xcode für den Tagescode;
• Cloud-Mac-mini – OpenClaw-Gateway + TencentDB-Memory + Ollama oder MLX auf einer Maschine;
• Remote – SSH oder Bildschirmfreigabe zum Debuggen; persistentes Daten-Volume auf Cloud-Disk.

Apple Silicon bringt Unified Memory und natives Unix: Node 22, Docker Desktop und Homebrew-Pfade sind vorhersehbar; ein Gateway kann auf M4 Mac mini im Leerlauf mit wenigen Watt laufen – weit unter einer Desktop-GPU. Wer kleine Modelle auf einer lokalen GPU testet, kann Inferenz auf Windows lassen und Memory plus macOS-Jobs, die online bleiben müssen, auf einen Kvmkit-Cloud-Mac verlagern – damit das Zuklappen des Lids die Session nicht killt.

Für Teams mit gemischten Betriebssystemen ist das oft der pragmatische Split: Windows-Laptop für Meetings und E-Mail, Cloud Mac als „Agent-Bunker“, der niemals schläft. Die Memory-Datenbank wächst dort kontinuierlich; Persona und Szenarien bleiben konsistent, auch wenn niemand physisch am Mac sitzt.

Kosten, Leistung und Risiken im Vergleich

Einfache Entscheidungsregel: Prototyp mit lokalem SQLite ohne Infrastrukturkosten; sobald Memory Team-Asset wird, Migration auf Always-on-Cloud-Mac oder Tencent-Instanz. Produktions-Agents zwei Wochen auf dem Laptop laufen lassen und später migrieren – L0-Dialog und refs/-Exporte werden leicht unterschätzt.

Backup und Verschlüsselung gehören in dieselbe Planung: SQLite-Dateien und refs/-Ordner enthalten oft Prompts, Repo-Pfade und API-Responses. Wer Memory auf einem Cloud Mac hostet, sollte Snapshots oder regelmäßige Exports in den Betriebsplan aufnehmen – nicht erst nach dem ersten Datenverlust.

FAQ

Zusammenfassung

• TencentDB Agent Memory nutzt L0–L3 plus Mermaid-Offload gegen Kontext-Explosion; lokales SQLite reicht zum Start.
• OpenClaw-Plugin ist der schnellste Einstieg; Hermes nutzt Docker; Enterprise-Stacks das Python-SDK auf Tencent Cloud.
• Wenn Memory und macOS-Tooling 7×24 laufen müssen, schlägt ein Cloud-Mac-mini ein schlafendes Laptop.

Agent-Memory löst sich nicht mit „noch ein paar Vektoren“. Zuerst das Schichtmodell verlässlich laufen lassen, dann entscheiden ob Daten auf lokalem SQLite bleiben oder auf einen Team-Knoten wandern – das erleichtert iOS-CI, MCP-Tools oder größere Modelle downstream deutlich.